Smart Database Technology

Dbvisit log gap report

Dbvisit can report on the difference between the primary and the standby database. This is done with the Dbvisit log gap report. To run the Dbvisit log gap report, run Dbvisit as follows on the primary server:

dbvisit11[/usr/local/dbvisit]> dbvisit -i w120n
=============================================================
Dbvisit Standby Database Technology
dbvisit started on dbvisit11: Mon May 24 10:08:35 2010
=============================================================

Contacting Standby Database w120n on dbvisit12...
Last standby sequence obtained (1159) for thread 1.

Dbvisit log gap report for w120n at 201005241008 (thread 1):
-------------------------------------------------------------
Standby database on dbvisit12 is at sequence: 1159.
Primary database on dbvisit11 is at log sequence: 1160.
Primary database on dbvisit11 is at archived log sequence: 1159.
Dbvisit last transfer log sequence: 1159.
Dbvisit last transfer at: 201005240949.

Archive log gap for w120n:  0.
Transfer log gap for w120n: 0.

=============================================================
dbvisit ended on dbvisit11
=============================================================

The report displays the following 2 key values:

• Archive log gap which is the difference between the last archived sequence on the primary and the last applied sequence on the standby database. The archive log gap should be near 0 (except when APPLY_DELAY_LAG_MINUTES is used).
• Transfer log gap which is the difference between the last archived sequence on the primary and the last sequence transferred to the standby server. The transfer log gap should be near 0.

The most important value is the Transfer log gap. This value represents your DR exposure. Having this value near 0 means all the available log files have been transferred to the standby server. They may not have been applied to the standby database, but they are queued up and ready to be applied.

The Dbvisit log gap report also:

• Emails the report to the user specified by the ADMINS email.
• Inserts the information into the Dbvisit repository to be used for trend analysis reporting purposes.

It is recommended to schedule the Dbvisit gap report every hour. This reporting is non-intrusive. No checkpoints are performed and no logs are transferred.

Adding or dropping redo logs to the standby database

If adding redo logs groups or redo logs members to the primary database, what should be done on the standby database?

To add normal redo logs (not standby redo logs) to a primary database, the new redo logs definitions must also be added to the standby database.

A standby database does not have redo logs so they cannot be added with the same SQL (ALTER DATABASE ADD STANDBY LOGFILE) commands as on the primary database. A standby database will only have redo logs when the standby database is activated to become a primary database. The activation process will create the redo logs.

The redo log information is held in the controlfile information on the primary database, so we can replace the standby controlfile with a new controlfile to automatically have the new redo log information available on the standby database.

This can be done in Dbvisit with the following command:

dbv_functions -Q database

Where database is your database name. This command is only run on the primary server.

This command will:

• Shutdown the standby database (It will not shutdown the primary database)
• Recreate the standby controlfile on standby server from the controlfile on the primary server.
• Restart the standby database.

Notes:

1. Ensure that the standby database is up to date before running this command.
2. The standby database must have the same structure as the primary database. If this is not the case, then the controlfile information has to be updated on the standby database once the controlfile has been replaced with the command:

   SQL> alter database rename file 'x' to 'y';

   Each datafile or redo file that is in a different location to the primary has to be renamed.

Dbvisit by default will send an email notification everytime that it is run on the primary and standby server. This is useful during the testing phase so that you get a sense of how Dbvisit is working.

However after the testing phase you only want to be notified by Dbvisit if there is an error or a threshold has been exceeded.
This can be easily done by setting the SUCCESSMAIL=No in the Dbvisit Database Configuration (DDC) file.

For example say your database is called w120n. Your DDC file will be called dbv_w120n.env.
Edit this file with any text editor on the primary server only:

[40 Mail Settings]
MAILCFG_MAIL_CLIENT = dbvisit
SUCCESSMAIL = No
SUCCESSMAIL_DR = No
...

Set both SUCCESSMAIL=No and SUCCESSMAIL_DR=No.
This will ensure Dbvisit will only email when there is an error or an alert on both the primary and standby servers.

Dbvisit will continue to send a heartbeat every day to ensure the emailing functionality is working.

The DDC file contains all the Dbvisit configurational settings. For each setting there is also an explanation into the function of the setting. The DDC should only be updated on the primary server. The next time Dbvisit is run on the primary server, it will automatically copy over the DDC file to the standby server if it detects an update.

We have released Dbvisit 5.2.26.

New features:

1. SOURCE and DESTINATION host name variables are now not case sensitive for Windows.
2. Display a message “please wait” to the user to indicate that Dbvisit may take some time to delete old archive files when running AMM (Archive Management Module) on the primary server.
3. Improve the ability to obtain the standby database sequence when the standby database sequence is 1.
4. Add message to SUCCESSMAIL emails on how to turn off success mails and only email on alerts.
5. Add option to use existing pfile/spfile on standby database during standby database creation.

Fixes:

1. Capture more information when another instance of Dbvisit is running on Windows to ensure it can be started or not.
2. During creation of standby database on Windows, Dbvisit may error when COMPRESS variable is set to ssh in a DDC file – Fixed
3. Dbvisit may error with the primary and the standby databases having redo logs with the same names under different logfile group numbers during Graceful Switchover – Fixed
4. In rare cases Dbvisit may error when trying to clean up trace files if a file has already been deleted by another dbvisit process running at the same time – Fixed.
5. When the user renames oracle init parameters while creating standby database, Dbvisit edits both standby pfile and spfile. If the standby database uses spfile, only spfile should be edited not pfile – Fixed.
6. Dbvisit does not capture ORA-12638 error message – Fixed.
7. Make the global variable PFILE non case sensitive for Windows while creating a standby database
8. While checking oracle database parameters pointing to ASM locations on primary when creating a standby database, dbvisit considers all parameters values that contain symbol + to be ASM locations which is not always the case – Fixed
9. In some cases fuser incorrectly reports file in use on HP-UX.
10. Remove REMOTE_LISTENER parameter from init.ora when creating standby database.

Dbvisit 5.2.26 can be downloaded from our website. Please see the README.txt file included in the download for upgrade instructions.