Make DDL changes in an active replication configuration
This procedure applies to DDL changes that are not of a type that is supported by SharePlex. DDL that is supported by SharePlex can be applied to the source database without reactivating the configuration file or stopping user access to objects, assuming the applicable SharePlex parameters are set correctly. Supported DDL is replicated by SharePlex to the target, where it is applied by Post. For a list of supported DDL operations and required parameters, see the SharePlex Release Notes.
Use this procedure to apply DDL that is not of a type that is supported by SharePlex. The DDL must be applied outside SharePlex on both the source and target systems. This procedure requires stopping access to the objects in the configuration file and a reactivation of the configuration file to update the internal tables. However, only the changed objects are analyzed, so the activation time will be shorter than the time required for a full activation.
Supported databases
Oracle
Requirements
Procedure
- On the source system, stop access to the source objects (on all systems if using peer-to-peer replication).
-
On the source system (trusted source in peer-to-peer), flush the data from the source system to the target systems. This command stops the Post process and places a marker in the data stream that establishes a synchronization point between the source and target data.
sp_ctrl> flush datasource
where: datasource is the database specification of the source instance, for example o.oraA.
-
On the target system (all secondary systems in peer-to-peer) verify that the number of messages in the post queue is 0 on each system and that Post stopped.
sp_ctrl> lstatus
- On the source system, make the DDL changes.
-
On the source system, reactivate the configuration file.
sp_ctrl> activate config filename
- On the source system, allow user activity to resume. Their replicated changes will accumulate in the post queue.
- On the target system, make the corresponding DDL changes.
-
[High availability and peer-to-peer replication only] On the secondary systems, reactivate the configuration file.
sp_ctrl> activate config filename
-
On the target systems, start Post.
sp_ctrl> start post
SharePlex resumes replication from the last stop point and the data remains synchronized.
Make Oracle changes that affect replication
This topic helps you make common changes to the Oracle environment while replication is active.
Supported databases
Oracle on Linux and UNIX
Move the location of ORACLE_HOME
If you change the ORACLE_HOME, you need to relink SharePlex to the Oracle libraries.
-
Shut down SharePlex.
sp_ctrl> shutdown
- Move the ORACLE_HOME.
- Edit the oratab file to point to the new ORACLE_HOME.
- Edit the connections.yaml file to point to the new ORACLE_HOME. This file is in the data subdirectory of the SharePlex var directory.
- Start SharePlex.
Change the target ORACLE_SID
- On the source system, run sp_ctrl.
-
On the source system, copy the active configuration file to a new name, but do not deactivate it.
sp_ctrl> copy config filename to newname
-
On the source system, open the new configuration file.
sp_ctrl> edit config filename
- Change the ORACLE_SID to the new one in all of the routing maps that include this target database and target system.
- Save and close the configuration file, but do not activate it.
- On the source system, stop user access to the objects involved in replication.
-
On the source system, flush the data in the queues to the target. This stops the Post process and establishes a synchronization point between the source and target databases.
sp_ctrl> flush datasource
where: datasource is the database indicator of the source instance, for example o.oraA.
-
On the source system, activate the new configuration file. This will deactivate the original configuration file.
sp_ctrl> activate config filename
Note: The activation will be brief because SharePlex does not need to analyze the tables.
- On the source system, allow users to access the objects involved in replication.
-
On the target system, verify that Post stopped. If Post is not stopped, continue to issue the command until it shows that Post stopped.
sp_ctrl> status
- On the target system, shut down the database and then rename the ORACLE_SID.
-
On the target system, start Post.
sp_ctrl> start post
Change the SharePlex database account
You can change the user name (schema or database), the password, or both in the SharePlex database account. The database account was established during the installation of SharePlex. These procedures guide you through the process in the correct order to maintain an active replication configuration.
Supported databases
All SharePlex-supported databases
Procedure
This procedure changes the user account name and/or password of the SharePlex user account in a database. This user account is the one that the SharePlex processes use to connect to the database when performing replication tasks.
Important! If using multiple variable-data directories, you must run this procedure for each one that you want to change.
-
(Unix and Linux only) If you are using multiple variable-data directories, export the environment variable that points to the variable-data directory for the SharePlex instance for which you are changing the account name or password.
ksh shell:
export SP_SYS_VARDIR=/full_path_of_variable-data_directory
csh shell:
setenv SP_SYS_VARDIR=/full_path_of_variable-data_directory
- Run sp_ctrl on the system where you are changing the password.
-
Stop the SharePlex processes on the system where you are changing the account information. For example, if you are changing the SharePlex account in the source database, stop Capture and Read. If you are changing the account in the target database, stop Post.
sp_ctrl> stop service
-
Verify that all SharePlex replication processes for this instance of SharePlex are stopped.
sp_ctrl> status
- Log in to the database as a DBA user and change the SharePlex account name and/or password to the new ones. Important! Do not delete the SharePlex objects!
-
If you changed the account name, copy all of the SharePlex database objects from the old account to the new one.
Note: Keep the old account and SharePlex objects as backup until you are certain replication resumes properly.
-
In sp_crtl, issue the following command to change the account name and/or password in the SharePlex internal records.
To change the user account:
sp_ctrl> connection {o.SID | r.database} set user=username
To change the password:
sp_ctrl> connection {o.SID | r.database} set password=password
where:
-
Start the SharePlex processes.
sp_ctrl> start service
Change the name or IP address of a replication host
Description
Use the provision utility to change a host name or IP address in the SharePlex configuration.
The SharePlex processes rely on the host names or IP addresses of the source and target machines to route data properly. The provision utility enables you to change host names or IP addresses within an active SharePlex instance, without reactivating a new configuration.
Note: The provision utility does not change anything in the database. It only affects SharePlex internal objects.
Supported databases
All databases supported by SharePlex on all supported platforms
Guidelines for using provision
- provision is only valid for SharePlex version 6.1.1 and above.
- (SharePlex 7.0.2 only) If provision is being used because the host name of a machine changed, contact Quest Support to request a new license. Otherwise SharePlex will not start after the change.
-
(SharePlex 7.0.2 only) Add the following parameter to the param-defaults file before you run provision:
SP_CFP_DEBUG I live int() 0x00000000
-
If running SharePlex on an AIX machine, set EXTSHM before running provision.
export EXTSHM=ON
-
Run provision on all of the machines in the SharePlex configuration. Each machine can reference the IP addresses of all the other machines.
Run provision
- Stop sp_cop. If sp_cop is running, provision will fail. Note: provision prevents sp_cop from being started while it is running.
-
Using the command line of the operating system, run provision from the SharePlex util sub-directory of productdir with the following syntax:
provision -f old_name[:old_ipaddress] -t new_name[:new_ipaddress] [-p port] [-n]
provision -h <new hostid> [
-p <port>]
-n
| -f old_hostname[:old_ipaddress] |
- -f is required and represents "from."
- old_hostname is the old (current) host name.
- old_IPaddress is the old IP address. Use if the IP address cannot be obtained from the network.
|
| -t new_hostname[:new_ipaddress] |
- -t is required and represents "to."
- new_hostname is the new host name.
- new_IPaddress is the new IP address. Use if the IP address cannot be obtained from the network.
|
| -p port |
For Windows systems, specifies the port of the SharePlex instance for which provision is being run.
(You can run the "-p" port provision only on the Windows system.) |
| -n |
Runs provision without actually making any changes. Generates a report on the changes that provision will make.
Important! The best practice is to run provision with -n first, to make certain you agree with the potential changes, then run it without -n to make the changes. |
| -h new_hostID |
- -h is required and represents changing host ID or replacing host ID
- new_hostid is the new IP address
|
| -i |
-i is required and represents host information |
Example:
provision -f oldname -t newname -n
provision -h newid -n
provision -i
- View the event log to view every change that was made. If the provision run fails or you do not agree with the changes that were made, you can undo them by running the undo_provision script. See Undo changes made by provision .
Undo changes made by provision
The provision utility creates an undo_provision script that can be used to restore the host names and IP addresses to their previous state. Run the undo_provision script from the util subdirectory of the SharePlex product directory. There are no input arguments to this script.
Known issues
The following may occur but do not affect the integrity of the replication environment:
- The provision utility does not change the active configuration file. This means that the configuration file no longer represents the current state of replication after provision is run. If you need to run the compare config command, or if you decide to reactivate the configuration, update the host name or IP address in the configuration file first.
- If an Export or Import error occurred when SharePlex connected to a machine before the name or address was changed, the error status persists and cannot be cleared.
- If the new or changed machine is a source machine, provision generates new routing information, but the Read process may still have the old routing in its cache. When you start sp_cop, Read might generate a warning that the stored IP address does not match the one for the machine. You can ignore this error.
- After provision is run for a source host, it might not update the "hostname" column in SHAREPLEX_ACTID table with the new host name details. If that column is not correctly updated, you must update the SHAREPLEX_ACTID table manually to specify the new host name. This is only required if the name change affected a source machine.
