Converse agora com nosso suporte
Chat com o suporte

SharePlex 10.1.2 - Administration Guide

About this Guide Conventions used in this guide 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 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

Activate replication with Oracle transportable tablespaces

Use this procedure to use the Oracle transportable tablespaces feature to establish a target Oracle instance and activate replication. It enables you to synchronize and resynchronize numerous objects quickly and with minimal downtime. It allows you to export just the metadata (data dictionary) and then copy the data files. This method also moves indexes so that there is no need to rebuild them in the target database, and you can move multiple tablespaces at one time.

Note: This document does not provide instructions for how to use transportable tablespaces. This procedure should be performed by someone who has a solid understanding of database copy methods.

Preliminary considerations

Read these points before you proceed.

Supported databases

Oracle source and Oracle target

Supported replication strategies

All replication strategies. This procedure may not appropriate for a high-availability strategy if the source database cannot be quieted even briefly.

Requirements

Naming conventions used

In this procedure, 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.
  • The primary node of a cluster (where the cluster VIP is running).

In this procedure, the "intermediary" system only needs to be part of this procedure if SharePlex will be posting to, and capturing from, an intermediary system in a cascading configuration.

In this procedure, 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.
  • The primary node (where the cluster VIP is running) of the target cluster.

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

Procedure

  1. On the source system, set the source tablespaces that you want to copy to READ ONLY.

    svrmgr1> alter tablespace name read only;

  2. On the source system, activate the configuration file.

    sp_ctrl> activate config filename

  3. On the source system, start sp_cop and sp_ctrl from the bin sub-directory of the SharePlex product directory.

  4. On the source system, verify that sp_cop and sp_ctrl are running.

    sp_ctrl> status

  5. On the intermediary and target systems, stop Post. Stopping Post allows replicated data to accumulate in the post queue until the databases have been recovered.

    sp_ctrl> stop post

  6. On the source system, export the metadata to an export file.
  7. When the export is finished, copy the datafiles to another location on the source system. This minimizes the impact on the source database of copying the files to the target system.

  8. Set the source tablespaces back to read/write mode.

    svrmgr1> alter Tablespace name read write;

  9. If any of the copied datafiles and tablespaces exist in the intermediary or target database, drop them so that the copied files can be applied.
  10. Copy the files from the new location on the source system to the intermediary and target systems.
  11. On the intermediary and target systems, use the Oracle import utility to import the metadata and the tablespace definitions.
  12. On the intermediary and target systems, set the tablespace(s) to read/write mode.
  13. On the intermediary and target systems, open the Oracle instances.

  14. On the intermediary and target systems, disable triggers on the tables, or run the sp_add_trigger.sql utility script so that the triggers ignore the SharePlex user.

  15. On the intermediary and target systems, disable check constraints and scheduled jobs that perform DML.
  16. [Partitioned replication only] If you are using vertically partitioned or horizontally partitioned replication for any tables, delete the unneeded columns and rows from those tables on the intermediary and target systems.

  17. [Intermediary system only] Set the SP_OCT_REPLICATE_POSTER parameter to 1. This directs SharePlex to capture posted changes on that system and replicate them to the target system.

    sp_ctrl> set param SP_OCT_REPLICATE_POSTER 1

  18. [Intermediary system only] Activate the configuration file.

    sp_ctrl> activate config filename

  19. [High availability] On the target system, stop the Export process.

    sp_ctrl> stop export

  20. [High availability and peer-to-peer replication] Activate the configuration on the target system(s).

    sp_ctrl> activate config filename

  21. Start Post on the intermediary and target systems. SharePlex begins executing the SQL statements that have been collecting in the post queue, keeping the source and target data in sync.

    sp_ctrl> start post

  22. [Peer-to-peer replication] Allow users to access the databases on all systems.

Activate replication with cold copy/transfer methods

Use this procedure to synchronize the source and target data with the following utilities:

  • Import/Export/Data Pump
  • Store/Restore from tape
  • FTP

Note: This document does not provide instructions for how to perform the chosen copy method. This procedure should be performed by someone who has a solid understanding of database copy methods.

Preliminary considerations

Read these points before you proceed.

Supported databases

Oracle source and Oracle target

Supported replication strategies

All but high-availability. This procedure is not appropriate for a high-availability strategy because it requires the source database to be quieted while the configuration file is being activated.

Requirements

  • [Unix and Linux systems] Verify that the ORACLE_SID and ORACLE_HOME in the oratab file are correct for the instance you will be establishing with the hot backup. The SID must be the SID used in the routing map in the configuration file that you will be activating.
  • Read the requirements before you start this procedure. For more information, see Requirements for activating a configuration.
  • Users must stop accessing the production database while the copy and configuration activation take place.
  • The target instance must exist.
  • Make certain SharePlex database accounts exist in the source and target databases. This account usually is created during installation. See the SharePlex Installation and Setup Guide for more information.
  • Before you start, review this procedure and see the SharePlex Reference Guide for more information about the commands that are used.

Naming conventions used

In this procedure, 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.
  • The primary node of a cluster (where the cluster VIP is running).

In this procedure, the "intermediary" system only needs to be part of this procedure if SharePlex will be posting to, and capturing from, an intermediary system in a cascading configuration.

In this procedure, 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.
  • The primary node (where the cluster VIP is running) of the target cluster.

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

Procedure

  1. On the source system, stop user access to the objects that are in the replication configuration.

    • If deploying consolidated replication, you can either stop access to all of the source systems at once and make the copies at the same time, or you can synchronize each source system one at a time using these instructions.
    • If deploying peer-to-peer replication, stop access to all databases in the peer group, including the trusted source.
  2. Copy the files from the source system to the intermediary and target systems.
  3. On the source system, start sp_cop and sp_ctrl.

  4. On the source system, activate the configuration file (all files if using consolidated replication).

    sp_ctrl> activate config filename

  5. On the intermediary and target systems, start sp_cop and sp_ctrl.

  6. On the intermediary and target systems, stop Post. Stopping Post allows any data that gets replicated before the target data is established to collect in the post queue.

    sp_ctrl> stop post

  7. On the source system, allow users to resume access to the source database.

  8. On the source system, verify that the sp_cop, Capture, and Read processes are running.

    sp_ctrl> status

  9. Start and mount the intermediary and target databases, but do not allow users access.
  10. On the intermediary and target systems, apply the copy to the database.

  11. On the intermediary and target systems, disable triggers on the tables, or run the sp_add_trigger.sql utility script so that the triggers ignore the SharePlex user.

  12. On the intermediary and target systems, disable check constraints and scheduled jobs that perform DML.
  13. [Partitioned replication only] If you are using vertically partitioned or horizontally partitioned replication for any tables, delete the unneeded columns and rows from those tables on the intermediary and target systems.

  14. [Intermediary system only] Set the SP_OCT_REPLICATE_POSTER parameter to 1. This directs SharePlex to capture posted changes on that system and replicate them to the target system.

    sp_ctrl> set param SP_OCT_REPLICATE_POSTER 1

  15. [Intermediary system only] Activate the configuration file.

    sp_ctrl> activate config filename

  16. [Peer-to-peer] Activate the configuration file on the target systems.

  17. Start Post on:

    • The intermediary system
    • The trusted source and all other targets in a peer group
    • All other targets

    Note: SharePlex will start executing SQL statements that accumulated in the post queue.

  18. [Peer-to-peer] On the target systems in the peer group, allow users to resume access to the database.

Activate replication from Oracle to Open Target

Use this procedure to synchronize an Oracle source database with an Open Target database. SharePlex replicates the Oracle data changes and maintains them in the Post queue until the target is established with the copy. When the target is ready, you run the SharePlex reconcile feature, which ensures that Post only applies the operations that occurred after the copy and discards operations that were committed to the source before the copy.

Preliminary considerations

Read these points before you proceed.

Supported databases

Oracle source and any supported target

Supported replication strategies

All

Requirements

  • You can use your Oracle RMAN backup system to take a hot backup of your primary instance and recover to an SCN or sequence number in a staging instance.

  • This document does not provide instructions for how to perform the chosen copy method. Someone with expertise in database copy methods should perform this procedure. You can use Toad Data point or a third-party tool to extract data from the staging instance into the Open Target database.
  • Read the requirements for activating a configuration file. For more information, see Requirements for activating a configuration.
  • Before you start, review this procedure and see the SharePlex Reference Guide for more information about the commands that are used.

Procedure

  1. On the source and target systems, start sp_cop and sp_ctrl from the bin sub-directory of the SharePlex product directory.

  2. On source and target systems, verify that the SharePlex processes are running.

    sp_ctrl> status

  3. On the target system, stop the Post process. This allows replicated data to accumulate in the post queue until the target database is instantiated and reconciled.

    sp_ctrl> stop post

  4. Activate the configuration on the source system.

    sp_ctrl> activate config filename

  5. On the source system, monitor activation status.

    Note: The command retains control of sp_ctrl until activation is finished.

  6. When activation is complete, start the hot backup to the staging instance.

  7. When the hot backup is finished, switch log files on the primary source system twice.

    On-premises database:

    svrmgr1> alter system switch logfile;

    svrmgr1> alter system switch logfile;

    Amazon RDS database:

    Run the Amazon RDS procedure rdsadmin.rdsadmin_util.switch_logfile twice.

  8. Copy the archive logs that were generated by the log switch from the primary instance to the staging instance.

  9. Do one of the following:

    1. If the source is RAC, recover the database on the staging server to the latest SCN of the last archive log that was copied to the staging server.

    2. If the source is not RAC, recover to the sequence number of the last archive log that was copied to the staging server.

      Note: The next steps apply the replicated changes that occurred after the backup point.

  10. Do one of the following:

    • If the source is RAC, make a note of the SCN that you recovered to on the staging server.

    • If source is non-RAC, make a note of the log sequence number that you recovered to on the staging server.

  11. Using the copy method of your choice, make a copy of the Oracle data from the staging server to the Open Target database. Wait until the copy is finished before proceeding to the next step.

  12. [Optional] If you are using named post queues and are unsure of the queue names, issue the qstatus command and make a note of them.

    sp_ctrl> qstatus

  13. On the target system, disable triggers on the target tables.
  14. On the target system, disable check constraints and scheduled jobs that perform DML.

  15. On the target system, run sp_ctrl, then issue one of the following reconcile commands. If you are using named post queues, issue the command for each one.

    • If the source is non-RAC, reconcile to the log sequence number of the log that you noted previously.

      sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number

      Example: reconcile queue SysA for o.prod1-r.rep1 seq 1234

    • If the source is RAC, reconcile to the SCN that you noted previously.

      sp_ctrl> reconcile queue queuename for datasource-datadest scn scn_number

      Example: reconcile queue SysA for o.prod1-r.rep1 scn 0123456789

      Note: The command retains control of sp_ctrl until the reconcile process is finished.

  16. On the target system, start the Post process. The two instances are now in synchronization, and SharePlex will continue replicating to maintain synchronization.

    sp_ctrl> start post

Monitor SharePlex

This chapter contains an overview of the tools that SharePlex provides to detect errors and monitor the replication processes. Like any mission-critical software, SharePlex should be monitored regularly for situations or events that could interfere with processing, especially those that could result in loss of data synchronization.

Contents
Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação