This chapter contains procedures to follow when you need to apply an application patch or upgrade and there is an active replication configuration. These procedures apply to Oracle databases.
This chapter contains procedures to follow when you need to apply an application patch or upgrade and there is an active replication configuration. These procedures apply to Oracle databases.
Review the following topics before you patch or upgrade an application on a system where SharePlex replication is active.
There are different procedures for applying an application patch or upgrade to an Oracle database while replication is in process. Which one to choose depends on what changes the patch or upgrade makes.
Changes made by the patch/upgrade | Steps to take |
---|---|
If the patch/upgrade applies DDL that is not supported by SharePlex. For details on the DDL that SharePlex supports, see the SharePlexSharePlex Release Notes. |
Manually apply the patch/upgrade to the source and target by following either of these procedures: |
If the patch/upgrade does any of the following:
|
Manually apply the patch/upgrade to the source, then allow SharePlex to replicate the changes to the target. Follow this procedure: Apply patch to source and replicate it to the target Note: Because this procedure assumes that SharePlex can replicate all of the changes that the patch or upgrade applies, the patch/upgrade is not applied to the target. |
A patch or upgrade can make changes that affect the column partitions of vertically partitioned replication in your configuration file. Take the following into account when you perform this procedure.
If the patch or upgrade does this to a table: | Do this: |
---|---|
Adds columns that do not satisfy the column partition of the table | (Optional) Drop the columns from the target table after the patch or upgrade is applied. |
Adds columns that need to be in the column partition of the table | Add those columns to the source and target column partition lists in the configuration file. |
Drops columns that are part of the column partition of the table |
Remove those columns from the source and target column partition lists in the configuration file. |
Changes the name of a column that is in the column partition of a table | Change the column name in the source and target column partition lists in the configuration file. |
For more information, see Configure vertically partitioned replication.
In these procedures, the "source" system is one of the following:
In these procedures, the "target" system is one of the following:
In this procedure, the SharePlex commands in the procedure apply to all sp_cop instances that apply to the replication strategy you are using (for example, all sp_cop processes on a target in consolidated replication).
Oracle on all supported platforms
Use this procedure if the patch or upgrade makes DDL changes of a type not replicated by SharePlex. For a list of objects for which DDL is supported, see the SharePlex Release Notes.
Use this procedure to run an Oracle hot backup to copy patches or upgrades from the source system to the target system, instead of applying the patch or upgrade directly on the target system. This is useful if the patch or upgrade makes extensive changes that are of the type(s) not supported by SharePlex replication, or if you are unsure of what it does.
With this procedure, you can keep the configuration file active on the source system. You use the reconcile command to identify and eliminate the following:
On the source system, flush the data to the target system. This command stops Post and places a marker in the data stream that establishes a synchronization point between source and target data.
sp_ctrl> flush datasource
where: datasource is the datasource of the source instance, for example o.oraA.
[If the patch/upgrade adds objects that must be replicated] Edit the configuration file as follows (do not deactivate it). The patch or upgrade may have affected column partitions or column conditions in partitioned replication. For more information, see Change an active configuration file.
Copy the configuration file.
sp_ctrl> copy config filename to newname
Edit the copy.
sp_ctrl> edit config newname
Save the file.
Do one of the following:
If you added objects in the previous step, activate the new configuration file.
sp_ctrl> activate config newname
If you did not make any changes to the original configuration file, activate that one.
sp_ctrl> activate config filename
On the source, switch log files and make a note of the highest archive-log sequence number.
On-premises database:
svrmgr1> alter system switch logfile;
Amazon RDS database:
Use Amazon RDS procedure rdsadmin.rdsadmin_util.switch_logfile.
On the target system, issue the reconcile command using the sequence number of the log that you noted previously. If you are using named post queues, issue the command for each one. If you do not know the queue names, issue the qstatus command first.
sp_ctrl> qstatus
sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number
Example: reconcile queue SysA for o.oraA-o.oraA seq 1234
Note: The reconcile process retains control of sp_ctrl until it is finished.
On the target system, perform any cleanup required by partitioned replication.
On the target system, start Post.
sp_ctrl> start post
The two instances are now in synchronization, and SharePlex resumes replication.
Oracle on all supported platforms
Use this procedure if the patch or upgrade makes DDL changes of a type not replicated by SharePlex. For a list of objects for which DDL is supported, see the SharePlex Release Notes.
Use this procedure to apply an application patch or upgrade if it includes changes to the database that are not replicated by SharePlex and you can stop user access to the source database to deactivate and reactivate the configuration file. It requires deactivation of the configuration file so that SharePlex can rebuild its object information to incorporate the changes that the patch or upgrade applied. When you reactivate the configuration, SharePlex will re-analyze all of the objects again. You can allow users to access the source data while the patch or upgrade is applied to the target system.
On the source system, flush the data to the target system. This command stops Post and places a marker in the data stream that establishes a synchronization point between source and target data.
sp_ctrl> flush datasource
where: datasource is the datasource of the source instance, for example o.oraA.
On the source system, deactivate the configuration.
sp_ctrl> deactivate config filename
[If the patch/upgrade adds objects that must be replicated] On the source system, edit the configuration file, including making any changes to column partitions or column conditions if using partitioned replication. For more information, see Change an active configuration file.
sp_ctrl> edit config filename
On the source system, activate the configuration file.
sp_ctrl> activate config filename
On the target system, start Post.
sp_ctrl> start post
The two instances are now in synchronization, and SharePlex resumes replication.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center