Replication Guide and Reference


Problem determination

When replication fails or executes in an unexpected way, you need to determine the cause of the problem and find a solution that fixes the problem. DB2 DataPropagator provides error messages, trace records, log records, and information stored in the control tables to assist you in the problem-determination task. Using the information provided by the product, you can often fix a problem yourself, but sometimes the best solution is to call IBM Software Support. This chapter includes:

This book also includes other resources that can help you in problem determination:

Recommendation: When using problem-determination facilities to test or debug your replication scenarios:


Problem determination scenario

The following scenario shows how you might trace a replication error using the facilities discussed in this chapter.

After you define replication sources and subscription sets, the SQL statements for your replication requests complete satisfactorily, but the Apply program does not replicate the data successfully. To determine the error, you could:

  1. Examine any error messages returned directly to the terminal for the Apply program job or process.
  2. Run the Replication Analyzer to verify that the replication setup is correct.
  3. Examine the Apply trail table (ASN.IBMSNAP_APPLYTRAIL) for any indicators of the problem.
  4. Examine the Capture program trace table (ASN.IBMSNAP_TRACE) for indicators from the Capture program's activity.
  5. Examine the log files for the Capture and Apply programs for indicators from their activities.
  6. Examine the CD and UOW tables to verify that the Capture program is capturing changes.
  7. Rerun the Capture and Apply programs with the trace option and examine the trace file for indicators of the problem.

Problem determination for replication administration

The DB2 Control Center or DJRA can encounter errors when it gathers information from source servers, target servers, or control servers to create the SQL statements for administration and when it is actually running the SQL statements to set up the replication sources and subscription sets. The primary indicators are SQL messages, SQLSTATE codes, and Capture- and Apply-program messages (those that begin with the letters ASN) that accompany the error. See the DB2 Universal Database Message Reference (or DB2 message reference for your platform) for more information about DB2 error messages and SQL states. The ASN messages are also described in Capture and Apply messages and Replication messages for AS/400.

The Capture- and Apply-program messages are issued or recorded in the following locations:

The Capture and Apply programs can also encounter problems while capturing and replicating changed data, even though the SQL that the DB2 Control Center or DJRA generated for defining replication sources and subscriptions ran without error. You can determine the cause of the errors with information from the following sections: Problem determination for the Apply program, Problem determination for the Capture program, and Troubleshooting.


Problem determination for the Apply program

DB2 provides the following problem-determination tools for the Apply program:

Apply-program messages
These messages describe errors from the Apply program. See Capture and Apply messages and Replication messages for AS/400.

Apply trail table
This table contains SQLSTATE codes and SQL error codes for a failed replication, as well as audit-trail information for the Apply program.

Apply-program trace file
This file contains a record of all Apply-program activity. There is one trace file for each Apply-program instance at the server where the Apply program is running. To get a trace file, you must specify one of the trace parameters when you start the Apply program.

Apply-program log file
This file summarizes the activities of the Apply program and can be a useful diagnosis tool.

Apply trail table

Each time the Apply program attempts to replicate a subscription set, it inserts a new row in the Apply trail table (ASN.IBMSNAP_APPLYTRAIL). This table is located at each control server, along with other control tables, and has one row for each successful or unsuccessful subscription cycle. Because the Apply program appends to this table, you should prune it periodically. For a description of the Apply trail table, see Apply trail table.

For subscription sets that do not replicate successfully, the Apply trail table records the SQL code and the SQLSTATE. Additional SQL codes and states associated with the problem can be found in the Apply program trace file.

To query the Apply trail table for problem-determination information:

Use the Replication Analyzer to view information in this table; see Using the Replication Analyzer. You can also query information in the Apply trail table directly to gather problem-determination information for failing subscription sets.

  1. Ensure that the data in the Apply trail table is current:
  2. To gather the problem-determination information, execute a query similar to:
    SELECT TARGET_TABLE, STATUS, SQLSTATE, SQLCODE, SQLERRM, APPERRM, LASTRUN, LASTSUCCESS
    FROM ASN.IBMSNAP_APPLYTRAIL
    WHERE STATUS <> 0
    ORDER BY TARGET_TABLE, LASTRUN DESC, SQLCODE DESC, SQLSTATE ASC 
    

    This query returns the following columns from the Apply trail table:

    TARGET_TABLE
    The target table for the current subscription set.

    STATUS
    Contains -1 to indicate the failed subscription set.

    SQLSTATE
    Contains the error SQLSTATE for the failed subscription set.

    SQLCODE
    Contains the error SQLCODE for the failed subscription set.

    SQLERRM
    Contains the text of the error message that corresponds to the SQL code.

    APPERRM
    Contains the text of the Apply program error message.
  3. Read the error message text to determine the database to which the Apply program was connected when the error occurred; for example, did the error occur while the Apply program was connected to the source server or the target server? Refer to the DB2 SQL Reference for information on the SQL codes and states.
  4. Be sure to reenable subscription sets that were successful.

Apply-program trace file

You can trace the operation of the Apply program to help isolate the causes of certain kinds of replication errors. The Apply program creates a trace file when you include a trace parameter to the Apply program start command. See the Capture and Apply chapter in for your platform in Operations for the syntax of the command.

While tracing its activity, the Apply program records the following kinds of information in the trace file:

The Apply program inserts error messages and indicators in the trace file at points when it encounters an error.

To create a trace file:

  1. Temporarily disable subscription sets that are successful to reduce the volume of information in the trace file and ensure that data in the trace file only applies to subscription sets that have problems.
  2. Start the Apply program with the appropriate trace parameter:

    trcflow
    Provides very detailed information that is oriented toward helping IBM Software Support diagnose errors.

    trcerr
    Provides less detail and can be a better choice when you are new to replication.

    When you specify a trace parameter, you must also specify the name of a trace file (for workstation systems, precede the trace file name with the greater than symbol (>) to redirect the output to the file). For example, to start Apply for Windows with trace, issue the following command from the command line:

    asnapply ApplyQual CtlSrvr trcflow > apply.trc
    

    where ApplyQual is the Apply qualifier, CtlSrvr is the control server, and apply.trc is the trace file. The trace file is created in the directory from which you start the Apply program.

  3. Let replication run until the problem recurs and the Apply program inserts a row into the Apply trail table.
  4. Stop the Apply program and restart it without the trace parameter. Be sure to re-enable subscription sets that were successful.
  5. View the trace file using any editor. You could also send the file to other systems or print it.

Apply-program log file

For a summary of the Apply program's activities, you can view the Apply program log file. The log file is in the directory from which you start the Apply program and contains messages issued by the Apply program. Because the information in the Apply program log file is high level, it typically directs you to the Apply trail table for more detailed information.

The name of the log file is ApplyQual.APP, where ApplyQual is the Apply qualifier associated with the Apply-program instance.


Problem determination for the Capture program

DB2 provides the following problem-determination tools for the Capture program:

Capture-program messages
These messages describe errors from the Capture program. See Capture and Apply messages and Replication messages for AS/400.

Trace table
This table contains audit-trail information for the Capture program.

Capture-program trace file
This file contains a record of all Capture-program activity.

Capture-program log file
This file summarizes the activities of the Capture program and can be a useful diagnosis tool.

This section also includes problem-determination for the Capture program on the following operating systems: AS/400, OS/390, VM and VSE.

Capture-program trace table

The Capture program inserts a new row in the trace table (ASN.IBMSNAP_TRACE) whenever it encounters an event for which it also issues a message. This table is located at the source server and contains basic information about the activities of the Capture program. For a description of the trace table, see Trace table.

To query the trace table for problem-determination information:

Use the Replication Analyzer to view information in this table; see Using the Replication Analyzer. You can also query information in the trace table directly to gather problem-determination information for the Capture program.

  1. Ensure that the data in the trace table is current. You might want to delete rows from the table to remove information from past Capture operations. The Capture program deletes all rows from this table when you cold start it, so if you want to keep trace information, you should copy the table before you cold start the Capture program.
  2. To gather the problem-determination information for the Capture program, execute a query similar to:
    SELECT *
    FROM ASN.IBMSNAP_TRACE
    ORDER BY TRACE_TIME
    

    This query returns the following columns from the trace table:

    OPERATION
    The type of Capture-program operation, such as initialization, capture, or an error condition.

    TRACE_TIME
    The time the current row was inserted into this table.

    DESCRIPTION
    The message ID and message text.

    For AS/400 systems, this table also includes the following columns:

    JOB_NAME
    The fully-qualified name of the job that wrote the current entry.

    JOB_STR_TIME
    The starting time for the job listed in the JOB_NAME column.

Capture-program trace file

You can trace the operation of the Capture program to help isolate the causes of certain kinds of replication errors. The Capture program creates a trace file when you include a trace parameter to the Capture program start command. See the Capture and Apply chapter in for your platform in Operations for the syntax of the command.

The Capture program inserts error messages and indicators in the trace file at points when it encounters an error.

To trace problems on AS/400 systems, view the job logs of the control and journal jobs. See Problem determination for AS/400 for more information.

To create a trace file:

  1. Start the Capture program with the trace parameter and redirect the output to a file. For example, to start Capture for Windows with trace, issue the following command from the command line:
    asnccp SrcSrvr trace > capture.trc
    

    where SrcSrvr is the source server and capture.trc is the trace file. Because this command does not include parameters for the type of start (WARM, WARMNS, or COLD) or for pruning (PRUNE or NOPRUNE), the Capture program uses the defaults (WARM and PRUNE). The trace file is created in the directory from which you start the Capture program.

  2. Let replication run until the problem recurs.
  3. Stop the Capture program and restart it without the trace parameter.
  4. View the trace file using any editor. You could also send the file to other systems or print it.

Capture-program log file

For a summary of the Capture program's activities, you can view the Capture-program log file. The log file is in the directory from which you start the Capture program and contains messages issued by the Capture program.

The name of the log file is SrcSrvr.CPP, where SrcSrvr is the name of the source server.

Other problem-determination facilities for the Capture program

For OS/390, VM, and VSE, the Capture program provides the following tools:

Trace buffer
The Capture program puts a small amount of critical diagnostic data in a wraparound trace buffer during processing. Each trace-buffer entry describes the current status of data capture. If a severe error occurs, the Capture program prints the trace buffer before terminating. The trace buffer supplements the Capture program error message.

Trace output
When an error occurs, you can run the Capture program with the TRACE option (see Capture-program trace file). When you use this option, the Capture program writes trace information logic flow to:

SYSPRINT (for OS/390)

the console (for VM)

STDOUT (for VSE)

This information can be used by IBM Software Support to diagnose operational problems.

Storage dump
When the Capture program terminates with a severe error, it generates a system dump in the SYS1.DUMP data set. This dump is IPCS readable, contains more diagnostic information than the Capture program trace, and can be used by IBM Software Support to diagnose system problems.

For OS/390, the Capture program also provides:

Alert generation
If a severe error occurs, the Capture program for OS/390 alerts NetView, if NetView is active. The alert uses the NMVT format for a generic alert defined by the SNA generic-alert architecture. If NetView is not available, the Capture program still writes error messages to the MVS console.

Problem determination for AS/400

Capture for AS/400 has unique problem determination facilities because of its dependency on journals and journal receivers as its primary source of input. This section describes problem-determination facilities for the Capture program for AS/400 and associated problem-recovery methods: gathering information about active jobs, determining if the journal job is started, and collecting data for problem determination.

Gathering information about active jobs

One of the first steps in problem determination is gathering information about currently active jobs. Issue the Work with Submitted Jobs command (WRKSBSJOB QZSNDPR) for a list of all active jobs in the subsystem. If you fail to find a particular job, use the WRKSBMJOB command to locate and view the job log for the job. The name of the Capture program control job is QZSNCTL5. The name of the journal job is the same as the journal name (either QSQJRN-the default journal name for SQL collections-or a name that you specified for the journal).

Be sure to record the 6-digit job numbers because you might need them later in the problem-determination process.

Determining if the journal job is started

If, five minutes (or more) after starting the Capture program, you discover that only one job (QDPRCTL5) is running, check the following conditions:

Collecting data for problem determination

The following items are needed for problem determination for the Capture program. The items are listed in order of importance:

  1. The job log of the Capture-program control job QDPRCTL5.
  2. The job log of the Capture-program journal job.
  3. Old journal receivers. They are important because they contain important time-sequence information. Save the journal receivers in a file or keep them if a remote sign-on by IBM Software Support is likely. The journal receivers for the following tables are useful for problem determination:

    Control tables
    These include the register table, the register extension table, the pruning control table, the unit-of-work table, the critical section table, and the warm start table. The journal for these tables is ASN/QSQJRN.

    Source table
    These journal receivers are kept as long as the Capture program needs them. Make sure that they are not deleted automatically by the system because they are useful for problem determination.

    Change data table of the replication source
    Usually, the journal is named QSQJRN and is in the same library as the source table. If it is not, find the library and the name of the journal by issuing a DSPFD lib/sys command (where lib is the library and sys is the system name of the CD table). To find the system name of the change data table, execute the following SQL statement:
    SELECT DBXFIL 
    FROM QSYS/QADBXREF
    WHERE DBXLFI = 'sqlname' AND DBXLIB = 'lib'
    

    where sqlname is the SQL name of the CD table. Both sqlname and lib are case sensitive.

  4. A formatted dump of the user index QDPR/QZSNINDEX5. Issue the following command before the Capture program ends:
    DMPOBJ QDPR/QZSNINDEX5 *USRIDX
    
  5. The contents of the rows in the register table and the register extension table that correspond to replication sources that you want to know more about. You can collect this information by executing the following SQL statements:
    SELECT A.*, HEX(CD_OLD_SYNCHPOINT), HEX(CD_NEW_SYNCHPOINT)
    FROM ASN/IBMSNAP_REGISTER A
    WHERE SOURCE_OWNER='SrcOwn' AND SOURCE_TABLE='SrcTbl'
     
    SELECT * 
    FROM ASN.IBMSNAP_REG_EXT
    WHERE SOURCE_OWNER='SrcOwn' AND SOURCE_TABLE='SrcTbl'
    

    where SrcOwn is the library name and SrcTbl is the table name of the replication source in question. Both SrcOwn and SrcTbl are case sensitive.

  6. The contents of the global row in the register table. You can check the progress of the Capture program by executing the following SQL statement:
    SELECT A.*, HEX(SYNCHPOINT)
    FROM ASN/IBMSNAP_REGISTER A
    WHERE GLOBAL_RECORD = 'Y'
    
  7. Entries in the trace table for significant job events. To find entries for the Capture program control job or the Capture program journal job, execute the following SQL statement:
    SELECT * 
    FROM ASN/IBMSNAP_TRACE
    WHERE SUBSTR(JOB_NAME, 21, 6) = 'jobnum'
    ORDER BY TRACE_TIME
    

    where jobnum is the job number for the job you want to investigate. The DESCRIPTION column provides important information about the job.

    Examples:

    To gather trace table entries after 7 a.m., March 31, 2000, execute the following query:

    SELECT * 
    FROM ASN/IBMSNAP_TRACE
    WHERE TRACE_TIME > '2000-03-31-07.00.00.000000'
    ORDER BY TRACE_TIME
    

    To retrieve all ASN0303 (data capturing is interrupted...) trace entries after 7 a.m., March 31, 2000, execute the following query:

    SELECT * 
    FROM ASN/IBMSNAP_TRACE
    WHERE TRACE_TIME > '2000-03-31-07.00.00.000000' AND
          SUBSTR(DESCRIPTION, 1, 7) = 'ASN0303'
    ORDER BY TRACE_TIME
    
  8. Rows from the warm start table. There is a row for every journal that is used by one or more replication sources. You can retrieve the row for the journal job by executing the following SQL statement:
    SELECT * 
    FROM ASN/IBMSNAP_WARM_START
    WHERE JRN_LIB='JLib' AND JRN_NAME='JName'
    

    where JLib is the library name and JName is the table name for the journal. Both JLib and JName are case sensitive.

  9. Data from the target server that can help determine how and why the Apply program fails to replicate to the target table:
  10. A formatted dump of the user spaces for the journal jobs. These jobs are in library QDPR and they have the name QDPRxxxxxx, where xxxxxx is the job number of the journal job. Issue the following command before the Capture program ends:
    DMPOBJ QDPR/QDPRxxxxxx *USRSPC
    

Using the Replication Analyzer

The Replication Analyzer analyzes the following tables for correctness, consistency, and efficiency: replication control tables, change data tables, target tables, and target-table indexes. It also checks database parameters for optimal replication performance. You can use the Replication Analyzer to analyze the behavior of the Capture program or the Apply program. It can answer such questions as: "Why is Capture not capturing?" and "why is Apply not applying?" The Replication Analyzer can help diagnose problems, verify replication setup, and offer suggestions for performance tuning.

You can run the Replication Analyzer at any time after replication setup is complete to analyze a failure by the Capture program or the Apply program, or simply to verify your setup. You can find the Replication Analyzer in the \sqllib\bin directory. The bind file for the Analyzer, analyze.bnd, is in the \sqllib\bnd directory, but it is not necessary to bind the program because the Analyzer is autobound for DB2 V6 and V7. If you run the Analyzer with DB2 V5, use the following command to bind the Analyzer:

bind analyze.bnd isolation UR

Important: The Replication Analyzer works only with DataPropagator Version 5 or later; it does not work with DataPropagator Version 1. Contact IBM Software Support if you need a version of the Replication Analyzer that can work with DataPropagator Version 1.

You run the Replication Analyzer from the Windows command line. Type the name of the Replication Analyzer command file (analyze.exe) followed by a list of DB2 alias names of source, target and control servers, separated by blanks (each of these names must be eight or fewer characters in length).

Because the Replication Analyzer runs from the command line, you do not need to have either DJRA or the DB2 Control Center running when you run the Replication Analyzer.

If end-user authentication is required to connect to any server, you must create a password file in the current directory. This file must be named analyze.pwd and should contain one or more entries with the following format:

SERVER=server_alias USER=userid PWD=password

IBM Software Support may ask you to run the Replication Analyzer and send the generated file to someone within IBM to check the output for correctness.

Syntax:

              .-----------------.
              V                 |
>>-analyze-+----DB_alias_name---+---+------------+---| A |--+--><
           |                        +-deepcheck--+          |
           |                        '-lightcheck-'          |
           '-?----------------------------------------------'
 
A
 
    .------------------------.
    V                        |
|------+------------------+--+---+------------------+-----------|
       '-q--=--ApplyQual--'      '-f--=--directory--'
 

deepcheck
Specifies that the Analyzer perform a more complete analysis, including CD and UOW table pruning information, DB2 for OS/390 tablespace partitioning and compression detail, and analysis of target indexes with respect to subscription keys. The analysis includes all servers. This keyword is optional.

f
Specifies the directory in which to store the output HTML file. If you do not specify this keyword, the HTML file is created in the current directory. No space is allowed between the keyword (f), the equal sign, and the value. This keyword is optional.

lightcheck
Specifies that all column detail be excluded from the report, thus reducing report generation time, saving resources, and producing a smaller HTML file. This keyword is optional and is mutually exclusive with the deepcheck keyword.

q
Specifies the Apply qualifier to use as a filter to restrict analysis of subscription sets. You can specify the q keyword more than once if you want to analyze multiple Apply qualifiers. No space is allowed between the keyword (q), the equal sign, and the value. This keyword is optional.

?
Shows the syntax of the analyze command.

The keywords are not case sensitive.

Output: The Replication Analyzer creates an output HTML file, analyze.htm, which you can open and view with any Web browser. This file is stored in the same directory from which you run the Analyzer, or in the directory specified by the f keyword. Messages from the Analyzer are sent to stdout. The output HTML file contains the following information:

Some of this information is only included when the deepcheck keyword is specified.

Examples:

analyze mydb1 mydb2  
 
analyze mydb1 mydb2 f=mydirectory 
 
analyze lightcheck mydb1 mydb2 
 
analyze q=applyqual1 q=applyqual2 deepcheck mydb1 mydb2 f=mydirectory

Troubleshooting

This section describes various problems that can occur when running the Capture and Apply programs and how to diagnose the cause of these problems. You should also use the Replication Analyzer to determine general and specific problems with the replication environment.

Problem: The Capture for OS/390 program does not start.

Ensure that APF authorization was performed for all STEPLIB libraries as specified in the RUN JCL.

Problem: Capture for VM or Capture for VSE does not start.

Ensure that:

Problem: The Capture program is not capturing updates.

Any of the following errors could prevent the Capture program from capturing updates:

Problem: I'm not sure if the Capture program is running successfully.

The first time that you start the Capture and Apply programs, the Apply program performs a full refresh to populate the target tables. Then the Capture program writes message ASN0104I to the trace table, providing information related to table owner name, table name, and starting log sequence number value. This information provides a point from which the Capture program starts to capture updates.

Updates captured from then on are placed in CD tables. They are eventually applied to target tables and pruned from the CD tables. After the Capture program runs for some time, you should see rows in the CD tables if changes are made to the sources. Periodically, check the trace table to see the progress made by the Capture program. If it encounters errors, it sends them to the console and also logs them in the trace table. Similarly, the Apply program logs its information in the Apply trail table.

Problem: Capture for OS/390 issued message ASN0000E instead of the proper message number.

Message ASN0000E is a generic message that is issued instead of a proper message if the specified VSAM message file in the RUN JCL was not found. See the Capture for OS/390 program directory for information on installing the VSAM message file.

Problem: Capture for VM or Capture for VSE issued message ASN0000E instead of the proper message number.

Message ASN0000E is a generic message that is issued instead of a proper message if either the default message file, ASNLS001 MSG, or the specified message file in the Capture startup JCL was not found. See the Capture for VM or Capture for VSE program directory for information on installing the message file.

Problem: The Capture program terminates.

The Capture program terminates either because of a severe error, or when you issue the stop command. The Capture program terminates with a return code that indicates successful or unsuccessful completion. Return codes are:

0
stop command issued

8
Error during initialization

12
Any other severe error

Problem: Capture for OS/390 failed while using the LE for OS/390 environment.

The Capture program runs in the LE for OS/390 environment and the recommended minimum Capture job-step region size when starting Capture is REGION=10M.

Problem: Error message 0509 was issued.

Error message 0509 occurs because multiple versions of DB2, or DB2 and DataJoiner, are installed on the same system:

Ensure that the LIBPATH environment variable is set to the same environment in which the Apply program starts.

Problem: Apply component for DB2 Universal Database stops with an SQLCODE= -330, SQLSTATE=22517, "A string cannot be used, because its characters cannot be translated".

When copying between DB2 for OS/390 and DB2 on another platform, the CCSID translation can cause an INSERT to fail if a translated value is longer than the DB2 column in which it will be inserted.

If you are running in a mixed environment, ensure that you have installed the latest maintenance for the CCSID support of your DB2 for OS/390 program.

For more information on character translation, see the character conversion appendix in the DB2 for OS/390: Installation Guide.

Problem: I received system error 1067 trying to start the Capture or Apply program as a Windows NT Service.

Error code 1067 occurs under the following circumstances:

Problem: The ASNSERV.LOG file in ASNPATH tells me that the Apply program was started correctly, but the Apply process terminated.

To find out why the Apply program terminated, change the syntax of NTSERV.ASN to:

...ASNAPPLY APPLYQUAL TRCFILE

The trace output will be written to the Apply trace file:

<ASNPATH pathname>ApplyQual.TRC

Problem: I performed a successful bind, but when running the Apply program, I still get SQLCODE -805, SQLSTATE 51002.

Make sure that the user ID has EXECUTE privilege on the Apply program packages, and make sure to bind both the Apply program packages to the control, source, and target server databases.

Problem: The DB2 log filled to capacity because I copied a very large table.

If the error occurred during a full refresh, you can use alternative methods to load large tables. You can either use the ASNLOAD exit routine, or you can perform your own load, as described in Loading target tables offline using DJRA.

If the error occurred while applying changed data, then you can change the data-blocking parameter to break down large blocks of changed data. See Specifying a data-blocking value.

Problem: Capture was cold started, which caused the Apply program to perform a full refresh, but I don't want a full refresh.

If your target table is very large, and in cases where you decided to use only your own load mechanism, you might want to suppress any future full refreshes of the Apply program. Set the DISABLE_REFRESH flag to 1 in the register table at the source server for the source table. In this case, the Apply program issues message ASN1016E and copies nothing until you perform a full refresh.

If you want to bypass full refresh and also start capturing data as soon as possible, you can use the offline load function of DJRA. In this case, you do not need to unload and reload the tables, but just run the SQL generated for step 1 and step 4. In addition to disabling full refresh, offline load also deactivates the subscription until you complete step 4. See Loading target tables offline using DJRA.

Problem: A gap was detected, so the Apply program won't perform a full refresh of my target table.

Force a full refresh by resetting the LASTSUCCESS, SYNCHTIME, and SYNCHPOINT values in subscription set table to null.

Problem: I unsuccessfully tried to start a second Apply program instance.

You must run each instance with a unique Apply qualifier.

Problem: I received a security violation message, and the Apply program is not authorized to connect to the database.

The control server name, user ID, and password definitions are case sensitive and must match exactly those specified in the password file. Check your definitions again.

Apply for AS/400 does not use a password file, so it attempts to connect to the database using the user ID specified in the user parameter of the STRDPRAPY CL command. Ensure that you correctly set up your DRDA connectivity definitions.

Problem: I received error ASN1003 with SQLCODE = -1032 and SQLSTATE = 57019.

You must start the database manager before invoking the Apply program.

Problem: Apply receives SQLCODE -206 when fetching the source data.

If you use a CCD table to stage replication to multiple target tables, ensure that the CD or CCD table includes all the columns expected in all target tables. Subsetting columns or selecting UOW columns to be replicated to the final targets can cause this problem when a CCD table is added to a replication scenario after the target tables are defined.

This problem should only occur if you manually define target tables and do not include all the columns when defining replication sources. You can avoid this problem by defining all target tables (adding to subscription sets) after defining any CD and internal CCD tables. DJRA does not allow columns in a target table that are not in the predefined CD or internal CCD tables; DJRA displays only a valid subset of the columns for the target table.

Problem: SQL1108 error while creating control table using DJRA

A SQL1108 error results if DB2 DataJoiner is installed on the same Windows NT system as DJRA, and you try to create the control tables in DB2 for OS/390. The problem is caused by a memory collision with the required memory space for ddcs.dll, because this DLL is not loaded during application initialization.

The workaround for this problem is to set the environment variable DB2DBMSADDR (range is between 20000000 to 70000000). This tells DB2 to put its memory in a different virtual address space to avoid collision with the application address space.


Problem-source identification questions

If you call IBM Software Support, you will be asked the following types of questions. You can save time, and perhaps diagnose the error yourself, by researching the answers to these questions:

  1. What was occurring at the time of the problem?
  2. What has changed recently in the environment?
  3. Describe the environment.
  4. What is the maintenance level of DB2 Universal Database where the Control Center is installed?
  5. On what platform is the Capture program running?
  6. What is the maintenance level of the Capture program?
  7. What is the maintenance level of DB2 (or non-IBM DBMS) where the Capture program is running?
  8. On what platform is the Apply program running?
  9. What is the maintenance level of the Apply program?
  10. On what release of DB2 (or DB2 DataJoiner) does the Apply program run?
  11. What is the maintenance level of DB2 (or DB2 DataJoiner) where the Apply program is running?
  12. Is this an occasionally-connected user? A DB2 Satellite user? A DB2 Everywhere user?
  13. What ASN messages were issued?
  14. Are there other messages in SYSLOG (for AS/400, the QSYSOPR message queue), on the screen, or in the trace file?
  15. What is the complete message text for all messages issued? Be sure to note all message numbers, database names, table names, user IDs, and file names that appear in these messages.
  16. Where does the failure occur?
    1. The DB2 Control Center
      • Is the problem with a replication source or subscription set?
      • What messages appear?
      • Can the user successfully connect to the source or target database from a command line or DB2 command window?
    2. DJRA
      • What level of DJRA are you using? Click Help -> About from the main window for this information.
      • If accessing non-IBM data sources, what level of DB2 DataJoiner are you using, and on which platform (AIX or Windows NT)?
      • Did you save the generated script file and the output file?
    3. The Capture program
      • Is the Capture program running?
      • If not, what happens when you try to warm start it?
      • Is there error information in the trace table (ASN.IBMSNAP_TRACE)?
      • Is there error information in the Capture program log file?
      • What is the DB2 configuration?
      • Are data changes successfully inserted into the CD tables?
      • Does the user ID running the Capture program have sufficient privileges to run the Capture program?
    4. The Apply program
      • Is the Apply program running?
      • If not, what occurs when the Apply program starts?
      • What messages appear?
      • Is there error information in the Apply trail table (ASN.IBMSNAP_APPLYTRAIL)?
      • Is there error information in the Apply program log file (for AS/400, in the Apply job log)?
      • Are data changes being successfully replicated to the target table?
      • Do all tables in a subscription set have the same problem?
      • What table types (for example, user copy, point-in-time, CCD) are involved in the failure?
      • Did you start the Apply program with the trace option?
      • Are CALL procedures being used?
      • Is a CCD table being used?


[ Top of Page | Previous Page | Next Page ]