Set the SharePlex port number
Set the SharePlex Port Number
The SharePlex processes use TCP to communicate with each other between different systems and uses UDP to communicate within a system. The default TCP and UDP port numbers for SharePlex are both set to 2100 at the time of installation. For some deployments of SharePlex you may need to change the TCP or UDP port numbers.
Before selecting a port number, review the following points:
- If your replication strategy requires multiple instances of sp_cop on a system, you must set a unique port number for each one. For more information, see Run Multiple Instances of SharePlex.
- When an non-default port is required, the same number must be used for both the TCP and UDP ports, and it must be used for the TCP and UDP ports of all other instances of sp_cop that are involved in the same replication configuration. If the ports are different, sp_cop on one system cannot connect to the sp_cop on another system to send or receive messages and data.
Supported databases
All databases supported by SharePlex on all supported platforms
Set the SharePlex port on Unix and Linux systems
To set the port number on Unix and Linux systems, a SharePlex Administrator must set both the TCP and UDP port parameters in the SharePlex environment. If there is an active configuration, you will be instructed to stop access to the source objects and shut down sp_cop.
To finish setting the port in an active configuration:
-
(If using multiple variable-data directories] Export the SP_SYS_VARDIR environment variable to point to the correct variable-data directory for the port you are setting.
ksh shell:
export SP_SYS_VARDIR=/full_path_of_variable-data_directory
csh shell:
setenv SP_SYS_VARDIR=/full_path_of_variable-data_directory
-
Export the following environment variables.
ksh shell:
export SP_COP_TPORT=port
export SP_COP_UPORT=port
csh shell:
setenv SP_COP_TPORT port
setenv SP_COP_UPORT port
where: port is the new port number
- Change directories to the SharePlex product directory.
-
Start sp_cop and sp_ctrl.
Note:If you are using multiple variable-data directories, start sp_cop with the -uport option, where port is the port number that you have chosen for the variable-data directory that you exported.
./sp_cop [-uport] &
-
Run sp_ctrl.
./sp_ctrl
-
In sp_ctrl, set the following SharePlex parameters.
sp_ctrl> set param SP_COP_TPORT port
sp_ctrl> set param SP_COP_UPORT port
-
Do one of two things:
-
If there is not an active configuration, use the shutdown command in sp_ctrl to stop sp_cop. The next time you start sp_cop, the new port number takes effect.
NOTE: If you do not have an active configuration, you are finished setting the port number.
-
If there is an active configuration, continue to the next step.
-
Stop access to the replicating objects on the source system, then issue the flush command in sp_ctrl on the source system to clear the queues.
sp_ctrl> flush o.database_identifier
where: database_identifier is o. followed by the Oracle SID, TNS alias, or PDB name that SharePlex uses to connect to the source database (depends on whether the database is a regular Oracle instance, RAC, or PDB in a container database).
-
On the source system, issue the qstatus command to verify that all of the messages reached the target system.
sp_ctrl> qstatus
Continue to issue the command until the export queue is empty.
- On the target system, issue the qstatus command to verify that all of the messages were posted to the database. Continue to issue the command until the post queue is empty.
-
On the target system, issue the status command to verify that Post stopped.
sp_ctrl> status
-
Shut down SharePlex on the source and target systems.
sp_ctrl> shutdown
-
Start sp_cop on the source and target systems.
Note:If you are using multiple variable-data directories, start sp_cop with the -uport option, where port is the port number that you have chosen for the variable-data directory that you exported.
./sp_cop [-uport] &
- Run sp_ctrl on the target system.
-
Start the Post process.
sp_ctrl> start post
- Allow users to access the replicating objects.
-
Use the status command on the source and target systems to verify that all SharePlex processes are running.
sp_ctrl> status
Apply an Oracle application patch or upgrade
Apply an Oracle Application Patch or Upgrade
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.
Contents
Before you patch or upgrade an application
Review the following topics before you patch or upgrade an application on a system where SharePlex replication is active.
Which procedure to use?
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.
|
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:
Apply Patch/Upgrade to Source then Copy it to Target
Apply Patch/Upgrade to Source and Target |
|
If the patch/upgrade does any of the following:
- Performs DML changes.
- Performs supported DDL on the source system. For details on the DDL that SharePlex supports, see the SharePlexSharePlex Release Notes.
- Changes users and security on source system (other than SharePlex)
|
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. |
The effect of patches and upgrades on partitioned replication
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.
| 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.
Naming conventions used
In these procedures, the "source" system is one of the following:
- The source system of a single-direction replication configuration, including cascading replication.
- All source systems of a consolidated replication configuration.
- The trusted source system in a peer-to-peer replication configuration.
In these procedures, the "target" system is one of the following:
- The target system of a single-direction replication configuration, including cascading and consolidated replication.
- The secondary systems in a peer-to-peer replication configuration.
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).
Apply patch/upgrade to source then copy it to target
Supported databases
Oracle on all supported platforms
When to use this procedure
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.
Overview of the procedure
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:
- Duplicate DML and supported DDL from the patch or upgrade operations that were replicated but also applied by the backup.
- Production transactions that were replicated but also applied by the backup.
Apply the patch/upgrade
To apply the patch or upgrade:
- Stop user access to the instances involved in replication on the source and target systems, but do not shut down SharePlex.
- On the source system, run sp_ctrl.
-
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, apply the patch or upgrade.
- On the source system, restore user access to the source instance.
-
[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, run the Oracle hot backup.
-
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, recover the target database from the hot backup using the UNTIL CANCEL option in the RECOVER clause, and cancel the recovery after Oracle fully applies the log that you recorded in the previous step.
- On the target system, open the database with the RESETLOGS option.
- Run the Database Setup utility on the target instance, but do not create a new user. Choose the existing SharePlex user and password (copied in the backup). For more information, see Database Setup Utilities in the SharePlex Reference Guide.
-
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, if the patch or upgrade installed triggers on the tables in replication, disable them or run the sp_add_trigger.sql utility script so that the triggers ignore the SharePlex user.
- On the target system, if the patch or upgrade added check constraints or scheduled jobs that perform DML, disable them.
-
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.
