Download CDC troubleshooting

Troubleshooting
4
Troubleshooting a problem
7
Understanding where to find troubleshooting information
10
Searching knowledge bases
11
Using Support Assistant in Management Console
12
To collect source and target information using Support Assistant
13
Locating event messages
14
To change the number of messages in the event log
15
To remove event messages daily
16
Locating log files
17
Enabling detailed tracing for InfoSphere CDC for z/OS
18
Enabling detailed InfoSphere CDC tracing for distributed systems
19
To enable tracing using Management Console
20
To enable tracing using the dmset command line utility
21
To disable tracing using Management Console
23
To disable tracing using the dmset command line utility
24
Using trace options in Management Console
25
To enable tracing for Management Console messages
26
To enable tracing for Access Server messages
27
To enable tracing for Access Server log information
28
To disable tracing for Management Console messages
29
To disable tracing for Access Server messages
30
To disable tracing for Access Server log information
31
Troubleshooting installation and configuration
32
Encountering a previous instance of InfoSphere CDC in the instance list
33
Encountering an ./oraclenativeapi.dll is not a valid win2k application message
34
Encountering problems while using InfoSphere CDC for InfoSphere DataStage with Direct
Connect
35
Encountering a You must perform a FULL DATABASE BACKUP to start the FULL or BULKLOGGED RECOVERY MODEL message when configuring InfoSphere CDC for DB2 for LUW 37
Encountering a You must perform a FULL DATABASE BACKUP to start the FULL or BULKLOGGED RECOVERY MODEL message when configuring InfoSphere CDC for Microsoft SQL
Server
38
Encountering a The RECOVERY MODEL for the database must be FULL or BULK-LOGGED
message when configuring InfoSphere CDC for Microsoft SQL Server
39
Encountering a Microsoft SQL Server is not configured for distribution. You must configure
distribution in Microsoft SQL Server message when configuring InfoSphere CDC for Microsoft SQL
Server
40
Encountering a Cannot bulk load because the file
"\\<server_name>\<directory_name>\<bcp_file_name>.bcp" could not be opened. Operating
system error code 5 (Access is denied.) message when configuring InfoSphere CDC for Microsoft
SQL Server
41
Encountering a Failed to initialize SMO message when configuring InfoSphere CDC for Microsoft
SQL Server
42
Configuration tool hangs during instance creation
43
Encountering an Invalid internal file structure contents detected in file <file_name> message and
InfoSphere CDC for Oracle databases shuts down
44
Encountering an com.datamirror.ts.commandlinetools.config.TsConfigError: IBM InfoSphere
Change Data Capture communication failure error during configuration
45
Troubleshooting Access Server and Management Console
46
Encountering a Your account has been locked because the number of consecutive log-in failures
exceeded the maximum allowed message when logging into Management Console
47
Encountering a Could not connect to Access Server using the <server name> and <port number>.
Access Server may be down or the host name and/or port number may be incorrect message
when logging into Management Console or connecting to Access Server
49
Encountering an Access Server could not connect to the database. Do you want to retry with a
new name or password? or Management Console could not establish a connection to the
datastore. An error has occurred while communicating with agent: java.net.ConnectException:
Connection refused: connect message when connecting to a datastore in Management Console
51
Encountering an An error occurred during communication initialization message after changing the
host name or port for a source datastore and attempting to replicate to the target
53
Changing the host name or port for a target datastore shows duplicate subscriptions in
Management Console
54
Troubleshooting data replication
55
Encountering a The single scrape staging store is corrupted. To resolve this issue, you must clear
the staging store using the dmclearstagingstore command line utility message after running
dmclearstagingstore
56
Encountering a IBM InfoSphere Change Data Capture has encountered a critical data definition
(DDL) change for source table <table name> and will shutdown message
57
Encountering errors after applying DDL changes to in-scope tables for InfoSphere CDC for z/OS
58
Encountering a The oldest open commit group in the staging space for subscription name opened
at time has exceeded the open commit group warning age of maximum minutes by exceeds
minutes message for long running Units of Recovery (URs) on InfoSphere CDC for z/OS
61
Encountering a CHC9219E DB2 IFI has returned non-zero status in a Log Record at position,
QW0306RC = return, QW0306RS = reason, QW0306DG = code decompression error on
InfoSphere CDC for z/OS
63
Replicating tables without a primary key (event ID 9604) on InfoSphere CDC for Microsoft SQL
Server
64
Troubleshooting mirroring replication
65
Mirroring stops when InfoSphere CDC encounters an apply error
66
To set conflict detection and resolution for source row wins
67
To map source and target tables for Adaptive Apply
68
To ignore database errors when applying data changes to the target for all subscriptions using
InfoSphere CDC for z/OS
70
To ignore database errors when applying data changes to the target for all subscriptions
71
Encountering a 911 SQL error message when configuring a table for mirror replication on
InfoSphere CDC for z/OS
72
Replication of tables containing LOB columns is slow
73
Encountering an An error occurred while turning on supplemental logging for <table_name>.
Unable to get exclusive lock on table <table_name> message when configuring a table for mirror
replication on InfoSphere CDC for Oracle databases
74
Troubleshooting refresh replication
76
Refreshing fails with a referential integrity constraint violation reported in the event log
77
Refreshing data to the target on InfoSphere CDC and encountering database errors
78
Encountering a A SQL exception has occurred. The SQL error code is '0'. The SQL state is:
HY000. The error message is: [CDC][Oracle JDBC Driver]Object has been closed message on
InfoSphere CDC for Oracle databases
79
Troubleshooting latency
80
Experiencing increased latency and no data is replicating to the target database
81
Experiencing increased latency and no data is replicating to the target database on InfoSphere
CDC for z/OS
82
Troubleshooting data replication maintenance
84
Running dmshowlogdependency on InfoSphere CDC for Oracle databases references a dated log
file
85
Encountering a CHC9214E DB2 Trace could not be started. All OPx trace buffers are in use or
CHC9217E DB2 CAF Message: [<DB2 CAF error>] message in the event log on InfoSphere CDC
for z/OS
87
Troubleshooting network and connectivity issues
88
Encountering communication interruptions
89
Getting fixes from Fix Central
91
Subscribing to Support updates
92
Understanding types of Support updates
93
To subscribe to InfoSphere CDC RSS feeds
94
To subscribe to My Notifications
95
Contacting IBM Support
96
Determining your version of InfoSphere CDC
97
To determine your version of InfoSphere CDC
98
Collecting InfoSphere CDC information for IBM Support
99
To collect InfoSphere CDC information
100
Collecting performance statistics on a subscription for IBM Support
101
To collect performance statistics on a subscription
102
Exchanging information with IBM Support
103
To send information to IBM Support
104
To receive files from IBM Support
105
Reporting a problem to IBM Support
106
To contact IBM Support
107
Troubleshooting
108
Using the IBM Support Assistant (ISA DC)
109
To use ISA DC to collect data for a product problem (command line)
110
To use ISA DC to collect data for a product problem (GUI)
113
To use ISA DC to collect data for a question or an enhancement request (command line)
115
To use ISA DC to collect data for a question or an enhancement request (GUI)
117
Contacting IBM Support
119
Troubleshooting a problem
The first step in good problem analysis is to describe the problem completely.
Without a problem description, you will not know where to start investigating the
cause of the problem.
This step includes asking yourself such basic questions as:
- What are the symptoms?
- Where is the problem happening?
- When does the problem happen?
- Under which conditions does the problem happen?
- Is the problem reproducible?
- Is this the first time the problem has happened? Was the system running
acceptably before the problem occurred, and what were the last things that
changed on the system before the problem occurred?
- Is this a recurring problem?
Answering these and other questions will lead to a good description to most
problems, and is the best way to start down the path of problem resolution.
What are the symptoms?
When starting to describe a problem, the most obvious question is "What is the
problem?" This might seem like a straightforward question; however, it can be
broken down into several other questions to create a more descriptive picture of the
problem. These questions can include:
- Who or what is reporting the problem?
- What are the error codes and error messages?
- How does it fail? For example, loop, hang, stop, performance degradation, or
incorrect result?
- What is the affect on business?
Where is the problem happening?
Determining where the problem originates is not always easy, but is one of the most
important steps in resolving a problem. Many layers of technology can exist between
the reporting and failing components. Networks, disks, and drivers are only a few
components to be considered when you are investigating problems.
- Is the problem specific to your database, operating system, or hardware platform?
- Is the problem on the source, target, or both environments?
- Can the problem be narrowed down to a specific area (such as a communications
socket issue, a source data issue, and so on)?
- Is the current environment and configuration supported?
- Is the application running locally on the database server or on a remote server?
- Is there a gateway involved?
- Is the database stored on individual disks, or on a RAID disk array?
These types of questions will help you isolate the problem layer, and are necessary
to determine the problem source. Remember that just because one layer is reporting
a problem, it does not always mean the root cause exists there.
Part of identifying where a problem is occurring is understanding the environment in
which it exists. You should always take some time to completely describe the
problem environment, including the operating system, its version, all corresponding
software and versions, and hardware information. Confirm you are running within an
environment that is a supported configuration, as many problems can be explained
by discovering software levels that are not meant to run together, or have not been
4
fully tested together.
When does the problem happen?
Developing a detailed time line of events leading up to a failure is another necessary
step in problem analysis, especially for those cases that are one-time occurrences.
You can most easily do this by working backwards: start at the time an error was
reported (as exact as possible, even down to milliseconds), and work backwards
through available logs and information. Usually you only have to look as far as the
first suspicious event that you find in any diagnostic log, however, this is not always
easy to do and will only come with practice. Knowing when to stop is especially
difficult when there are multiple layers of technology each with its own diagnostic
information.
- Does the problem only happen at a certain time of day or night?
- How often does it happen?
- What sequence of events leads up to the time the problem is reported?
- Does the problem happen after an environment change such as upgrading existing
or installing new software or hardware?
Responding to questions like this will help you create a detailed time line of events,
and will provide you with a frame of reference in which to investigate.
Under which conditions does the problem happen?
Knowing what else is running at the time of a problem is important for any complete
problem description. For example, if a problem occurs in a certain environment or
under certain conditions, the environment or conditions can be help determine the
cause of the problem.
- Does the problem always occur when performing the same task?
- Does a certain sequence of events need to occur for the problem to surface?
- Do other applications fail at the same time?
- Is there a third party application consuming resources that may be using up
resources and affecting InfoSphere® CDC?
Answering these types of questions will help you explain the environment in which
the problem occurs, and correlate any dependencies. Remember that just because
multiple problems might have occurred around the same time, it does not
necessarily mean that they are always related.
Is the problem reproducible?
From a problem description and investigation standpoint, the "ideal" problem is one
that is reproducible. With reproducible problems you almost always have a larger set
of tools or procedures available to use to help your investigation. Consequently,
reproducible problems are usually easier to debug and solve. However, reproducible
problems can have a disadvantage: if the problem is of significant business impact,
you don't want it recurring. If possible, recreating the problem in a test or
development environment is often preferable in this case.
- Can the problem be recreated on a test machine?
- If the problem can be recreated, can further tracing be enabled to help determine
the problem?
- Are multiple users or applications encountering the same type of problem?
- Can the problem be recreated by running a single command, a set of commands,
or a particular application, or a standalone application?
Recreating a single incident problem in a test or development environment is often
preferable, as there is usually much more flexibility and control when investigating.
5
6
Troubleshooting a problem
The first step in good problem analysis is to describe the problem completely.
Without a problem description, you will not know where to start investigating the
cause of the problem.
This step includes asking yourself such basic questions as:
- What are the symptoms?
- Where is the problem happening?
- When does the problem happen?
- Under which conditions does the problem happen?
- Is the problem reproducible?
- Is this the first time the problem has happened? Was the system running
acceptably before the problem occurred, and what were the last things that
changed on the system before the problem occurred?
- Is this a recurring problem?
Answering these and other questions will lead to a good description to most
problems, and is the best way to start down the path of problem resolution.
What are the symptoms?
When starting to describe a problem, the most obvious question is "What is the
problem?" This might seem like a straightforward question; however, it can be
broken down into several other questions to create a more descriptive picture of the
problem. These questions can include:
- Who or what is reporting the problem?
- What are the error codes and error messages?
- How does it fail? For example, loop, hang, stop, performance degradation, or
incorrect result?
- What is the affect on business?
Where is the problem happening?
Determining where the problem originates is not always easy, but is one of the most
important steps in resolving a problem. Many layers of technology can exist between
the reporting and failing components. Networks, disks, and drivers are only a few
components to be considered when you are investigating problems.
- Is the problem specific to your database, operating system, or hardware platform?
- Is the problem on the source, target, or both environments?
- Can the problem be narrowed down to a specific area (such as a communications
socket issue, a source data issue, and so on)?
- Is the current environment and configuration supported?
- Is the application running locally on the database server or on a remote server?
- Is there a gateway involved?
- Is the database stored on individual disks, or on a RAID disk array?
These types of questions will help you isolate the problem layer, and are necessary
to determine the problem source. Remember that just because one layer is reporting
a problem, it does not always mean the root cause exists there.
Part of identifying where a problem is occurring is understanding the environment in
which it exists. You should always take some time to completely describe the
problem environment, including the operating system, its version, all corresponding
software and versions, and hardware information. Confirm you are running within an
environment that is a supported configuration, as many problems can be explained
by discovering software levels that are not meant to run together, or have not been
7
fully tested together.
When does the problem happen?
Developing a detailed time line of events leading up to a failure is another necessary
step in problem analysis, especially for those cases that are one-time occurrences.
You can most easily do this by working backwards: start at the time an error was
reported (as exact as possible, even down to milliseconds), and work backwards
through available logs and information. Usually you only have to look as far as the
first suspicious event that you find in any diagnostic log, however, this is not always
easy to do and will only come with practice. Knowing when to stop is especially
difficult when there are multiple layers of technology each with its own diagnostic
information.
- Does the problem only happen at a certain time of day or night?
- How often does it happen?
- What sequence of events leads up to the time the problem is reported?
- Does the problem happen after an environment change such as upgrading existing
or installing new software or hardware?
Responding to questions like this will help you create a detailed time line of events,
and will provide you with a frame of reference in which to investigate.
Under which conditions does the problem happen?
Knowing what else is running at the time of a problem is important for any complete
problem description. For example, if a problem occurs in a certain environment or
under certain conditions, the environment or conditions can be help determine the
cause of the problem.
- Does the problem always occur when performing the same task?
- Does a certain sequence of events need to occur for the problem to surface?
- Do other applications fail at the same time?
- Is there a third party application consuming resources that may be using up
resources and affecting InfoSphere® CDC?
Answering these types of questions will help you explain the environment in which
the problem occurs, and correlate any dependencies. Remember that just because
multiple problems might have occurred around the same time, it does not
necessarily mean that they are always related.
Is the problem reproducible?
From a problem description and investigation standpoint, the "ideal" problem is one
that is reproducible. With reproducible problems you almost always have a larger set
of tools or procedures available to use to help your investigation. Consequently,
reproducible problems are usually easier to debug and solve. However, reproducible
problems can have a disadvantage: if the problem is of significant business impact,
you don't want it recurring. If possible, recreating the problem in a test or
development environment is often preferable in this case.
- Can the problem be recreated on a test machine?
- If the problem can be recreated, can further tracing be enabled to help determine
the problem?
- Are multiple users or applications encountering the same type of problem?
- Can the problem be recreated by running a single command, a set of commands,
or a particular application, or a standalone application?
Recreating a single incident problem in a test or development environment is often
preferable, as there is usually much more flexibility and control when investigating.
8
9
Understanding where to find troubleshooting
information
InfoSphere® CDC offers different types of troubleshooting information, including
diagnostic tools, messages, and log files. Use one or more of these methods to help
gather helpful information for IBM® Support when assisting you with your problem.
In this section, you will learn:
- Searching knowledge bases
You can often find solutions to problems by searching IBM knowledge bases. You
can optimize your results by using available resources, support tools, and search
methods. You can find useful information by searching the Knowledge Center for
InfoSphere CDC, but sometimes you need to look beyond the Knowledge Center
to answer your questions or resolve problems.
- Using Support Assistant in Management Console
Support Assistant lets you collect messages that are communicated between
Management Console, Access Server, and datastores. Use Support Assistant to
collect diagnostic data such as configuration, log, and runtime information for your
support issue.
- Locating event messages
InfoSphere CDC event messages help you monitor subscriptions. Use them to
understand the progress of your subscriptions and troubleshoot problems. Use the
event log within Management Console to view messages generated during
replication.
- Locating log files
In addition to the Management Console event log, InfoSphere CDC produces
other logs to help troubleshoot installation and replication errors.
- Enabling detailed tracing for InfoSphere CDC for z/OS
Tracing of InfoSphere CDC for z/OS® tasks should only be performed once IBM
Support has reviewed the SPOOLed output and can provide advice on the trace
points to enable if it is necessary to further the investigation.
- Enabling detailed InfoSphere CDC tracing for distributed systems
When troubleshooting InfoSphere CDC and there are no clear error messages in
the Management Console event log, or product logs for failures, the next best
diagnostic tool is product tracing.
- Using trace options in Management Console
Use the Management Console trace options to enable tracing of messages
between Access Server, Management Console, and datastores. The message
collection includes configuration information for the products, any log files, or any
error reports. Use the trace options within Management Console when you have
encountered a problem with Management Console and you want to send the issue
to IBM Support.
10
Searching knowledge bases
You can often find solutions to problems by searching IBM knowledge bases. You
can optimize your results by using available resources, support tools, and search
methods. You can find useful information by searching the Knowledge Center for
InfoSphere® CDC, but sometimes you need to look beyond the Knowledge Center
to answer your questions or resolve problems.
Use any of the following knowledge bases as resources for troubleshooting:
- Locate product support information from the IBM® Support Portal. This portal is a
unified, centralized view of all technical support tools and information for all IBM
systems, software, and services. The IBM Support Portal lets you access the IBM
electronic support portfolio from one place. You can tailor the pages to focus on
the information and resources that you need for problem prevention and faster
problem resolution. Familiarize yourself with the IBM Support Portal by viewing the
demo videos
(https://www.ibm.com/blogs/SPNA/entry/the_ibm_support_portal_videos) about
this tool. These videos introduce you to the IBM Support Portal, explore
troubleshooting and other resources, and demonstrate how you can tailor the page
by moving, adding, and deleting portlets.
- Understand InfoSphere CDC features, system requirements, and supported
environments from the InfoSphere CDC product Web site.
- Refer to troubleshooting information from the InfoSphere CDC troubleshooting site.
- Search for content by using the IBM masthead search. You can use the IBM
masthead search by typing your search string into the Search field at the top of any
ibm.com® page.
- Search for content by using any external search engine, such as Google, Yahoo,
or Bing. If you use an external search engine, your results are more likely to
include information that is outside the ibm.com domain. However, sometimes you
can find useful problem-solving information about IBM products in newsgroups,
forums, and blogs that are not on ibm.com.Tip: Include IBM and the name of the
product in your search if you are looking for information about an IBM product.
Parent topic:Understanding where to find troubleshooting information
11
Using Support Assistant in Management Console
Support Assistant lets you collect messages that are communicated between
Management Console, Access Server, and datastores. Use Support Assistant to
collect diagnostic data such as configuration, log, and runtime information for your
support issue.
Within Management Console, select Help > Service Information > Support Assistant.
See also:
- To collect source and target information using Support Assistant
Parent topic:Understanding where to find troubleshooting information
12
To collect source and target information using
Support Assistant
Procedure
1. Start Management Console and log into Access Server.
2. Ensure you are connected to the datastores for which you want to collect
information.
3. Click Help > Service Information > Support Assistant.
4. Select the Enable Collection check box for the datastore for which you want to
collect information.
5. Click Options and click Detailed to collect detailed information for the selected
datastore.
6. Click OK.
7. Select the location where you want Support Assistant to store the output file for
the generated information.
8. Allow Support Assistant to clean up diagnostic files after collection by selecting
Clean-up diagnostic files after collection.
9. Click Collect Now to start collecting the messages.
Parent topic:Using Support Assistant in Management Console
Related concepts
- Exchanging information with IBM Support
13
Locating event messages
InfoSphere® CDC event messages help you monitor subscriptions. Use them to
understand the progress of your subscriptions and troubleshoot problems. Use the
event log within Management Console to view messages generated during
replication.
For InfoSphere CDC for z/OS®, the event log data is stored in the Product
Administration Log VSAM cluster. Events are cleaned up when an address space is
started. To set more frequent cleanup, modify the PALCLEANUPTIME parameter in
the CHCCFGxx member to set cleanup to occur every day at a specific time. In
addition, specify which events are removed during cleanup, by modifying the
PALRETPD parameter. If the PALRETPD parameter is not set, by default, events
older than two weeks are removed.
For all other InfoSphere CDC replication engines, the event log has a set default
value of 10000 messages. If InfoSphere CDC generates more events than that, it
discards the earliest events so that they are not visible from the event log. You can
increase the maximum number of events that InfoSphere CDC will store in the event
log by modifying the events_max_retain system parameter to your preferred level.
See also:
- To change the number of messages in the event log
- To remove event messages daily
Parent topic:Understanding where to find troubleshooting information
14
To change the number of messages in the event log
Procedure
1. Ensure that you are using InfoSphere® CDC with an replication engine that is not
for z/OS®.
2. Start Management Console and log into Access Server.
3. Click Configuration > Subscriptions.
4. Right-click the datastore that generates these events. This could be the source or
target database.
5. Click Properties.
6. Click Add on the System Parameters tab.
7. Type events_max_retain as the name of the parameter in the Parameter
Name box.
8. Type the number of messages you want the event log to show in the Value box.
The default is 10000 messages, and the maximum is 2147483647.
Parent topic:Locating event messages
15
To remove event messages daily
Procedure
1. Ensure that you are using InfoSphere® CDC for z/OS®.
2. Set the PALCLEANUPTIME parameter in the CHCCFGxx member to the time
that clean up should occur each day.
3. Set the PALRETPD parameter in the CHCCFGxx member to the number of days
that you want to retain messages.
Parent topic:Locating event messages
16
Locating log files
In addition to the Management Console event log, InfoSphere® CDC produces
other logs to help troubleshoot installation and replication errors.
Review the log files in the <CDC_installation directory>\Uninstall\Logs directory
if you encounter any errors during the installation of InfoSphere CDC, Management
Console, or Access Server.
For InfoSphere CDC for z/OS®, if you encounter replication errors or replication
stops, review the SPOOLed output for the address space:
- CHCPRINT—Contains all messages issued by the product during replication. This
should be viewed for all error and warning messages.
- CHCAUDIT—Contains information on maintenance applied and parameters used
for the running address space, and information on configuration changes to
replication.
- CHCREPRT—Contains output from reports. Some errors cause diagnostic reports
to be generated. The staging space report can be run against an active
subscription to report on the Units of Recovery in progress.
For all other InfoSphere CDC replication engines, if you encounter replication errors
or replication stops, review any of these trace logs:
- <CDC_installation_directory>/log—This directory contains information for an
InfoSphere CDC problem. Refer to this directory if the problem is related to
configuring an InfoSphere CDC instance. However, it is always useful to refer this
directory as well as the <CDC_installation_directory>/instance/<instance_name>
/log directory to troubleshoot any problem.
- <CDC_installation_directory>/instance/<instance_name>/log—This directory
stores trace files for a specific InfoSphere CDC instance. It is also useful to refer to
the <CDC_installation_directory>/instance/<instance_name>/log directory to
troubleshoot your problem. When tracing has been enabled, the trace files will be
enabled under <CDC_installation_directory>/instance/<instance_name>/log/on.
- <CDC_installation_directory>/instance/<instance_name>/tmp—This directory
temporarily stores data such as incomplete large transactions and large LOB data
values.
- <CDC_installation_directory>/instance/<instance_name>/stagingstore—This
directory stores sincle scrape staging store data that does not fit in memory. When
an InfoSphere CDC instance is stopped normally, the contents of this staging store
are written to files that are stored in this directory.
Parent topic:Understanding where to find troubleshooting information
17
Enabling detailed tracing for InfoSphere CDC for
z/OS
Tracing of InfoSphere® CDC for z/OS® tasks should only be performed once IBM®
Support has reviewed the SPOOLed output and can provide advice on the trace
points to enable if it is necessary to further the investigation.
Tracing is initiated through a modify command issued to a specific task. Your
support representative will provide the specific command required to gather the
needed information. By default, the trace is directed to GTF and requires that GTF is
running and configured to accept InfoSphere CDC trace records. The trace may be
redirected to SYSOUT with the TRACEDEST command. Here are examples using
the TRACEDEST command for this purpose: MODIFY <address_space>,TRACEDEST=SYSOUT
F <address_space>,TRACEDEST=SYSOUT
Parent topic:Understanding where to find troubleshooting information
18
Enabling detailed InfoSphere CDC tracing for
distributed systems
When troubleshooting InfoSphere® CDC and there are no clear error messages in
the Management Console event log, or product logs for failures, the next best
diagnostic tool is product tracing.
A minimal level of tracing is always enabled. This contains additional information
beyond what is stored in the event logs. Before enabling additional tracing, consider
whether the minimal level is sufficient for your environment.
You can turn on additional tracing by modifying InfoSphere CDC system
parameters:
- global_trace_hours—Set this system parameter to specify the number of hours for
which tracing is to be enabled. You can either set this parameter to a numeric
value to represent the number of hours tracing will be enabled, or you can set it to
minutes using the format hhh:mm. Once the time is set, it will be decremented by 1
every minute. So once set, the value of this system parameter will be constantly
changing if viewed in Management Console.
- global_trace_files_total_mb—Set this system parameter to 200. This indicates the
total size of all trace files in MBs.
- global_trace_files_each_mb—Set this system parameter to 20. This indicates the
size of an individual trace file in MBs. This value should be kept at a manageable
level for file transferring and manipulation, especially when you use a text editor to
open the file.
You can enable system parameters using Management Console or the dmset
command line utility available in the /bin directory of your InfoSphere CDC
installation. There is no need to restart the instance after turning on tracing. Since
tracing significantly degrades performance, it should only be used when necessary
while troubleshooting the problem.
Trace files are located in the following directories:
- <CDC_installation_directory>/log—Contains trace files that can be relevant to all
instances.
- <CDC_installation_directory>/instance/<instance_name>/log—Contains trace
information for a specific instance.
See also:
- To enable tracing using Management Console
- To enable tracing using the dmset command line utility
- To disable tracing using Management Console
- To disable tracing using the dmset command line utility
Parent topic:Understanding where to find troubleshooting information
19
To enable tracing using Management Console
Procedure
1.
2.
3.
4.
5.
6.
Start Management Console and log into Access Server.
Click Configuration > Datastores.
Right-click on a datastore and select Properties.
On the System Parameters tab, click Add.
Type global_trace_hours in the Parameter Name box.
Type a number in the Value box to set the amount of time that tracing will be
enabled.You can either set this parameter to a numeric value to represent the
number of hours tracing will be enabled, or you can set it to minutes using the
format hhh:mm. The following list provides some sample values:
- 2 would enable tracing immediately; tracing would continue for two hours
- 013:30 would enable tracing immediately; tracing would continue for thirteen
hours and thirty minutes
- 000:90 would enable tracing immediately; tracing would continue for ninety
minutes
Once the time is set, it will be decremented by minutes. So once set, the value
of this system parameter will be constantly changing if viewed in Management
Console. Once the value is zero, tracing will be disabled.
7. Type global_trace_files_total_mb in the Parameter Name box.
8. Type 200 in the Value box.
9. Type global_trace_files_each_mb in the Parameter Name box.
10. Type 20 in the Value box.
Parent topic:Enabling detailed InfoSphere CDC tracing for distributed systems
20
To enable tracing using the dmset command line
utility
Procedure
1. Navigate to the bin directory under your InfoSphere® CDC installation directory.
To view the available parameters and a description for each, type dmset -?.
Depending on whether or not you have set the environment variable for
TSINSTANCE, you can run the dmset command with or without the -I option. For
example, if you have set the environment variable TSINSTANCE to match the
name of your InfoSphere CDC instance, then you can run the command without
<instance_name> parameter as follows:
dmset "global_trace_hours=013:30"
For example, if you have not set the environment variable and the name of your
InfoSphere CDC instance is MYINSTANCE, then you would specify:
dmset -I MYINSTANCE "global_trace_hours=013:30"
If the command runs successfully, it returns a value of 0. Otherwise, if the
command fails, it returns a non-zero value.
2. Run the command with the global_trace_hours parameter:You can either set this
parameter to a numeric value to represent the number of hours tracing will be
enabled, or you can set it to minutes using the format hhh:mm. The following list
provides some sample values:
- 2 would enable tracing immediately; tracing would continue for two hours
- 013:30 would enable tracing immediately; tracing would continue for thirteen
hours and thirty minutes
- 000:60 would enable tracing immediately; tracing would continue for sixty
minutes
Once the time is set, it will be decremented by 1 every minute. So once set, the
value of this system parameter will be constantly changing if viewed in
Management Console.
- If you have set the environment variable TSINSTANCE to match the name of
your InfoSphere CDC instance, run: dmset
"global_trace_hours=000:60"
.
- If you have not set the environment variable and the name of your InfoSphere
CDC instance is MYINSTANCE, then run: dmset -I MYINSTANCE
"global_trace_hours=000:60"
If the command runs successfully, it returns a value of 0. Otherwise, if the
command fails, it returns a non-zero value.
3. Run the command with the global_trace_files_total_mb parameter:
- If you have set the environment variable TSINSTANCE to match the name of
your InfoSphere CDC instance, run: dmset
"global_trace_files_total_mb=200"
.
21
- If you have not set the environment variable and the name of your InfoSphere
CDC instance is MYINSTANCE, then run: dmset -I MYINSTANCE
global_trace_files_total_mb=200
If the command runs successfully, it returns a value of 0. Otherwise, if the
command fails, it returns a non-zero value.
4. Run the command with the global_trace_files_each_mb parameter:
- If you have set the environment variable TSINSTANCE to match the name of
your InfoSphere CDC instance, run: dmset
"global_trace_files_each_mb=20"
.
- If you have not set the environment variable and the name of your InfoSphere
CDC instance is MYINSTANCE, then run: dmset -I MYINSTANCE
global_trace_files_each_mb=20
If the command runs successfully, it returns a value of 0. Otherwise, if the
command fails, it returns a non-zero value.
Parent topic:Enabling detailed InfoSphere CDC tracing for distributed systems
22
To disable tracing using Management Console
Procedure
1. Start Management Console and log into Access Server.
2. Click Configuration > Datastores.
3. Right-click on a datastore and select Properties.
4. Select global_trace_hours and set its value to zero.Alternatively, you can
select global_trace_hours and click Delete
5. Verify that tracing has been disabled by looking for Trace is off in the trace.
Parent topic:Enabling detailed InfoSphere CDC tracing for distributed systems
23
To disable tracing using the dmset command line
utility
Procedure
1. Navigate to the bin directory under your InfoSphere® CDC installation directory.
2. Run the following command:dmset -I <instance_name>
global_trace_hours=
If the command runs successfully, it returns a value of 0. Otherwise, if the
command fails, it returns a non-zero value.
Parent topic:Enabling detailed InfoSphere CDC tracing for distributed systems
24
Using trace options in Management Console
Use the Management Console trace options to enable tracing of messages between
Access Server, Management Console, and datastores. The message collection
includes configuration information for the products, any log files, or any error reports.
Use the trace options within Management Console when you have encountered a
problem with Management Console and you want to send the issue to IBM®
Support.
Within Management Console, select Help > Service Information > Trace Options >
Enable the collection of tracing information and complete the following
troubleshooting tasks:
- Capture Access Server messages—Diagnoses configuration and monitoring
problems between Management Console, Access Server, and datastores.
- Capture Management Console messages—Diagnoses problems between a single
Management Console and Access Server or datastores.
- Capture Access Server logging information—Diagnoses Access Server-specific
problems. This option should only be used when instructed by IBM Support.
Management Console tracing is enabled until you close or restart Management
Console. Likewise, Access Server tracing is enabled until you end or restart Access
Server.
See also:
- To enable tracing for Management Console messages
- To enable tracing for Access Server messages
- To enable tracing for Access Server log information
- To disable tracing for Management Console messages
- To disable tracing for Access Server messages
- To disable tracing for Access Server log information
Parent topic:Understanding where to find troubleshooting information
25
To enable tracing for Management Console
messages
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Select Enable the collection of tracing information.
4. Select Capture Management Console messages.
Parent topic:Using trace options in Management Console
26
To enable tracing for Access Server messages
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Select Enable the collection of tracing information.
4. Select Capture Access Server messages.
Parent topic:Using trace options in Management Console
27
To enable tracing for Access Server log information
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Select Enable the collection of tracing information.
4. Select Capture Access Server log information.
Parent topic:Using trace options in Management Console
28
To disable tracing for Management Console
messages
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Clear Enable the collection of tracing information.
Parent topic:Using trace options in Management Console
29
To disable tracing for Access Server messages
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Clear Enable the collection of tracing information.
Parent topic:Using trace options in Management Console
30
To disable tracing for Access Server log
information
Procedure
1. Start Management Console and log into Access Server.
2. Click Help > Service Information > Trace Options.
3. Clear Enable the collection of tracing information.
Parent topic:Using trace options in Management Console
31
Troubleshooting installation and configuration
Follow the steps in the Management Console and Access Server installation guide
to install and configure Management Console and Access Server. Follow the steps
in the InfoSphere® CDC end-user documentation to install and configure an
instance of InfoSphere CDC.
If you encounter problems with these tasks, troubleshoot them.
Review the log files in the <CDC_installation directory>\Uninstall\Logs directory
if you encounter any errors during the installation of InfoSphere CDC, Management
Console, or Access Server.
In this section, you will learn:
- Encountering a previous instance of InfoSphere CDC in the instance list
- Encountering an ./oraclenativeapi.dll is not a valid win2k application
message
- Encountering problems while using InfoSphere CDC for InfoSphere
DataStage with Direct Connect
- Encountering a You must perform a FULL DATABASE BACKUP to start the
FULL or BULK-LOGGED RECOVERY MODEL message when configuring
InfoSphere CDC for DB2 for LUW
- Encountering a You must perform a FULL DATABASE BACKUP to start the
FULL or BULK-LOGGED RECOVERY MODEL message when configuring
InfoSphere CDC for Microsoft SQL Server
- Encountering a The RECOVERY MODEL for the database must be FULL or
BULK-LOGGED message when configuring InfoSphere CDC for Microsoft
SQL Server
- Encountering a Microsoft SQL Server is not configured for distribution. You
must configure distribution in Microsoft SQL Server message when
configuring InfoSphere CDC for Microsoft SQL Server
- Encountering a Cannot bulk load because the file
"\\<server_name>\<directory_name>\<bcp_file_name>.bcp" could not be
opened. Operating system error code 5 (Access is denied.) message when
configuring InfoSphere CDC for Microsoft SQL Server
- Encountering a Failed to initialize SMO message when configuring
InfoSphere CDC for Microsoft SQL Server
- Configuration tool hangs during instance creation
- Encountering an Invalid internal file structure contents detected in file
<file_name> message and InfoSphere CDC for Oracle databases shuts down
- Encountering an com.datamirror.ts.commandlinetools.config.TsConfigError:
IBM InfoSphere Change Data Capture communication failure error during
configuration
32
Encountering a previous instance of InfoSphere
CDC in the instance list
Environment
Any InfoSphere® CDC replication engine on a Windows environment.
Symptoms
You uninstall InfoSphere CDC, and the previous instance remains in the instance
list. You cannot remove this instance from the instance list in the configuration utility.
You encounter the following error: Cannot save changes: There is a problem with
the TS service: Error: Access is denied.
Causes
If the Windows user account control feature is enabled, then you cannot write to the
services file that retains previous installed services (such as InfoSphere CDC
instances). Resolution
Disable user account control or request your system administrator to disable this
feature for you. Refer to your Windows documentation for more details.
Parent topic:Troubleshooting installation and configuration
33
Encountering an ./oraclenativeapi.dll is not a valid
win2k application message
Environment
Any InfoSphere® CDC replication engine on a Windows environment.
Symptoms
You tried to create an instance of InfoSphere CDC and you encounter the following
error or one that is similar except for the name of the DLL: ./oraclenativeapi.dll is not
a valid win2k application
Causes
You may be trying to create a 64-bit instance of InfoSphere CDC with a 32-bit of
your database. Resolution
When configuring a InfoSphere CDC instance, choose the bit length for InfoSphere
CDC that matches the bit length of the database client libraries that you have
installed.
Parent topic:Troubleshooting installation and configuration
34
Encountering problems while using InfoSphere
CDC for InfoSphere DataStage with Direct Connect
Environment
InfoSphere® CDC for InfoSphere DataStage®. Symptoms
While mapping tables using the Direct Connect method, InfoSphere CDC for
InfoSphere DataStage fails after mirroring has been initiated. Causes
To use the Direct Connect method for table mapping, you must successfully
integrate InfoSphere CDC and InfoSphere DataStage, and apply the necessary
fixes. Resolution
Download and install the following fixes from Fix Central
(http://www.ibm.com/support/fixcentral):
- InfoSphere CDC for InfoSphere DataStage 6.5 interim fix 2 or higher
- Either of these InfoSphere DataStage fixes:
- InfoSphere DataStage 8.5 patch JR37451 and InfoSphere DataStage 8.5 patch
JR38113
- InfoSphere DataStage 8.5 fix pack 1
To download InfoSphere CDC for InfoSphere DataStage 6.5 interim fix 2 or higher:
1. Go to http://www.ibm.com/support/fixcentral.
2. Select Information Management from the Product Group list.
3. Select IBM InfoSphere Change Data Capture from the Product list.
4. Select 6.5.0 from the Installed Version list.
5. Select your operating system from the Platform list.
6. Click Continue.
7. Select Browse for fixes.
8. Click Continue.
9. Select interim fix 2 or above, and proceed to download.
To download InfoSphere DataStage 8.5 patch JR37451:
1. Go to http://www.ibm.com/support/fixcentral.
2. Enter JR37451 in the Search field.
3. Click Search.
4. Select JR37451 from the search results.
To download InfoSphere DataStage 8.5 patch JR38113:
1. Go to http://www.ibm.com/support/fixcentral.
2. Enter JR38113 in the Search field.
3. Click Search.
4. Select JR38113 from the search results.
To download InfoSphere DataStage 8.5 fix pack 1:
1. Go to http://www.ibm.com/support/fixcentral.
2. Select Information Management from the Product Group list.
3. Select IBM InfoSphere DataStage from the Product list.
4. Select All from the Installed Version list.
5. Select your operating system from the Platform list.
6. Click Continue.
7. Select Browse for fixes.
35
8. Click Continue.
9. Select fix pack 1, and proceed to download.
Parent topic:Troubleshooting installation and configuration
36
Encountering a You must perform a FULL
DATABASE BACKUP to start the FULL or BULKLOGGED RECOVERY MODEL message when
configuring InfoSphere CDC for DB2 for LUW
Environment
InfoSphere® CDC for DB2® for LUW. Symptoms
When configuring an instance of InfoSphere CDC using the InfoSphere CDC
configuration tool, you receive the following error:You must perform a FULL
DATABASE BACKUP to start the FULL or BULK-LOGGED RECOVERY MODEL
Causes
You have not performed a full database backup. You must perform a full backup of
your database to start using the full or bulk-logged recovery model. A full database
backup activates the new recovery model. Until you perform a full database backup,
your database will continue logging with the simple recovery model. Resolution
Back up your database. For example, the following SQL statement will perform a full
backup of the abc database:BACKUP DATABASE abc TO DISK = 'c:\mssql\backup\abc.bak'
For more information on how to perform this task, contact your database
administrator or refer to your database documentation.
Parent topic:Troubleshooting installation and configuration
37
Encountering a You must perform a FULL
DATABASE BACKUP to start the FULL or BULKLOGGED RECOVERY MODEL message when
configuring InfoSphere CDC for Microsoft SQL
Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptoms
When configuring an instance of InfoSphere CDC using the InfoSphere CDC
configuration tool, you receive the following error:You must perform a FULL
DATABASE BACKUP to start the FULL or BULK-LOGGED RECOVERY MODEL
Causes
There are two possible causes to this problem:
- You have not performed a full database backup. You must perform a full backup of
your database to start using the full or bulk-logged recovery model. A full database
backup activates the new recovery model. Until you perform a full database
backup, your database will continue logging with the simple recovery model.
- In Microsoft SQL Server, your transaction log may have been backed up at some
point with the truncate only options (BACKUP LOG WITH NO_LOG or BACKUP
LOG WITH TRUNCATE_ONLY). As a result, your Microsoft SQL Server database
reverts to logging using the simple recovery model, despite showing that it is using
the full or bulk-logged recovery model.
Resolution
Back up your database. For example, the following SQL statement will perform a full
backup of the abc database:BACKUP DATABASE abc TO DISK = 'c:\mssql\backup\abc.bak'
For more information on how to perform this task, contact your database
administrator or refer to your database documentation.
Parent topic:Troubleshooting installation and configuration
38
Encountering a The RECOVERY MODEL for the
database must be FULL or BULK-LOGGED message
when configuring InfoSphere CDC for Microsoft
SQL Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptoms
When configuring an instance of InfoSphere CDC using the configuration tool, you
encounter the following error:The RECOVERY MODEL for the database must be
FULL or BULK-LOGGED.
Causes
InfoSphere CDC requires the full or bulk-logged recovery model (versus a simple
one) in your Microsoft SQL Server database. Resolution
In Microsoft SQL Server, configure your recovery model to be either full or bulklogged. The following example uses a SQL statement to configure the recovery
model for the ABC database:ALTER DATABASE ABC SET RECOVERY FULL
For more information on how to perform this task in Microsoft SQL Server, contact
your database administrator or refer to your Microsoft SQL Server documentation.
Note: Once you have completed the changes to the recovery mode, ensure you
complete these steps:
- Run a full database backup.
- Configure the instance of InfoSphere CDC.
Parent topic:Troubleshooting installation and configuration
39
Encountering a Microsoft SQL Server is not
configured for distribution. You must configure
distribution in Microsoft SQL Server message when
configuring InfoSphere CDC for Microsoft SQL
Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptoms
You configure an instance of InfoSphere CDC as a source. The configuration tool
displays this error:Microsoft SQL Server is not configured for distribution. You must
configure distribution in Microsoft SQL Server.
Causes
InfoSphere CDC requires that you enable Microsoft SQL Server replication in your
database to ensure the data required by the product is available in the database
transaction log. A distribution database stores metadata and history data for
replication. Resolution
Enable Microsoft SQL Server replication in your database. Microsoft SQL Server
supports a local distribution database (local distributor) or a remote distribution
database (remote distributor). If you are using a remote distribution database, you
are required to install InfoSphere CDC on your local database server, not the
distribution database server.For more information on how to perform this task in
Microsoft SQL Server, contact your database administrator or refer to your
Microsoft SQL Server documentation.
Parent topic:Troubleshooting installation and configuration
40
Encountering a Cannot bulk load because the file
"\\<server_name>\<directory_name>\
<bcp_file_name>.bcp" could not be opened.
Operating system error code 5 (Access is denied.)
message when configuring InfoSphere CDC for
Microsoft SQL Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptom
When configuring an instance of InfoSphere CDC using the configuration tool, you
receive an error (event ID 6645) similar to the following in the event log:Exception
occurred during replication. Errors occurred in BCP: java.sql.SQLException:
[CDC][SQLServer JDBC Driver][SQLServer] Cannot bulk load because the file
"\\<server_name>\<directory_name>\<bcp_file_name>.bcp" could not be opened.
Operating system error code 5(Access is denied.).
Causes
Microsoft SQL Server does not have read permission for the InfoSphere CDC
refresh loader directory (local or remote) that you specified in the configuration tool.
Microsoft SQL Server requires read permission for this directory; InfoSphere CDC
requires read and write permissions for this directory. User accounts for Microsoft
SQL Server and InfoSphere CDC must also be from the same domain.
Resolution
On the Windows server where Microsoft SQL Server is installed, grant Microsoft
SQL Server read and write permission for the refresh loader directory that you
specified in the configuration tool.
Parent topic:Troubleshooting installation and configuration
41
Encountering a Failed to initialize SMO message
when configuring InfoSphere CDC for Microsoft
SQL Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptoms
You deploy InfoSphere CDC as a target on a different machine from your target
database. When configuring an instance, you receive an error message that starts
with the following text:Failed to initialize SMO ...
Causes
To allow InfoSphere CDC to communicate with the target database, you must install
Microsoft SQL Server connectivity tools on the server where you install InfoSphere
CDC. Resolution
Install SQL Server 2008 Management Objects (SMO). This software package is
available for download at www.microsoft.com.
Parent topic:Troubleshooting installation and configuration
42
Configuration tool hangs during instance creation
Environment
InfoSphere® CDC for Sybase databases Symptoms
While you were attempting to create an instance, the InfoSphere CDC configuration
tool hangs. Causes
The log and data devices for the Sybase database selected for the instance could
be full, resulting in Sybase not being able to process any new data changes.
Resolution
The database’s log and data devices will need to have sufficient disk space to hold
the requested data.
Parent topic:Troubleshooting installation and configuration
43
Encountering an Invalid internal file structure
contents detected in file <file_name> message and
InfoSphere CDC for Oracle databases shuts down
Environment
InfoSphere® CDC for Oracle databases. Symptoms
InfoSphere CDC shuts down with this error:2919: Invalid internal file structure
contents detected in file <file_name>.
Causes
Your InfoSphere CDC installation needs to be configured to recognize ASM
(Automatic Storage Management). If the Oracle redo logs are stored on an ASM
device, when rebalance happens, the raw device locations that the InfoSphere CDC
log reader is using to read the raw device blocks become invalid and the log reader
fails. You may experience symptoms such as incorrect data on the target and likely
end with InfoSphere CDC shutting down with an error. Resolution
Refresh your data because of incorrect data on the target. Use one of the following
resolutions to address this problem:
- Set InfoSphere CDC to read archive logs only—Set InfoSphere CDC to only
read archive logs. This requires storing archive logs on a different device other
than ASM. By default, InfoSphere CDC reads both Oracle online redo logs and
Oracle archive redo logs. Modify the oracle_archive_logs_only system parameter
to true so that InfoSphere CDC only reads archive logs. Note: This method will
lead to latency as InfoSphere CDC must wait for the logs to be archived which can
take minutes to hours, depending on the data volume and your Oracle
configuration.
- Clean up staging stores and transaction queues when you rebalance ASM
—Changing the priority (ASM power limit) of when you rebalance will affect the
frequency of this error. While this will not resolve the problem entirely, you can at
least continue replicating with InfoSphere CDC until the next time you encounter
this error. For more information on how to clean up your staging stores, see the
resolution outlined in Encountering a The single scrape staging store is corrupted.
To resolve this issue, you must clear the staging store using the
dmclearstagingstore command line utility message after running
dmclearstagingstore.
- Set InfoSphere CDC for remote log shipping—Ship your logs from the ASM
device to the database where InfoSphere CDC is installed. Use Oracle's Data
Guard Log Transport services. Alternatively, you can configure InfoSphere CDC to
use custom scripts to ship log files. For more information on how to configure log
shipping, see Configuring InfoSphere CDC for Oracle databases for log shipping.
Parent topic:Troubleshooting installation and configuration
44
Encountering an
com.datamirror.ts.commandlinetools.config.TsConfi
gError: IBM InfoSphere Change Data Capture
communication failure error during configuration
Environment
InfoSphere® CDC for Oracle databases. Symptoms
When attempting to configure InfoSphere CDC on to work with an Oracle 11g
database configured with Automatic Diagnostic Repository (ADR) running on AIX,
the InfoSphere CDC configuration tool may fail with a stack trace that begins with
com.datamirror.ts.commandlinetools.config.TsConfigError: IBM InfoSphere Change
Data Capture communication failure” Causes
The configuration tool was unable to connect to the Oracle database.
Resolution
There are two known resolutions to this issue:
1. Turn off ADR by issuing the Oracle statement (set diag_adr_enabled=false)
2. Increase the pthread_stack_size by setting the environment variable
PTHREAD_DEFAULT_STACK_SIZE to a large enough value
Parent topic:Troubleshooting installation and configuration
45
Troubleshooting Access Server and Management
Console
Management Console is a graphical user interface application that you use to
configure, monitor and manage replication on various servers, specify replication
parameters, and initiate refresh and mirroring operations from a client workstation.
Before you log into Management Console, you must first install and start Access
Server.
In this section, you will learn:
- Encountering a Your account has been locked because the number of
consecutive log-in failures exceeded the maximum allowed message when
logging into Management Console
- Encountering a Could not connect to Access Server using the <server
name> and <port number>. Access Server may be down or the host name
and/or port number may be incorrect message when logging into
Management Console or connecting to Access Server
- Encountering an Access Server could not connect to the database. Do you
want to retry with a new name or password? or Management Console could
not establish a connection to the datastore. An error has occurred while
communicating with agent: java.net.ConnectException: Connection refused:
connect message when connecting to a datastore in Management Console
- Encountering an An error occurred during communication initialization
message after changing the host name or port for a source datastore and
attempting to replicate to the target
- Changing the host name or port for a target datastore shows duplicate
subscriptions in Management Console
46
Encountering a Your account has been locked
because the number of consecutive log-in failures
exceeded the maximum allowed message when
logging into Management Console
Environment
InfoSphere® CDC for all replication engines. Symptoms
You cannot log into Management Console and receive the following error message:
Your account has been locked because the number of consecutive log-in failures
exceeded the maximum allowed. Please contact your IBM InfoSphere Change Data
Capture administrator for assistance.
Causes
A user account is automatically locked after the number of failed login attempts
exceeds the locking policy your Access Server system administrator (with rights to
manage accounts) may have set in the Access Server Options dialog box in
Management Console. A system administrator with privileges to manage datastores
and user accounts can unlock the account. Resolution
If you are not a system administrator, contact your system administrator to unlock
your account in Management Console. To unlock a Management Console user
account:
1. Ensure you have system administrator authority with privileges to manage
datastores and user accounts in Management Console
2. Start Management Console and log into Access Server.
3. Click Access Manager > User Management.
4. Right-click the user that is locked out of the account and select Properties.
5. Disable the Account is locked check box.This check box is enabled automatically
after the number of failed login attempts exceeds the locking policy set in the
Access Server Options dialog box within Management Console.
If you are the system administrator and you are locked out, then issue the
dmunlockuser command to unlock your own account. To unlock a system
administrator account for Management Console:
1. Ensure you have system administrator authority with privileges to manage
datastores and user accounts in Management Console
2. Issue the dmunlockuser command where Access Server is installed:dmunlockuser
user_name [-accessserver hostnameportadminuseradminpassword]
where the values for the parameters are as follows:
- username
- Specifies the name of the Management Console user you want to unlock.
The user_name is the only required parameter.
The following parameters are optional and are only required if you are running
this command remotely from the system where you have installed Access Server
. The -accessserver parameter indicates that you want to connect to a remote
installation of Access Server. It indicates that you want to run this command for
an installation of Access Server that is physically remote from the Access Server
installation where you are running this command.
- hostname
- The fully qualified host name of the remote system where Access Server is
installed.
47
- port
- The port number of the remote system where Access Server is installed.
- adminuser
- A user with system administrator (SYSADMIN) privileges (see role parameter
in the dmcreateuser command) and the ability to manage users and
datastores (see manager parameter in the dmcreateuser command).
- adminpassword
- The password for the specified SYSADMIN user.
Parent topic:Troubleshooting Access Server and Management Console
48
Encountering a Could not connect to Access
Server using the <server name> and <port number>
. Access Server may be down or the host name
and/or port number may be incorrect message when
logging into Management Console or connecting to
Access Server
Environment
InfoSphere® CDC for all replication engines. Symptoms
While attempting to log into Management Console, you receive the following error
message:
Could not connect to Access Server using the <server name> and <port number>.
Access Server may be down or the host name and/or port number may be
incorrect. Verify your connection settings and try again. Causes
There are several causes for not being able to connect to Access Server:
- Your user name, password, host name, port number, or combination, specified to
access Management Console is incorrect.
- The Access Server service may not be running.
- If you are running a client firewall, it may be blocking Management Console.
- If you are running a server firewall between Access Server and Management
Console, it may be blocking local ports to access Management Console.
Resolution
If you cannot access Management Console because of an incorrect user name,
password, host name, port number, or combination, take action depending on your
access level with Management Console. If you are a system administrator, log on
using the user name, password, host name, and port number that you specified
when you installed and configured Access Server and Management Console. If you
are a user without system administrator authority, you may not have the correct
Management Console login information. Contact your system administrator to verify
this information.If you cannot access Management Console because Access Server
has not started, you must start it. On Windows, select Control Panel >
Administrative Tools > Services. Next, right-click IBM®InfoSphere Change Data
CaptureAccess Server and click Start. On the UNIX or Linux platforms, navigate to
the /bin directory under your Access Server installation directory and run
./dmaccessserver &.
If you cannot access Management Console because of client firewall blocking
Management Console, modify your client firewall configuration settings:
1. Locate the file you use to configure your client firewall settings.If you are unsure
of how or where to edit firewall configuration settings, consult your firewall
documentation.
2. Add DmClient.exe to the list of firewall exceptions.
If you cannot access Management Console because of server firewall blockages
between Access Server and Management Console, create a well-defined set of
ports between Access Server and the datastore and then ensure your firewall allows
connections to those ports:
1. Open the dmaccessserver.vmargs file in a text editor. This file is located in the
conf directory under your Access Server installation directory.
49
2. Edit the local_port and local_port_count entries as follows:-jar
lib/server.jar local_port:<first_port> local_port_count:
<number_available_ports><Access_Server_listener_port>
where:
- <first_port>—The first port in the range that you want the Access Server service
to use when sending messages or establishing connections.
- <number_available_ports>—The number of ports you want to reserve for this
use.To calculate the number of Access Server ports to open, use this formula:
number of ports to open
= 2 * (number of users + (number of users * number of datastores)
+ number of datastores)
where a datastore refers to an instance InfoSphere CDC.
- <Access_Server_listener_port>—The port number that Access Server listens
on. This is set during the Access Server installation. You do not have to specify
a value here if you are using the default port number of 10101.
For example, if the number of available ports for communication is 500 and you
want Access Server to listen for connections on port 10101, then the entry would
be as follows: -jar lib/server.jar local_port:10102 local_port_count:500 10101
This enables Access Server to listen for connections on port 10101 and restricts it
to using ports in the range of 10102 to 10601.
3. Restart the Access Server service to the new firewall settings to take effect.
4. Modify your firewall configuration settings to accept connection to the Access
Server ports defined above.
Parent topic:Troubleshooting Access Server and Management Console
50
Encountering an Access Server could not connect
to the database. Do you want to retry with a new
name or password? or Management Console could
not establish a connection to the datastore. An error
has occurred while communicating with agent:
java.net.ConnectException: Connection refused:
connect message when connecting to a datastore in
Management Console
Environment
InfoSphere® CDC for all replication engines. Symptoms
While attempting to connect to a datastore in Management Console, you receive
one of the following error messages:
- Access Server could not connect to the database. Do you want to retry with a new
name or password?
- Management Console could not establish a connection to the datastore. An error
has occurred while communicating with agent: java.net.ConnectException:
Connection refused: connect.
Causes
If you are the system administrator that has assigned a user to this datastore, you
may not have specified the correct host name, port number, or connection settings
in Management Console. If there is a server firewall between Access Server and the
datastore, it may be disallowing connections between them.
Resolution
To ensure the user access parameters for the datastore are correct, verify them in
the Access Server perspective of Management Console:
1. Start Management Console and log into Access Server.
2. Click Access Manager > User Management.
3. Right-click the user from the list and select Assign Datastore.
4. Ensure the access parameters for the datastore are correct.
To ensure you can connect to datastores, prevent a server firewall blockage
between Access Server and Management Console by creating a well-defined set of
ports between Access Server and the datastore and then ensuring your firewall
allows connections to those ports:
1. Open the dmaccessserver.vmargs file in a text editor. This file is located in the
conf directory under your Access Server installation directory.
2. Edit the local_port and local_port_count entries as follows:-jar
lib/server.jar local_port:<first_port> local_port_count:
<number_available_ports><Access_Server_listener_port>
where:
- <first_port>—The first port in the range that you want the Access Server service
to use when sending messages or establishing connections.
- <number_available_ports>—The number of ports you want to reserve for this
use.To calculate the number of Access Server ports to open, use this formula:
number of ports to open
= 2 * (number of users + (number of users * number of datastores)
+ number of datastores)
where a datastore refers to an instance InfoSphere CDC.
51
- <Access_Server_listener_port>—The port number that Access Server listens
on. This is set during the Access Server installation. You do not have to specify
a value here if you are using the default port number of 10101.
For example, if the number of available ports for communication is 500 and you
want Access Server to listen for connections on port 10101, then the entry would
be as follows: -jar lib/server.jar local_port:10102 local_port_count:500 10101
This enables Access Server to listen for connections on port 10101 and restricts it
to using ports in the range of 10102 to 10601.
3. Restart the Access Server service to the new firewall settings to take effect.
4. Modify your firewall configuration settings to accept connection to the Access
Server ports defined above.
Parent topic:Troubleshooting Access Server and Management Console
52
Encountering an An error occurred during
communication initialization message after
changing the host name or port for a source
datastore and attempting to replicate to the target
Environment
InfoSphere® CDC for all replication engines. Symptoms
You have changed the host name or port for a datastore used as the source in a
subscription, and are unable to replicate data to the target datastore. You received
this message in the Management Console event log:An error occurred during
communication initialization.
If you initiate replication using the dmstartmirror command instead, you also see an
error message, guiding you to the event log: There was an error for
<subscription_name>. See the event log for details.
Causes
The source subscription configuration can optionally identify the host name that is
used to select the network interface used by InfoSphere CDC. When you change
the host name for the source machine and update the datastore definition in Access
Manager, the subscription itself may still reference the old host name or port.
Resolution
Ensure that the source subscriptions map to that new datastore host name and port:
1. Restart Access Server to ensure there are no users logged in.
2. Start Management Console and log into Access Server.Note: If you use the
auto-connect feature for connecting to datastores, turn it off by clicking Edit >
Preferences > Connect, and disabling Connect to Datastores Automatically prior
to connecting to Access Server.
3. Click Access Manager > Datastore Management.
4. Right-click the datastore and select Properties.
5. Update the Host Name and Port fields for the datastore.
6. Click OK.
7. Click File > Access Server > Disconnect to log off Access Server.
8. Click File > Access Server > Connect and log back into Access Server.
9. Click Configuration > Datastores.
10. Connect to the source datastore by right-click it and selecting Connect.
11. Right-click the subscription from the Subscriptions perspective, and select
Properties.
12. Click Advanced Settings.
13. Verify that the value in the TCP Host field. If it identifies the old host name,
select Auto-Select and then click OK.
14. Click OK.
15. If this datastore is also the target for subscriptions, follow the steps to update
related subscriptions in Changing the host name or port for a target datastore
shows duplicate subscriptions in Management Console.
Parent topic:Troubleshooting Access Server and Management Console
53
Changing the host name or port for a target
datastore shows duplicate subscriptions in
Management Console
Environment
InfoSphere® CDC for all replication engines. Symptoms
You have changed the host name or port for a datastore used as the target in a
subscription, and now see duplicate subscriptions in the Management Console
Subscriptions view. One of the subscriptions shows the correct datastore, but the
target is identified as the old host name and port. The other subscription shows that
the source datastore is unknown and the correct target datastore. Causes
The source component of the subscription stores the host name and port for the
target, so that the source and target can communicate. When you change the host
name or port for the datastore, and update the datastore definition in Access
Manager, existing subscriptions will continue to reference the old host name or port.
Resolution
Ensure that the target subscriptions map to the new datastore host name and port
information:
1. Restart Access Server to ensure there are no users logged in.
2. Start Management Console and log into Access Server.Note: If you use the
auto-connect feature for connecting to datastores, turn it off by clicking Edit >
Preferences > Connect, and disabling Connect to Datastores Automatically prior
to connecting to Access Server.
3. Click Access Manager > Datastore Management.
4. Right-click the datastore and select Properties.
5. Update the Host Name and Port fields for the datastore.
6. Click OK.
7. Click File > Access Server > Disconnect to log off Access Server.
8. Click File > Access Server > Connect and log back into Access Server.
9. Click Configuration > Datastores.
10. Connect to the datastore and to all datastores that have subscriptions where this
datastore is the target, by right-clicking the target datastores and selecting
Connect.
11. Right-click the datastore you updated above from the Datastores perspective,
and select Properties.
12. Click Update Related Subscriptions and complete the steps to update the
subscriptions where this datastore is the target.
13. If this datastore is also the source for subscriptions, follow the steps to update
related subscriptions in Encountering an An error occurred during
communication initialization message after changing the host name or port for a
source datastore and attempting to replicate to the target.
Parent topic:Troubleshooting Access Server and Management Console
54
Troubleshooting data replication
Regardless of the replication method InfoSphere® CDC uses to process data, you
may encounter general data replication problems.
In this section, you will learn:
- Encountering a The single scrape staging store is corrupted. To resolve this
issue, you must clear the staging store using the dmclearstagingstore
command line utility message after running dmclearstagingstore
- Encountering a IBM InfoSphere Change Data Capture has encountered a
critical data definition (DDL) change for source table <table name> and will
shutdown message
- Encountering errors after applying DDL changes to in-scope tables for
InfoSphere CDC for z/OS
- Encountering a The oldest open commit group in the staging space for
subscription name opened at time has exceeded the open commit group
warning age of maximum minutes by exceeds minutes message for long
running Units of Recovery (URs) on InfoSphere CDC for z/OS
- Encountering a CHC9219E DB2 IFI has returned non-zero status in a Log
Record at position, QW0306RC = return, QW0306RS = reason, QW0306DG =
code decompression error on InfoSphere CDC for z/OS
- Replicating tables without a primary key (event ID 9604) on InfoSphere CDC
for Microsoft SQL Server
55
Encountering a The single scrape staging store is
corrupted. To resolve this issue, you must clear the
staging store using the dmclearstagingstore
command line utility message after running
dmclearstagingstore
Environment
InfoSphere® CDC for all replication engines other than InfoSphere CDC for z/OS®.
Symptoms
You see the following event in your source event log: EventMessage_2930=The
single scrape staging store is corrupted. To resolve this issue, you must clear the
staging store using the dmclearstagingstore command line utility.
You encounter an error while running the dmclearstagingstore command, so that
your attempt to clear the corrupt staging store directory on the source fails.
Causes
In some cases, the dmclearstagingstore command is not able to clear the staging
store. Resolution
Complete post steps to recover from running the dmclearstagingstore command
unsuccessfully:
1. On both source and target databases where InfoSphere CDC is installed, end all
InfoSphere CDC processes by running the following command: dmshutdown [-I
<instance_name>]
2. On the machine hosting the InfoSphere CDC source, delete the following files:
- All files from the staging store directory located at <CDC_installation_directory>
/instance/<instance_name>/stagingstore.
- All the txq* files from the configuration directory located at
<CDC_installation_directory>/instance/<instance_name>/conf.
3. On the both the source and target InfoSphere CDC machines, delete the following
files:
- All the files from <CDC_installation_folder>/instance/<instance_name>/tmp.
- If you want to remove previous events from the event log, then remove all files
from the <CDC_installation_folder>/instance/<instance_name>/events directory.
4. On both the source and target InfoSphere CDC machines, restart InfoSphere
CDC.
5. Restart the subscriptions.
Parent topic:Troubleshooting data replication
56
Encountering a IBM InfoSphere Change Data
Capture has encountered a critical data definition
(DDL) change for source table <table name> and will
shutdown message
Environment
InfoSphere® CDC for all replication engines other than InfoSphere CDC for z/OS®.
Symptoms
You encounter this error message:
IBM InfoSphere Change Data Capture has encountered a critical data definition
(DDL) change for source table <table name> and will shutdown.
Causes
You have performed a Data Definition Language (DDL) change against an in-scope
table configured for replication. Resolution
Update the definition of the table in Management Console and then refresh your
target tables.To update the definition of a table:
1. Start Management Console and log into Access Server.
2. Click Configuration > Datastores.
3. Right-click Replication Tables.
4. Expand the database user or schema until you display its tables.
5. Select the table that has changed in your relational database management
system and click Update.The replication method and status of the updated table
will change to Mirror and Parked.
To refresh your target tables:
1. Start Management Console and log into Access Server.
2. Ensure that the subscription has at least one table mapping with replication
method set to Mirror. You set this when mapping tables in the Map Tables wizard.
3. Ensure that you have ended any active replication on the subscription.
4. Click Configuration > Subscriptions.
5. Select the subscription that contains the mapped source and target tables.
6. Select the mapped source and target tables in the Table Mappings view.
7. Right-click on the table and click Flag for Refresh ....
8. Select Full Refresh from the Flag for Refresh dialog.
When you are ready to start mirroring, InfoSphere CDC will send all changes from
the source table to the target table so that both tables are synchronized. InfoSphere
CDC will then mirror subsequent changes to the target.
Parent topic:Troubleshooting data replication
57
Encountering errors after applying DDL changes to
in-scope tables for InfoSphere CDC for z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
Replication stops and one or more of the following event messages are issued:
- CHC0068E
- CHC0598W
- CHC0599W
- CHC0604W
- CHC0605E
- CHC0839W
- CHC0799W
- CHC0801W
- CHC0802W
- CHC0803W
- CHC0804W
- CHC0805W
- CHC0859E
- CHC1503E
Causes
You performed DDL changes that significantly affected the structure of the source
table and you have not enabled DATA
CAPTURE CHANGES on the SYSIBM.SYSTABLES system catalog table in DB2®.
These operations cause data to be written to the log which will not be received by
InfoSphere CDC or cause the log record format of the table to change (that is, the
layout of the data in the database logs change). For operations where the log record
format changes, the log reader must be directed on how to proceed when a change
is encountered. InfoSphere CDC metadata must be modified to accommodate the
new log record format; otherwise the log reader will fail to properly decode log
records after the point of the DDL change. Changes that do not materially affect the
physical structure of the table in the log or the DATA CAPTURE
CHANGES setting for the table will not interrupt replication.
InfoSphere CDC is able to continue when columns are added to tables, however
there are some limitations. Refer to the InfoSphere Change Data Capture for z/OS
End-User Documentation to understand the factors affecting this capability.
Resolution
InfoSphere CDC can detect most DDL changes on in-scope tables only if DATA
CAPTURE
CHANGES is enabled on the SYSIBM.SYSTABLES system catalog table in DB2. If it
is not enabled, InfoSphere CDC will be aware of DDL changes when it encounters a
log record that does not match the definition in the metadata. In this case, its actions
will depend on the type of DDL operation and the version of DB2.If InfoSphere CDC
detects a DDL operation being performed on a table which is in-scope for
replication, it will analyze the change made. If no material change is detected, it
executes an auto-read and replication continues. If a column has been added, the
information is added to the InfoSphere CDC for z/OS metadata and replication
continues; however, the new column is no longer selected for replication. Any other
58
material change to the table will either end replication for the subscription or idle the
table and continue replication as configured by the ONSCHEMACHANGE
parameter. This applies to InfoSphere CDC for z/OS version 6.5 and 6.2 with current
maintenance applied. See the end-user documentation for details.
To make DDL changes without a refresh:
1. Quiesce the tables for which the DDL change is needed.
2. Ensure that mirroring is running with zero latency, at head of log.
3. Ensure that all changes for these tables have been applied to the target tables.
4. Make the DDL changes, changing the target table if required.
5. Start Management Console and log into Access Server.
6. Click Configuration > Subscriptions.
7. Select the subscription containing the tables affected by the DDL change.
8. Right click on a table and select Update Table Definition > Source.
9. Check table mappings for correctness.When DDL modifies columns, make sure
the target table can accommodate the new data format (for example, going from
CHAR(1) to CHAR(10)).
10. Start replication.The database may now be opened for data changes at this time
for all tables in-scope for replication.
If InfoSphere CDC is not running and DML statements occur between DDL
statements, or you perform an action to cause a section of the log to be skipped
(such as running SETLOGPOS), perform a refresh to resynchronize tables.
Consider the following scenario:
- DDL statements were issued.
- InfoSphere CDC detected the DDL statements and ended replication.
- While replication was down, DDL and DML operations were performed on the table
(for example, insert a row, add another column, insert a row, drop a column).
- The table definition was updated within the product.
Here, the table definition would have been updated to the latest structure of the
table, and will not account for all operations that occurred while replication was
down. You will need to update the source table definition, verify the table mappings
and refresh the affected tables.
To recover from DDL changes if DML statements occur between DDL statements:
1. Run a REORG on the tablespaces containing the changed tables.
2. Start Management Console and log into Access Server.
3. Click Configuration > Subscriptions.
4. Select the subscription containing the tables affected by the DDL change.
5. Right click on a table and select Update Table Definition > Source.
6. Check table mappings for correctness.When DDL modifies columns, make sure
the target table can accommodate the new data format (for example, going from
CHAR(1) to CHAR(10)).
7. Select all affected tables and set them to Mirror Refresh.
8. Start replication.If Mirroring is selected, the Refresh will complete before
InfoSphere CDC begins mirroring changes for all tables.
Parent topic:Troubleshooting data replication
59
60
Encountering a The oldest open commit group in
the staging space for subscription name opened at
time has exceeded the open commit group warning
age of maximum minutes by exceeds minutes
message for long running Units of Recovery (URs)
on InfoSphere CDC for z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
While replicating, you encounter the following warning: CHC0051W The oldest open
commit group in the staging space for subscription name opened at time has
exceeded the open commit group warning age of maximum minutes by exceeds
minutes.
Causes
Long running transactions or URs pose a challenge for all replication software. All
changes must be collected for the unit of work until the disposition of the UR is
known (commit or rollback).InfoSphere CDC checks for long running URs every 15
minutes. This warning occurs when a UR has been open in the database for longer
than the amount of time set by the OPENCOMMITWARNAGE parameter (the
default is 60 minutes). If a subscription is stopped when a long running UR has not
completed, InfoSphere CDC will need to re-read the log beginning at the time when
this UR began. You should resolve this before stopping the subscription.
Resolution
A staging space report will provide details about the UR including the URID. This
report is requested using the REPORT,TYPE=STGSP console command, and the
report is written to the CHCREPRT SPOOLed output data set.Each subscription has
its own staging space and you can request a unique report for each subscription.
Each report describes the following details about the staging space:
- A description of the UR, including the UR ID, the member identifier (if running in a
Data Sharing Group mode), and the date and time when the UR first entered the
staging space.
- Security information about the UR, including the address space name, the security
identifier of the originating job, and the name of the DB2® plan used to create the
UR.
- SQL operations contained in the staging space for the UR. The report also tracks
all the INSERT, UPDATE, and DELETE operations, and the UR’s current
disposition. The disposition indicates the status of the UR: whether the UR is
currently being collected into the staging space, is being or has been committed or
rolled back, is queued for transmission to the target, or is being transmitted to the
target.
With the URID, you can run a DSN1LOGP report (see the DB2 documentation for
instructions) to retrieve details about the UR from the database. With this
information you can determine the user who is running the job and take steps to
ensure they end the UR in a timely manner.
Under certain conditions, it is possible to write an incomplete UR (that is, one that
does not have the full complement of UR control records that describe how it was
disposed of) to the DB2 log. In this case, the UR can remain idle and be stalled in
the staging space. You can see stalled URs in the staging space report. Issue the
61
ENDUR console command against the stalled UR to force a commit (and transmit its
contents to the target) or roll back (and purge its contents from the staging space).
Issuing this command does not disrupt replication activities.
After resolving a stalled UR, open a PMR with IBM® Support and provide the output
from the staging space report and the DSN1LOGP report.
Parent topic:Troubleshooting data replication
62
Encountering a CHC9219E DB2 IFI has returned
non-zero status in a Log Record at position,
QW0306RC = return, QW0306RS = reason,
QW0306DG = code decompression error on
InfoSphere CDC for z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
The subscription ends and this message is found in the event log: CHC9219E DB2
IFI has returned non-zero status in a Log Record at position, QW0306RC = return,
QW0306RS = reason, QW0306DG = code.
Causes
DB2® has failed to successfully read a record from the DB2 Log. The most common
reason is a failure in decompression of the log record. This is indicated by these
values showing in this message:QW0306RC = X'00000008', QW0306RS =
X'00C90063', QW0306DG =X'00C90064'
The X’00C90063’ indicates a failure to decompress a record read from the log and
the X’00C90064’ is the code indicating the compression dictionary was
unavailable.
Resolution
The likely cause of this error is that a REORG has been run on the tablespace
containing a table in-scope for replication. One method to avoid this is to use the
KEEPDICTIONARY option when running a REORG.InfoSphere CDC uses the DB2
Instrumentation Facility Interface (IFI) to read the data from the log for tables that
are in-scope for replication. The IFI decompresses the data from compressed table
spaces before providing it to InfoSphere CDC. The IFI has the ability to detect a
change in compression dictionary and handle it under certain conditions.
Other reason codes may be returned. Refer to your DB2 documentation or contact
the IBM® DB2 support organization for assistance with these errors.
Parent topic:Troubleshooting data replication
63
Replicating tables without a primary key (event ID
9604) on InfoSphere CDC for Microsoft SQL Server
Environment
InfoSphere® CDC for Microsoft SQL Server. Symptoms
When mapping a table in Management Console without a primary key you receive
the following error:
ERROR: An error has occurred while setting the replication method for
<table_name> [An error occurred while turning on supplemental logging for
<table_name>. Microsoft SQL Server encountered a problem while turning on data
capture for table ’<table_name>’ due to the fact that the table has no primary key.
IBM InfoSphere Change Data Capture strongly recommends creating a primary key
on the table. If a primary key can not be created on the table then you have to
enable and take responsibility to maintain Microsoft SQL Server Change Data
Capture feature for the table ’<table_name>’.]. For more information, see error
messages in the Event Log view.
Causes
You are replicating a table without a primary key. Resolution
There are two possible solutions to this problem:
- Add a primary key to the table.
- Enable Microsoft Change Data Capture in Microsoft SQL Server. Do this for both
the table that does not have a primary key, and the database that contains that
table. Contact your database administrator or refer to your Microsoft SQL Server
documentation for more information on how to perform this task.
Note: If you are using Microsoft SQL Server 2008, replicating data in a table without
a primary key will cause all the changed row data to be logged to a table in the
Microsoft SQL Server database. This can result in a dramatic performance
decrease. Consult your Microsoft SQL Server documentation for further details on
how the Change Data Capture feature is implemented and its likely performance
impact on your database.
Parent topic:Troubleshooting data replication
64
Troubleshooting mirroring replication
InfoSphere® CDC replicates data using two methods: mirroring or refreshing data.
When InfoSphere CDC mirrors data for replication, it continuously replicates
changed data from a source system to the target system.
In this section, you will learn:
- Mirroring stops when InfoSphere CDC encounters an apply error
- Encountering a 911 SQL error message when configuring a table for mirror
replication on InfoSphere CDC for z/OS
- Replication of tables containing LOB columns is slow
- Encountering an An error occurred while turning on supplemental logging
for <table_name>. Unable to get exclusive lock on table <table_name>
message when configuring a table for mirror replication on InfoSphere CDC
for Oracle databases
65
Mirroring stops when InfoSphere CDC encounters
an apply error
Environment
InfoSphere® CDC for all replication engines. Symptoms
InfoSphere CDC stops mirroring when it encounters an apply error. Causes
There are two reasons why InfoSphere CDC would be unable to apply data to a
target table:
- Other applications or users are changing data on a target database.
- A table capture point was marked incorrectly; that is, at a point where the target
table was not actually synchronized with the source table contents.
Resolution
Operational issues such as resource constraints and some data synchronization
issues can be related to having applications other than InfoSphere CDC change the
target tables. Apply errors can manifest through such symptoms as lock time outs,
which would be classified as operational issues, or as row operations (insert,
update, and delete) failing. Unintentional changes to the target database by
applications other than InfoSphere CDC can be resolved by preventing the
applications from working with the target database. If having the target database
updated by applications other than InfoSphere CDC in intentional behavior, then
there are multiple ways to resolve:
- Enable conflict detection and resolution to resolve conflicts.
- Enable bidirectional replication and set up the appropriate conflict detection and
resolution rules if the changes made to the target database by applications other
than InfoSphere CDC should also be replicated to the source.
- Remap the tables using Adaptive Apply.
There may also be very specific situations in which the database reports an error
that causes InfoSphere CDC to stop, but which you have determined replication
should proceed. In these situations, configure InfoSphere CDC to ignore specific
database errors.
See also:
- To set conflict detection and resolution for source row wins
- To map source and target tables for Adaptive Apply
- To ignore database errors when applying data changes to the target for all
subscriptions using InfoSphere CDC for z/OS
- To ignore database errors when applying data changes to the target for all
subscriptions
Parent topic:Troubleshooting mirroring replication
66
To set conflict detection and resolution for source
row wins
Procedure
1. Select the subscription that contains the mapped source and target tables.
2. Click the Table Mappings view and select the table mapping containing the target
table you want to continue mirroring to. The tables should be mapped for
Standard Replication.
3. Right-click Open Mapping Details.
4. Click the Conflicts tab.The Target Column displays all of the columns in the target
table.
5. Select the columns on which you want to detect conflicts.
6. Select Source Wins from the Conflict Resolution Method list.
7. Click Apply.When you start replication on the subscription, if InfoSphere® CDC
detects a conflict in the target column, the source data is replicated to the target.
Parent topic:Mirroring stops when InfoSphere CDC encounters an apply error
67
To map source and target tables for Adaptive Apply
Procedure
1.
2.
3.
4.
5.
Start Management Console and log into Access Server.
Click Configuration > Subscriptions.
Select a subscription, right-click and select Map Tables.
Select Custom Table Mapping > Adaptive Apply and click Next.
Select the source table from the Source Tables list and click Next.If you want to
hide columns so that the target is not aware of them, click Filter Columns and
clear the check box for the column you want to hide.
6. Select a table from the Target table list and click Next.
7. Choose one of the following and click Next:
8. Choose a replication method from the following and click Next:
- Mirror (Change Data Capture)—Immediately replicates changes made to the
source table to the target table or accumulate source table changes and
replicate at a later time. If your configuration requires you to prevent recursive
updates when mirroring, enable the Prevent Recursion check box. This check
box is only available in versions of InfoSphere® CDC that support both source
and target databases.
- Refresh (Snapshot)—Replicates a snapshot of the source table to the target
table.
9. If you are replicating source database changes using InfoSphere CDC for Oracle
databases (trigger) and want to use a journal table to mirror database operations
from the source to the target table, then enable one of the following:
- Use Default Journal—Enable when you want InfoSphere CDC for Oracle
databases to use the default journal table provided with InfoSphere CDC for
Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this
journal table to detect and replicate database changes from the source to the
target.
- Use Selected Journal—Enable when you want InfoSphere CDC for Oracle
databases to use another journal table other than the default journal table
provided with InfoSphere CDC for Oracle databases. When you select the
database owner and provide a name for the journal table, InfoSphere CDC for
Oracle databases creates this new journal table and uses it to detect and
replicate database changes from the source to the target.
- Owner—Lists the database owner of the journal table.
- Name—Lists the name of the journal table.
10. Click Next.
11. Review the mapping summary.
12. Choose one of the following options and click Finish:
- Define column mappings—Continues with the column mapping.
- Create a new table mapping—Allows you to start a new table mapping.
- Return to current view—Returns you to the current view.
68
Parent topic:Mirroring stops when InfoSphere CDC encounters an apply error
69
To ignore database errors when applying data
changes to the target for all subscriptions using
InfoSphere CDC for z/OS
Procedure
1. Ensure that you your target database is using InfoSphere® CDC for z/OS®.
2. Modify the setting for ENDONERROR in the CHCCFGxx member.
ENDONERROR=(YES,YES,YES) is the default, indicating the settings for
Refresh, Mirroring, and Auditing, respectively.
Changing the values for one of the settings will cause InfoSphere CDC to
continue replication after encountering an error while applying data to the target
database during the corresponding type of replication activity.
3. Override the global settings for a subscription replicating from InfoSphere CDC for
z/OS to InfoSphere CDC for z/OS by selecting Subscriptions > Properties >
Advanced within Management Console.
Parent topic:Mirroring stops when InfoSphere CDC encounters an apply error
70
To ignore database errors when applying data
changes to the target for all subscriptions
Procedure
1. Ensure that you your target database is not using InfoSphere® CDC for z/OS®.
2. Ensure you know the database error code which is returned by the SQLException
class in JDBC. This error code is database vendor-specific and always an integer,
such as "ORA-00001".
3. Start Management Console and log into Access Server.
4. Click Configuration > Datastores.
5. Right-click on the datastore for your target database and select Properties.
6. Select mirror_expected_errors_list from the System Parameters tab.
7. Click Modify.
8. Type the integer error code returned by the SQLException class in JDBC that you
want to ignore, in the Value box. Specify multiple error codes with a comma
separated list.Notes:
- Ensure that you only configure the parameter to ignore errors that you are
certain are safe to ignore (such as unique constraint ORA-00001).
- Latency may increase when using this system parameter since InfoSphere CDC
will not use JDBC array apply in order to track the errors specified.
Parent topic:Mirroring stops when InfoSphere CDC encounters an apply error
71
Encountering a 911 SQL error message when
configuring a table for mirror replication on
InfoSphere CDC for z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
While configuring a table for mirroring in Management Console, InfoSphere CDC
issues message showing a 911 SQL error, which indicates a deadlock or timeout.
Causes
This error occurs when you attempt to mirror a source table in Management Console
but since there are one or more URs running against the table, DB2® cannot lock
the table to complete the ALTER TABLE <table> ADD DATA CAPTURE
CHANGES SQL statement issued by InfoSphere CDC. InfoSphere CDC requires
DATA
CAPTURE CHANGES to replicate tables properly and this can only be completed
when the table is not being updated or locked by other users. Resolution
Enable DATA CAPTURE CHANGES during a maintenance window. If DATA
CAPTURE CHANGES is already configured on a table, InfoSphere CDC will detect
this and will not need a lock on the table during configuration for mirroring. You can
configure the table for mirroring during a maintenance window, or manually enable
the DATA CAPTURE
CHANGES during the window and complete the table configuration later.
Parent topic:Troubleshooting mirroring replication
72
Replication of tables containing LOB columns is
slow
Environment
InfoSphere® CDC for z/OS® Symptoms
Replication for a subscription that has source tables that contain LOB columns is
very slow. Sometimes it might appear that replication is stalled. Causes
The ROWID column that is associated with the LOB column or columns might not
have an index defined on it. When InfoSphere CDC selects the LOB column data
from the source table, DB2® might use a table space scan to retrieve the LOB data.
Resolution
Apply the PTF for APAR PH13842. This PTF extends the LOB data selection logic
to use any qualifying unique index, not just the index over the LOB's ROWID
column, to access the LOB's auxiliary table space. When no suitable index is found,
a warning message is issued to notify you of the possible poor performance.
Parent topic:Troubleshooting mirroring replication
73
Encountering an An error occurred while turning on
supplemental logging for <table_name>. Unable to
get exclusive lock on table <table_name> message
when configuring a table for mirror replication on
InfoSphere CDC for Oracle databases
Environment
InfoSphere® CDC for Oracle databases. Symptoms
While configuring a table for mirroring in Management Console, InfoSphere CDC
issues the following message:
[ERROR] An error occurred while turning on supplemental logging for <table_name>
. Unable to get exclusive lock on table <table_name>
Causes
This error occurs when you attempt to mirror a source table in Management Console
but since there are many open transactions, InfoSphere CDC cannot lock the table
and add supplemental logging. InfoSphere CDC requires supplemental logging to
replicate tables properly and this can only be completed when the table is not being
updated or locked by other users.In addition, when InfoSphere CDC executes an
ALTER TABLE command to enable supplemental logging, it requires exclusive lock
on the target table. Ensure there are no locked transactions or shared locks.
Resolution
You can resolve this issue in one of the following ways:
- Locate open transactions on the specific source table. If there are locks, either wait
for the transactions to complete, or terminate. Here is an example or how to
terminate the transaction:select B.SID, C.USERNAME, C.OSUSER,C.TERMINAL,
DECODE(B.ID2, 0, A.OBJECT_NAME,
'Trans-'||to_char(B.ID1)) OBJECT_NAME,
B.TYPE,
DECODE(B.LMODE,0,'--Waiting--',
1,'Null',
2,'Row Share',
3,'Row Excl',
4,'Share',
5,'Sha Row Exc',
6,'Exclusive',
'Other') "Lock Mode",
DECODE(B.REQUEST,0,'',
1,'Null',
2,'Row Share',
3,'Row Excl',
4,'Share',
5,'Sha Row Exc',
6,'Exclusive',
'Other') "Req Mode"
from DBA_OBJECTS A, V$LOCK B, V$SESSION C
where A.OBJECT_ID = B.ID1 and a.object_id
= 67491 (get object_id from dba_objects)
and B.SID = C.SID
From this example, determine the SID and serial number, and then run this SQL
74
command:alter
system kill session <'SID, serial number>’;
- Continue to replicate the source table until the transaction completes and
InfoSphere CDC adds logging. Once the transaction completes, configure the
table.
- Manually terminate Oracle sessions with open transactions on the specific source
table. Note: You may lose hours of database processing time when you terminate
a session. In addition, it may take some time for the work of that session to be
rolled back by Oracle. Only proceed when you have understood the impact of
closing your transactions in this way.
Parent topic:Troubleshooting mirroring replication
75
Troubleshooting refresh replication
InfoSphere® CDC replicates data using two methods: mirroring or refreshing data.
When InfoSphere CDC refreshes data for replication, it synchronizes the target
system with the current contents of a source system.
In this section, you will learn:
- Refreshing fails with a referential integrity constraint violation reported in the
event log
- Refreshing data to the target on InfoSphere CDC and encountering database
errors
- Encountering a A SQL exception has occurred. The SQL error code is '0'.
The SQL state is: HY000. The error message is: [CDC][Oracle JDBC
Driver]Object has been closed message on InfoSphere CDC for Oracle
databases
76
Refreshing fails with a referential integrity
constraint violation reported in the event log
Environment
InfoSphere® CDC for all replication engines. Symptoms
You encounter a referential integrity constraint violation error in the event log.
Causes
The referential integrity constraints in the target database conflict with the order in
which InfoSphere CDC is refreshing the tables.
Resolution
Ensure that you have truncated or cleared all target tables, then refresh your tables
by logical order (for example, parent, then child). InfoSphere CDC will not truncate
the parent table if the child table contains data.Also, ideally, the parent and child
tables should be part of the same replication, with proper ordering.
Parent topic:Troubleshooting refresh replication
77
Refreshing data to the target on InfoSphere CDC
and encountering database errors
Environment
InfoSphere® CDC for all replication engines other than InfoSphere CDC for z/OS®.
Symptoms
While refreshing data to the target, you encounter database errors. In some cases,
refresh also fails. Causes
You can safely ignore some informational database errors since they do not affect
replication; however, accumulating too many of these errors can cause InfoSphere
CDC to stop replication. For example, if you are using InfoSphere CDC for Oracle
databases or InfoSphere CDC for Oracle databases (trigger), you can ignore the
following error during mirroring:ORA-00001: unique constraint violated (<schema>.<constraint>)
Resolution
Configure InfoSphere CDC to ignore specified database errors when refreshing data
to the target:
1. Ensure you know the database error code for the error you want InfoSphere CDC
to ignore. The error code is returned by the SQLException class in JDBC. This
error code is database vendor-specific and always an integer, such as "ORA00001" specifies a specific Oracle error.
2. Start Management Console and log into Access Server.
3. Click Configuration > Datastores.
4. Right-click on a datastore and select Properties.
5. On the System Parameters tab, select refresh_expected_errors_list.
6. Click Modify.
7. In the Value box, type the integer error code returned by the SQLException class
in JDBC that you want to ignore. Specify multiple error codes with a comma
separated list.Note: Latency may increase when using this system parameter
since InfoSphere CDC will not use JDBC array apply in order to track the errors
specified.
Parent topic:Troubleshooting refresh replication
78
Encountering a A SQL exception has occurred. The
SQL error code is '0'. The SQL state is: HY000. The
error message is: [CDC][Oracle JDBC Driver]Object
has been closed message on InfoSphere CDC for
Oracle databases
Environment
InfoSphere® CDC for Oracle databases. Symptoms
You attempt to replicate subscriptions, and receive the following error:Failed to
apply DDL ''{1}'' on table {0}. Database operation failed. A SQL exception has
occurred. The SQL error code is '0'. The SQL state is: HY000. The error message
is: [CDC][Oracle JDBC Driver]Object has been closed.
Causes
Typically, a message containing Object has been closed indicates that the session
was abruptly ended, likely due to an internal Oracle error. Resolution
Check Oracle’s alert log and the user dump destination. Refer to the
background_dump_dest and user_dump_dest parameters for the locations of these
files.
Parent topic:Troubleshooting refresh replication
79
Troubleshooting latency
Latency is calculated as the difference in time between when a particular operation
was applied to the source database, and when that same operation is applied to the
target database by InfoSphere® CDC.
In this section, you will learn:
- Experiencing increased latency and no data is replicating to the target
database
- Experiencing increased latency and no data is replicating to the target
database on InfoSphere CDC for z/OS
80
Experiencing increased latency and no data is
replicating to the target database
Environment
InfoSphere® CDC for all replication engines. Symptoms
Latency is increasing and no data is being replicated to the target database.
Causes
This can occur when InfoSphere CDC is processing a large transaction that has
recently executed on the source database. Resolution
Complete either of the following resolutions:
- Confirm that InfoSphere CDC is processing a large transaction by clicking Collect
Statistics in Management Console. This feature displays various metrics reflecting
different stages of the flow of replication data from the source to the target. When
Management Console is processing a large transaction you will see that the source
side metrics are changing.
- Use the Performance view within the Monitoring perspective in Management
Console. This allows you to view, investigate and diagnose the performance of
subscriptions or tables within them to determine the causes of unexpected or
unacceptable levels of latency.
Parent topic:Troubleshooting latency
81
Experiencing increased latency and no data is
replicating to the target database on InfoSphere
CDC for z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
There is a sudden increase in latency with subscriptions. You know that there have
been many changes made to the source DB2® database on z/OS. InfoSphere CDC
for z/OS reports that it is operating normally, yet you find no changes on the target
system. Causes
There are two probable causes:
- Large group of changes in progress—If a very large UR was committed before
the UR with your current changes, InfoSphere CDC may still be busy processing
the first UR. Once completed and processed on the target system, the following
URs will be replicated in the order they were committed.
- Time latency value for your environment is too narrow—InfoSphere CDC uses
a DB2 trace so that it is notified of all changes written to the DB2 log. This
notification is sent when a percentage of the OPx buffer has been filled by DB2. If
you have not allocated an appropriate size and threshold for the OPx buffer,
notification of changes will be less frequent. These values can be set for
InfoSphere CDC using the keywords BUFTHRESHOLD and BUFSIZE. If the value
for BUFTHRESHOLD is set too high, then InfoSphere CDC does not notify
subscriptions of new data efficiently and therefore, increases latency. For instance,
if you have a BUFSIZE of 1 GB and set the BUFTHRESHOLD to 50%, InfoSphere
CDC receives change notification only when 500 MB of data has been written to
the DB2 log. Only then will it inform the active subscriptions that they can resume
scraping log data.
Resolution
Depending on the cause of the replication failure, resolve it as follows:
- Run staging space report for the subscription showing latency—When a large
UR is being assembled in the staging space (located in the source installation of
InfoSphere CDC), or being transmitted to the target system, observe its progress
using the staging space report. This report is requested using the
REPORT,TYPE=STGSP console command, and the report is written to the
CHCREPRT SPOOLed output data set. Each subscription has its own staging
space and you can request a unique report for each subscription. Each report
describes the following details about the staging space:
- A description of the UR, including the UR ID, the member identifier (if running in a
Data Sharing Group mode), and the date and time when the UR first entered the
staging space.
- Security information about the UR, including the address space name, the
security identifier of the originating job, and the name of the DB2 plan used to
create the UR.
- SQL operations contained in the staging space for the UR. The report also tracks
all the INSERT, UPDATE, and DELETE operations, and the UR’s current
disposition. The disposition indicates the status of the UR: whether the UR is
currently being collected into the staging space, is being or has been committed
or rolled back, is queued for transmission to the target, or is being transmitted to
the target.
82
Consecutive staging space reports obtained for the same subscription with a short
interval between them will show the progress of a large UR, through the staging
space and out to the target. Under certain conditions, it is possible to write an
incomplete UR (that is, one that does not have the full complement of UR control
records that describe how it was disposed of) to the DB2 log. If a very large UR
was committed before the UR with your current changes, InfoSphere CDC may still
be busy processing the first UR. Once completed and processed on the target
system, the following URs will be replicated in the order they were committed.
- Increase the time latency value for your environment—Determine an
appropriate time latency value for your environment. When a higher value is
specified for BUFTHRESHOLD, that percentage of the OPx buffer must contain
DB2 log data before InfoSphere CDC notifies subscriptions of data to be
processed. If the default for BUFSIZE is used (the optimal value is 132 KB), then a
BUFTHRESHOLD value of 50% means that at least 66 KB of DB2 log data must
have been written to the DB2 log before InfoSphere CDC can start to process the
new data. This 66 KB of data represents the DB2 Log data latency. If you know the
average rate at which the DB2 log is being extended, then a data latency of 66 KB
can be converted to a time latency value that can be calculated using the following
formulas: TimeLatency = DataLatency / DB2LogDataRate
DataLatency = TimeLatency * DB2LogDataRate
To obtain an acceptable time latency value, use the preferred time latency value in
the second formula and calculate an appropriate value for the data latency. Next,
convert the data latency value to a percentage of the value of the BUFSIZE
keyword, and use the calculated percentage as the value of the BUFTHRESHOLD
keyword.
Contact your DB2 database administrator to determine the DB2 log data rate. The
maximum and minimum DB2 log data rates within a cyclical period (for example, a
day, a week, month-end peak) may also be a consideration when determining the
preferred value for BUFTHRESHOLD. A smaller time latency value is desirable
when real-time, continuous mirroring of data is being performed. If real-time,
continuous mirroring is not being used, then time latency has no significance for
determining the value of the BUFTHRESHOLD keyword.
Parent topic:Troubleshooting latency
Related concepts
- Encountering a The oldest open commit group in the staging space for subscription
name opened at time has exceeded the open commit group warning age of
maximum minutes by exceeds minutes message for long running Units of
Recovery (URs) on InfoSphere CDC for z/OS
83
Troubleshooting data replication maintenance
You may have ongoing maintenance issues, such as maintaining log files or
cleaning up your system.
In this section, you will learn:
- Running dmshowlogdependency on InfoSphere CDC for Oracle databases
references a dated log file
- Encountering a CHC9214E DB2 Trace could not be started. All OPx trace
buffers are in use or CHC9217E DB2 CAF Message: [<DB2 CAF error>]
message in the event log on InfoSphere CDC for z/OS
84
Running dmshowlogdependency on InfoSphere
CDC for Oracle databases references a dated log
file
Environment
InfoSphere® CDC for Oracle databases. Symptoms
You have issued the dmshowlogdependency command and it returns a list of log
files that you must keep. This list includes old log files. Causes
This issue is usually indicative of one of two things:
- You have a subscription in your replication environment (with at least one table)
that you have not replicated in an extended period of time. For example, you may
have created a test subscription before promoting your tables to another
subscription in a production environment. The dmshowlogdependency command
will include the log files that InfoSphere CDC would need to use if that subscription
was started.
- You have occasionally long running transactions in your database. Long running
transactions affect log dependency regardless of whether or not they include tables
that are being replicated. A long running transaction may be from a batch job that
requires a significant period of time to execute, but may also be from an application
or interactive user session that makes a small number of data changes and waits a
long time before committing those changes. Note that when one or more of your
subscriptions has some latency, log dependency may be affected by a transaction
that was long running but has recently been committed.
Resolution
If you have test subscriptions and would like to keep them, you can change the data
replication method for the table mappings from Mirror to Refresh. Note that this
would mean that if you want to use this subscription in the future, all the tables
would need to be refreshed. If there are occasional long running transactions in your
database, you may want to monitor the database and determine if those long
running transactions are necessary.To change the data replication method of a
table:
1. Ensure that you have ended any active replication on the subscription.
2. Start Management Console and log into Access Server.
3. Click Configuration > Subscriptions.
4. Select the subscription that contains the tables you want to remove from mirroring
activity.
5. On the Table Mappings view, select all the table mappings within the subscription.
6. Right-click and select Change replication method.
7. Enable Refresh (Snapshot). This changes the replication method and status of
each mapped table to Refresh.
You can also set the bookmark at source for the test subscription, which will not look
for long running transactions.
To identify open transactions that may be long running, run the following query
against the source database:
select
a.USERNAME,a.PROGRAM,a.PROCESS,a.CLIENT_INFO,b.START_DATE from
gv$session a inner join gv$transaction b on a.saddr=b.ses_addr
order by b.START_DATE asc;
85
Parent topic:Troubleshooting data replication maintenance
86
Encountering a CHC9214E DB2 Trace could not be
started. All OPx trace buffers are in use or
CHC9217E DB2 CAF Message: [<DB2 CAF error>]
message in the event log on InfoSphere CDC for
z/OS
Environment
InfoSphere® CDC for z/OS®. Symptoms
InfoSphere CDC for z/OS stops DB2® activity. One of the following errors displays
in the Management Console event log:
- CHC9214E DB2 Trace could not be started. All OPx trace buffers are in use.
- CHC9217E DB2 CAF Message: [<DB2 CAF error>].
Causes
InfoSphere CDC requires DB2 tracing to run so that it can be notified when the DB2
log is extended. These errors indicate that InfoSphere CDC was unable to start a
trace because none of the DB2 OPx trace buffers are available for use. There are
several possible causes for this for DB2 version 8 or earlier:
- For DB2, cancelling the InfoSphere CDC address space leaves the trace active.
This does not allow InfoSphere CDC to stop the trace in the OPx buffer it is using,
and DB2 tracing can fail to start.
- If you configured InfoSphere CDC to use a specific OPx buffer, and that buffer is
being used by something else (such as another instance of InfoSphere CDC), DB2
tracing can fail to start.
- If you configured InfoSphere CDC to select the first available OPx buffer, but there
are no available OPx buffers (the maximum is 8 buffers), then DB2 tracing can fail
to start.
Resolution
If you receive the CHC9214E error, request that your DBA release at least one of
the allocated DB2 OPx buffers and then restart InfoSphere CDC using the START
command. If you receive the CHC9217E error, contact your DBA to review the DB2
CAF (Call Attach File) error message. If the CAF message indicates that an error
has occurred, your database administrator should correct the problem. Once the
correction is made, restart the InfoSphere CDC address space using the START
command.
Parent topic:Troubleshooting data replication maintenance
87
Troubleshooting network and connectivity issues
Network connectivity issues can cause data replication to terminate.
In this section, you will learn:
- Encountering communication interruptions
88
Encountering communication interruptions
Environment
InfoSphere® CDC for all replication engines. Symptoms
InfoSphere CDC cannot work because of a lost connection. You may receive errors
issued in the InfoSphere CDC Event Log, similar to the following ones: For
InfoSphere CDC for z/OS®:
- CHC6503E (DTSPROD) Communications link to ADDRESS.IBM.COM:0
abnormally terminated by remote system (link <#>, process <#>)
- CHC9500E TCP/IP name(string) service call has failed. The returned error is <
description of error returned by TCP/IP> for value of <error number returned by
TCP/IP>.
For all other InfoSphere CDC replication engines:
- COMMS : send failed -- link tag=<#> is not found
- IBM InfoSphere Change Data Capture heartbeat timeout has occurred. Replication
will end. The timeout is currently <#> minutes. There may be a network problem or
a problem on the remote system. Resolve the problem and then restart replication.
- CHANNEL: [tag=<#>, name="<NAME>", type=<CO|DO]", port=<#>]: Connection
reset
- COMMS : send failed -- link tag=<#> is not found
Causes
A network connection failed. A network can disconnect because of several
scenarios:
- Your firewall detects an idle connection and proceeds to close it. This condition is
unknown to the application until it tries to use the connection (such as sending a
message to the remote system).
- Your firewall configurations have changed, which can cause an already
established connection to be dropped.
- There is a network disruption, such as a planned maintenance window or
unplanned power outage, which may cause the connection to be dropped.
If the cause is in the network, generally both sides of the connection will receive
connection reset errors, but the timing may differ as the two sides will not know (or
be informed) of the connection reset error until there is an attempt to use the
connection. Therefore, the connection drop may be detected at different times.
Resolution
A reset connection error indicates that the communication link to InfoSphere CDC
has been terminated by the server to which InfoSphere CDC was connected. This
error is not caused by the instance of InfoSphere CDC which has reported the
problem. Determine if the connection reset error is reported for a remote connection
to Access Server or to InfoSphere CDC installed on your source or target system. If
the connection terminated was to Access Server, you would receive the following
error message:
Access Server has detected that the connection to datastore <datastore_name> has
been lost. Management Console will now disconnect from the datastore. Monitor
agent connection (host: < > port < >) lost.
For a connection terminated to a peer installation of InfoSphere CDC, investigate
the event log in Management Console for any errors there. If errors have occurred in
Access Server or the InfoSphere CDC peer instance, which appear to have caused
the problem, attempt to resolve the problem reported on that system. If you are
89
unable to resolve the problem, then log a PMR with IBM® Support for the Access
Server or peer InfoSphere CDC instance on which the problem occurred.
If both InfoSphere CDC and the remote end of the connection report a
communications error (that is an ECONNRESET error), contact your network
administrator to investigate the cause of the problem. This type of error generally
means that the server or some router or firewall in between the two servers has
caused the connection reset error to occur. Contact your administrator to complete
the following tasks:
- Investigate the connection and reset more reasonable firewall idle timeout values.
If the problem is because of the firewall closing the connection due to idle timeout,
try decreasing the KEEP_ALIVE_TIMEOUT system parameter for InfoSphere CDC
. The suggested value is 20 seconds.
- Check for viruses which may inject connection-reset packets into an established
stream, causing the operating system to behave as if the connection was
terminated by the remote.
Parent topic:Troubleshooting network and connectivity issues
90
Getting fixes from Fix Central
You can use Fix Central to find the fixes that are recommended by IBM Support for
a variety of products, including InfoSphere® CDC. With Fix Central, you can search,
select, order, and download fixes for your system with a choice of delivery options. A
InfoSphere CDC product fix might be available to resolve your problem.
To find and install fixes for InfoSphere CDC for z/OS
1. Go to www.ibm.com/ibmlink.
2. View a list of fixes available for InfoSphere CDC for z/OS® by selecting Service
Information Search and entering the FMID for your version. The FMID is shown in
your program directory (for example HCHC650 for version 6.5). A list of all
available PTFs will be displayed which you can order.
3. Optionally, configure your user profile to have notifications sent when new PTFs
become available by selecting Automatic Software Alert Process.
To find and install fixes for all InfoSphere CDC for all
replication engines other than InfoSphere CDC for z/OS
1. Obtain the tools that are required to get the fix. If not installed, obtain your product
update installer. The installer can be downloaded from Fix Central.This site
provides download, installation, and configuration instructions for the update
installer.
2. Select InfoSphere CDC as the product, and select one or more check boxes that
are relevant to the problem that you want to resolve.
3. Identify and select the fix that is required.
4. Download the fix:
A. Open the download document and follow the link in the Download Package
section.
B. When downloading the file, ensure that the name of the maintenance file is not
changed. This change might be intentional, or it might be an inadvertent
change that is caused by certain Web browsers or download utilities.
5. Apply the fix:
A. Follow the instructions in the Installation Instructions section of the download
document.
B. For more information, see the Installing fixes with the Update Installer topic in
the product documentation.
91
Subscribing to Support updates
To stay informed of important information about the IBM products that you use, you
can subscribe to updates. By subscribing to receive updates, you can receive
important technical information and updates for specific IBM Support tools and
resources.
In this section, you will learn:
- Understanding types of Support updates
You can subscribe to Support updates by using one of two approaches: RSS
feeds or My Notifications.
92
Understanding types of Support updates
You can subscribe to Support updates by using one of two approaches: RSS feeds
or My Notifications.
- RSS feeds
- You can subscribe to the InfoSphere® CDC RSS feed to obtain current support
information about the product.For general information about RSS, including
steps for getting started and a list of RSS-enabled IBM web pages, visit the
IBM Software Support RSS feeds site.
- My Notifications
- With My Notifications, you can subscribe to Support updates for any IBM
product. (My Notifications replaces My Support, which is a similar tool that you
might have used in the past.) With My Notifications, you can specify that you
want to receive daily or weekly email announcements. You can specify what
type of information you want to receive (such as publications, hints and tips,
product flashes (also known as alerts), downloads, and drivers). My
Notifications enables you to customize and categorize the products about which
you want to be informed and the delivery methods that best suit your needs.
Until you modify your RSS feeds and My Notifications preferences, you receive
notifications of updates that you have requested. You can modify your preferences
when needed (for example, if you stop using one product and begin using another
product).
See also:
- To subscribe to InfoSphere CDC RSS feeds
- To subscribe to My Notifications
Parent topic:Subscribing to Support updates
93
To subscribe to InfoSphere CDC RSS feeds
Procedure
1. Go to IBM® Support RSS Feeds Web site.
2. Click RSS feeds for Information Management productsInfoSphere® Change Data
Capture.
3. Click Subscribe Now.
Parent topic:Understanding types of Support updates
Related information
-
IBM Software Support RSS feeds
Subscribe to My Notifications support content updates
My notifications for IBM technical support
My notifications for IBM technical support overview
94
To subscribe to My Notifications
Procedure
1. Go to the IBM® Support Portal.
2. Click My Notifications in the Notifications portlet.
3. Sign in using your IBM ID and password, and click Submit.
4. Click the Subscribe tab.
5. Select the appropriate software brand or type of hardware.
6. Select one or more products by name and click Continue.
7. Select your preferences for how to receive updates, whether by email, online in a
designated folder, or as an RSS or Atom feed.
8. Select the types of documentation updates that you want to receive, for example,
new information about product downloads and discussion group comments.
9. Click Submit.
Parent topic:Understanding types of Support updates
Related information
-
IBM Software Support RSS feeds
Subscribe to My Notifications support content updates
My notifications for IBM technical support
My notifications for IBM technical support overview
95
Contacting IBM Support
IBM® Support provides assistance with product defects.
Before contacting support, ensure you have the appropriate information for IBM
Support. Also, your company must have an active IBM software maintenance
contract, and you must be authorized to submit problems to IBM. For information
about the types of maintenance contracts available, see Enhanced Support in the
Software Support Handbook at: techsupport.services.ibm.com/guides/services.html
In this section, you will learn:
- Determining your version of InfoSphere CDC
Before contacting support, ensure you identify the version and build number of the
InfoSphere® CDC product you are currently running.
- Collecting InfoSphere CDC information for IBM Support
To help IBM Support understand and troubleshoot your problem, provide as much
InfoSphere CDC information to them as possible.
- Collecting performance statistics on a subscription for IBM Support
When encountering a performance issue with your subscriptions, the IBM Support
team requires statistics information to properly analyze the subscription. By default,
collecting statistics for a subscription is automatically enabled.
- Exchanging information with IBM Support
To diagnose or identify a problem, it is sometimes necessary to provide IBM
Support with data and information from your system. In other cases, IBM Support
might provide you with tools or utilities to use for problem determination.
Submitting diagnostic information to IBM can help IBM Support begin a Problem
Management Report (PMR). If you have a problem and have opened a PMR to
find a solution, problem determination data is needed to find a solution.
- Reporting a problem to IBM Support
You can contact IBM Support with a problem.
Parent topic:Troubleshooting
96
Determining your version of InfoSphere CDC
Before contacting support, ensure you identify the version and build number of the
InfoSphere® CDC product you are currently running.
Use the dmshowversion command to display the version and build number of
InfoSphere CDC. Run this command before you contact your IBM® representative.
Note: This command is not available for InfoSphere CDC for z/OS®. For z/OS
version information, consult the SPOOLed output. A complete description of the
installation, including all maintenance (PTFs) applied is available there.
See also:
- To determine your version of InfoSphere CDC
Parent topic:Contacting IBM Support
97
To determine your version of InfoSphere CDC
Procedure
Enter the following command:dmshowversion [-L <locale>]
where <locale> is the name of the language locale used for the InfoSphere® CDC
instance. The default is your machine's locale.
Parent topic:Determining your version of InfoSphere CDC
98
Collecting InfoSphere CDC information for IBM
Support
To help IBM® Support understand and troubleshoot your problem, provide as much
InfoSphere® CDC information to them as possible.
Collecting InfoSphere CDC information on InfoSphere CDC
for z/OS
All SPOOLed output for the InfoSphere CDC for z/OS® address space should be
collected. If a dump has been generated, the output from the dump should be
collected as well. All data from the mainframe should be sent in TERSED format as
this retains the formatting of the data for the mainframe while it is transferred using
non-mainframe systems, ensuring the data is useful for IBM Support. It has the
added advantage of reducing the size of the files. Files should be named with the
extension .trs. See the documentation for AMATERSE, if you need assistance.
Collecting InfoSphere CDC information on all replication
engines other than InfoSphere CDC for z/OS
You can collection information by running the dmsupportinfo command, which
creates a ZIP file containing InfoSphere CDC information useful to a Support
personnel. Send this file to IBM Support when contacting them regarding your
problem.In some cases, you may not be able to start your InfoSphere CDC instance.
You can run the dmsupportinfo command without a running instance; however, the
command will collect a limited scope of data.
If you are unclear as to whether the problem is on the source or target, you can run
the command on both sides.
Once you run this command, it outputs the name and location of the generated ZIP
file to provide to IBM Support.
- To collect InfoSphere CDC information
Parent topic:Contacting IBM Support
99
To collect InfoSphere CDC information
Procedure
1. Ensure that your InfoSphere® CDC is running.
2. Switch to the <CDC_installation_directory>/bin directory.
3. Run dmsupportinfo -I <instance_name>. Note: If you are not be able to start your
InfoSphere CDC instance, you can run this command withou the -I parameter;
however, the command will collect a limited scope of data.
Parent topic:Collecting InfoSphere CDC information for IBM Support
100
Collecting performance statistics on a subscription
for IBM Support
When encountering a performance issue with your subscriptions, the IBM® Support
team requires statistics information to properly analyze the subscription. By default,
collecting statistics for a subscription is automatically enabled.
Note: Collecting performance statistics is not supported with InfoSphere® CDC for
z/OS®.
InfoSphere CDC collects statistics information on each subscription every 30
seconds. This is ideal if you have a subscription that is replicating a day's worth of
data (that is, 24 hours of data).
See also:
- To collect performance statistics on a subscription
Parent topic:Contacting IBM Support
101
To collect performance statistics on a subscription
Procedure
1. Start Management Console and log into Access Server.
2. Ensure you are connected to the datastore for the subscription for which you want
to collect information.
3. Click Help > Service Information > Support Assistant.
4. Select the Enable Collection check box for the datastore for which you want to
collect information.
5. Click Options and click Detailed to collect detailed information for the selected
datastore.
6. Click OK.
7. Select the location where you want Support Assistant to store the output file for
the generated information.
8. Allow Support Assistant to clean up diagnostic files after collection by selecting
Clean-up diagnostic files after collection.
9. Click Collect Now to start collecting the messages.
Parent topic:Collecting performance statistics on a subscription for IBM Support
102
Exchanging information with IBM Support
To diagnose or identify a problem, it is sometimes necessary to provide IBM Support
with data and information from your system. In other cases, IBM Support might
provide you with tools or utilities to use for problem determination. Submitting
diagnostic information to IBM® can help IBM Support begin a Problem Management
Report (PMR). If you have a problem and have opened a PMR to find a solution,
problem determination data is needed to find a solution.
See also:
- To send information to IBM Support
- To receive files from IBM Support
Parent topic:Contacting IBM Support
103
To send information to IBM Support
Procedure
1. Open a problem management record (PMR).
2. Collect the diagnostic data that you need. Diagnostic data helps reduce the time
that it takes to resolve your PMR. You can collect the diagnostic data manually
(through logs) or automatically (using Support Assistant):
- Collect the data automatically by using Support Assistant
- On z/OS®, collect all SPOOLed output for the InfoSphere® CDC address
space.
- On Linux, UNIX, and Windows, collect the data manually by referring to trace
logs and event messages.
3. Compress the files by using the TRS format and the TRSMAIN utility on z/OS;
use the ZIP or TAR format on Linux, UNIX, and systems.
4. Transfer the files to IBM. You can use one of the following methods to transfer the
files to IBM:
- Support Assistant
- The Service Request tool
- Standard data upload methods: FTP, HTTP
- Secure data upload methods: FTPS, SFTP, HTTPS
- Email
If you are using a z/OS product and you use ServiceLink / IBMLink to submit
PMRs, you can send diagnostic data to IBM Support in an email or by using FTP.
All of these data exchange methods are explained on the IBM Support site.
Parent topic:Exchanging information with IBM Support
104
To receive files from IBM Support
Procedure
1. Ensure that your IBM technical-support representative has provided you with the
preferred server to use for downloading the files and the exact directory and file
names to access.
2. Use FTP to connect to the site that your IBM technical-support representative
provided and log in as anonymous. Use your email address as the password.
3. Change to the appropriate directory:
A. Change to the /fromibm directory. cd fromibm
B. Change to the directory that your IBM technical-support representative
provided:cd nameofdirectory
4. Enable binary mode for your session:binary
5. Use the get command to download the file that your IBM technical-support
representative specified:get filename.extension
6. End your FTP session:quit
Parent topic:Exchanging information with IBM Support
105
Reporting a problem to IBM Support
You can contact IBM® Support with a problem.
See also:
- To contact IBM Support
Parent topic:Contacting IBM Support
106
To contact IBM Support
Procedure
1. Define the problem, gather background information, and determine the severity of
the problem. For help, see the Contacting IBM® in the Software Support
Handbook: techsupport.services.ibm.com/guides/beforecontacting.html
2. Gather diagnostic information.
3. Submit your problem to IBM Support in one of the following ways:
- Using IBMSupport Assistant (ISA):
- Online: Click the Report problems tab on the IBM Software Support site:
www.ibm.com/software/support/probsub.html
- By phone: For the phone number to call in your country, go to the Contacts page
of the Software Support Handbook:
techsupport.services.ibm.com/guides/contacts.html
What to do next
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Support creates an Authorized Program Analysis Report
(APAR). The APAR describes the problem in detail. Whenever possible,IBM
Support provides a workaround that you can implement until the APAR is resolved
and a fix is delivered. IBM publishes resolved APARs on the IBM Support web site
daily, so that other users who experience the same problem can benefit from the
same resolution.
Parent topic:Reporting a problem to IBM Support
107
Troubleshooting
If you encounter issues while running InfoSphere® CDC, you have a number of
options for tracking and troubleshooting issues to help with problem resolution.
There are three methods that you can use in InfoSphere CDC for tracking and
troubleshooting issues:
- Data Collection with the IBM® Support Assistant (ISA DC)
- Management Console Support Assistant
- The dmsupportinfo command, which is executed on the replication engine
If you are trying to troubleshoot issues with InfoSphere CDC version 10.2 or later on
Linux, UNIX and Windows operating systems, you should use the ISA DC tool
unless otherwise instructed by IBM Technical Support.
In this section, you will learn:
- Using the IBM Support Assistant (ISA DC)
- Contacting IBM Support
IBM Support provides assistance with product defects.
108
Using the IBM Support Assistant (ISA DC)
You can use the IBM® Support Assistant Data Collection tool (ISA DC) to collect
InfoSphere® CDC data to provide to IBM Technical Support to assist you in
troubleshooting issues with InfoSphere CDC, to request a product enhancement or
to ask a question about InfoSphere CDC.
ISA DC can be used with InfoSphere CDC replication engines that are version 10.2
or later, except InfoSphere CDC for z/OS®.
The ISA DC tool is included in the InfoSphere CDC installation process, and does
not require configuration. The executable files are located in the isa folder in the
InfoSphere CDC directory. Simply run the isadc.bat, isadc.sh or index.html file, as
appropriate, to launch the tool.
Prerequisites and considerations for using ISA DC
The following prerequisite must be satisfied on the machine on which ISA DC will be
run, in order to successfully use the tool:
- IBM JRE/JDK version 1.6 or later
The following issues should be taken into consideration before you attempt to use
ISA DC:
- ISA DC cannot be run remotely. It must be run on the machine where the instance
is configured.
- ISA DC cannot be used to collect data from InfoSphere CDC for z/OS.
- If InfoSphere CDC is installed but you have not configured an instance or are
unable to configure an instance, ISA DC can still be used to collect minimal data to
assist IBM Technical Support in resolving the issue.
See also:
- To use ISA DC to collect data for a product problem (command line)
- To use ISA DC to collect data for a product problem (GUI)
- To use ISA DC to collect data for a question or an enhancement request
(command line)
- To use ISA DC to collect data for a question or an enhancement request
(GUI)
Parent topic:Troubleshooting
109
To use ISA DC to collect data for a product problem
(command line)
Procedure
1. Launch the IBM® Support Assistant.Run the isadc.bat or isadc.sh file, located in
the isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Enter 1 to accept the license agreement and press Enter.After the license
agreement has been accepted, it will not be shown again.
3. Provide a file name and press Enter.The name provided will be given to the .zip
file containing the data collection results.
If you do not want to assign a name to the data collection results, press Enter
and a default name will be used.
4. Enter 1 to confirm your chosen file name and press Enter to continue.
5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data
Collector and press Enter.The Welcome page is displayed.
6. Read the Welcome page information and enter 1 to proceed. Press Enter.
7. Enter 1 to collect data for a product problem and press Enter.
8. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
9. Select the name of the InfoSphere CDC instance for which data will be collected.
If you have multiple instances of InfoSphere CDC configured, you will be asked
to select which instance for which you want to collect. Enter the corresponding
number for the instance name and press Enter.
If you have a single InfoSphere CDC instance configured, it will be selected
automatically and this step will be skipped.
Even if you do not have an instance configured, ISA DC will still collect what
data is available. If no instance is configured, you can skip to Step 14.
10. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
11. If your selected instance is not running, you will be alerted by ISA DC. As only
minimal data is available if the instance is stopped, it is preferable that the
instance be running during data collection.Try to start your instance. When the
instance is running, enter 1 and press Enter.
If you cannot start your instance and want to continue the data collection
process, enter 2 and press Enter.
110
12. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
13. If the instance is running, you will be asked for information regarding when the
problem occurred.
A. Enter the date and time when you think the problem began and press Enter.
This information must be entered in the following format: yyyy-mm-dd
hh:mm:ss
B. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
C. Determine the period of time for which the data will be collected and press
Enter.The amount specified will be applied as a before value and an after
value to the date and time specified previously. For example, if you select 1
Day as the time period, data will be collect for 24 hours before the specified
date and time and for the 24 hours after the specified date and time.
D. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
14. Select the method to transfer the data collection archive file and press Enter.
Choose one of the following options:
- Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to
IBM Support using a secure protocol.
- Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM
Support using an unencrypted protocol.
- Send using FTP to another location (unencrypted)—Sends the .zip file to a
recipient of your choice, using an unencrypted protocol.
- End the collection without sending—Ends the data collection and creates
the .zip file, but does not transfer it.
15. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
16. If you chose to end the collection without sending the output, ISA DC will notify
your when the .zip file has been successfully created. Enter 1 and press Enter to
exit the application.
17. If you chose to transfer the file using HTTPS, follow these steps:
A. If you want to receive a confirmation email when the upload was successful,
111
enter an email address and press Enter. If you do not want to receive
confirmation, press Enter to continue.
B. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
C. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of PMRNumber.BranchNumber.CountryCode. If an unknown
PMR number is entered, you will be asked to correct the PMR number and
re-send the data.
D. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
18. If you chose to transfer the file to IBM Technical Support using unencrypted
FTP, follow these steps:
A. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR
number is entered, you will be asked to correct the PMR number and re-send
the data.
B. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
19. If you chose to transfer the file using unencrypted FTP, follow these steps:
A. Enter the FTP host name and press Enter.
B. Enter the user name and press Enter.
C. Enter the password for the user name and press Enter.
D. Enter the path for the directory on the FTP server and press Enter.
E. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
20. When you receive notice that the operation has completed successfully, enter 1
and press Enter to exit the application.
Parent topic:Using the IBM Support Assistant (ISA DC)
112
To use ISA DC to collect data for a product problem
(GUI)
Procedure
1. Launch the IBM® Support Assistant.Run the index.html file, located in the
isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Read the license agreement and click OK to accept it.After the license
agreement has been accepted, it will not be shown again.
3. Click Start.The Welcome screen opens.
4.
5.
6.
7.
Click OK.
Select A product problem from the drop down box.
Click OK.
Select the name of an InfoSphere CDC instance from the drop down list and
click OK.If you have multiple instances of InfoSphere CDC configured, you will
be asked to select which instance for which you want to collect.
If you have a single InfoSphere CDC instance configured, it will be selected
automatically and this step will be skipped.
8. If your selected instance is not running, you will be alerted by ISA DC. As only
minimal data is available if the instance is stopped, it is preferable that the
instance be running during data collection.Try to start your instance. When the
instance is running, select Yes, I have started the instance from the drop down
box and click OK.
If you cannot start your instance and want to continue the data collection
process, select No, continue with minimal data collection from the drop down
box and click OK.
9. If the instance is running, you will be asked for information regarding when the
problem occurred. Enter the date and time when you think the problem began
and click OK.This information must be entered in the following format: yyyy-mmdd hh:mm:ss.
10. Determine the period of time for which the data will be collected and click OK.
Choose one of the following values:
- 6 hours
- 12 hours
- 1 Day
- 2 Days
- 7 Days
The amount specified will be applied as a before value and an after value to the
date and time specified previously. For example, if you select 1 Day as the time
period, data will be collect for 24 hours before the specified date and time and
for the 24 hours after the specified date and time.
113
11. If you chose to end the collection without sending the output, select Do not
transfer data to IBM. ISA DC will notify you when the .zip file has been
successfully created.
12. If you want to transfer the data to IBM using a secure transfer (HTTPS), select
the Transfer to IBM option.
A. Choose the HTTPS transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Enter your email address.
D. Click Transfer.
13. If you want to transfer the data to IBM using unencrypted FTP, select the
Transfer to IBM option.
A. Choose the FTP transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Click Transfer.
14. If you choose to send the data to a location other than IBM using unencrypted
FTP, click Transfer to another server via FTP
A. Enter the email address or IP address of the recipient in the Hotmail/IP
Address field.
B. Enter the user name.
C. Enter the password.
D. Enter the path for the directory on the FTP server.
E. Click Transfer.
15. When you receive notice that the operation has completed successfully, click
Browse directory if you want to see the file you created or click Start New
Collection to collect more data.To exit the application, close your browser tab or
window.
Parent topic:Using the IBM Support Assistant (ISA DC)
114
To use ISA DC to collect data for a question or an
enhancement request (command line)
Procedure
1. Launch the IBM® Support Assistant.Run the isadc.bat or isadc.sh file, located in
the isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Enter 1 to accept the license agreement and press Enter.After the license
agreement has been accepted, it will not be shown again.
3. Provide a file name and press Enter.The name provided will be given to the .zip
file containing the data collection results.
If you do not want to assign a name to the data collection results, press Enter
and a default name will be used.
4. Enter 1 to confirm your chosen file name and press Enter to continue.
5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data
Collector and press Enter.The Welcome page is displayed.
6. Read the Welcome page information and enter 1 to proceed. Press Enter.
7. Enter 2 to collect data for a question or an enhancement request and press
Enter.
8. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
9. Select the method to transfer the data collection archive file and press Enter.
Choose one of the following options:
- Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to
IBM Support using a secure protocol.
- Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM
Support using an unencrypted protocol.
- Send using FTP to another location (unencrypted)—Sends the .zip file to a
recipient of your choice, using an unencrypted protocol.
- End the collection without sending—Ends the data collection and creates
the .zip file, but does not transfer it.
10. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
11. If you chose to end the collection without sending the output, ISA DC will notify
your when the .zip file has been successfully created. Enter 1 and press Enter to
exit the application.
12. If you chose to transfer the file using HTTPS, follow these steps:
A. If you want to receive a confirmation email when the upload was successful,
115
enter an email address and press Enter. If you do not want to receive
confirmation, press Enter to continue.
B. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
C. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of PMRNumber.BranchNumber.CountryCode. If an unknown
PMR number is entered, you will be asked to correct the PMR number and
re-send the data.
D. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
13. If you chose to transfer the file to IBM Technical Support using unencrypted
FTP, follow these steps:
A. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR
number is entered, you will be asked to correct the PMR number and re-send
the data.
B. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
14. If you chose to transfer the file using unencrypted FTP, follow these steps:
A. Enter the FTP host name and press Enter.
B. Enter the user name and press Enter.
C. Enter the password for the user name and press Enter.
D. Enter the path for the directory on the FTP server and press Enter.
E. Enter 1 to process your input and continue collecting data. Press Enter.If you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
15. When you receive notice that the operation has completed successfully, enter 1
and press Enter to exit the application.
Parent topic:Using the IBM Support Assistant (ISA DC)
116
To use ISA DC to collect data for a question or an
enhancement request (GUI)
Procedure
1. Launch the IBM® Support Assistant.Run the index.html file, located in the
isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Read the license agreement and click OK to accept it.After the license
agreement has been accepted, it will not be shown again.
3. Click Start.The Welcome screen opens.
4.
5.
6.
7.
Click OK.
Select A question or enhancement request from the drop down box.
Click OK.
If you chose to end the collection without sending the output, select Do not
transfer data to IBM. ISA DC will notify you when the .zip file has been
successfully created.
8. If you want to transfer the data to IBM using a secure transfer (HTTPS), select
the Transfer to IBM option.
A. Choose the HTTPS transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Enter your email address.
D. Click Transfer.
9. If you want to transfer the data to IBM using unencrypted FTP, select the
Transfer to IBM option.
A. Choose the FTP transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Click Transfer.
10. If you choose to send the data to a location other than IBM using unencrypted
FTP, click Transfer to another server via FTP
A. Enter the email address or IP address of the recipient in the Hotmail/IP
Address field.
B. Enter the user name.
C. Enter the password.
D. Enter the path for the directory on the FTP server.
E. Click Transfer.
11. When you receive notice that the operation has completed successfully, click
Browse directory if you want to see the file you created or click Start New
Collection to collect more data.To exit the application, close your browser tab or
117
window.
Parent topic:Using the IBM Support Assistant (ISA DC)
118
Contacting IBM Support
IBM® Support provides assistance with product defects.
Before contacting support, ensure you have the appropriate information for IBM
Support. Also, your company must have an active IBM software maintenance
contract, and you must be authorized to submit problems to IBM. For information
about the types of maintenance contracts available, see Enhanced Support in the
Software Support Handbook at: techsupport.services.ibm.com/guides/services.html
In this section, you will learn:
- Determining your version of InfoSphere CDC
Before contacting support, ensure you identify the version and build number of the
InfoSphere® CDC product you are currently running.
- Collecting InfoSphere CDC information for IBM Support
To help IBM Support understand and troubleshoot your problem, provide as much
InfoSphere CDC information to them as possible.
- Collecting performance statistics on a subscription for IBM Support
When encountering a performance issue with your subscriptions, the IBM Support
team requires statistics information to properly analyze the subscription. By default,
collecting statistics for a subscription is automatically enabled.
- Exchanging information with IBM Support
To diagnose or identify a problem, it is sometimes necessary to provide IBM
Support with data and information from your system. In other cases, IBM Support
might provide you with tools or utilities to use for problem determination.
Submitting diagnostic information to IBM can help IBM Support begin a Problem
Management Report (PMR). If you have a problem and have opened a PMR to
find a solution, problem determination data is needed to find a solution.
- Reporting a problem to IBM Support
You can contact IBM Support with a problem.
Parent topic:Troubleshooting
119