How do I keep the standby database behind the primary by a certain time period? This is useful for us so that changes caused by corruption (or user error) do not flow through immediately to the standby side, and we can use the standby database as a means to reverse this impact.
If you do want to implement a delay in archive logs being applied to the standby database you can specify the
APPLY_DELAY_LAG_MINUTES value in the DDC configuration file. If you set this to, for example, 60 the standby database will only apply changes up to the last 60 minutes.
The archive logs will still be transferred to the standby, but on the standby there will always be a 60 minute delay (LAG). Meaning the apply process will apply the logs, but will keep a 60min gap.
Below is an extract from the configuration file where this parameter can be set:
Default value: 0
This parameter 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 send 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.
Example if you specify a value of 10 (which is 10 minute delay), the standby database will always be recovered to the current time minus 10minutes, which if the current time is 2pm, the standby will be recovered till 1:50pm.
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 of this delay (LAG) set: APPLY_DELAY_LAG_MINUTES=0
Important If you want to use this option to enable a delay in applying archived redo on the standby, it is required that 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. Example:
To set a 100minute delay, set the following value: APPLY_DELAY_LAG_MINUTES=100
Mike Donovan July 07, 2013 23:47