1. STREAMS failover and resynchronization
LCG 3D - Database Administrator CNAF
12 June 2007
Eva Dafonte Perez (CERN)

2. Agenda SCN numbers Overview Recovery on a destination Database
Streams synchronization example
Streams failover and resynchronization 2

3. SCN numbers Overview SCN = System Change Number
FIRST_SCN: lowest SCN in the redo log from which a capture process can capture changes
START_SCN: SCN from which the capture process will start to capture changes
REQUIRED_CHECKPOINT_SCN: Lowest checkpoint SCN for which the capture process requires redo information
MAX_CHECKPOINT_SCN: SCN at which the last checkpoint was taken by the capture process
CAPTURED_SCN: most recent change scanned in the redo log
OLDEST_MESSAGE_NUMBER: earliest SCN that might need to be re-applied
used for the synchronization
first SCN
start SCN
required checkpoint SCN
maximum checkpoint SCN
Captured SCN and Applied SCN
The captured SCN is the SCN that corresponds to the most recent change scanned in the redo log by a capture process. The applied SCN for a capture process is the SCN of the most recent event dequeued by the relevant apply processes. All events lower than this SCN have been dequeued by all apply processes that apply changes captured by the capture process. The applied SCN for a capture process is equivalent to the low-watermark SCN for an apply process that applies changes captured by the capture process.
First SCN
The first SCN is the lowest SCN in the redo log from which a capture process can capture changes. If you specify a first SCN during capture process creation, then the database must be able to access redo log information from the SCN specified and higher.
The DBMS_CAPTURE_ADM.BUILD procedure extracts the source database data dictionary to the redo log. When you create a capture process, you can specify a first SCN that corresponds to this data dictionary build in the redo log. Specifically, the first SCN for the capture process being created can be set to any value returned by the following query:
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT
COLUMN NAME HEADING 'Log File Name' FORMAT A50
SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES';
The value returned for the NAME column is the name of the redo log file that contains the SCN corresponding to the first SCN. This redo log file, and subsequent redo log files, must be available to the capture process. If this query returns multiple distinct values for FIRST_CHANGE#, then the DBMS_CAPTURE_ADM.BUILD procedure has been run more than once on the source database. In this case, choose the first SCN value that is most appropriate for the capture process you are creating.
In some cases, the DBMS_CAPTURE_ADM.BUILD procedure is run automatically when a capture process is created. When this happens, the first SCN for the capture process corresponds to this data dictionary build.
Start SCN
The start SCN is the SCN from which a capture process begins to capture changes. You can specify a start SCN that is different than the first SCN during capture process creation, or you can alter a capture process to set its start SCN. The start CN does not need to be modified for normal operation of a capture process.
Start SCN Must Be Greater Than or Equal to First SCN
If you specify a start SCN when you create or alter a capture process, then the start SCN specified must be greater than or equal to the first SCN for the capture process. A capture process always scans any unscanned redo log records that have higher SCN values than the first SCN, even if the redo log records have lower SCN values than the start SCN. So, if you specify a start SCN that is greater than the first SCN, then the capture process may scan redo log records for which it cannot capture changes, because these redo log records have a lower SCN than the start SCN.
Scanning redo log records before the start SCN should be avoided if possible because it may take some time. Therefore, Oracle Corporation recommends that the difference between the first SCN and start SCN be as small as possible during capture process creation to keep the initial capture process startup time to a minimum.
Capture Process Checkpoints
At regular intervals, a capture process tries to record a checkpoint. At a checkpoint, the capture process records its current state persistently in the data dictionary of the database running the capture process.
The required checkpoint SCN is the lowest checkpoint SCN for which a capture process requires redo information. The redo log file that contains the required checkpoint SCN, and all subsequent redo log files, must be available to the capture process. If a capture process is stopped and restarted, then it starts scanning the redo log from the SCN that corresponds to its required checkpoint SCN. The required checkpoint SCN is important for recovery if a database stops unexpectedly. Also, if the first SCN is reset for a capture process, then it must be set to a value that is less than or equal to the required checkpoint SCN for the captured process. You can determine the required checkpoint SCN for a capture process by querying the REQUIRED_CHECKPOINT_SCN column in the DBA_CAPTURE data dictionary view.
Also, the SCN value that corresponds to the last checkpoint recorded by a capture process is the maximum checkpoint SCN. If you create a capture process that captures changes from a source database, and other capture processes already exist which capture changes from the same source database, then the maximum checkpoint SCNs of the existing capture processes can help you decide whether the new capture process should create a new LogMiner data dictionary or share one of the existing LogMiner data dictionaries. You can determine the maximum checkpoint SCN for a capture process by querying the MAX_CHECKPOINT_SCN column in the DBA_CAPTURE data dictionary view.
NULL First SCN and Non-NULL Start SCN for a Downstream Capture Process
If the use_database_link parameter is set to true during capture process creation, then the database link is used to obtain the current SCN of the source database. In this case, the new capture process creates a new LogMiner data dictionary if either one of the following conditions is true:
* There is no existing capture process that captures changes to the source database at the downstream database, and the specified value for the start_scn parameter is greater than or equal to the current SCN for the source database.
* There are existing capture processes that capture changes to the source database at the downstream database, but none of the capture processes have taken a checkpoint yet, and the specified value for the start_scn parameter is greater than or equal to the current SCN for the source database.
In either of these cases, the BUILD procedure in the DBMS_CAPTURE_ADM package is run during capture process creation. The first time you start the new capture process, it uses the resulting build of the source data dictionary in the redo log files copied to the downstream database to create a LogMiner data dictionary. Here, the first SCN for the new capture process corresponds to the SCN of the data dictionary build.
However, if there is at least one existing capture process that has taken a checkpoint and captures changes to the source database at the downstream database, then the new capture process shares an existing LogMiner data dictionary with one or more of these existing capture processes, regardless of the use_database_link parameter setting. In this case, one of these existing capture processes with a first SCN that is lower than or equal to the specified start SCN must have been started successfully at least once.
Streams failover and resynchronization 3

4. Recovery on destination
Point-in-time recovery on the destination database
re-apply captured changes that had already being applied
split the streams setup for the recovered destination
create new capture process and new propagation that propagates changes only to the recovered destination
apply changes from the last SCN applied
other destination databases not impacted
old archived logs may be needed
Streams failover and resynchronization 4

5. Recovery on destination
This method cannot be used if any of the following conditions are true:
the archived log files that contain the start SCN are not longer available
the oldest message number is lower than the first SCN
Maximum checkpoint SCN
first SCN
start SCN
required checkpoint SCN
maximum checkpoint SCN
first SCN
start SCN
oldest_message_number
Streams failover and resynchronization 5

6. point-in-time recovery
Resynchronization example
CERN
SITE 1
SITE 2
point-in-time recovery
# Dropped a datafile and recorded the time
09:40:12 datafile dropped
# Stopped the database
09:40:18 SQL> shutdown immediate;
# Connected to RMAN, recovery catalogue and target database
RMAN> RESTORE DATABASE UNTIL TIME "TO_DATE('30-AUG :30','DD-MON-YYYY HH24:MI')";
RMAN> RECOVER DATABASE UNTIL TIME "TO_DATE('30-AUG :30','DD-MON-YYYY HH24:MI')";
# Restart database to make sure OK
Streams failover and resynchronization 6

7. Resynchronization example
## select oldest_message_number from dba_apply_progress:
oldest SCN
oldest SCN >> captured SCN
propagation jobs
SITE 1
LCR
propagation jobs
SITE 1
SITE 2
SITE 2
SITE 1
propagation jobs
capture process
SITE 2
RECOVERY x
SITE 2
start SCN = oldest SCN
new capture process x
propagation job
SITE 2
propagation job
SITE 2
Streams failover and resynchronization 7

8. Questions & Answers Streams Replication Administrator's Guide
9 Managing Capture, Propagation, and Apply
Performing Database Point-in-Time Recovery in a Streams Environment
Streams failover and resynchronization 8