In a planned failover of database activity to a secondary Oracle instance, you can quickly move SharePlex to the secondary system. While users continue their transactions on that system, SharePlex captures their changes and stores them until the primary system is back online and activity is moved back to that system.
Oracle database on Unix or Linux
This procedure is divided into logical segments. Follow them in the order presented. Do not shut down the primary instance until prompted in the procedure.
On the primary system, flush the data in the queues to the secondary system. This command stops Post on the secondary system and places a marker in the data stream to establish a synchronization point between the primary and secondary data.
sp_ctrl> flush datasource
where: datasource is the datasource specification of the primary Oracle instance, for example o.OraA.
On the secondary system, verify that Post stopped. (Continue to issue this command until it shows that Post stopped.)
sp_ctrl> status
On the primary system, verify that there are no messages in the capture and export queues. The Number of Messages and the Backlog (messages) fields must be 0.
sp_ctrl> qstatus
On the secondary system, verify that there are no messages in the post queue. The Number of Messages and the Backlog (messages) fields must be 0.
sp_ctrl> qstatus
On the primary system, shut down the Oracle instance with the abort option. Do not use the immediate option.
svrmgr1> shutdown abort
Note: This resets the sequence on the primary system to the top of the cache when the database starts.
On the secondary system, verify that Export is stopped. This prevents user changes from being replicated to the primary system until it is back online and SharePlex is ready to receive them. Stop Export if needed.
sp_ctrl> status
sp_ctrl> stop export
On the secondary system, start Export so that SharePlex sends the accumulated replicated data to the primary system.
sp_ctrl> start export
Note: SharePlex passes any sequence updates from the secondary system back to the primary system when Export starts.
On the primary system, stop Export.
sp_ctrl> stop export
On the primary system, allow Post to process the message backlog that was sent from the primary system.
On the secondary system, flush the data in the queues to the primary system.
sp_ctrl> flush datasource
where: datasource is the datasource specification of the secondary Oracle instance, for example o.OraB.
On the primary system, verify that Post stopped. (Continue to issue this command until it shows that Post stopped.)
sp_ctrl> status
On the secondary system, verify that there are no messages in the capture and export queues. The Number of Messages and the Backlog (messages) fields must be 0.
sp_ctrl> qstatus
On the primary system, verify that there are no messages in the post queue. The Number of Messages and the Backlog (messages) fields must be 0.
sp_ctrl> qstatus
On the secondary system, shut down SharePlex.
sp_ctrl> shutdown
On the secondary system, shut down the Oracle instance with the abort option. Do not use the immediate option.
svrmgr1> shutdown abort
Note: This resets the sequence on the secondary system to the top of the cache when the database starts.
On the secondary system, start the Oracle instance.
svrmgr1> startup
Note: The sequence on the secondary system is now at the top of the cache. When the next value is selected on the primary system, a new cache is acquired and is replicated to the secondary system. Now, the primary system is at the start of a cache, and the secondary system is at the top of a cache.
On the secondary system, stop Export. This prevents any accidental DML on that system from being replicated to the primary system.
sp_ctrl> stop export
On the primary system, start export.
sp_ctrl> start export
On the secondary system, start Post.
sp_ctrl> start post
Replication from the primary instance to the secondary instance is now active to keep the two databases synchronized and ready for future failover when needed.
The procedure is typically used in these situations:
To resume replication when the source, target or both have failed, there must be the following in place at the onset of replication:
The following diagram depicts a DR configuration at the onset of replication. There is a source production instance and a mirrored source DR instance that is kept current by Oracle Data Guard. Similarly, there is a production target instance and a mirrored DR target instance that is kept current by Oracle Data Guard.
Figure 2: DR configuration at the onset of replication
This example illustrates one of the potential failure/recovery scenarios, in this case where the production target instance fails. The recovery path is shown as the diagonal, orange dotted line in the DR configuration at the onset of replication diagram.
The following diagram illustrates the configuration and the names that are used in this example.
Figure 3: Normal replication and mirroring configuration
The Target PROD target fails, as represented by the red X across it in the following diagram. SharePlex can no longer replicate to Target PROD, as represented by the red X over the original replication data stream.
Because Target PROD is offline, Oracle Data Guard can no longer keep Target DR up to date. However, SharePlex can. SharePlex (SPO in the diagram) is able to resume replication from Source PROD to Target DR, thus resuming data availability.
Figure 4: Failure and recovery by SharePlex (SPO)
In this procedure you will do the following to direct SharePlex to recover replication:
Note: This procedure requires the following:
To resume replication
Note: In these instructions, the source and target systems are whichever source and target are operational after the failover.
Shut down SharePlex on the source system, if it is still running.
sp_ctrl> shutdown
On the target, start sp_cop if it is not running already.
$ /productdir/bin/sp_cop &
On the target, use the qstatus command to make certain that all of the message in the queues are posted to the target database. The command output should show 0 backlog in the post queue.
sp_ctrl> qstatus
From the command line of the target, run the show_scn utility from the bin subdirectory of the SharePlex product directory. For ORACLE_SID use the ORACLE_SID of the target database.
$ /productdir/bin/show_scn ORACLE_SID
Shut down sp_cop on the source and target.
sp_ctrl> shutdown
Run ora_cleansp on the source and target to clean out the queues.
$ /productdir/bin/ora_cleansp
Start sp_cop on the source and target.
$ /productdir/bin/sp_cop &
On the target, stop Post.
sp_ctrl> stop post
On the source, issue the activate config command with the scn option to activate the configuration. For scn_value, use the value that is shown in the output of the show_scn utility on the line that states On source activate to scn=nnnnnnn.
sp_ctrl> activate config configname scn=scn_value
Example:
sp_ctrl> activate config myconfig scn=510012416
On the target, copy the first reconcile command from the show_scn output and then execute it in sp_ctrl. Then do the same for the second reconcile command, and work your way down the list.
Example:
sp_ctrl> reconcile queue spx11 for o.ora112-o.ora112 scn 235690
sp_ctrl> reconcile queue pq1 for o.ora112-o.ora112 scn 132436
sp_ctrl> reconcile queue pq2 for o.ora112-o.ora112 scn 246843
sp_ctrl> reconcile queue pq3 for o.ora112-o.ora112 scn 123457
The reconcile command may seem stalled until new data comes in. However, the command is working.
On the target, start Post.
sp_ctrl> start post
This chapter contains instructions for making datbase changes, or performing system and software maintenance, on systems where SharePlex replication is active.
Add or change table specifications in an active replication configuration
Change Partitioned Replication
Add Oracle sequences to an active replication configuration
Remove objects from replication
Make DDL changes in an active replication configuration
Make Oracle changes that affect replication
Change the SharePlex database account
Many procedures that change an element of the replication environment will also involve changing the SharePlex configuration file. The recommended method to modify an active configuration file is to make a copy of the file first using a new file name. For example, append the date to the file name. By copying the file first, you preserve the original file in case it is needed again or you encounter a problem with the new file. By copying the file first, you also can control when to activate the new configuration file.
In most cases, activation of an edited configuration is less time-consuming than the original activation if you do not deactivate the original configuration. The activation of the new configuration automatically deactivates the original configuration, and SharePlex only needs to analyze the new, changed, and removed objects. If you deactivate the original configuration before you activate a new one, SharePlex re-analyzes all of the objects.
To change a configuration file, see Add or change objects in an active configuration.
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy