立即与支持人员聊天
与支持团队交流

SharePlex 11.1 - Administration Guide

About this Guide Conventions used in this guide Revision History Overview of SharePlex Run SharePlex Run multiple instances of SharePlex Execute commands in sp_ctrl Set SharePlex parameters Configure data replication Configure replication to and from a container database Configure named queues Configure partitioned replication Configure replication to a change history target Configure a replication strategy Configure DDL replication Configure error handling Configure data transformation Configure security features Assign SharePlex users to security groups Start replication on your production systems Monitor SharePlex Prevent and solve replication problems Repair out-of-sync data Tune the Capture process Tune the Post process Recover replication after Oracle failover Make changes to an active replication environment Apply an Oracle application patch or upgrade Back up Oracle data on the source or target Troubleshooting Tips Appendix A: Peer-To-Peer Diagram Appendix B: SharePlex environment variables

Remove objects from replication

Remove Source Objects from Replication

To remove source objects from replication, the configuration must be reactivated.

Note: (Oracle only) Objects being removed are locked when the configuration is activated, but only those objects are locked, so the activation is less time-consuming that the original activation.

You can prevent posting to a table without removing it from the configuration file. You may need to do this if, for example, there is data corruption and you do not want DML or DDL operations to be applied to that table. To prevent posting to a table, use the SP_OPO_DISABLE_OBJECT_NUM parameter. For more information about this parameter, see theSharePlex Reference Guide.

Supported databases

All databases supported by SharePlex

Procedure

To remove the source objects from replication:

  1. In sp_ctrl, issue the copy config command to make a copy of the active configuration file.

    sp_ctrl> copy config filename to newname

    Where: filename is the name of the active file and newname is the name of the new one.

  2. Issue the edit config command to open the new configuration file in the default text editor.

    sp_ctrl> edit config newname

  3. In the new configuration file, delete the entries for the objects that you want to remove from replication. If the object that you want to remove from replication satisfies a wildcard, use the not notation to exclude the object. For more information, see Use Wildcards to Specify Multiple Objects.

  4. Save and close the file.

  5. Activate the new configuration. This deactivates the original configuration.

    sp_ctrl> activate config newname

  6. Allow users to access the removed objects.

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

  1. On the source system, stop access to the source objects (on all systems if using peer-to-peer replication).

  2. 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.

  3. 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

  4. On the source system, make the DDL changes.

  5. On the source system, reactivate the configuration file.

    sp_ctrl> activate config filename

  6. On the source system, allow user activity to resume. Their replicated changes will accumulate in the post queue.
  7. On the target system, make the corresponding DDL changes.

  8. [High availability and peer-to-peer replication only] On the secondary systems, reactivate the configuration file.

    sp_ctrl> activate config filename

  9. 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.

Perform the following steps to relink SharePlex to the Oracle libraries:

  1. Shut down SharePlex.

    sp_ctrl> shutdown

  2. Move the ORACLE_HOME.
  3. Edit the oratab file to point to the new ORACLE_HOME.
  4. Edit the connections.yaml file to point to the new ORACLE_HOME. This file is in the data subdirectory of the SharePlex var directory.
  5. Start SharePlex.

Change the target ORACLE_SID

  1. On the source system, run sp_ctrl.

  2. 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

  3. On the source system, open the new configuration file.

    sp_ctrl> edit config filename

  4. Change the ORACLE_SID to the new one in all of the routing maps that include this target database and target system.
  5. Save and close the configuration file, but do not activate it.
  6. On the source system, stop user access to the objects involved in replication.

  7. 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.

  8. 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.

  9. On the source system, allow users to access the objects involved in replication.

  10. 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

  11. On the target system, shut down the database and then rename the ORACLE_SID.

  12. On the target system, start Post.

    sp_ctrl> start post

Change the SharePlex database account

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.

  1. (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

  2. Run sp_ctrl on the system where you are changing the password.

  3. 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

  4. Verify that all SharePlex replication processes for this instance of SharePlex are stopped.

    sp_ctrl> status

  5. 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!

  6. 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.

  7. 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:

    • SID is the ORACLE_SID of the database, if the database is Oracle.
    • database is the name (not the DSN) of the database, if the database is non-Oracle.
    • username is the new account name.

    • password is the new password.

  8. Start the SharePlex processes.

    sp_ctrl> start service

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级