Collecting data for Q Replication, SQL Replication, and Event Publishing

If you experience a problem with Q Replication or SQL Replication that requires assistance from IBM® Support, you need to gather certain information to help in diagnosing the problem.

Be ready to provide the following information:

  1. A detailed description of the problem that includes the following details:
    1. Any error messages.
    2. Any changes that were made to the system before the problem occurred.
    3. Whether the problem can be re-created.
    4. Conditions or exact steps that lead to the error.
  2. Whether you are using Q Replication, SQL Replication, or Event Publishing
  3. The type of replication (unidirectional, bidirectional, peer-to-peer, update-anywhere)
  4. A list of all operating systems, including version, where the replication programs run
  5. A list of all database systems, including version, that are used in replication:
    1. If the database is Db2® for z/OS®, see z/OS
    2. If the database is Db2 for Linux®, UNIX, and Windows, include the output from the db2level command.
  6. Is this a production, development, or test environment?
  7. What is the business impact of this problem? Examples:
    1. Cannot roll out a new application
    2. Cannot monitor security systems in a store or other place of business
    3. Losing money because applications cannot communicate with each other

Provide this additional information depending on the feature or platform:

Capture program
  • Capture log (the naming convention for the log is db2instance.capture_server.capture_schema.CAP.LOG)
  • Output from the Analyzer program (asnanalyze.htm)
  • If the error includes a SQLCODE, provide the db2diag.log
Apply program
  • Apply log (the naming convention for the log is db2instance.control_server.apply_qualifier.APP.LOG)
  • Output from the Analyzer program (asnanalyze.htm)
  • If the error includes a SQLCODE, provide the db2diag.log
Replication Alert Monitor
  • Monitor log (the naming convention for the log is db2instance.monitor_server.monitor_qualifier.MON.LOG)
  • Trace information that you can gather by specifying debug=yes to the asnmon command when you start a monitor. For example, the following command sends trace information to a file called monitor.trc:
    asnmon monitor_server=mondb monitor_qual=MON1 debug=yes > monitor.trc
    Recreate the problem with as few steps as possible when running with the debug option. Remove debug=yes from the startup command for subsequent runs of the asnmon command.
asntdiff or asntrep utilities
  • The command that was used.
  • Log files that were generated in the directory from which the command was run or in a location that was specified by the DIFF_PATH parameter.
Q Capture program
  • Q Capture log (the naming convention for the log is db2instance.qcapture_server.qcapture_schema.QCAP.LOG)
  • IBM MQ version and whether you are using MQ client-server
  • If the error includes a SQLCODE, provide the db2diag.log
Q Apply program
  • Q Apply log (the naming convention for the log is db2instance.qapply_server.qapply_schema.QAPP.LOG)
  • MQ version and whether you are using MQ client-server
  • If the error includes a SQLCODE, provide the db2diag.log
Migration
Detailed steps or migration scripts that were used
z/OS
  • Db2 version
  • Current® APAR level for replication program
  • Joblog including JES output
  • A dump of the Db2 MSTR address space