The synchronziation of standby database is wholly managed by Dbvisit StandbyMP Automated Standby Update (ASU). It is by default enabled after the CSD task completes. It is the only module needed to keep your standby database in sync.
The ASU includes following tasks:
forcing online log switch on primary (generating new archivedlog)
archivelog transfer from primary
archivelog apply on standby
ASU can be manually disabled or enabled and user can specify interval indicating how frequently should the force online log switch occur.
1. ASU status and modification
ASU status can be checked by mouse-over in the dbvserver DASHBOARD configuration ASU icon:
ASU status can be modified by selectin “Automated Standby Update” from the ACTIONS right pane:
You are able to enable / disable ASU (1) and modify its interval (2):
You must click on Set (3) to apply any modifications you made.
2. Checking Standby database gap
In Standard edition, it is not possible to rely in v$ views to determine standby database lag. Sqlplus command archive log list on standby will not have any relevant information either.
Standby database gap (or how much it is lagging behind the primary) can be done in two ways:
Information from Last applied Archivelog Job
Log gap report
Note that both values are independent on each other.
A. Information from Last applied Archivelog Job
This information is displayed as a small information below the configuration name:
It is updated automatically by the apply job.
B. Log Gap Report
User has the possibility to run log gap report, which will check the recovery status of standby database. This report can bne initiated by running “View Detailed Log gap Report” (1) from the ACTIONS right pane:
The standby database is considered in sync when Current Source Sequence (2) is the same as Destination Next Required Recovery Sequence (3)
Log gap report is an expensive operation, because it requires running SQL in primary and standby database with network roundtrip. When used for monitoring, we recommend interval of at least 2-3 minutes between individual runs.
3. Manually transferring and applying single archiveglog file
This task is very useful when in doubt about synchronization status and for testing that individual ASU synchronization jobs work without any issues.
ASU must be disabled prior to performing this operation, otherwise ASU transfer and apply jobs can conflict with manual jobs
A. Transferring archivelog from primary
Transfer of single archivelog can be initiated from the ACTIONS pane:
New job is created and should complete successfully:
You will be able to view job details:
B. Applying transferred archivelog on standby
Apply of single archivelog can be initiated from ACTIONS pane as well:
Apply Logs option is visible only if transfer completed successfuly.
As with transfer, there will be an apply job and you can also check its details:
