Smart Database Technology

We have just released Dbvisit 5.2.18 for all platforms.

This release incorporates a number of suggestions from our customers, which will improve usability of the software. We would like to thank those of you who have made suggestions, and we greatly appreciate your feedback.

From this release forward, all Dbvisit production releases will be an even release number (18, 20, 22, etc) and the development or stage releases will be an uneven number (17, 19, 21 etc).
So 5.2.18 is the production release of 5.2.17.

Some of the highlights in this release are:

• Allow for multiple archive log destinations to be managed by Dbvisit.
• Archive logs can now be managed by specifying partial days. For example keep the archive log files for 3.5 days.
• Improve remote checksum processing. If remote checksum process fails, then only checksum process is repeated, not the whole transfer process.
• Allow for Database which has been recovered with point-in-time recovery with resetlogs where SCN may be lower than current SCN.

The full details of this release are:
New features:

1. Allow for multiple archive log destinations in AMM (Archive Management Module) processing (AMM_PROCESS_MULTIPLE_ARCH_DEST).
2. Improve restartability of standby database creation. Standby Database is now shutdown after all the standby database parameters are obtained.
3. Graceful switchover synchronisation process now includes retries if there are network issues.
4. Improve remote checksum processing. If remote checksum process fails, then only checksum process is repeated, not the whole transfer process.
5. Allow for decimal numbers for DAYS_TO_KEEP_ARCHSOURCE and DAYS_TO_KEEP_ARCHDEST. For example 3.5 days.
6. Detect Oracle XE admin location for Linux.
7. Check for Standby archive log destination during graceful switchover. If location does not exist, then exit as switchover will not be successful.
8. Reduce number of trace file that Dbvisit keeps on server:
   NUM_TRACE_TO_KEEP = 100, DAYS_TO_KEEP_TRACE = 10

9. Check that Database is in archivelog mode.
10. Allow for Database which has been recovered with point-in-time recovery with resetlogs where SCN may be lower than current SCN.
11. Allow for “-” in the DDC file. Example: dbv_prod-vm2.env

Fixes:

1. Improve duplicate archive log handling for OMF files. Include a unique identifier to ensure the same file does not get renamed more than once.
2. Add check for ORA-00342: archived log does not have expected resetlogs SCN.
3. If same archive log is needed more than once by standby database for non RAC, ensure archive log can be compressed.
4. Allow for multiple NLS_LANGUAGE setting during RAC processing.
5. Add 24hour time clock to trace file.
6. Fixed calling AMM from dbv_functions -A
7. Improve error message in Windows if during standby database creation the standby database fails to start.
8. Fixed issue if first_change# is displayed as float, then graceful switchover was not successful.
9. Allow for different instance_name to database_name for graceful switchover.
10. Notify if create standby database process is not able to remove file on standby database.
11. Allow for %d log_archive_format.
12. Check and report if “ORA-00332: archived log is too small” is found.

Dbvisit can be downloaded from our website http://www.dbvisit.com.

During recent testing, a datafile from one of our development databases was deleted. At the same time the same datafile was also deleted from the standby database. So this meant that our development primary and standby databases were no longer available.

However Dbvisit came to our rescue, and the functionality we have been recommending to our customers for a number of years now actually saved us! We employed Dbvisit to successfully recreate our primary and standby databases.

We have the following development servers:
Dev servers 1
dbvisit11 – primary database server
dbvisit12 – standby database server for dbvisit11

Dev servers 2
avisit31 – primary database server
avisit32 – standby database server for avisit31

Dev servers 2 are a clone of dev servers 1 with the same databases.
Due to the deletetion of the datafiles, the databases on dbvisit11 and dbvisit12 were gone.

Here is what we did to get the databases back on dbvisit11 and dbvisit12:

1. Logged onto avisit32 and used dbvisit_setup to automatically create a new standby database on dbvisit12.
2. Activated the standby database on dbvisit12 to become a new primary database.
3. Used dbvisit_setup on dbvisit12 to create a new standby database on dbvisit11.
4. Used graceful switchover to switch the roles between dbvisit12 and dbvisit11.

And so in 4 easy steps we had our databases back on our Dev servers 1: dbvisit11 (primary database) and dbvisit12 (standby database).

It is very rewarding to be able to use our own technology to recover a primary and standby database.