1. Scheduling archive log send and apply
When scheduling Standby there are a few key factors to be taken into consideration such as the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) of your environment.
This is a business decision, but certain factors play a key role. These are:
Speed of the network
Activity on the database
Speed of the disks
The compression method is chosen and CPU power to compress and uncompress archive log files.
A well-recommended time frame is to schedule Dbvisit Standby every 5-15 minutes on both the primary and standby servers. This can be automatically done during the creation of the standby database itself, so as soon the standby is created the scheduling kicks off and archvielogs are sent from primary to standby and then its applied on standby automatically.
Shutting down the dbvagentmanager on primary also stops the automated standby update schedules. The archivelogs will not be sent from primary to standby and it will not be applied on standby when the agentmanager is down.
By default during the CSD process, this parameter is enabled and it performs archivelog shipping from primary to standby every 600 sec (10 mins)
2. Standby Update Delay
Standby Update Delay is NOT supported with applying archivelogs via RMAN (APPLY_ARCHIVE_RMAN = Y) until version 11.6
From Version 11.7 Standby update delay can be set when applying archivelogs using RMAN (APPLY_ARCHIVE_RMAN=Y)
This option can be used to specify a Delay (also known as a LAG or planned GAP) between the primary and standby database. Archive logs will be sent to the standby database as normal (based on the schedule used) but if this value is set, Dbvisit Standby will recover the standby database using an until time clause where the value specified for this parameter is deducted from the current time. The effect of this is that the Standby database is only recovered up until the current time minus this lag. For example, if you specify a value of 10 (which is a 10-minute delay), the standby database will always be recovered to the current time minus 10minutes, which if the current time is 2 pm, the standby will be recovered till 1:50 pm.
Note that the archive logs are still transferred to the standby server as normal without delay.
When this variable is greater than 0, MAX_TIMES_TRIED can no longer be relied on to alert when there are no new archives to be applied to the standby database. Use TRANSFER_LOG_GAP_THRESHOLD instead for alerting.
To turn off this delay (LAG) set this to zero
If you want to use this option to enable a delay in applying archived redo on the standby, it is required that the timezone on the Primary and Standby operating systems be exactly the same.
Changing timezones should be done with caution and it is recommended to review the Oracle documentation or contact Oracle support before making any timezone changes to a database environment.
Ideally, timezones should be configured before database creation.
By default this option is disabled. To enable this , you need to set the delay lag with number of minutes ( 1 ) and then click on set ( 2 ) to set the value. In below example we have set the value for Delay Log application for 10mins.
3. Start/Stop Database
This option can be used to start/stop the primary database and also can be used to start the standby database to read-only mode. This option can also be used to restart the standby database from read-only mode and back to recovery mode.
Below are the options available for the primary database.
( 1 ) Choose to display the status of the database
( 2 ) Actual status of the database along with any PDB and their status
( 3 ) Option not enabled as the current status of the database is Online
( 4 ) Click to stop the primary database
( 5 ) Used for restarting the primary database.
Below are the options available for standby database
( 2 ) Current status of the standby database. It is in recovery mode.
( 3 ) Option not enabled as the current status of the database is Recovering mode
( 4 ) Option used to stop the standby database.
( 5 ) This is used for restarting the standby database
( 6 ) This option is used for starting the standby database in read-only mode ( When the database is in read-only mode the archivelogs are still transferred from primary to standby)
4. Send and Apply archive logs manually
This option is used to send and apply archivelogs manually when the Automated Standby update is disabled.
4.1 Send logs from Primary to standby
4.2 Apply archive logs in standby
This option can be seen only when an automated standby update is disabled or when the standby update delay is set.
5. Advanced options
There are five major operations that can be performed using the advanced options. Lets see these options one by one.
5.1 Edit DDC File
This feature can be only used with oracle configuration where there is a number of settings can be changed directly here. Changing these settings can have drastic and potentially catastrophic effects on the databases. Please make changes only when you are absolutely confident or check with the dbvisit support team.
For example, you can change the settings for archivelog and transfer log gap threshold for notification and trace file management settings. The option to use RMAN for applying archivelogs can also be done by editing the settings.
5.2 View Detailed Log Gap Report
This option provides a report on the detailed log gap between standby and primary.
In the above example, the current source sequence# indicates the current online redolog that is yet to be archived. The archived source sequence is the archivelog that is being transferred from primary to standby and Destination recovery sequence is the archive log that is needed for recovery.
The Time lag is the difference in time between standby and primary.
Transfer log gap is the number of archivelogs that needed to be transferred from primary to standby
Archive log gap is the number of archivelog that are required to be applied on the standby database
5.3 Recreate Standby Control File
Using this action, you can resolve problems with a corrupt/malformed Standby control file by replacing it from the Source Host.
NOTE: Initiating this action ( 1 ) will restart the standby database, and thus may take some time.
5.4 Refresh One Data File
This action allows you to refresh a single database backup file, from Source to Destination. This can be extremely useful in case a single file was corrupted during transfer, and you do not have the time or network resources to perform the entire backup process again.You will need to know the file number that you want to refresh/replace. Press Start ( 4 ) to start the data file refresh process.
( 1 ) File Number: This is a mandatory field to provide the datafile number. This can be obtained from v$datafile (file# column) or dba_data_files (file_id column)
( 2 ) File Source(optional): The source location where the datafile backup can be taken. By default, the location is $DBVISIT_BASE/standby/tmp directory. It is recommended to provide a location where there is enough space available in case the datafile size is huge.
( 3 ) File Destination(optional): The destination location where the datafile backup is transferred to. By default, the location is $DBVISIT_BASE/standby/tmp directory. It is recommended to provide a location where there is enough space available in case the datafile size is huge.
5.5 Send One Log File
This action allows you to re-send a single archive log file, most frequently use in cases of data corruption. Enter the desired Sequence ( 1 ) and Thread ( 2 ) numbers, and initiate by clicking Start ( 3 ).
6. Remove Configuration
This option is used to completely remove the configuration from the control center. Once the configuration is removed by clicking Yes. The configuration and all the configuration files and repositories associated to this configuration is removed. You have to recreate it fresh if you want to get the configuration back. This does not drop or disturb your Primary or Standby database and also does not remove the archivelogs in the standby database as well.
7. Create Support Package
One of the most important aspects of troubleshooting any issues pertaining to dbvisit is the creation of a support package. Support packages is useful for the support team to investigate and troubleshoot issues and also avoids the need to go back and forth with the customer as the support package has all the necessary files required by the support team. A support package can be created in three different ways.
The support package can be created both from primary and standby , but this will collect all the necessary files from both the environments
You can create a support package by providing specific PID or tracefile Name.
In the below example. You can directly create a support package by clicking on Create support package ( 1 ) or using the PID for the failing process ( 2 ) or using the tracefile ( 3 ). It is recommended to create the support package from the server the task failed. In the below case the server is tahi ( The primary database server).
Comments