To ensure the primary and standby databases are up to date, you can run the Log Gap Report using the following command from the primary database server:
./dbvctl -d <DDC> -i |
Important: In the example below the line numbers indicated below on the left with "1. -->", "2. -->" etc is used only for documentation purpose to help explain the report and is not included in the actual report
[oracle@dbvel71 standby]$ ./dbvctl -d orcl -i ============================================================= DDbvisit Standby Database Technology (10.0.0RC_24_g94ba1d85) (pid 18054) dbvctl started on dbvel71: Thu Dec 3 13:22:54 2020 ============================================================= Dbvisit Standby log gap report for orcl at 202012031322: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- 1. -->Source 5546142 2020-12-03:13:22:53 +13:00 2. -->Destination 5546129 2020-12-03:13:22:24 +13:00 3. -->Standby database time lag (DAYS-HH:MI:SS): +00:00:29 Report for Thread 1 ------------------- SOURCE 4. -->Current Sequence 373 5. -->Last Archived Sequence 372 6. -->Last Transferred Sequence 372 7. -->Last Transferred Timestamp 2020-12-03 13:22:28 DESTINATION Next Required Recovery Sequence 373 9. -->Transfer Log Gap 0 10. -->Apply Log Gap 0 ============================================================= dbvctl ended on dbvel71: Thu Dec 3 13:22:56 2020 ============================================================= |
The report line numbers are explained in more detail below:
The log gap report is divided into three parts.
The First part being the table where it provides information
The second part of the log gap report provides information about the source/primary database
The third part of the log gap report provided information about the destination/standby database
To ensure the primary and standby databases are up to date, you can run the Log Gap Report using the following command from the primary database server:
./dbvctl -d <DDC> -i |
Below is an example of running a Log Gap report in a Single Instance Primary environment.
Information for only one thread will be shown.
[oracle@dbvel71 standby]$ ./dbvctl -d orcl -i ============================================================= Dbvisit Standby Database Technology (10.0.0RC_24_g94ba1d85) (pid 18054) dbvctl started on dbvel71: Thu Dec 3 13:22:54 2020 ============================================================= Dbvisit Standby log gap report for orcl at 202012031322: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 5546142 2020-12-03:13:22:53 +13:00 Destination 5546129 2020-12-03:13:22:24 +13:00 Standby database time lag (DAYS-HH:MI:SS): +00:00:29 Report for Thread 1 ------------------- SOURCE Current Sequence 373 Last Archived Sequence 372 Last Transferred Sequence 372 Last Transferred Timestamp 2020-12-03 13:22:28 DESTINATION Next Required Recovery Sequence 373 Transfer Log Gap 0 Apply Log Gap 0 ============================================================= dbvctl ended on dbvel71: Thu Dec 3 13:22:56 2020 ============================================================= |
Running the log gap report in an Oracle RAC environment will list information about all the threads in the Oracle RAC cluster.
The command to be executed is the same, but the result as you can see below will include information for all threads.
oracle@kiwi81[/acfs/dbvisit/standby]: ./dbvctl -d MYDEV -i ============================================================= Dbvisit Standby Database Technology (9.0.0_1383_g276092d5) (pid 27344) dbvctl started on kiwi812-vip: Fri May 24 13:15:58 2019 ============================================================= Dbvisit Standby log gap report for MYDEV at 201905241315: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 1115263 2019-05-24:13:16:50 +12:00 Destination 1115055 2019-05-24:13:12:50 +12:00 Standby database time lag (DAYS-HH:MI:SS): +00:04:00 Report for Thread 1 ------------------- SOURCE Current Sequence 13 Last Archived Sequence 12 Last Transferred Sequence 12 Last Transferred Timestamp 2019-05-24 13:13:16 DESTINATION Recovery Sequence 12 Transfer Log Gap 0 Apply Log Gap 1 Report for Thread 2 ------------------- SOURCE Current Sequence 5 Last Archived Sequence 4 Last Transferred Sequence 4 Last Transferred Timestamp 2019-05-24 13:13:30 DESTINATION Recovery Sequence 5 Transfer Log Gap 0 Apply Log Gap 0 ============================================================= dbvctl ended on kiwi812-vip: Fri May 24 13:17:24 2019 ============================================================= |
This section provides you with an overview of how you can run the Log Gap Report using the Central Console (GUI).
Step 1: Navigate to the Database Actions Menu option as shown below [1]
Step 2: For the DDC in question (DEV in this example), click on the first icon highlighted (two pages on top of each other) as shown below [1]. The [ 2] shows the precise time gap between source and destination. This will start the log gap report process.
Step 3: Review the log gap report as shown below.
To reduce the Time, Transfer or Archive Log gap, you need to enable the shipping and applying of logs
From Dbvisit standby 9.0.14, there are new improvements in task actions, statuses and flexibility. Below are the changes
All active tasks now come with a terminate task button. When you press this button on any active task, it would kill the task.
If a Task is terminated at any time, either by using the new button above or manually from the CLI, it will now be reported in the GUI as follows and Signal 9 is what is used for the Terminate button, if the user can specify a different signal when manually killing a Task, it will display here accordingly. It should no longer be possible to have “floating” Tasks that are actually no longer available.
If a task suddenly stops being updated for any reason, Dbvisit central console detects this and displays like below
Note the new orange Task icon type - this is used for Stuck tasks. Any stuck Task is force-refreshed every 10 seconds, e.g. if it wasn’t updating due to a network fault, it will again begin updating automatically. Note also that the Task is not greyed-out, because we’re assuming at this point that it is still active, we just can’t see it.
If you click on a Task that is marked as not updating, you will see the following details:
Note the warning up top, and the fact that the Terminate Task button is gone - you cannot Terminate stuck Tasks from the GUI, since it is stuck probably means we can’t get through to dbvagent. |
If dbvagent is shut down in any way (including a crash) while a Task is active, the Task process itself will most likely continue (i.e. the dbvctl execution). However, all Task progress after the Agent crashes is lost. This means that anything that happens after an Agent crash is unavailable to us. Thus, we introduce a new Task type: the Incomplete Information Task.
While the Agent is down, any active Task from it can only be reported as Stuck (as above), because until the Agent becomes available again we cannot access any information about the Task at all. However, once dbvagent comes back (e.g. is manually restarted), we can now detect that a particular Task has incomplete information, i.e. we don’t know how it ended. When this happens, the Task is displayed like this:
If you click on this Task, you will see this:
Note the new orange border, unique to this Task type, and the warning message at the top. All available information prior to the Agent crash/termination is now preserved. Note also the final line, indicating the point at which the Agent went down, after which no progress information could be captured.