JR27060: REPLICATION ENGINE FIXES FOR DB2 V9FP4

DB2 Version 9.1 Fix Pack 4a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 4 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 5   for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6   for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12  for Linux, UNIX and Windows

APAR status

• Closed as new function.

Error description

Local fix

Problem summary

• This APAR addresses the following problems:
   1. wsdbu00316678: Q Apply is not able to consume all messages
     from the spill queue and gets MQRC = 2033 (queue empty)
     after the first MQGET from the spill queue.  SUN customers
     using load will not be able to finish successfully if
      there are changes on the source table during the time load
     is proceeding as Q Apply is not able to process the spill
     queue for load successfully.
   2. wsdbu00190669: If there are too many rows to prune each
      interval, the pruning thread could block too long to detect
     a stop signal for that thread.
  3. wsdbu00308538: New message added.
  4. wsdbu00306301: Q Apply logs exceptions twice for
     conflict_action S or Q
  5. wsdbu00307346: Without the range, asntdiff processes too
     many rows.
  6. wsdbu00307534: Q Capture issued SQL error message when
     preparing predicates.
  7. wsdbu00306030: P2P restriction causes Capture error when a
     column is added to a table.
  

Problem conclusion

• 1. This problem has been fixed.
  2. A limit of 15000 rows deleted per interval was put in place
     so the prune thread would not become unresponsive.  As long
     as the prune thread interval is adjusted according to the
     number of prunable rows generated by qcapture, the prune
     thread should be able to delete any required rows, while
     being responsive to any stop signals.
  3. New message added that reflects the time slice that was
     used in monitoring.
  4. Q Apply should not put two entries for the same exception.
     Q Apply will correctly log only once into the exceptions
     table for conflict_action/error_Action S or Q.
  5. The number of rows must be limited by an option.  The
     REANGECOL option is introduced.
  6. Q Capture does not issue SQL error message on first
  7. The restriction has been removed.
  These fixes will be available in DB2 LUW V9.1 FP4.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  REPLICATION SER

• Fixed component ID

  5724N9800

Applicable component levels

• R910 PSY

     UP