Chat now with support
Chat with Support

SharePlex 9.2.7 - 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

DDL logging and error handling

Both Capture and Post log the DDL that they process. SharePlex also prints replicated DDL to the SharePlex Event Log, but it may be truncated. Only the Post DDL log contains complete DDL statements. SharePlex stores the DDL logs in the log subdirectory of the variable-data directory on the source and target systems.

By default, Post stops on DDL errors. An error usually indicates that the database component for which the DDL was executed on the source system does not exist in the target database. The default setting of the SP_OPO_STOP_ON_DDL_ERR parameter stops Post on DDL errors, so that subsequent DML on that object does not fail. This enables you to correct the problem and keep the databases synchronized. For more information about this parameter, see the SharePlex Reference Guide.

Table 3: SharePlex DDL log naming conventions

DDL log type Naming convention Example
Capture o.ORACLE_SID_ocap_ddl_log_number.log o.ora12_ocap_ddl_01.log
Oracle target o.ORACLE_SID_machine_name_opo_ddl_log_number.log o.ora12_server2_opo_ddl_01.log
Open Target target r.database_name_machine_name_xpst_ddl_log_number.log r.mssdb1_server3_xpst_ddl_01.log

Configure error handling

This chapter contains an overview of the tools that SharePlex provides to handle errors that are returned by the Post process.

Contents

Continue to Post when there is an error

SharePlex provides a way for Post to continue processing after it encounters a DML error, rather than stop.

Continue posting on Oracle and SharePlex errors

Valid for Oracle targets

When SharePlex posts to an Oracle target, you can configure Post to ignore specific Oracle DML errors and specific SharePlex error messages and continue processing. Post determines which messages to ignore based on the list in the oramsglist file. The file is installed with a small list of errors by default, but you can remove any of them as desired.

When Posts ignores an error, it writes the error to the SharePlex Event Log. Post also logs the error and the SQL statements that caused the error to the Error log. This log is named SID_errlog.sql log file and is stored in the data directory in the SharePlex variable-data directory. For more information, see View events and errors.

Note: There are certain errors that Post will not ignore, and it will stop for those messages even if they are listed in the oramsglist file.

Important: Use caution when using this feature. It could result in hidden out-of-sync conditions. Enable this parameter only if your target users cannot tolerate replication lag and it is acceptable to have some out-of-sync data. Check the SID_errlog.sql log frequently to see if there were errors that could cause replication problems.

To configure Post to continue on errors

  1. On the target system, change directories to the data sub-directory of the SharePlex variable-data directory.

  2. Find the oramsglist file.
  3. If replication is not active, open the file in a text editor. If replication is active, make a copy of the file and then open the copy in the editor.

  4. Increase the number on the first line by the number of errors that you are adding. This number must be equal to the total number of errors that are in the file. For example, in the following file there are 10 errors listed.

    ora@sys1dad > vi oramsglist
    10
    604
    900
    902
    908
    909
    910
    911
    932
    960
    1026
  5. Starting at the end of the file, add the number of each Oracle or SharePlex error, one per line as shown in the preceding example. The messages need not be in numerical order.

  6. Save and close the file.
  7. Stop Post (if running).

    sp_ctrl> stop post

  8. If you edited a copy of the oramsglist file, save the copy to the original name of oramsglist.
  9. Change the value of the SP_OPO_CONT_ON_ERR parameter to 1. Or change the value to 2 to also continue posting on table errors listed in the oramsglist file. See the SharePlex Reference Guide for a description of the SP_OPO_CONT_ON_ERR parameter.

    sp_ctrl> set param SP_OPO_CONT_ON_ERR 1

  10. Start Post.

    sp_ctrl> start post

Continue posting on ODBC errors

Valid for Open Target

When SharePlex posts to an Open Target target, you can configure Post to ignore ODBC errors and continue processing. Post writes the error to the SharePlex Event Log. Post also logs the error and the SQL statements that caused the error to the Error log. This log is named ID_errlog.sql log file, where ID is the database identifier. The file is stored in the data directory in the SharePlex variable-data directory. For more information, see View events and errors.

Important: Use caution when using this feature. It could result in hidden out-of-sync conditions. Enable this parameter only if your target users cannot tolerate replication lag and it is acceptable to have some out-of-sync data. Check the SID_errlog.sql log frequently to see if there were errors that could cause replication problems.

To configure Post to continue on errors

  1. On the target system, change directories to the data sub-directory of the SharePlex variable-data directory.

  2. Look for one of the following files, depending on the database. These files are installed empty.

    File name Supported database

    postgresmsglist

    Postgres
    sqlservermsglist Microsoft SQL Server
    sybasemsglist SAP Adaptive Server Enterprise (ASE)
    tdmsglist Teradata
    mysqlmsglist Oracle MySQL

    Note: There are certain errors for which Post will stop, even if you list those errors in the message file.

  3. If replication is not active, open the file in a text editor. If replication is active, make a copy of the file and then open the copy in the editor.

  4. Starting at the end of the file, add the number of each error, one per line as shown in the example. The messages need not be in numerical order.

    Example:

    sqlservermsglist:

    8102

    8180

    544

    2627

    3621

  5. Save and close the file.
  6. Stop Post (if running).

    sp_ctrl> stop post

  7. If you copied the original file, save it back to its original name.
  8. Change the value of the SP_OPX_CONT_ON_ERR parameter to 1.

    sp_ctrl> set param SP_OPX_CONT_ON_ERR 1

  9. Start Post.

    sp_ctrl> start post

Continue to Post on DDL errors

By default, Post stops on DDL errors. An error usually indicates that the database component for which the DDL was executed on the source system does not exist in the target database. The default setting of the SP_OPO_STOP_ON_DDL_ERR parameter stops Post on DDL errors, so that subsequent DML on that object does not fail. This enables you to correct the problem and keep the databases synchronized. For more information about this parameter, see the SharePlex Reference Guide.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating