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:
- A detailed description of the problem that includes the following
details:
- Any error messages.
- Any changes that were made to the system before the problem occurred.
- Whether the problem can be re-created.
- Conditions or exact steps that lead to the error.
- Whether you are using Q Replication, SQL Replication, or Event Publishing
- The type of replication (unidirectional, bidirectional, peer-to-peer, update-anywhere)
- A list of all operating systems, including version, where the replication programs run
- A list of all database systems, including version, that are used
in replication:
- If the database is Db2® for z/OS®, see z/OS
- If the database is Db2 for Linux®, UNIX, and Windows, include the output from the db2level command.
- Is this a production, development, or test environment?
- What is the business impact of this problem? Examples:
- Cannot roll out a new application
- Cannot monitor security systems in a store or other place of business
- 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:
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.asnmon monitor_server=mondb monitor_qual=MON1 debug=yes > monitor.trc
- 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