IBM® DB2 Universal Database™ Replication Guide and Reference
IBM® DB2 Universal Database™ Replication Guide and Reference
SC27-1121-01
IBM DB2 Universal Database
Replication Guide and Reference
Version 8
SC27-1121-01
Before using this information and the product it supports, be sure to read the general information under Notices.
This document contains proprietary information of IBM. It is provided under a license agreement and is protected by
copyright law. The information contained in this publication does not include any product warranties, and any
statements provided in this manual should not be interpreted as such.
You can order IBM publications online or through your local IBM representative.
v To order publications online, go to the IBM Publications Center at www.ibm.com/shop/publications/order
v To find your local IBM representative, go to the IBM Directory of Worldwide Contacts at
www.ibm.com/planetwide
To order DB2 publications from DB2 Marketing and Sales in the United States or Canada, call 1-800-IBM-4YOU
(426-4968).
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1994, 2003. All rights reserved.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this book . . . . . . . . . . xi Planning for conflict detection . . . . . . 11
Who should read this book . . . . . . . xi Planning for non-DB2 relational sources . . . 12
How to use this book . . . . . . . . . xi Planning transaction throughput rates for
Conventions and terminology used in this Capture triggers. . . . . . . . . . 12
book . . . . . . . . . . . . . . xiii Planning the log impact for non-DB2
How to read syntax diagrams . . . . . . xiv relational source servers . . . . . . . 12
Road map . . . . . . . . . . . . xv Planning locks for Oracle source servers . 13
How to send your comments . . . . . . xvi Planning coexistence of pre-existing
triggers with Capture triggers . . . . . 13
Whats new for DB2 replication for Planning for code page translation . . . . 13
Version 8? . . . . . . . . . . . . xvii Replicating data between databases with
| Whats new in Version 8.1.4? . . . . . . xvii compatible code pages . . . . . . . 14
| New function . . . . . . . . . . xvii Configuring national language support
| Performance improvements . . . . . xvii (NLS) for replication . . . . . . . . 14
Whats new in Version 8 FixPak 2? . . . . xvii | Replication planning for DB2 UDB for z/OS 15
Usability improvements . . . . . . xviii | Performance tuning . . . . . . . . . 16
Performance improvements . . . . . xviii
New function . . . . . . . . . . xviii Chapter 2. Setting up for replication . . . 17
Changes to control tables . . . . . . xviii Controlling access to replication servers . . . 17
Whats new in Version 8.1? . . . . . . . xix Connectivity requirements for replication 17
Usability improvements . . . . . . . xix Authorizing user IDs for replication . . . . 19
Performance improvements . . . . . . xx Authorization requirements for
New user interface . . . . . . . . xxi administration . . . . . . . . . . 19
New function . . . . . . . . . . xxi Authorization requirements for the
Serviceability improvements . . . . . xxv Capture program . . . . . . . . . 21
Changes to replication system commands xxv Authorization requirements for Capture
Changes to control tables . . . . . . xxvii triggers on non-DB2 relational databases . 22
Functions no longer supported . . . . xxviii Authorization requirements for the Apply
program . . . . . . . . . . . . 23
Part 1. Replication guide . . . . . 1 Authorization requirements for the
Replication Alert Monitor . . . . . . 24
Storing user IDs and passwords for
Chapter 1. Planning for replication . . . . 3
replication (UNIX, Windows) . . . . . . 26
| Migration planning . . . . . . . . . . 3 Setting up the replication control tables . . . 26
Memory planning . . . . . . . . . . 3
Creating control tables (UNIX, Windows) 26
Memory used by the Capture program . . 3
Creating control tables (z/OS) . . . . . 27
Memory used by the Apply program . . . 5
Creating control tables (OS/400) . . . . 27
Memory used by the Replication Alert
Creating control tables for non-DB2
Monitor . . . . . . . . . . . . . 5
relational sources . . . . . . . . . 27
Storage planning . . . . . . . . . . . 6
Creating multiple sets of Capture control
Planning log impact . . . . . . . . . 6
tables . . . . . . . . . . . . . 28
Planning the storage requirements of target
| Capture control tables on multiple
tables and control tables . . . . . . . 8
| database partitions . . . . . . . . . 29
Planning storage requirements for
Setting up the replication programs . . . . 29
temporary files . . . . . . . . . . 9
Contents v
Reviewing historical data for trends. . . . 177 Coordinating replication events with
Reviewing Capture program messages 179 database application events . . . . . . 226
Examining Capture program throughput 179 Setting an event END_SYNCHPOINT
Displaying latency of data processed by using the USER type signal . . . . . 226
the Capture program. . . . . . . . 180 | Creating journal signal tables for remote
Reviewing Apply program messages . . 181 | journaling . . . . . . . . . . . 228
Examining Apply program throughput 181 Using the Capture CMD STOP signal . . 229
Displaying the average length of time Performing a CAPSTART handshake
taken to replicate transactions . . . . . 182 signal outside of the Apply program . . 232
| Reviewing Monitor program messages 183 Performing a CAPSTOP signal . . . . 233
| Setting up the Replication Alert Monitor . . 183 Promoting your replication configuration to
Creating Monitor control tables . . . . 184 another system. . . . . . . . . . . 235
Defining contact information for the
Replication Alert Monitor . . . . . . 185 Chapter 13. Maintaining your replication
Selecting alert conditions for the environment . . . . . . . . . . . 237
Replication Alert Monitor . . . . . . 185 Maintaining your source systems . . . . 237
Starting the Replication Alert Monitor . . 187 Maintaining source objects . . . . . . 237
Scheduling when to start the Replication Maintaining and retaining source logs
Alert Monitor . . . . . . . . . . 193 and journal receivers . . . . . . . . 238
Reinitializing the Replication Alert Maintaining your control tables . . . . . 243
Monitor . . . . . . . . . . . . 193 Using the RUNSTATS utility (UNIX,
Stopping the Replication Alert Monitor 194 Windows, z/OS) . . . . . . . . . 243
Monitoring the progress of the Capture Rebinding packages and plans (UNIX,
program (OS/400) . . . . . . . . . 195 Windows, z/OS) . . . . . . . . . 244
Reorganizing your control tables . . . . 244
Chapter 12. Making changes to your Pruning your control tables . . . . . 245
replication environment . . . . . . . 197 Preventing replication failures and
Registering new objects . . . . . . . . 198 recovering from errors . . . . . . . 249
Changing registration attributes for Maintaining your target tables . . . . . 251
registered objects . . . . . . . . . . 198
Adding columns to source tables. . . . . 199 Part 2. Replication Center . . . . 253
Stop capturing changes for registered objects 202
Reactivating registrations . . . . . . . 203
Chapter 14. Using the DB2 Replication
Removing registrations . . . . . . . . 205
Center . . . . . . . . . . . . . 255
Changing Capture schemas . . . . . . 205
Prerequisites for the DB2 Replication Center 257
Creating new subscription sets . . . . . 208
| Configuring the Replication Center for
| Adding new subscription-set members to
| host RDBMSs . . . . . . . . . . 257
| existing subscription sets . . . . . . . 209
Starting the DB2 Replication Center . . . . 258
| Disabling subscription-set members from
Using the Replication Center launchpad . . 259
| existing subscription sets . . . . . . . 210
Managing user IDs and passwords for the
| Enabling subscription-set members to
Replication Center . . . . . . . . . 260
| existing subscription sets . . . . . . . 210
Creating replication profiles . . . . . . 261
Changing attributes of subscription sets . . 210
Creating control-table profiles . . . . . 262
Changing subscription set names . . . . 211
Creating source-object profiles . . . . 262
Splitting a subscription set . . . . . . . 213
Creating target-object profiles . . . . . 263
Merging subscription sets . . . . . . . 218
Creating replication control tables . . . . 264
Changing Apply qualifiers of subscription
Creating Capture control tables . . . . 265
sets . . . . . . . . . . . . . . 221
Creating Apply control tables . . . . . 266
Deactivating subscription sets . . . . . . 224
Creating Monitor control tables . . . . 266
Removing subscription sets . . . . . . 226
Contents vii
ADDDPRSUBM: Adding a DPR Scheduling programs on UNIX operating
subscription-set member (OS/400) . . . . 395 systems . . . . . . . . . . . . . 483
ANZDPR: Operating the Analyzer (OS/400) 406 Scheduling programs on Windows operating
CHGDPRCAPA: Changing DPR Capture systems . . . . . . . . . . . . . 483
attributes (OS/400) . . . . . . . . . 410 Scheduling programs on z/OS operating
CRTDPRTBL: Creating the replication control systems . . . . . . . . . . . . . 484
tables (OS/400) . . . . . . . . . . 415 Scheduling programs on the OS/400
ENDDPRAPY: Stopping Apply (OS/400) . . 416 operating system . . . . . . . . . . 484
ENDDPRCAP: Stopping Capture (OS/400) 420
GRTDPRAUT: Authorizing users (OS/400) 422 Chapter 22. How the DB2 replication
INZDPRCAP: Reinitializing DPR Capture components communicate . . . . . . 485
(OS/400) . . . . . . . . . . . . . 432 The Replication Center, the Capture program
OVRDPRCAPA: Overriding DPR capture or triggers, and the Apply program . . . . 485
attributes (OS/400) . . . . . . . . . 434 The Capture program and the Apply
RMVDPRREG: Removing a DPR registration program . . . . . . . . . . . . . 486
(OS/400) . . . . . . . . . . . . . 440 The Capture triggers and the Apply program 488
RMVDPRSUB: Removing a DPR The Replication Center and the Replication
subscription set (OS/400) . . . . . . . 441 Alert Monitor . . . . . . . . . . . 489
RMVDPRSUBM: Removing a DPR The Replication Alert Monitor, the Capture
subscription-set member (OS/400) . . . . 443 program, and the Apply program . . . . 490
RVKDPRAUT: Revoking authority (OS/400) 446
STRDPRAPY: Starting Apply (OS/400) . . . 447 Chapter 23. Table structures . . . . . 491
STRDPRCAP: Starting Capture (OS/400) . . 456 Tables at a glance . . . . . . . . . . 492
WRKDPRTRC: Using the DPR trace facility List of tables used at the Capture control
(OS/400) . . . . . . . . . . . . . 466 server . . . . . . . . . . . . . . 499
List of tables used at the Apply control
Chapter 19. Operating the replication server . . . . . . . . . . . . . . 502
programs (z/OS) . . . . . . . . . . 473 List of tables used at the Monitor control
Using JCL or system-started tasks to operate server . . . . . . . . . . . . . . 504
the replication programs (z/OS) . . . . . 473 List of tables used at the target server . . . 505
Using JCL to operate replication Tables at the Capture control server and
programs . . . . . . . . . . . 473 their column descriptions . . . . . . . 506
Using system-started tasks to operate ASN.IBMSNAP_CAPSCHEMAS . . . . 506
replication programs . . . . . . . . 475 schema.IBMSNAP_AUTHTKN (OS/400) 507
Using MVS Automatic Restart Manager schema.IBMSNAP_CAPENQ (UNIX,
(ARM) to automatically restart replication Windows, z/OS) . . . . . . . . . 508
programs (z/OS) . . . . . . . . . . 476 schema.IBMSNAP_CAPMON . . . . . 509
Migrating your replication environment to schema.IBMSNAP_CAPPARMS . . . . 511
data-sharing mode (z/OS) . . . . . . . 477 schema.IBMSNAP_CAPTRACE (DB2 only) 515
schema.CCD_table (non-DB2) . . . . . 517
Chapter 20. Using the Windows Service schema.CD_table . . . . . . . . . 518
Control Manager to issue system | schema.IBMSNAP_PARTITIONINFO . . 519
commands (Windows) . . . . . . . 479 schema.IBMSNAP_PRUNCNTL . . . . 520
Creating a replication service . . . . . . 479 schema.IBMSNAP_PRUNE_LOCK . . . 523
Operating a replication service . . . . . 481 schema.IBMSNAP_PRUNE_SET . . . . 524
Dropping a replication service . . . . . 481 schema.IBMSNAP_REG_EXT (OS/400) 525
schema.IBMSNAP_REGISTER . . . . . 527
Chapter 21. Scheduling replication schema.IBMSNAP_REG_SYNCH (non-DB2
programs on various operating systems . 483 relational) . . . . . . . . . . . 536
schema.IBMSNAP_RESTART . . . . . 537
Contents ix
x DB2 Replication Guide and Reference
About this book
This book describes how to plan, set up, and maintain a DB2 data replication
environment.
The organization and content of this book have changed since the last release.
This book contains three parts:
v Part 1, Replication guide, on page 1 describes how to plan, set up, run,
and maintain your replication environment. It includes the following
chapters:
Chapter 1, Planning for replication, on page 3 describes how to plan
and design your replication environment.
Chapter 2, Setting up for replication, on page 17 describes how to
prepare your environment for replication.
Chapter 3, Registering tables and views as replication sources, on page
43 describes what you need to know to register replication sources.
Chapter 4, Subscribing to sources, on page 71 describes what you need
to know to create subscription sets and add members to subscription
sets.
This book uses standard terminology for database, connectivity, copying, SQL,
and LAN concepts. All the replication concepts used in this book are defined
in the glossary.
For example, the section entitled Starting the Apply program (UNIX, Windows,
z/OS) explains how to start the Apply program from DB2 Universal Database
for Linux and for all UNIX operating systems, DB2 Universal Database for
Windows, or DB2 Universal Database for z/OS and OS/390. Also, the section
entitled Starting the Apply program (OS/400) explains how to start the Apply
program if you are using DB2 DataPropagator for iSeries.
v If you can choose from two or more items, they appear vertically, in a stack.
If you must choose one of the items, one item of the stack appears on the
main path.
required_item required_choice1
required_choice2
If choosing one of the items is optional, the entire stack appears below the
main path.
required_item
optional_choice1
optional_choice2
Road map
This section identifies other sources of information about DB2 replication that
you might find useful.
| List aliases and user IDs in the password file: The asnpwd command allows
| you to list the aliases and user IDs contained in the password file. You can
| also use the encrypt parameter of the asnpwd command to encrypt either all
| of the entries in a file or just the password entry in a file.
| Performance improvements
| Improved availability of data on Oracle sources: The Apply program no
| longer needs to issue lock table statements for CCD tables on Oracle sources.
| To take advantage of this improvement, you must migrate any existing
| registrations and subscriptions for Oracle sources following the instructions in
| the Migration Guide: Migrating to Replication Version 8.
| Viewing messages generated by Apply and Monitor programs. You can use the
| Replication Center to view messages generated by the Apply and Monitor
| programs (APPLYTRACE and MONTRACE).
Performance improvements
| IASP support: On iSeries, you can catalog the database that is available from
| base Auxiliary Storage Pools (ASP) or from Independent Auxiliary Storage
| Pools (IASP).
New function
| The Capture program can now capture changes from multi-partitioned tables:
| If you are running DB2 Enterprise Server Edition, you can capture changes to
| source tables that are spread across multiple partition tables.
| Full refresh of single members: You can add one or more members to an
| existing subscription set without performing a full refresh for all members.
| You can also disable individual members of a subscription set.
Capture and Apply programs can be started in any order: In Version 8, you
can start the Capture program after you start the Apply program, or you can
start the Apply program after you start the Capture program. In Version 7,
you had to start the Capture program before you started the Apply program.
Greater control over what is captured for each registration: When you
register a table for replication you can specify whether you want the Capture
program to capture changes for a row whenever any column of the table
changes or only when a registered column changes. In previous versions, you
could control what was captured using a start-up parameter for the Capture
program, which meant all tables were treated the same. The start-up
parameter is not available in V8 because you can control what is captured for
each registration.
Greater control over recapturing data from replicas: When you register a
source, you can specify if you want changes recaptured from some tables but
not others. By default:
v Changes are not recaptured from replica tables and forwarded to other
replica tables.
v Changes to master tables in update-anywhere replication are recaptured
and sent to replica tables.
One Windows service per program: In Version 7, you could create only one
Windows service to operate all of your Capture and Apply programs. Now
you can create separate services for each Capture and Apply program, as well
as the Replication Alert Monitor. You can use each service to start or stop
replication. You can use either the Replication Center or new commands to
create (asnscrt command) or drop (asnsdrop command) a service for
replication programs.
Capture pruning runs concurrently with reading the DB2 log (UNIX,
Windows, z/OS): The Capture program reads the DB2 log while it prunes
tables; therefore, pruning does not affect capture latency. In Version 7, the
Capture program performed these tasks serially, not concurrently. Also, in
Version 8, the Capture program prunes the UOW table, CD tables, trace
tables, as well as the new signal (IBMSNAP_SIGNAL) table and monitor
(IBMSNAP_CAPMON) table.
| Faster full refreshes of target tables (UNIX, Windows, z/OS): DB2 replication
| takes advantage of the improvements to the load utility in the following DB2
| products to provide faster full refreshes of target tables:
v DB2 Universal Database for Windows and UNIX, Version 8
v DB2 Universal Database for z/OS and OS/390, Version 7 or later
The Replication Center is part of the DB2 Control Center set of tools and has
the look and feel of the other DB2 centers. The Replication Center includes all
of the replication function previously available from the DB2 Control Center
and the DB2 DataJoiner Replication Administration (DJRA) tool. The
Replication Center also has a launchpad that helps you perform the basic
functions needed to set up a DB2 replication environment. The launchpad
shows you graphically how the different steps are related to one another.
On-demand monitoring: You can query the status of the Capture, Apply, and
Monitor programs using the asnccmd, asnacmd, asnmcmd status commands.
More control over cold starts (UNIX, Windows, and z/OS): The warm
start-up parameter is replaced by two parameters to give you more control
over cold starts:
warmsi
| If warm-start information is available, the Capture program resumes
| processing where it ended in its previous run. If this is the first time
| that the Capture program is starting or the new restart
| (IBMSNAP_RESTART) table is empty, the Capture program switches
| to cold start. This is the default start-up parameter in Version 8.
warmsa
| If warm-start information is available, the Capture program resumes
More frequent commits by the Apply program: In many situations, if you have
user-copy, point-in-time, CCD, or replica target tables in a subscription set,
you can specify that you want the Apply program to commit its work after it
processes a specified number of transactions. To do so, you must run the
Apply program in transaction mode.
Referential integrity for more types of target tables: In many situations, you
can have referential integrity on user-copy and point-in-time target tables by
starting the Apply program so that it commits its work in transaction mode.
More ways to set operational parameters for the Capture program: You can
use the shipped defaults to operate the Capture program or you can create
new defaults using the Capture parameters (IBMSNAP_CAPPARMS) table to
suit your replication environment. You can also supply operational parameters
for the Capture program when you start the program, if you do not want to
use the defaults for that session. While the Capture program is running, you
can change the operational parameters using the Replication Center, the
chgparms keyword of the asnccmd command (UNIX, Windows, z/OS), or the
OVRDPRCAPA command (iSeries). These changes last until you end the
session or until you issue another change command.
More tables pruned by the Capture program: The Capture program prunes the
following tables: CD tables, UOW table, trace (IBMSNAP_CAPTRACE) table,
as well as the new signal (IBMSNAP_SIGNAL) table and monitor
(IBMSNAP_CAPMON) table.
Longer table names and column names: DB2 replication now supports source
table and target table names up to 128 characters, and column names up to 30
characters for databases that support long names.
New signals to control the Capture program: The Capture program can now
be controlled by signals written to the signal (IBMSNAP_SIGNAL) table. The
signal table provides a way to communicate with the Capture program
through log records. Capture uses the signals for the following situations:
v To determine when to start capturing changes for a particular table
v To determine when to terminate
v Whether it must perform update-anywhere replication
v To provide the log sequence number for setting a precise end point for
Apply events
Not only does the signal table let the Apply program tell the Capture program
when to start capturing data, it also allows for precise termination of log
record reading and for user-defined signals through log records.
64-bit support added (Windows, UNIX, z/OS): In Version 8, you can replicate
on operating systems where DB2 offers 64-bit support. Applications running
on 64-bit operating systems benefit from the increased memory address space
that these systems provide.
| New and updated error messages: New error messages were added for new
| functionality. Existing messages were updated to improve readability.
Changes to replication system commands
New and changed replication system commands for UNIX, Windows, z/OS:
The syntax of existing system commands on Windows, UNIX, and z/OS was
modified. The following changes were also made:
v The Capture command line (asncmd) was renamed to asnccmd so that it is
consistent with the new Apply command line (asnacmd), which you use to
operate the Apply program, and the new Monitor command line
(asnmcmd), which you use to operate the Monitor program.
v The asnccp command for starting the Capture program was renamed to
asncap.
The following new system commands, which run on UNIX, Windows, and
z/OS operating systems, were added:
v asnacmd (Apply command line) operates and stops the Apply program.
v asnmon (Monitor command) starts the Replication Alert Monitor
v asnmcmd (Monitoring command line) operates and stops the Replication
Alert Monitor.
v asnanalyze (Analyzer command) generates reports about the state of the
replication control tables.
v asnpwd (Password command) creates and maintains password files needed
in a distributed replication environment.
New and changed replication system commands for OS/400 operating systems
(iSeries): The following new system commands, which run on an OS/400
system, were added:
v ADDDPRREG (Add a DPR registration) registers a user table for
replication.
v RMVDPRREG (Remove a DPR registration) removes a user table from the
list of source tables available for replication.
v ADDDPRSUB (Add DPR subscription set) creates an empty subscription
set or a subscription set with one member.
v RMVDPRSUB (Remove DPR subscription set) removes an empty set or a
set and all of its members.
v ADDDPRSUBM (Add DPR subscription-set member) adds a member to an
existing subscription set.
v RMVDPRSUBM (Remove DPR subscription-set member) removes a single
subscription-set member from a subscription set.
v OVRDPRCAPA (Override DPR Capture attributes) changes the attributes
for the Capture program that is currently running.
v ANZDPR (Analyzer) generates reports about the state of the replication
control tables on the specified systems. These reports can be used to verify
and tune your replication environment or to diagnose problems.
v WRKDPRTRC (Trace options) operates various trace options such as
Dump.
Some changes were made to existing system commands for OS/400 systems:
v DPRVSN (DataPropagator Version) parameter was removed from all
system commands.
v CAPCTLLIB (Capture Control Library) parameter was added to the
Capture commands.
v New parameters were added to the CHGDPRCAPA (Change DPR Capture
attributes) and STRDPRCAP (Start DPR Capture) commands to take
advantage of the new tracing and monitoring functions.
v A new parameter was added to the ENDDPRCAP (End DPR Capture)
command so that it automatically reorganizes the CD and UOW tables to
reclaim space.
v New parameters were added to the STRDPRAPY (Start DPR Apply)
command that enable the Apply program to run only once, clean up the
Apply trail (IBMSNAP_APPLYTRAIL) table, and optimize processing of
single subscription sets.
The following new tables were added for the Replication Alert Monitor:
v IBMSNAP_ALERTS contains a history of all alerts issued by the Replication
Alert Monitor.
v IBMSNAP_CONDITIONS contains alert conditions for each monitored
server.
v IBMSNAP_CONTACTGRP maps contacts with groups.
v IBMSNAP_CONTACTS contains contact names and addresses.
v IBMSNAP_GROUPS contains contact groups.
v IBMSNAP_MONENQ ensures that only one Monitor process is running for
a single Monitor qualifier.
| v IBMSNAP_MONPARMS contains parameters that you can modify to
| control the operation of the Replication Alert Monitor program.
v IBMSNAP_MONSERVERS contains the most recent time that the
Replication Alert Monitor monitored a Capture or Apply control server.
v IBMSNAP_MONTRACE traces Replication Alert Monitor activity.
v IBMSNAP_MONTRAIL contains a history of Monitor activity for every
Monitor cycle.
The following tables from previous versions of DB2 replication are now
obsolete:
v IBMSNAP_CRITSEC is replaced by IBMSNAP_SIGNAL.
v IBMSNAP_WARMSTART is replaced by IBMSNAP_RESTART.
The DB2 Control Center does not support Version 8 replication control tables,
and you cannot use the Control Center to register sources or define
subscription sets that use V8 control tables. You can use the Control Center for
Version 7 replication environments. Use the Replication Center for V8
replication environments.
Chapter 10, Operating the Apply program, on page 149 describes how to
operate the Apply program for all operating-system environments.
| Migration planning
| If you are migrating from an existing replication environment, certain
| migration issues need to be considered. The Migration Guide: Migrating to DB2
| Replication describes how to migrate from an existing DB2 replication
| environment to Version 8 replication. It also describes how to migrate
| replication environments that currently use DB2 DataJoiner to replicate data to
| or from non-DB2 relational servers. This document is available online at
| www.ibm.com/software/data/dpropr/library.html
Memory planning
You must plan for the amount of memory required by DB2 replication. DB2
replication uses memory only as needed. The amount of memory required is
directly proportional to how much data is being replicated from the source
and the concurrency of the transactions. Basically, the more data that is being
replicated and the more concurrent transactions you have, the more memory
is required by replication.
Running the Capture and Apply programs can consume a significant amount
of memory resources.
Memory used by the Capture program
When the Capture program reads the DB2 log, the Capture program stores
individual transaction records in memory until it reads the associated commit
or abort record. Data associated with an aborted transaction is cleared from
memory, and data associated with a commit record is written to the CD table
To monitor how much memory the Capture program is using, look in the
CURRENT_MEMORY column of the Capture monitor (IBMSNAP_CAPMON)
table.
You can set the memory_limit parameter when you start the Capture program
to ensure that Capture uses a specified amount of memory for storage that is
associated with transactions. Other storage use is not limited by this
parameter. You can also change the memory_limit parameter while the
Capture program is running. If Capture reaches the memory limit, it writes
some transactions to a spill file. See Planning space requirements for spill
files for the Capture program on page 10 for the storage requirements of spill
files. You need to consider the memory resources that are used by the Capture
program in relation to its storage space requirements.
You should also consider the size of user transactions and the commit interval
when planning for the Capture programs memory requirements. Long
running batch jobs without interim commits take a lot of memory when you
run the Capture program. Generally, the smaller the commit interval, the less
memory required by the Capture program.
Reading log records (UNIX, Windows, z/OS): When DB2 replication reads
log records it uses a memory buffer. The default size of the buffer on UNIX
and Windows operating systems is fifty 4 KB pages. The default size on the
z/OS operating system is sixty-six 1 KB pages, and it is ECSA (extended
common service area) storage. Replication uses ECSA only in this situation.
Information about active subscription sets is read and stored in memory when
the Apply program is running. The amount of memory used at one time by
the Apply program is generally proportional to the amount of memory
required to process the subscription set that has the most members.
Memory used by the Replication Alert Monitor
Memory is used for storing the definitions and for keeping the alerts in
memory before they are sent as notifications. The amount of memory needed
for the definitions is directly proportional to the number of definitions. The
Replication Alert Monitor reserves 32 KB of memory for storing alert
notifications. More memory is requested, as needed, and released when no
longer required.
All of the sizes given in the following sections are estimates only. To prepare
and design a production-ready system, you must also account for such things
as failure prevention. For example, the holding period of data (discussed in
Planning the storage requirements of target tables and control tables on
page 8) might need to be increased to account for potential network outages.
Consider the updates made to the source database by your applications and
the replication requirements. For example, if an updating application typically
OS/400:
v DB2 logs full-row images for each UPDATE statement. One way to reduce
the log volume is to reduce the number of columns defined for the
replication source, for example, do not capture before-images if theyre not
required.
v To minimize the amount of storage used for CD tables and UOW tables,
frequently reorganize these tables because pruning does not recover DASD
for you. You can use the keyword RGZCTLTBL (Reorganize control tables)
on the ENDDPRCAP command to reorganize control tables. Observe the
DASD usage patterns under normal operating conditions to help you
predict and manage DASD usage. If journaling is on, also take into account
that the log or journal volume increases as DB2 log insertions to and
deletions from the UOW table and CD tables.
v When the current receiver is full, the system switches to a new one; you
can optionally save and delete old ones no longer needed for replication.
When a system handles a large number of transactions, the Capture
program can occasionally lag behind. If Capture is frequently lagging
behind, you can separate your source tables into multiple journals to
distribute the workload to multiple instances of the Capture program.
OS/400: If the target operating system is OS/400, you also need to consider
the log space (journal receivers space) of the target tables. Because journal
receivers for target tables on OS/400 can be created with the
MNGRCV(*SYSTEM) and DLTRCV(*YES) parameters, and because you need
to journal only the after-image columns, use the following formula to estimate
the volume of the journal receivers for the target tables:
journal_receiver_volume=target_table_row_length X journal_receiver_threshold
The CD tables grow in size for every change made to a source table until the
Capture program prunes the CD table. To estimate the space required for the
CD tables, first determine how long you want to keep the data before pruning
it, then specify how often the Capture program should automatically prune
these tables or how often you will prune the tables using a command.
To determine the recommended size for the CD table, use the following
guideline:
recommended_CD_size =
( (21 bytes) + sum(length of all registered columns) ) X
(number of inserts, updates, and deletes to source table
during the contingency period)
Example: If the rows in the CD table are 100 bytes long (plus the 21 bytes for
overhead), and 100,000 updates are captured during a 24-hour contingency
period, the storage required for the CD table is about 12 MB.
The UOW table grows and shrinks based on the number of rows inserted by
the Capture program during a particular commit interval and on the number
of rows that are pruned. A row is inserted in the UOW table each time an
application transaction issues a COMMIT and the transaction executed an
INSERT, DELETE, or UPDATE operation against a registered replication
source table. You should initially over-estimate the space required by the table
and monitor the space actually used to determine if any space can be
recovered.
Planning storage requirements for temporary files
You must plan for the storage requirements of spill files and diagnostic log
files.
If you are concerned about storage, you have the option of reusing the
program logs so that each time the program starts it deletes its log and
recreates it. You can specify if you want to reuse the log when you start the
program.
Planning space requirements for spill files for the Capture program
If the Capture program does not have sufficient memory, it writes (or spills)
transactions to spill files. The Capture program writes the biggest transaction
to file; however, the biggest transaction is not necessarily the one that
exceeded the memory limit.
v UNIX, Windows: On UNIX and Windows, spill files are always on disk.
One file per transaction is created in the capture_path directory.
v OS/400: On OS/400, spill files are created in library QTEMP, one spill file
for each registration that needs a spill file.
v z/OS: On z/OS, spill files go to virtual I/O (VIO).
The size of the Capture spill files depends on the following factors:
Memory limit
Use the memory_limit operational parameter to specify how much
memory can be used by the Capture program. The more memory you
allow, the less likely the Capture program will spill to files.
Size of transactions
Larger transactions might increase the need to spill to file.
Number of concurrent transactions
If the Capture program processes more transactions at the same time,
or processes interleaved transactions, the Capture program needs to
store more information in memory or on disk.
Commit interval
Typically the lower the commit interval the lower the need for storage
because Capture has to store information in memory for a shorter
period of time before committing it.
Planning space requirements for spill files for the Apply program
The Apply program requires temporary space to store data. (If you are using
the ASNLOAD utility, you might have a load input file instead of a load spill
file.) The Apply program uses spill files to hold the updates until it applies
them to the target tables. In general, the spill files are disk files; however, on
z/OS operating systems, you can specify that data be spilled to memory.
Unless you have virtual memory constraints, store the spill files in virtual
memory rather than on disk.
On UNIX, Windows, z/OS, the spill files row size is the target row size,
including any replication overhead columns. The row size is not in DB2
packed internal format, but is in expanded, interpreted character format (as
fetched from the SELECT). The row also includes a row length and null
terminators on individual column strings. The following example estimates
the size of the spill file that is required for the data selected for replication
and it does not take into account the extra space needed for the other data
that is stored in the spill file.
Example: If change volume peaks at 12,000 updates per hour and the Apply
program frequency is planned for one-hour intervals, the spill file must hold
one-hours worth of updates, or 12,000 updates. If each update represents 100
bytes of data, the spill file will be approximately 1.2 MB at a minimum.
Additional space is required for the other data that is stored in the spill file.
If you run out of log space and the Capture trigger cannot insert a record into
the CCD table, the transaction attempted by the user or application program
will not complete successfully.
Planning locks for Oracle source servers
Any application currently updating the Oracle source must finish before the
Apply program can start applying data. The Apply program must lock the
CCD table so that it can process data and set its synchpoint. The locks on the
CCD tables are held only until the Apply program sets its synchpoint, not
through the entire Apply cycle. Applications that need to update the source
table must wait until the Apply program unlocks the CCD table.
Planning coexistence of pre-existing triggers with Capture triggers
The Capture trigger logic is in the SQL script generated by the Replication
Center when you register a source. By default, an INSERT trigger, an
UPDATE trigger, and a DELETE trigger are created so that those types of
changes (insert, update, delete) can be replicated from the source table. The
trigger name consists of the name of the CCD table preceded by a letter
describing the type of trigger: I for INSERT, U for UPDATE, D for DELETE.
For example, if the CCD table name is undjr02.ccd001, the name of the
generated DELETE trigger is undjr02.dccd001. You must not change the
names of the triggers that are generated in the script.
If a trigger already exists on the table that you want to register for replication
and that trigger has the same name as the one that is in the generated script,
youll receive a warning when the script is generated. Do not run the
generated script because the RDBMS might overwrite the existing trigger.
Determine how you want to merge the pre-existing triggers with the new
triggers, and create a script that merges your existing logic with the trigger
logic generated by the Replication Center.
If the type of trigger that you want to create already exists on the table that
you want to register for replication, and the RDBMS allows only one such
trigger per table, you must merge the logic before you run the generated
script.
If you plan to replicate data between databases with differing code pages,
check the DB2 Administration Guide to determine if the code pages you have
are compatible. For example, if you are using DB2 for UNIX or Windows see
the section on the conversion of character data.
Once you have verified that your databases have compatible code pages,
determine if the databases use code pages differently. For example, assume
that one database product allows a different code page for each column in a
table while another database product does not allow different code pages per
column, it requires the code page to be specified only at the database level. A
table with multiple code pages in the first product cannot be replicated to a
single database in the second product. Therefore, how the databases handle
code pages affects how you must set up replication to ensure that data is
successfully replicated between the various databases in your environment.
Configuring national language support (NLS) for replication
The NLS configuration for replication is defined when you set up database
connectivity between systems. However, if you are running the Capture
program on UNIX or Windows operating systems, the Capture program must
use the same code page as the database from which it is capturing the data. If
the Capture program does not use the same code page, you must set a DB2
environment variable or registry variable called DB2CODEPAGE.
| Some database products implement code page support differently from others,
| which can impact your replication configuration. For example, the current
| DB2 on iSeries (OS/400) allows a code page to be specified at the column
| level, but DB2 for Linux, UNIX, and Windows allows a code page to be
| specified only at the database level. Therefore, if you have an OS/400 table
| with multiple columns using different code pages, those columns cannot be
| replicated to a single DB2 for UNIX and Windows database unless all the
| code pages are compatible.
| Restriction: If you want to replicate between DB2 UDB for z/OS new-function
| mode subsystems and DB2 UDB on Linux, Unix, Windows, or iSeries, you
| must use schema names that are 30 bytes or shorter. If you use schema names
| that are longer than 30 characters on DB2 UDB for z/OS Version 8 in
| new-function mode, you cannot replicate between that platform and DB2 UDB
| for Linux, UNIX, Windows, or iSeries.
If you use the Replication Alert Monitor, the workstation on which it runs
must be able to connect to the Monitor control server and to any server that it
monitors. If you want to use the Replication Center to set up monitoring,
ensure that the Replication Center can connect to the Monitor control server.
Before you attempt to replicate from non-DB2 relational source servers, you
must set up your federated server and database. There are three main setup
steps:
1. Define a wrapper so that the DB2 database can access other non-DB2
relational databases.
2. Define a non-DB2 relational database using a server mapping.
3. If the user ID and password combination that is used to connect to the
DB2 database differs from the one used to access the non-DB2 relational
database, you must create a user mapping.
| Prerequisites:
| The following conditions must exist before you can connect to an iSeries
| server:
| v You must have a DB2 Universal Database or DB2 Connect installed on your
| workstation.
| v You must have TCP/IP set up on your workstation.
Where server_name is the TCP/IP host name of the iSeries system, and
rdb_name is the name of the iSeries relational database that you found
in Step 1 on page 18.
3. In the command window, issue the following command:
db2 terminate
4. Ensure that the iSeries user profile that you will use to log on to your
iSeries system uses CCSID37:
a. Log on to the iSeries system.
b. Type the following command, where user is the user profile:
CHGUSRPRF USRPRF (user) CCSID(37)
c. Make sure that the DDM server is started on the iSeries system type:
STRTCPSVR SERVER(*DDM)
5. Make sure that DB2 for Windows and DB2 for iSeries are connected:
db2 connect to rdb_name user user_name using password
Also, ensure that the user ID has WRITE access to the capture path
directory (USS) or high-level qualifier (z/OS). To run the Capture
program in the USS shell, the STEPLIB system variable must be set
and it must include the Capture load library. The HFS path,
| /usr/lpp/db2repl_08_01/bin, must be in your PATH.
Requirements for OS/400
Use the Grant DPR Authority (GRTDPRAUT) command to authorize
a user to run the Capture program on a local system. See
GRTDPRAUT: Authorizing users (OS/400) on page 422 for
command syntax and parameter descriptions. If you are replicating
between only OS/400 systems, you should use the same user ID for
all servers. If the GRTDPRAUT command is not installed on a
machine, you must use the Grant Object Authority (GRTOBJAUT)
command.
Authorization requirements for Capture triggers on non-DB2 relational
databases
If you are replicating from a non-DB2 RDBMS, Capture triggers are used to
capture changes from the source. Remote user IDs (for example, from user
applications) that change the remote source tables need authority to make
inserts into the CCD table. In most cases, you do not need explicit authority
You can use different user IDs at each server in your replication environment.
Authorization requirements for the Replication Alert Monitor
| The user ID that runs the Monitor program must be able to access and update
| all replication control tables on the Monitor control server, and execute the
You use the asnpwd command to create and maintain a password file so that
the Apply program, the Replication Alert Monitor, and the Replication
Analyzer can access data on remote servers. (The Capture program does not
require a password file.) The information in the password file is encrypted to
ensure confidentiality. See asnpwd: Maintaining password files (UNIX and
Windows) on page 349 for command syntax and parameter descriptions.
| For information about password requirements for the Replication Center, see
| the Replication Center help and Managing user IDs and passwords for the
| Replication Center on page 260.
You can create a new set of Capture control tables with a new Capture
schema. You can create a maximum of 25 schemas. Use the Create DPR Tables
(CRTDPRTBL) command, as described in Creating multiple sets of Capture
control tables on page 28. You can also use the CRTDPRTBL command if
your replication control tables are accidentally deleted or corrupted. For
details about this command, seeCRTDPRTBL: Creating the replication control
tables (OS/400) on page 415.
| For a user-defined file system, you can create the replication control tables in
| the base Auxiliary Storage Pool (ASP) or in Independent Auxiliary Storage
| Pool (IASP) groups, but not in both. If you create control tables in an IASP
| group, you must first remove all Capture and Apply control tables from the
| base ASP. Issue the SETASPGRP command for the ASP group that contains
| the ASN library (or any other library for a Capture schema) before you start
| the Capture or Apply programs.
Creating control tables for non-DB2 relational sources
If you want to replicate from a non-DB2 RDBMS, such as Informix, you must
use the Replication Center to create control tables, just as you would if you
are replicating from DB2. For these types of sources, the Replication Center
creates the following Capture control tables in the non-DB2 relational
database:
v Prune control table (IBMSNAP_PRUNCNTL)
v Prune set table (IBMSNAP_PRUNE_SET)
v Register synchronization table (IBMSNAP_REG_SYNCH)
Nicknames are created in a federated database for all but the sequencing table
(IBMSNAP_SEQTABLE). (The sequencing table is used only by the Informix
triggers. The Apply program doesnt use it.) Triggers are created automatically
on the signal table (IBMSNAP_SIGNAL) and the register synchronization
table (IBMSNAP_REG_SYNCH).
Important: Do not remove or modify the triggers that are created on the
IBMSNAP_SIGNAL and IBMSNAP_REG_SYNCH tables.
Creating multiple sets of Capture control tables
If you want to use more than one Capture program on a server you must
create more than one set of Capture control tables and ensure that each set of
tables has a unique Capture schema. This schema identifies the Capture
program that uses a set of tables. Multiple Capture schemas enable you to run
multiple Capture programs concurrently.
You might want to run multiple Capture programs in the following situations:
v To optimize performance by treating low-latency tables differently from
other tables. If you have low latency tables, you might want to replicate
those tables with their own Capture program. That way, you can give them
a different run-time priority. Also, you can set the Capture program
parameters, such as pruning interval and monitor interval, to suit the low
latency of these tables.
v To potentially provide higher Capture throughput. This may be a significant
benefit in a source environment with multiple CPUs. The trade-off for the
higher throughput is additional CPU overhead associated with multiple log
readers.
If you want to replicate from multiple non-DB2 source databases within the
same federated database, you must create multiple sets of Capture control
tables, with each set having its own schema. Or, if you prefer, you can use
separate federated databases, in which case the Capture control tables on each
server can use the default ASN schema.
On z/OS systems, you can use multiple Capture schemas it you want to work
with UNICODE and EBCDIC encoding schemes separately or if you want to
run more than one instance of the Capture program on a subsystem. See
Creating control tables (z/OS) on page 27 for information about creating
control tables.
| If you are starting the Capture program for the first time and select the
| WARMSI start mode, the IBMSNAP_PARTITIONINFO table does not exist.
| The Capture program creates this table and a unique index for it in the table
| space that the IBMSNAP_RESTART table is located. After the
| IBMSNAP_PARTITIONINFO table is created, the Capture program inserts a
| row into it for every database partition.
| If this is not the first time that you started the Capture program and you
| select one of the warm start modes, the IBMSNAP_PARTITIONINFO table
| already exists. If you selected the One or more partitions have been added
| since Capture was last run check box, the Capture program inserts a row into
| the IBMSNAP_PARTITIONINFO table for every database partition that you
| added since the Capture program last ran. For information about how to
| create Capture control tables for multiple database partitions from the
| Replication Center, see the Replication Center help.
Procedure:
Preparing the DB2 database to run the Capture program (UNIX, Windows)
Procedure:
2. Capture must be run in the same code page as the database for which it is capturing data. DB2 derives the Capture
code page from the active environment where Capture is running. If DB2CODEPAGE is not set, DB2 derives the
code page value from the operating system. The value derived from the operating system is correct for Capture if
you used the default code page when creating the database.
Procedure:
These commands create packages, the names of which are in the file
capture.lst.
Procedure:
These commands create packages, the names of which are in the files
applycs.lst and applyur.lst.
Procedure:
These commands create packages, the names of which are in the files
asnmoncs.lst and asnmonur.lst.
3. For each server that you are monitoring and to which the Replication Alert
Monitor program connects, do the following steps:
a. Connect to the database by entering:
db2 connect to database
These commands create packages, the names of which are in the file
asnmonit.lst.
Setting up the Capture and Apply programs (OS/400)
You must set up your environment if you want to use the Apply program
with remote systems on other, non-OS/400 operating systems. The following
sections explain the steps involved in setting up your replication environment:
For information about using the CRTSQLPKG command, see DB2 Universal
Database for iSeries SQL Programming.
The packages are created using the ASN qualifier. On OS/400 they are created
in the ASN library. On other operating systems, they are created in the ASN
schema.
Creating SQL packages for the Apply program: You must create SQL
packages so that the Apply program can interact with all the remote servers
to which it needs to connect. For example, run this command on the system
where Apply is running to enable it to connect to a remote system:
CRTSQLPKG PGM(QDP4/QZSNAPV2) RDB(remote_system)
where remote_system is the relational database entry name for the remote
system to which the Apply program needs to connect.
Creating SQL packages for the Replication Analyzer: You must create SQL
packages so that the Replication Analyzer can interact with the servers that
you are analyzing, such as the Capture control server or the target server. Run
this command on the system where the Replication Analyzer is running:
CRTSQLPKG PGM(QDP4/QZSNANZR) RDB(remote_system)
where remote_system is the name of the system that you are analyzing.
where source_system is the name of the system where the source table actually
exists.
| Whenever the Capture program is warm started, Capture reads the list of
| database partitions for the partition group in which its control tables are
| located. Capture compares the number of database partitions known to DB2
| with the number of database partitions listed in the
| IBMSNAP_PARTITIONINFO table. The number of database partitions listed
| If you have added one or more database partitions since the last time you ran
| the Capture program, you must tell the Capture program about the new
| database partitions. You can do this in the Replication Center by selecting the
| One or more partitions have been added since Capture was last run check
| box when you set the STARTMODE option to any of the warm start modes on
| the Start Capture window. For information on how to set up Capture for
| multiple database partitions from the Replication Center, see the Replication
| Center help.
DB2 DataPropagator for iSeries runs under commitment control for most
operations and therefore requires journaling on the control tables. (The
QSQJRN journal is created when the CRTDPRTBL command creates a
collection.)
Administrators must make sure the libraries containing the source table, CD
table, and target table contain journals. They must also ensure that all the
source tables are journaled correctly.
Before you register a table for replication on OS/400, the table must be
journaled for both before-images and after-images.
The following sections describe the journal setup required for replication:
v Creating journals for source tables (OS/400)
v Managing journals and journal receivers (OS/400) on page 38
Creating journals for source tables (OS/400)
To set up the source table journals, you must have the authority to create
journals and journal receivers for the source tables to be defined. (Skip this
section if your source tables are already journaled.)
Important: Use a different journal for the source tables than one of those
created by DB2 DataPropagator for iSeries in the ASN (or other capture
schema) library.
Procedure:
You can use two values on the RCVSIZOPT parameter of the CRTJRN
command (*RMVINTENT and *MINFIXLEN) to optimize your storage
availability and system performance. See the OS/400 Programming:
Performance Tools Guide for more information.
3. Start journaling the source table using the Start Journal Physical File
(STRJRNPF) command, as in the following example:
STRJRNPF FILE(library/file)
JRN(JRNLIB/DJRN1)
OMTJRNE(*OPNCLO)
IMAGES(*BOTH)
Specify the name of the journal that you created in step 2. The Capture
program requires a value of *BOTH for the IMAGES parameter.
4. Change the source table journaling setup:
| Restriction: When you use the RTVJRNE command to retrieve journal entries,
| no more than 299 source physical files can use the same journal and Capture
| schema. If you need to register more than 299 files in the same journal, break
| your source registrations into multiple Capture schemas.
You can alter the default definitions for the three types of work management
objects or provide your own definitions. If you create your own subsystem
description, you must name the subsystem QZSNDPR and create it in a
library other than QDP4. See iSeries Work Management, SC415306 for more
information about changing these definitions.
Use the CHGJRN command to detach the old journal receiver and attach a
new one. This command prevents Entry not journaled error conditions and
limits the amount of storage space that the journal uses. To avoid affecting
performance, do this at a time when the system is not at maximum use.
You can switch journal receiver management back to the system by specifying
CHGJRN MNGRCV(*SYSTEM).
You should regularly detach the current journal receiver and attach a new one
for two reasons:
v Analyzing journal entries is easier if each journal receiver contains the
entries for a specific, manageable time period.
v Large journal receivers can affect system performance and take up valuable
space on auxiliary storage.
The default message queue for a journal is QSYSOPR. If you have a large
volume of messages in the QSYSOPR message queue, you might want to
associate a different message queue, such as DPRUSRMSG, with the journal.
You can use a message handling program to monitor the DPRUSRMSG
message queue. For an explanation of messages that can be sent to the journal
message queue, see OS/400 Backup and Recovery.
To take advantage of the delete journal receiver exit routine and leave journal
management to the system, specify DLTRCV(*YES) and MNGRCV(*SYSTEM)
on the CHGJRN or CRTJRN command.
Important: If you remove the registration for the delete journal receiver exit
routine, you must change all the journals used for source tables to have the
DLTRCV(*NO) attribute.
If the journal that is associated with the receiver is not associated with any of
the source tables, this exit routine approves the deletion of the receiver.
If the journal receiver is used by one or more source tables, this exit routine
makes sure that the receiver being deleted does not contain entries that have
not been processed by the Capture program. The exit routine disapproves the
deletion of the receiver if the Capture program still needs to process entries
on that receiver.
If you must delete a journal receiver and the delete journal receiver exit
routine does not approve the deletion, specify DLTJRNRCV DLTOPT(*IGNEXITPGM)
to override the exit routine.
Removing the delete journal receiver exit routine: If you want to handle the
deletion of journal receivers manually, you can remove the delete journal
receiver exit routine by using the following command:
RMVEXITPGM EXITPNT (QIBM_QJO_DLT_JRNRCV)
FORMAT(DRCV0100)
PGMNBR(value)
Procedure:
Registering the delete journal receiver exit routine: Use the ADDEXITPGM
command if you removed the exit point and want to put it back. You must
register the exit routine with this command:
When you register a source, you identify the table or view that you want to
use as a replication source, which table columns you want to make available
for replication, and the properties for how DB2 replication captures data and
changes from the source.
For DB2 replication, you can register the following objects as sources:
v A DB2 table
v A non-DB2 relational table through a nickname
v A subset of the data in a table (DB2 or non-DB2 relational)
v A view over a single table (DB2)
v A view that represents an inner join of two or more tables (DB2)
For all DB2 sources except for OS/400, the source table DDL requires the
DATA CAPTURE CHANGES option. Do not remove this option from your
source.
Note for non-relational source tables: You can register DB2 tables that
contain data from non-relational database management systems, such as IMS.
To do this, you need an application, such as IMS DataPropagator or Data
Refresher, to populate a CCD table with the data from the non-relational
database. The application captures changes to the non-relational segments in
the IMS database and populates a CCD table. The CCD table must be
complete, but it can be either condensed or non-condensed. Like other CCD
sources, there is no Capture program that is associated with a CCD source
table because the table already stores changed data from the non-relational
source table. IMS DataPropagator and Data Refresher products maintain the
values in the register (IBMSNAP_REGISTER) table so that the Apply program
can read from this source table correctly. If you do not use one of these
products to maintain these types of CCD tables and you maintain the tables
yourself, see Maintaining CCD tables as sources (IMS) on page 68.
Prerequisites:
Restrictions (OS/400):
v Because SQL statements are limited to a length of 32,000 characters, you can
register only approximately 2000 columns per table; the exact number of
columns depends on the length of the column names.
v For a single Capture schema, do not register more than 300 source tables
that use the same journal.
| v Source tables, CD tables, and journals for the source tables must all be in
| the same Auxiliary Storage Pool (ASP) as the Capture control tables that
| contain the registration information for these source tables.
Procedure:
When you register a DB2 table, you identify which table you want to register
by specifying the source server, source table name, and the Capture schema.
You can register the same table multiple times using different Capture
schemas. You can use the default settings for registration, or you can modify
the registration options to meet your replication needs. See Registration
options for source tables on page 47 for a complete list of registration
options, their defaults, and an explanation of when you might want to use or
change the defaults.
By default, the CCD owner is derived from the schema name of the source
table. If you modify the CCD owner so that it does not match the schema
name, make sure that the source table owner is authorized to write to the
CCD table. If the source table owner cannot update the CCD table, triggers on
the source table will not be able to write changes to the CCD table.
Prerequisite:
Capture control tables must already exist on the Capture control server that
will process this source. If you need to create Capture control tables, see
Creating control tables for non-DB2 relational sources on page 27.
Restrictions:
v If you are using a single federated DB2 database to access multiple
non-DB2 relational source servers, you must use a different Capture schema
for each non-DB2 relational source server on that single federated database;
no two can be the same. You can register a non-DB2 relational table under
only one Capture schema.
v You cannot register columns in non-DB2 relational tables that have data
types of LOB or DATALINK. If you register a table that includes these data
types, you must register a column subset. See Registering a subset of
columns (vertical subsetting) on page 48 for details on how to register only
a subset of columns.
Procedure:
When you register a non-DB2 relational table, you identify which table you
want to register by specifying the nickname of the source table. You can use
the default settings for registration, or you can modify the registration options
to meet your replication needs. See Registration options for source tables for
a complete list of registration options, their defaults, and an explanation of
when you might want to use or change the defaults.
When you create views over tables and register the views as sources, the
views registration options are determined by the registration definition of the
underlying tables. For details on which characteristics views inherit from the
underlying tables and how views behave according to the underlying
registration definition, see How views behave as replication sources on page
65.
After you choose which table that you want to register, you can identify
which columns you want to make available for replication, and you can
define properties that determine how registered data from this source will be
handled and stored. You can also specify other registration options, such as
how you want the Capture program to store source data in the CD table (or
how you want the Capture triggers to store data in the CCD table). This
section discusses the following options that you can specify when registering
tables as sources:
v Registering a subset of columns (vertical subsetting) on page 48
v Full-refresh copying and change-capture replication on page 48
v After-image columns and before-image columns on page 50
v Before-image prefix on page 53
v Stop the Capture program on error on page 54
v How the Capture program stores updates on page 55
When you define a source table for replication, you dont need to register all
the columns in the table for replication; you can register a subset of the
columns in your source table. This vertical subset can be useful if you do not
want to make all of the columns in the table available for targets to subscribe
to. You might also want to select this option if the target tables for this source
do not support all data types that are defined for the source table.
To register a subset of the columns, select only those columns that you want to
make available for replication to a target table. The columns that you do not
select will not be available for replication to any target table. Because CD (and
CCD) tables must contain sufficient key data for some types of target tables
(such as point-in-time), make sure that your subset contains the columns that
will act as the key columns (primary key or unique index) for the target.
Tip: Register a subset of the columns in the source table only if you are sure
that you will never want to replicate the unregistered columns. If you register
a subset of the columns at the source and later want to replicate columns that
you didnt register, you must then alter your registrations to add unregistered
columns. (For non-DB2 relational sources, you must redefine your
registrations altogether to add new columns to a registration.) If you plan to
have an internal CCD associated with this source, it can be even more difficult
to add columns later because registering new columns adds them to the CD
table but not the internal CCD. To avoid these problems, you might want to
register all columns at the source and use the Apply program instead to
subset which columns are replicated to the targets. For details on how to
subset at the target instead of the source, see Source columns that you want
applied to the target on page 101.
Full-refresh copying and change-capture replication
Default: Change-capture replication
You can choose whether you want all the data in the source table to be
replicated to the targets during each replication cycle (full-refresh-only
replication), or whether you want only the changes that occurred since the last
time that the targets were updated (change-capture replication).
Tip for smaller tables: You might want to choose full-refresh only replication
if you have a very small source table that does not take much time or
resources to copy.
Tip for larger tables: If you have larger tables and want to use full-refresh
only replication, you might want to use the ASNLOAD exit routine to load
your tables faster. See Refreshing target tables using the ASNLOAD exit
routine on page 167 for details.
Change-capture replication
Default: Changes to all rows are captured
If you choose not to allow full refresh for target tables, you must manually
reload the table if the source and target tables need to be resynchronized.
After the target is loaded with the initial source data, the Capture program
captures changes that occur at the source and stores them in the CD table. In
change-capture replication for non-DB2 relational sources, the Capture triggers
capture changes at the source and store them in the CCD table. The Apply
program reads the changes from the CD or CCD table and applies the
changes to the targets that subscribe to the registered source.
When you define a DB2 source table for change-capture replication, you might
not want to store all changes that occur at the source in the CD table. You can
register a row (horizontal) subset that filters the changes so that fewer are
By default, changes are captured whenever a row is updated for any column
(registered or unregistered) at the source table. If you register only a subset of
the columns, the Capture program records the row values for the registered
columns in the CD table every time a change occurs to the source table, even
if the columns that changed are different from the registered columns. Use
this default option if you want to keep a history of all changes to the source
table. This is the only option available for non-DB2 relational sources, the
Capture triggers capture all changed rows at the source, even if the change
occurs in an unregistered column.
Example: Assume that you have 100 columns in your table and you register
50 of those columns for replication. By default, any time a change is made to
any of the 100 columns in your table, the Capture program will write a row to
the CD table (or the Capture triggers will write a row to the CCD table).
If you have a DB2 source, you might want the Capture program to capture
changes for registered columns only. In this case, the Capture program writes
a row to the CD table only when changes occur to registered columns.
Suggestion: Choose to capture changes for all rows if you need information
for auditing purposes, or if changes in the table almost always occur in
registered columns only. Choose to capture changes for only registered
columns if changes frequently occur that only affect unregistered columns.
Use this option if you dont want to keep a history of all changes to the
source table.
After-image columns and before-image columns
Default: After-image columns only
When you are registering a source for change-capture replication, you can
choose whether you want the Capture program to capture only the
after-image value (the value in the column after a change was made) or both
the after-image value and the before-image value (the value that was in the
column before the change was made). For UNIX, Windows, and z/OS, you
can select whether to capture before-image values for each column in the
table. For OS/400, you can select whether to capture before images for all or
none of the columns in the table; you cannot select this option for each
individual column. The sections below discuss when you should choose each
option.
Columns with certain data types do not allow you to include before-image
values in the CD table:
v Columns with LOB data types
v Columns with DATALINK data types
You dont need before images if you plan to use only base aggregate and
change aggregate target-table types for this source. Before-image columns do
not make sense if you plan to use your target table for computed values
because there is no before image for computed columns. All other target-table
types can make use of before-image columns. See A computed summary of
data or changes at the source on page 90 for more information on aggregate
target tables.
When you choose to store both the before and after images in the CD (or
CCD) table, the before-image columns and after-image columns have different
values for different actions performed on the source tables:
Action Column value
Insert The before-image column contains a NULL value. The
after-image column contains the inserted value.
Update The before-image column contains the column value before
the change occurred. The after-image value contains the
column value after the change occurred.
Important for UNIX, Windows, and OS/400: For columns that have
before-images defined, DB2 replication limits column names to 29 characters
because the entire column name can have only 30 characters. If the column
name is longer, DB2 replication truncates the additional characters from the
right by default, unless you have set your profile to truncate from the left.
Because DB2 replication adds a before-image column identifier (usually X) to
target columns and each column name must be unique, you cannot use
column names that are longer than 29 characters. For tables that you do not
plan to replicate, you can use longer column names, but consider using
29-character names in case you might want to replicate these columns in the
future.
Important for z/OS: For tables in DB2 for z/OS, you can use 18-character
column names, but DB2 DataPropagator will replace the 18th character with
the before-image column identifier in target tables, so you must ensure that
the first 17 characters of the name are unique.
The following sections describe cases in which you might want to capture
before-image values:
v For keeping a history of your source data
v For update-anywhere configurations with conflict detection
v When the key columns at the target are subject to update on page 53
For keeping a history of your source data: If you want to keep data for
auditing purposes, you might want to select both before and after images so
that you have a record of how the data has changed over a period of time. A
set of before-image and after-image copies is useful in some industries that
require auditing or application rollback capability.
Although you register these before-image values when you register the source
table or view, DB2 replication does not know that your application will make
updates to the target key. Later when you define which targets subscribe to
this source (by creating subscription sets), you can specify for the Apply
program to perform special updates when applying changes from non-key
columns at the source to key columns at the target. See How the Apply
program updates the target key columns with the target-key change option
on page 105 for more information.
Before-image prefix
Default (Replication Center): X
Example: If you use X as your before-image prefix and you register a source
column named COL, you cannot register a column named XCOL because it is
If you are not replicating any before-image columns for a table, you can
choose not to have a before-image prefix and set this property to null.
Stop the Capture program on error
Default: The Capture program stops when it encounters certain errors
| This option stops the Capture program when the following fatal errors occur:
| v The CD table space is full.
| v SQLCODE-911 error occurs 10 times in a row.
| v Unexpected SQL errors occur.
| This option does not stop the Capture program when certain non-fatal errors
| occur, for example:
| v SQLCODES indicate invalid length of data.
| v For Capture programs run under z/OS, the compression dictionary does
| not exist.
| When those non-fatal errors occur, the Capture program invalidates the
| registrations and keeps running.
Do not stop Capture on error
The Capture program continues to run when certain errors occur. If it
encounters errors during the first time trying to process the source, it
does not activate the registration. If the registered source was already
| active, it stops processing the registration. The registration is stopped
| in either case. A stopped registration has a value of S (stopped) in
| the STATE column of the register (IBMSNAP_REGISTER) control
| table.
This option does not stop the Capture program when the following non-fatal
errors occur:
v The registration is not defined correctly.
You can choose how source updates are stored in the CD (or CCD) table.
When the Capture triggers or Capture program captures an update to the
source table, it can either save the updated value in a single row in the CD
table, or it can store the delete in one row and the insert in another, using two
rows in the CD (or CCD) table. By default, the update is stored in a single
row. You can use this default to reduce storage and increase performance
because only one row is stored in the CD (or CCD) table and is read by the
Apply program for each change. However, there are some scenarios where
you should instruct the Capture program or triggers to capture updates to the
source table as DELETE and INSERT pairs.
You must capture updates as DELETE and INSERT statements when your
source applications update one or more columns referenced by a predicate on
the subscription-set member. Suppose that you plan to define a target that
subscribes only to source data with a predicate based on a specific column
value (for example, WHERE DEPT = J35). When you change that column
(for example, to DEPT=FFK), the captured change will not be selected for
replication to the target because it does not meet the predicate criteria. That is,
your new FFK department will not be replicated because your subscription-set
member is based on department J35. Converting the updates to a DELETE
and INSERT pair ensures that the target-table row is deleted.
Each captured update is converted to two rows in the CD (or CCD) table for
all columns. You might need to adjust the space allocation for the CD (or
CCD) table to accommodate this increase in captured data.
When you are registering the source table that will act as the master in your
update-anywhere configuration, you can choose from the following two
options:
Recapture changes at master
Updates to the master that originated at a replica are recaptured at the
master and forwarded to other replicas.
Do not recapture changes at master
Updates to the master that originated at a replica are not recaptured
at the master and forwarded to other replicas.
For multiple replicas that are mutually exclusive partitions of the master
Master: Do not recapture changes at master
If you plan to have several replicas that are partitions of the master table, you
might want to prevent changes from being recaptured at both the master and
each replica. This setting is optimal if none of the replicas is a source for other
replica tables. When replicas are partitions of the master, no two replicas ever
subscribe to the same data at the master. Therefore, any change that originates
at any replica does not need to be recaptured at the master and forwarded on
to the other replicas because only the replica where the change occurred
subscribes to that source data.
If you plan to have several replicas that subscribe to the same data in the
master table, you might want the Capture program to recapture changes at
the master. Changes that originate at a replica are then recaptured at the
master and replicated down to other replicas that subscribe to the updated
master data.
You can have a multi-tier configuration in which the master (tier 1) acts as a
source to a replica (tier 2), and then that replica also acts as a source to
another replica (tier 3). If you plan to have this type of configuration, you
might want the Capture program to recapture changes at the middle replica
(tier 2) so that changes that originated at the master are forwarded to the next
replica (tier 3).
Also, when you have recapture set for the middle replica (tier 2), changes that
originate at the final replica (tier 3) are recaptured at the middle replica (tier
2) and forwarded to the master (tier 1).
Restrictions:
v Tables from non-DB2 relational databases cannot participate in
update-anywhere; therefore, non-DB2 relational sources do not have conflict
detection.
v If you have an update-anywhere configuration that includes DATALINK
columns, you must specify None for the conflict-detection level. DB2 does
not check update conflicts for external files pointed to by DATALINK
columns.
v If you have an update-anywhere configuration that includes LOB columns,
you must specify None for the conflict-detection level. Columns of LOB
data type cannot participate in update-anywhere replication.
Although you set the conflict-detection level for individual replication sources,
the Apply program uses the highest conflict-detection level of any
subscription-set member as the level for all members of the set.
The Apply program cannot detect read dependencies. If, for example, an
application reads information that is subsequently removed (by a DELETE
statement or by a rolled back transaction), the Apply program cannot detect
the dependency.
When registering OS/400 tables that use remote journaling, you can define for
DB2 replication to use the remote journal as the replication source instead of
the local journal. By selecting the remote journaling option for replication, you
move the CD tables, the Capture program, and the Capture control tables to
an OS/400 database server that is separate from the OS/400 server that the
source table is on.
When you register tables on OS/400 as sources, the default assumes that you
do not want to use remote journaling.
Recommendation: Whenever you are replicating data from one OS/400 table
to another OS/400 table and you have a remote journal set up, it is highly
recommended that you use the remote journaling function when registering.
Using remote journaling in replication will greatly increase performance.
Because the remote journal function makes it possible to move the
registration, the Capture program, and the Capture control tables away from
the system on which the source table resides, more resources are left available
on that system. This reduces processor usage and saves disk space. Also,
Before you register an OS/400 table that uses remote journaling, make sure
that your remote journal is in an active state.
| Restriction: Replica target table types are not supported in a remote journal
configuration.
For more information about the remote journal function, see Backup and
Recovery, SC41-5304, and OS/400 Remote Journal Function for High Availability
and Data Replication, SG24-5189.
Using relative record numbers (RRN) instead of primary keys (OS/400)
Typically, the target table for a source uses the same key columns as the
primary key columns in the source. The Apply program uses this key value to
track which data it has replicated from the sources CD table to the target. If
you are registering an OS/400 table that does not have a primary key, a
unique index, or a combination of columns that can be used as a unique
index, you must register the table using the relative record numbers (RRN).
When you choose to replicate using the RRN, both the CD table and the
target table have an extra column, IBMQSQ_RRN of type INTEGER, which
contains a unique value for each row. This column contains the RRN that
corresponds to each source table row.
The RRN is used as a primary key for the source table row as long as the
source table is not reorganized. When the source table is reorganized, the RRN
of each source table row changes; therefore, the RRN in the CD and target
table rows no longer has the correct value that reflects the rows new position
in the source table. Any time that you reorganize a source table (to compress
deleted rows, for example), DB2 DataPropagator for iSeries performs a full
refresh of all the target tables in the set of that source table. For this reason,
place target tables that use RRN as primary keys in subscription sets with
other targets that use RRNs, and not in sets with tables that use some other
uniqueness factor.
When you register a view over a table that is registered for change-capture
replication, a view is created for you over the underlying tables CD table.
This CD view contains only the columns referenced by the registered view.
You cannot register a subset of columns in the view; all of the columns in the
view are automatically registered.
Views over a join of two or more tables
When you register a view over a join of two or more tables, the underlying
tables can be registered or non-registered tables, as long as at least one table
in the join is registered. You can also have inner-joins of CCD tables that are
registered as sources.
Restriction: If you define a join that includes a CCD table, all other tables in
that join must be CCD tables.
For a join view to be a viable replication source, you must create it using a
correlation ID. (Views over single tables do not require a correlation ID.)
where VW000 is the name of the view. SRC001 and SRC005 are the tables that
are part of the view and C000, C001, C002, and C003 are the columns that are
part of the view under the condition that the C000 columns are equal in both
tables (SRC001 and SRC005).
The type of replication that the view inherits depends on the combination of
its underlying tables, each of which can be:
v Registered for change-capture replication
v Registered for full-refresh-only replication
v Not registered
Table 2 shows the various combinations of underlying tables and what type of
source view and CD view results from each combination.
Table 2. Combinations of underlying tables for views
Table 1 Table 2 Description of join view and CD view
Registered for change Registered for change The view is registered for change-capture replication.
capture capture The CD views contain the referenced columns from
Table 1s CD table and from Table 2s CD table.
Registered for change Registered for The view is registered for change-capture replication.
capture full-refresh only The CD view contains the referenced columns from
Table 1s CD table and the referenced columns from
Table 2. Only changes to columns that are in Table 1
will be replicated to the registered views target during
each replication cycle.
Registered for Registered for The view is registered for full-refresh-only replication.
full-refresh only full-refresh only There is no CD view.
Registered for Not registered The view is registered for full-refresh-only replication.
full-refresh only There is no CD view.
Registered for change Not registered The view is registered for change-capture replication.
capture The CD view contains referenced columns from Table
1s CD table and the referenced columns from Table 2.
Only changes to columns that are in Table 1 will be
replicated to the registered views target during each
replication cycle.
Not registered Not registered The view is not a valid replication source and cannot
be registered.
To avoid double-deletes, you must define a CCD table for one of the source
tables in the join. This CCD table should be condensed and non-complete and
should be located on the target server. Defining a condensed and
non-complete CCD table for one of the source tables in the join solves the
double-delete problem in most situations because the IBMSNAP_OPERATION
column in the CCD table allows you to detect the deletes. Simply add an SQL
statement to the definition of the subscription set that should run after the
subscription cycle. This SQL statement removes all the rows from the target
table for which the IBMSNAP_OPERATION is equal to D in the CCD table.
Problems with updates and deletes can still occur if, during the same Apply
cycle, a row is updated on the source table that has the CCD while the
corresponding row is deleted on the other table in the join. As a result, the
Apply program is unable to find the corresponding row in the joined table
and cannot replicate the updated value.
Prerequisites:
v Capture control tables must already exist on the Capture control server that
will process the view that you want to register as a source. If you need to
create Capture control tables, see Setting up the replication control tables
on page 26.
v The name of the source views must follow the DB2 table naming
conventions.
| v You must register at least one of the views underlying base tables as a
| source. When you register the base table, use the same Capture schema that
| you plan to use when you register the view. For information about how to
| register a table, see Registering DB2 tables as sources on page 43.
Procedure:
Registration options for views are derived from the registration definition of
the source tables on which the views are defined. See Registration options
for source tables on page 47 for a complete list of registration options, their
defaults, and an explanation of when you might want to use or change the
defaults. For information on what type of replication that the view will inherit
based on its underlying tables (change-capture or full-refresh only), see How
views behave as replication sources on page 65.
Important: This assumes that the values that are used in the CCD table for
IBMSNAP_COMMITSEQ and IBMSNAP_LOGMARKER are always increasing
values. The Apply program will not detect that a full refresh has been
performed on the source CCD table unless the CCD_OLD_SYNCHOINT value
is larger than the most recently applied SYNCHPOINT value.
Related concepts:
v Chapter 14, Using the DB2 Replication Center, on page 255
Related tasks:
v Chapter 4, Subscribing to sources, on page 71
Related reference:
v ADDDPRREG: Adding a DPR registration (OS/400) on page 367
When planning for subscription sets, be aware of the following rules and
constraints:
v A subscription set maps a source server with a target server. A
subscription-set member maps a source table or view with a target table or
view. Subscription sets and subscription-set members are stored in the
Apply control server.
v The Apply program processes all members in a subscription set as a single
group. Because of this, if any member of the subscription set requires
full-refresh copying for any reason, all members for the entire set are
refreshed.
A single Apply program, which has a unique Apply qualifier, can process one
or many subscription sets. A single subscription set can contain one or many
subscription-set members. The following sections discuss the trade-offs for
having few or many sets per Apply program, and few or many
subscription-set members per subscription set.
Planning the number of subscription-set members
When you add members to a subscription set, you must decide whether to
group all of your source-target pairs (subscription-set members) into one
subscription set, create separate subscription sets for each pair, or create a
small number of subscription sets, each with a number of pairs.
By grouping multiple members into one subscription set, you can ensure that
replication for all members begins at the same time. Also, you reduce the
number of database connections needed to process the subscription sets and
you reduce the administration overhead for maintaining your replication
environment. If the subscription set contains SQL statements or stored
procedures, you can use those statements or procedures to process all of the
members of the subscription set.
If you want to be able to more easily locate any errors that cause the Apply
program to fail, add only a small number of members to a subscription set.
With fewer members, you will likely find the source of the problem more
quickly than if the set contains a large number of members. If one member of
a subscription set fails, all of the data that has been applied to other members
You can run as many instances of the Apply program (each with its own
Apply qualifier) as you need, and each Apply program can process as many
subscription sets as you need. You have two basic options:
v Associate each Apply qualifier with one subscription set (each Apply
program processes exactly one subscription set)
If speed is important, you can spread your sets among several Apply
qualifiers, which allows you to run several instances of the Apply program
| at the same time. If you decide to have an Apply-program instance process
| one subscription set, you can use the Apply programs OPT4ONE startup
| option, which loads the control-table information for the subscription set
| into memory. If you use this option, the Apply program does not read the
control tables for the subscription-set information for every Apply cycle.
| Therefore, the Apply program performs better. However, the more
| Apply-program instances that you run, the more system resources they will
| use, and the slower their overall performance might be.
v Associate each Apply qualifier with multiple subscription sets (each Apply
program processes many subscription sets)
By using more than one Apply qualifier, you can run more than one
instance of the Apply program from a single user ID.
The Apply program tries to keep all sets for a given Apply qualifier as
current as possible. When an Apply cycle starts, the Apply program
determines which of the subscription sets contains the least current data
and starts processing that set first.
If speed is not your main goal, you might want to replicate a large number
of subscription sets with one Apply qualifier. For example, this could be a
very good option if you wait until after business hours before replicating.
One disadvantage of having one Apply program process multiple
subscription sets is that the Apply program processes the subscription sets
sequentially; thus, your overall replication latency can increase.
Prerequisites:
1. You must create the Apply control tables in the Apply control server for
the subscription set.
2. Before you add subscription-set members to subscription sets, you must
register the tables or views that you want to use as sources. If you need to
register sources for replication, read and follow the instructions in
Chapter 3, Registering tables and views as replication sources, on page
43. You should also consider how you want to group your sets. If you
need to plan for your sets, see Planning how to group sources and
targets on page 71 for more information.
Procedure:
To create a subscription set, you can use either of the following two methods:
When you create a subscription set, you can use the default settings for how
the Apply program processes the set, or you can modify the subscription
properties to meet your replication needs. See Processing options for
subscription sets for a complete list of processing options for subscription
sets, their defaults, and an explanation of when you might want to use or
change the defaults.
You can specify whether you want the Apply program to begin processing the
subscription set. When you activate a subscription set, the Apply program
initiates a full refresh for that set. You have three activation levels to choose
from:
Active The Apply program processes the set during its next cycle. Activate
the set if you want the Apply program to process the set the next time
You can specify an approximate number of minutes worth of data for the
Apply program to retrieve from the replication source during each Apply
cycle. There are several situations for which this specification can be useful:
v When the amount of data to be processed within one subscription-set cycle
is large.
Subscription sets that replicate large blocks of changes in one Apply cycle
can cause the spill files or logs (for the target database) to overflow. For
example, batch-Apply scenarios can produce a large backlog of enqueued
transactions that need to be replicated.
v An extended outage of the network can cause a large block of data to
accumulate in the CD tables, which can cause the Apply programs spill file
and the targets log to overflow.
The number of minutes that you specify is called the data block. The
data-blocking value that you specify is stored in the MAX_SYNCH_MINUTES
column of the subscription sets (IBMSNAP_SUBS_SET) table. If the
accumulation of data is greater than the size of the data block, then the Apply
program converts a single Apply cycle into several mini-cycles. If resources
are still not sufficient to handle the blocking factor provided, the Apply
program reduces the size of the data block to match available system
resources. By retrieving smaller sets of data, the Apply program can lessen
both the network load and the temporary space required for the retrieved
data.
Example: If you specify that the Apply program should retrieve at most 10
minutes worth of data per mini-cycle, the Apply program will retrieve an
amount of committed data from the CD table at the source that is within
approximately 10 minutes of the last mini-cycle.
In addition to preventing the logs and spill files from overflowing, these
mini-cycles have several other benefits. If there is an error during the
replication cycle, the Apply program must roll back only the changes that it
made during the mini-cycle that failed. If replication fails during a mini-cycle,
the Apply program tries to process the subscription set from the last
successful mini-cycle, which can save a significant amount of time if a large
amount of changed data is available to be processed. Figure 5 on page 79
shows how the changed data is broken down into subsets of changes.
The number of minutes that you set should be small enough so that all
transactions for the subscription set that occur during the interval can be
copied without causing the spill files or log to overflow during the mini-cycle.
When processing data, the Apply program does not take any of the following
actions:
v Split a unit of work (meaning that a long running batch job without
commits cannot be broken up by the data blocking factor).
v Roll back previously committed mini-subscription cycles.
v Use the data blocking factor during a full refresh.
Deciding how the Apply program loads target tables that have referential
integrity
If you want to have referential integrity between target tables in a set, you
must choose how the Apply program will process the source data during the
initial load of the target tables. By default, the Apply program performs the
full refresh of the targets by reading all the rows in the source, storing them
in memory, and then inserting the rows into the targets tables. However, you
have other options about the way that the target tables are initially loaded.
You do not make these decisions when you create subscription sets or define
the source-to-target mappings (members) for each set; you decide how the
targets will be loaded when you set the startup parameters for the Apply
Consider one of the following two alternatives on when you can create these
referential integrity relationships:
v Before the target tables are populated.
This requires that no changes are made at the source table during the entire
extract and load stage of the target table. Also, you must start the Apply
program using the LOADX startup option in order to get the speed of the
load processing and to bypass the referential constraint checking during
this initial population. If you do not use the Apply startup option of
LOADX, the inserts in the target table could fail.
v After the Apply program has fully populated the target tables and has
processed one complete and successful cycle of applying changes to this set
of tables.
The advantage waiting to add the referential integrity constraints to these
tables is that the changes can still be made at the source table while the
target tables are being loaded. You can start the Apply program with or
without the LOADX startup option, because there are no constraints that
need to be bypassed. A full refresh will typically be much faster using the
LOADX startup option. During the initial population of the target tables,
the targets might be out of synch with each other regarding their referential
integrity relationships; but, as they are being loaded, all changes are being
captured for the set. After the Apply program replicates the first set of
changes, all target tables will contain the same transactions and will have
referential integrity. At this point, you can deactivate the set, add the
referential integrity constraints, and then reactivate the set.
For more information about the startup options that you have for how your
target tables are initially loaded, see Refreshing target tables using the
ASNLOAD exit routine on page 167.
Specifying how the Apply program replicates changes for members in the
set
When the subscription set has change-capture replication, you can decide how
you want the Apply program to replicate changes to every source-to-target
mapping in the set. After the target tables are initially loaded, the Apply
program starts to read the CD (or CCD) tables and collects the changes into
spill files. For each CD (or CCD) table, the Apply program creates a separate
spill file. The Apply program then reads the changes from the spill files and
applies them to the target tables. It can do this in one of three ways:
v Using table-mode processing
v Using transaction-mode processing
By specifying the type of processing for the subscription set, you can control
how often the Apply program commits its changes to the target table or view.
The Apply program can commit once for each subscription-set member or
after applying a number of transactions. Having one commit can reduce the
latency for the subscription set, but having multiple commits allows the
Apply program to apply the data in the original commit sequence.
Table mode
The Apply program reads all changes from a spill file for a CD (or CCD)
table, applies the changes to the corresponding target tables, and then begins
to process the spill file for the next CD (or CCD) table. When it is done
reading and applying changes from all the CD (or CCD) tables in the set, it
then issues a DB2 commit to commit all of the changes to all of the target
tables in the subscription set.
Transaction mode
The Apply program opens all of the spill files at once and processes the
changes from them at the same time. The order in which the changes are
applied to the target tables is the order in which the transactions took place at
| the source tables. The COMMIT_COUNT column in the IBMSNAP_SUBS_SET
| table controls how changes are applied and committed to all target tables for
| that subscription set. Use the transaction-mode processing when you have
referential integrity constraints on the target tables in the subscription set.
You can specify that the Apply program use transaction-mode processing for
any subscription set, however, it only changes the Apply programs behavior
for sets with user-copy and point-in-time target tables, but not sets with the
following types of target tables:
v CCD target tables. Sets containing CCD tables as sources are always
processed in table mode.
v Any target table for which the source table is a CCD table. Sets containing
CCD tables are always processed in table mode.
v Replica target tables. Sets containing replica tables are always processed in
transaction mode.
Defining SQL statements or stored procedures for the subscription set
You can define SQL statements or stored procedures that run each time the
Apply program processes the subscription set. These statements can be useful
for pruning CCD tables or manipulating source data before it is applied to
targets. You can specify when and where the SQL statements or stored
procedures should run:
v At the Capture control server before the Apply program applies the data.
When you use the Replication Center to add SQL statements to a subscription
set, you can click Prepare statement in the Add SQL Statement or Procedure
Call window to verify the statements syntax.
Scheduling the replication of a subscription set
You can control how often the Apply program processes a subscription set
and thereby control how current the data in your target tables is. You can
control how often the subscription set is eligible for processing by using
time-based or event-based scheduling, or you can use these scheduling
options together. The Apply program begins processing a subscription set
when the subscription set is eligible for processing. For example, you can set
an interval of one day, and also specify an event that triggers the subscription
cycle. If you use both of these scheduling options, the subscription set will be
eligible for processing at both the scheduled time and when the event occurs.
| In update-anywhere replication, you can use the same or different timing for
| the master-to-replica and replica-to-master subscription sets.
| Procedure:
| To specify the schedule for a subscription set, you can use either of the
| following two methods:
| Replication Center
| Use one of the following notebooks:
| v Create Subscription Set. Use the Schedule page to select the
| scheduling option that you want.
| v Subscription Set Properties. Use this notebook if you have already
| created the subscription set and want to change the scheduling for
| the subscription set.
| See the Replication Center online help for details.
Time-based scheduling
The simplest method of controlling when the set is processed is to use
time-based scheduling (also known as relative timing or interval timing). You
determine a specific start date, time, and interval. The interval can be specific
(from one minute to one year) or continuous, but time intervals are
approximate. The Apply program begins processing a subscription set as soon
as it is able, based on its workload and the availability of resources. Choosing
a timing interval does not guarantee that the frequency of replication will be
exactly at that interval. If you specify continuous timing, the Apply program
replicates data as frequently as it is able.
Event-based scheduling
To replicate data using event-based scheduling (also known as event timing),
you can specify an event name when you define the subscription set. To allow
the Apply program to recognize the event when it occurs, you must also
populate the subscription events (IBMSNAP_SUBS_EVENT) table with a
timestamp for the event name. When the Apply program detects the event, it
begins replication.
EVENT_NAME is the name of the event that you specify while defining the
subscription set. EVENT_TIME is the timestamp for when the Apply program
begins to process the set. END_OF_PERIOD is an optional value that indicates
that updates that occur after the specified time should be deferred until a
future event or time. END_SYNCHPOINT is also an optional value that
indicates that updates that occur after the specified log-sequence number
should be deferred until a future event or time. If you specify values for both
END_OF_PERIOD and END_SYNCHPOINT, the value for
END_SYNCHPOINT takes precedence. Set the EVENT_TIME value using the
clock at the Apply control server, and set the END_OF_PERIOD value using
the clock at the source server. This distinction is important if the two servers
are in different time zones.
You can post events in advance, such as next week, next year, or every
Saturday. If the Apply program is running, it starts at approximately the time
that you specify. If the Apply program is stopped at the time that you specify,
when it restarts, it checks the subscription events table and begins processing
the subscription set for the posted event.
The Apply program does not prune the table; you must populate and
maintain this table. Also, you cannot use the Replication Center to update the
subscription events table. You must issue SQL statements or define automated
procedures to add events to this table.
Example:
INSERT INTO ASN.IBMSNAP_SUBS_EVENT
(EVENT_NAME, EVENT_TIME)
VALUES (EVENT01, CURRENT TIMESTAMP + 1 MINUTES)
Any event that occurs prior to the most recent time that the Apply program
processed the subscription set (as specified by the value in the LASTRUN
column of the subscription-set control table) is considered to be an expired
event and is ignored. Therefore, if the Apply program is running, you should
post events that are slightly in the future to avoid posting an expired event.
Prerequisites:
Before you set up targets that subscribe to changes at sources, you must
register the tables or views that you want to use as sources. If you didnt
already register sources for replication, read and follow the instructions in
Chapter 3, Registering tables and views as replication sources, on page 43.
You should also create a subscription set and plan for how many members
you want to add in a set. If you need to create a subscription set, see
Creating subscription sets on page 74. If you need to plan for
subscription-set members, see Planning the number of subscription-set
members on page 72.
Restrictions:
v DB2 replication does not support views of non-DB2 relational tables as
sources.
v If you define a target view, that view must be an insertable view. That is, all
of the views columns must be updateable and the full select for the view
cannot include the keywords UNION ALL.
v If you are using the Replication Center, you cannot add a column to a
subscription-set member if that column does not already exist in the target
table.
v For Windows, UNIX, z/OS: You can define a maximum of 200 members for
each subscription set.
v For OS/400: You can define a maximum of 78 members for each
subscription set.
Procedure:
To add a subscription-set member, you can use either of the following two
methods:
Replication Center
Use one of the following notebooks:
v Create Subscription Set. Use this notebook when you create the
subscription set.
To map a source with a target, specify the following information about the
registered table or view that you want to use as the source:
v The source table or view and a target table or view (including a table space
and index for the target table).
v The type of target table.
v The registered columns from the source table that you want to replicate to
the target table.
When you use the Replication Center to map a source with a target, LOB
columns and DATALINK columns are not automatically included in the
column mapping. You must explicitly select those columns.
v The rows from the source table that you want to replicate to the target table
(you include a WHERE clause to specify the rows).
To map the chosen source to a DB2 target, specify the following information
about the target table or view:
v The schema of the target table or view.
v The name of the table or view you want to use as the target.
Default: The default name comes from the target object profile for the
target server, if there is one. If you have not set this profile, the default is
TG followed by the name of the source table or view. (For example, if the
name of your source table is EMPLOYEE, the name of your target table
defaults to TGEMPLOYEE.)
v The type of target table
Default: user copy
If the specified target table does not exist, the Replication Center or the
ADDDPRSUBM system command creates it.
To map the chosen source to a non-DB2 relational target, specify the following
information about the target table:
When you add a subscription-set member, you can use the default target table
type of user copy, or you can select another target table type to meet your
replication needs.
When you add a subscription-set member for a target table that does not yet
exist, you can use the default settings, or you can modify the member
properties to meet your replication needs. You can first pick the type of target
table that you want to use, and you can then set properties for how the Apply
program replicates data to that target. See Selecting a target type for a
description of various replication scenarios and which target table types you
might want to use in each case. The section also helps guide you through
which settings to choose based on your replication goals. Regardless of what
target type you select, you can modify the common set of properties that all
members share. See Common properties for all target table types on page
100 for a complete list of options for subscription-set members, their defaults,
and an explanation of when you might want to use or change the defaults.
The names of all non-DB2 relational target tables and indexes must follow the
DB2 table and index naming conventions.
Restrictions:
The following sections discuss possible uses for each target type. Each section
guides you through the types of target tables that you can use and how you
can set the target-table properties to meet your replication needs:
v Defining read-only target tables on page 90
v Replicating the net change for a row to the target table on page 93
v Defining middle tiers in a multi-tier configuration on page 94
v Defining read-write targets (update-anywhere) on page 97
v Using an existing table as the target table on page 99
Depending on how you want the source data to appear at your target, you
can define read-only target tables to contain:
v A copy of the source table or view
v A history of changes or audit information on page 92
v A computed summary of data or changes at the source
Copy of source table: By default, a user copy table will be created as your
target type when you define a subscription-set member. Use this default type
if you want the target table to match the source table at the time the copy is
made. User copy tables do not contain any additional replication-control
columns, but they can contain a subset of the rows or columns in the source
table or additional columns that are not replicated.
You can create target tables that contain summaries of the entire contents of
the source tables or of the most recent changes made to the source table data.
For aggregate target-table types, you can define target columns by using
aggregate SQL column functions such as COUNT, SUM, MIN, MAX, and
AVG. These columns do not contain the original source data; they contain the
computed values of the SQL function that you define. The Apply program
doesnt create aggregations during full refresh; rows are appended over time
as the Apply program processes the set. An advantage of using an aggregate
table is that DB2 replication can replicate summary information only rather
than each individual row, thus saving both network bandwidth and space in
the target table.
Use a base-aggregate target table to track the state of a source table during
each replication cycle. For a base-aggregate target table, the Apply program
aggregates (reads and performs calculations) from the source table. A
base-aggregate table also includes a timestamp of when the Apply program
performed the aggregation.
If a registered source table has only a base-aggregate table as its target, you
do not need to capture changes for the source table.
Example: Suppose that you want to know the average number of customers
that you have each week. If your source table has a row for each customer,
the Apply program would calculate the sum of the number of rows in your
source table on a weekly basis and store the results in a base aggregate table.
If you perform the aggregation every week, the target table will have 52
entries that show the number of customers you had for each week for the
year.
Example: Suppose that you want to know how many new customers you
gained each week (INSERTs) and how many existing customers you lost
You might want to audit the source data or keep a history how the data is
used. By using a CCD table as your target type, you can track the history of
source changes in various ways, depending on how you define the CCD table.
For example, you can track before and after comparisons of the data, when
changes occurred, and which user ID made the update to the source table.
To define a read-only target table that keeps a history of your source table,
define the target CCD table to include the following attributes:
Noncondensed
To keep a record of all of the source changes, define the CCD table to
be noncondensed, so it stores one row for every change that occurs.
Because noncondensed tables contain multiple rows with the same
key value, do not define a unique index. A noncondensed CCD table
holds one row per UPDATE, INSERT, or DELETE operation, thus
maintaining a history of the operations performed on the source table.
If you capture UPDATE operations as INSERT and DELETE
operations (for partitioning key columns), the CCD table will have
two rows for each update, a row for the DELETE and a row for the
INSERT.
Complete or noncomplete
You can choose whether you want the CCD table to be complete or
noncomplete. Because noncomplete CCD tables do not contain a
complete set of source rows initially, create a noncomplete CCD table
to keep a history of updates to a source table (the updates since the
Apply program began to populate the CCD table).
Include UOW columns
For improved auditing capability, include the extra columns from the
UOW table. If you need more user-oriented identification, columns for
the DB2 for z/OS correlation ID and primary authorization ID or the
OS/400 job name and user profile are available in the UOW table. For
details on which UOW columns you can include in a CCD table, see
Consistent-change data (CCD) table on page 594.
If changes occur frequently at a source table, you can create an internal CCD
table to summarize the committed changes that occurred at the source since
the last Apply cycle. Because the CD table is constantly in flux when the
Capture program appends changes from the log, the local cache of source
changes in the CCD acts as a more stable source for your targets.
When the original source table is updated, the Capture program reads the
frequent changes in the sources log and adds them to the sources CD table.
From that CD table, an Apply program reads the changes in the CD table and
populates the internal CCD table. You can define the internal CCD table to
contain only the most recent change for each row in the CD table that
occurred during the last cycle. Therefore, the CCD table is static between
Apply cycles (for the Apply program replicating from the CD table to the
CCD table) and thus makes a more stable source for targets. By condensing
changes from the source, you can improve overall replication performance by
not replicating many updates for the same row to the target table.
Recommendations:
v Define a subscription-set member between the source table and the internal
CCD table before defining other subscription-set members between the
source table and other target tables. That way, the Apply program will use
the internal CCD table rather than the CD table for replicating changes
from the source table. If you define other subscription-set members and
begin replication using those members before you define the internal CCD
table for the source table, you might have to perform a full refresh for all
targets of the source table.
v Combine all internal CCD tables into one subscription set to ensure that all
target tables for the source database are in synch with one another.
v Even if you only want a subset of the frequently changing source columns
to be applied to other targets, use the default that all registered source
columns are replicated to the internal CCD. That way, you can use the
internal CCD table as a source for future target tables that might need data
from the other registered columns in the original source table. Only
columns in the internal CCD table will be available for change-capture
replication for any future target.
The basic replication model is a two-tier model, with a single source and one
or more targets; but you can set up configurations with three (or more) tiers.
For example, in a three-tier model, the first tier (tier 1) is the source database,
the second tier (tier 2) is the target for tier 1. Tier 2 is also a source for a third
tier of targets (tier 3), and can distribute changes to one or many tier-3
databases. When you have more than two tiers in your replication
configuration, the middle tiers, which act as both sources and targets, are
CCD tables.
Figure 6. Three-tier replication model. You can replicate data from a source table to a target table,
and then from that table to another target table.
Restriction:
Procedure:
This procedure also applies for replica tables. CCD tables are usually used for
read-only replication, but replica tables are used for update-anywhere
replication.
Important: If a full refresh occurs on the external CCD (the middle tier), then
the Apply programs for all subsequent tiers that use that external CCD as a
source will perform full refreshes. This is called a cascade full refresh.
Defining read-write targets (update-anywhere)
Target table type: Replica
Prerequisites:
Restrictions:
| v Replica target table types are not supported in a remote journal
| configuration.
v You cannot use CCD tables as sources or targets in update-anywhere
replication.
Procedure:
Requirements:
v If the subscription-set member definition contains fewer columns than are
in the existing target table, the target-table columns that are not involved in
replication must allow nulls or be defined as NOT NULL WITH DEFAULT.
v There must be a unique index for point-in-time, user copy, replica, and
condensed CCD tables. When you define the subscription-set member using
the existing target table, you can use the existing unique index or specify a
new one.
Restrictions:
v A subscription-set member definition cannot contain more columns than are
in the existing target table.
v If you are using the Replication Center, you cannot add a column to a
subscription-set member if that column does not already exist in the target
table.
DB2 replication checks for inconsistencies between your existing target table
and the subscription-set member definition.
In some replication scenarios, you might not want to replicate all columns to
the target table, or the target table might not support all data types defined
for the source table. You can define a column (vertical) subset that has fewer
columns than your source table.
By default, your target table contains all the registered columns from the
source table, except LOB and DATALINK columns. If you dont want the
target table to contain all of the columns that exist in the source table, select
only those source columns that you want to replicate to the target table. The
registered columns in the source table that you do not select are still available
for other subscription-set members, but are not included for the current
source-to-target mapping.
You can also add calculated columns to a target table. These columns can be
defined by SQL scalar functions, such as SUBSTR, or they can be derived
columns, such as the division of the value of column A by the value of
column B (colA/colB). These calculated columns can refer to any columns
from the source table.
Source rows that you want applied to the target
Default: all source rows are replicated to the target
By default, your target table contains all the rows in the source table. For
some replication scenarios, you might not want to replicate all rows from the
source table to the target table, or you might want to replicate source rows
containing different sorts of data to different target tables. You can define a
row (horizontal) subset that contains rows matching a certain condition (an
SQL WHERE clause). The SQL predicate can contain ordinary or delimited
identifiers. See the DB2 SQL Reference for more information about WHERE
clauses.
Examples:
v Assume that your target table is an operational data store for one of your
companys operational divisions. You can define a WHERE clause in the
subscription-set member to replicate all rows for the division (or all
departments in the division) from the source table to the target table.
v Assume that you have several target tables in the same database. You can
define a WHERE clause in one subscription-set member to replicate all LOB
columns (plus the primary-key column) to one target table, and you can
define a WHERE clause in another subscription-set member to replicate all
other columns to a separate target table. Thus, your target database can
The following examples show WHERE clauses that you can use to filter rows
of the target table. These examples are very general and are designed for you
to use as a model.
v WHERE clause specifying rows with specific values
To copy only the rows that contain a specific value, such as MGR for
employees that are managers, use a WHERE clause like:
EMPLOYEE = MGR
v WHERE clause specifying rows with a range of values
To copy only the rows within a range, such as employee numbers between
5000 and 7000 to the target table, use a WHERE clause like:
EMPID BETWEEN 5000 AND 7000
By default, the column names in the target table (if it does not yet exist) will
match the column names in the source table, and the data value in a source
column will be replicated to the target column with the same name. You can
change the names of all columns in your target tables except the replication
control columns (which begin with IBMSNAP or IBMQSQ). If the target table
exists, the Replication Center will map the columns by name.
| Target table columns can have different lengths than source columns. If the
| target column is shorter than the source column, you can use an expression in
| the subscription-set member to map the characters from the longer column to
| the shorter column, or register a view that includes the expression. For
| If the target column name is longer, pad the target column name with blanks.
If you are mapping a DB2 table to a non-DB2 relational table with an existing
nickname for the non-DB2 relational table, the data types of some columns
might not be compatible. If the data types of the source columns are not
compatible with the data types in the target columns, you can modify the
data type at the target to make it compatible with the source:
v You can add calculated columns to adjust the data types from the source to
match the required data type for the target.
v You can alter the nickname for a non-DB2 relational target table to change
the data-type conversions.
Example: You want to replicate data from a DB2 source table with a DB2
column of data type DATE to an Oracle target table with an Oracle column of
data type DATE.
Table 4. Mapping a DB2 DATE column to an Oracle DATE column
DB2 Column Nickname Data Mapping Oracle Column
A_DATE DATE A_DATE TIMESTAMP A_DATE DATE
A_DATE DATE
The Oracle target table is created with an Oracle data type of DATE (which
can contain both date and timestamp data). The initial nickname for an Oracle
DATE data type in a federated database maps the DB2 data type as a
TIMESTAMP. The DB2 Replication Center and the OS/400 system commands
for replication alter the nickname data type to DATE, so that a DATE is
replicated to Oracle and not a TIMESTAMP.
| When you are creating a target table using the Replication Center, you can
| rename columns at the target regardless of the target-table type. Also, you can
| change column attributes (data type, length, scale, precision, and whether it is
| nullable) where the attributes are compatible. You cannot use the Replication
| Center to rename columns of existing target tables. If the source and target
| columns do not match, you can either use the Replication Center to map the
| columns from the source to the target, or you can create a view of the target
| table that contains a match to the source column names.
If you are creating a new target table, you can use the default index name and
schema or change the defaults to match your naming conventions.
To create a unique index for a new target table, you have two options:
v Specify the columns that you want as the unique index for the target table.
v Have DB2 replication select a unique index for you.
If you do not select columns for the unique index, DB2 replication checks
the source table for one of the following definitions, in the following order:
1. A primary key
2. A unique constraint
3. A unique index
If DB2 replication finds one of these definitions for the source table, and the
associated columns are registered and part of the target table, DB2
replication uses the source tables primary key (or unique index or RRN) as
| the target key. In the case of a unique constraint, DB2 replication creates a
| unique index for the target table using the constraint columns.
For an OS/400 source table that does not have a primary key or unique
index, modify the registration for that table to use the relative record
number (RRN) as a uniqueness factor. When you define the subscription-set
member, specify the RRN column as the unique index for the target table.
See Using relative record numbers (RRN) instead of primary keys
(OS/400) on page 64 for details on defining an RRN for an OS/400 source
table.
For existing target tables, you must select the unique index. You can select one
of the following options:
v Use an index that already exists for the target table.
To use an existing index, select the columns that represent the index in the
Replication Center. If the Replication Center finds an exact match then it
only sets a target key for the Apply program to use, otherwise it creates the
unique index and sets a target key for the Apply program to use.
v Create another index for the target table.
The unique index will be created if it does not already exist, and the target
key will be set for the Apply program to use.
Important: If you select a key for the target table that includes columns that
can be updated at the source table, you must instruct the Apply program to
make special updates to the target key columns. See How the Apply
program updates the target key columns with the target-key change option
for more information.
How the Apply program updates the target key columns with the
target-key change option
Restrictions:
v You cannot use the target-key-change option for source tables that are
registered to capture updates as delete/insert pairs.
| v You cannot map an expression in a source table to a key column in a target
| table if the Apply program updates the target table based on the before
| images of the target key column (that is, if the TARGET_KEY_CHG column
| of the IBMSNAP_SUBS_MEMBR table has a value of Y for that target table).
If you choose the target-key change option when you define the
subscription-set member, then the Apply program makes special updates to
the target key columns when the target key changes. In order for the Apply
program to make these special updates, the columns that are in the source
table that are part of the target-key columns for the target table must be
registered with the before-image columns in the CD (or CCD) table. If you did
not define the source registration to capture the before-image values of the
columns that make up the target key, then you must alter your registration to
include them before subscribing to a target table with a different key.
After you ensure that the before-image values of the target key columns are in
the CD (or CCD) table, select the subscription-set member option for the
Apply program to use the before-image values when updating target key
columns.
| If the target_key_chg variable is set to Y, the SQL statement for the update
| operation is:
| UPDATE targettable SET <all columns> = after-image values
| WHERE <key columns> = before-image values
Related concepts:
v Chapter 14, Using the DB2 Replication Center, on page 255
Related tasks:
v Chapter 3, Registering tables and views as replication sources, on page 43
v Chapter 6, Subsetting data in your replication environment, on page 117
v Appendix A, UNICODE and ASCII encoding schemes on z/OS, on page
711
Related reference:
v ADDDPRSUBM: Adding a DPR subscription-set member (OS/400) on
page 395
v ADDDPRSUB: Adding a DPR subscription set (OS/400) on page 378
v Consistent-change data (CCD) table on page 594
| DB2 replication can replicate the following data types under certain
| circumstances:
| Long variable graphic (LONG VARGRAPHIC) data if the source and
| target tables reside in DB2 for z/OS.
| Long variable character (LONG VARCHAR) data requires either that the
| source database tables be in DB2 for z/OS or both the source and target
| tables be in DB2 Universal Database (for Windows and UNIX). See the
| Alter Table section of the DB2 Universal Database SQL Reference to learn
| how to enable LONG VARCHAR data.
| DB2 replication cannot replicate a table that contains abstract data types.
DB2 replication can replicate tables with spatial data type columns but
cannot replicate the actual spatial data type columns.
The Capture program reads the LOB descriptor in the log records to
determine if any data in the LOB column has changed and thus should be
replicated, but does not copy the LOB data to the change-data (CD) tables.
When a LOB column changes, the Capture program sets an indicator in the
CD table. When the Apply program reads this indicator, the Apply program
then copies the entire LOB column (not just the changed portions of LOB
columns) directly from the source table to the target table.
Because a LOB column can contain up to two gigabytes of data, you must
ensure that you have sufficient network bandwidth for the Apply program.
Likewise, your target tables must have sufficient disk space to accommodate
LOB data.
Restrictions:
v The Apply program always copies the most current version of a LOB
column directly from the source table (not the CD table), even if that
column is more current than other columns in the CD table. Therefore, if
the LOB column in the target row changes, it is possible that this LOB
column could be inconsistent with the rest of the data in that target row. To
reduce this possibility of inconsistent data in the target row, ensure that the
interval between the Apply cycles is as short as practical for your
application.
v You can replicate 10 LOB columns or fewer per table. If you register a table
with more than 10 LOB columns, the Apply program returns an error
message. The Replication Center returns an error message if you attempt to
register more than 10 LOB columns per table.
v You can copy LOB data only to read-only tables. Thus, you cannot replicate
LOB data to replica tables.
v To copy LOB data between DB2 for OS/390 Version 6 (or later) and DB2
Universal Database (for any other operating system), you need DB2
Connect 7 or later.
v You cannot refer to LOB data using nicknames.
DB2 Universal Database supports the DATALINK data type that allows the
database to manage the access control, referential integrity, and recovery of
these large and unstructured files. DB2 Universal Database supports
DATALINK values on the following operating systems:
v AIX
v Solaris Operating Environments
v Windows
v OS/400
When the Apply program reads data with a data type of DATALINK, the
Apply program places reference data in the spill file and also places the URL
of the updated file into an input file.
The Apply program then invokes the ASNDLCOPY exit routine. This
ASNDLCOPY exit routine ensures that the physical file exists on the source
file system, maps the URL to its corresponding file on the target file system,
stores this target file location in a result file, and then connects to the
appropriate file-copy daemon (DLFM_ASNCOPYD, ASNDLCOPYD, or FTP)
to copy the external file from the source file system to the target file system.
On UNIX and Windows: Start the Apply program with the loadxit parameter
set to y to invoke the ASNLOAD exit routine. The ASNLOAD exit routine
copies external files (to which the DATALINK values point) during a full
refresh. See Refreshing target tables using the ASNLOAD exit routine on
page 167 for more information.
On OS/400: Modify the ASNLOAD exit routine to call the ASNDLCP exit
routine to enable the Apply program to copy external files during a full
refresh. See Refreshing target tables using the ASNLOAD exit routine on
page 167 for more information.
Important: Because external files can be very large, you must ensure that you
have sufficient network bandwidth for both the Apply program and the
file-transfer mechanism that you use to copy these files. Likewise, your target
system must have sufficient disk space to accommodate these files.
Restrictions:
v You cannot replicate DATALINK columns between DB2 databases on
OS/400 and DB2 databases on other operating systems.
v On the OS/400 operating system, there is no support for the replication of
the comment attribute of DATALINK values.
The following sections discuss the user exit routine and the file-copy daemons
that the Apply programs use (depending on the operating system) to replicate
both the DATALINK values and the external file to which the URL points to
the target system:
v Setting up and using the ASNDLCOPY exit routine
v Setting up and using DLFM_ASNCOPYD (UNIX, Windows) on page 113
v Setting up and using ASNDLCOPYD (OS/400) on page 115
Setting up and using the ASNDLCOPY exit routine
You can configure your own exit routine to replicate the external files, but you
must name the program ASNDLCOPY. Place the configuration files in the
current execution path of the Apply program.
Procedure:
Because the Apply program calls the ASNDONE exit routine after
subscription processing completes regardless of success or failure, you can use
the routine to perform any necessary clean up if the ASNDLCOPY routine
fails to replicate any external files.
Setting up and using DLFM_ASNCOPYD (UNIX, Windows)
If you installed DB2 Data Links Manager Version 8, you can use the Data
Links Manager replication daemon (DLFM_ASNCOPYD) to copy the files that
are referenced by the DATALINK data type.
After the ASNDLCOPY exit routine maps the source and target URLs, this
exit routine connects to a daemon to copy the files. You can configure the
ASNDLUSER configuration file, specifying the address and port number
needed to connect to the file-copy daemon that you want to use. You can use
any FTP daemon or the DLFM_ASNCOPYD file-copy daemon.
Both the FTP and the DLFM_ASNCOPYD daemons copy external files from
the source file system to the target file system. However, the
DLFM_ASNCOPYD file-copy daemon provides additional functionality:
v Allows retrieval of a particular version of a file that is referenced by a
DATALINK column defined as RECOVERY YES.
v Allows retrieval of files referenced by DATALINK columns defined as
READ PERMISSION DB depending on the access privilege of the user.
v Provides the ability to preserve the last modification time of replicated files.
You can use the DLFM_ASNCOPYD file-copy daemon with only the
following operating systems: AIX, Solaris Operating Environments, and
Windows.
Procedure:
The Data Links File Manager archives a new version of a source file with a
DATALINK column defined as RECOVERY YES each time an application
links to the file through a standard SQL operation. When the Capture
program captures changes to a row with a DATALINK column defined as
RECOVERY YES, the Capture program records the version number of the file
and places that version number in the CD table. The Apply program reads the
data changes from the CD table along with the version number and passes the
URLs of the new DATALINK column values and the version number to the
ASNDLCOPY exit routine. When the ASNDLCOPY exit routine connects to
the DLFM_ASNCOPYD daemon, this file-copy daemon retrieves a consistent
version of the external file.
You can find the ASNDLCOPYD sample file in library QDP4, source file
QCSRC, member ASNDLCPD. The sample file builds three programs:
ASNDLCOPYD
The main parent program and file-copy daemon.
ASNCHILD
The program that coordinates connections from the client to the
ASNDLCOPYD daemon. ASNCHILD is part of the ASNDLCOPYD
daemon, which spawns a new ASNCHILD process for each request
from the client.
ASNDLCFG
A configuration program for adding and removing user IDs and for
changing user ID passwords.
Prerequisite:
Procedure:
where libraryname is any existing library name. See the PROLOG section of
the sample program for more information.
4. Place the executables into the QDP4 library.
5. Modify the configuration files to meet the requirements of your site.
6. Start the ASNDLCOPYD daemon with administrator authority and
superuser access. Specify both the port number and the directory that
contains the configuration files.
The ASNDLCOPYD file-copy daemon creates a log file for all the messages
generated by the ASNDLCOPYD program. This log file has the following
name: ASNDLCOPYDYYYYMMDDHHMMSS.LOG, where YYYYMMDDHHMMSS is the
time that the daemon started running.
Related tasks:
v Chapter 10, Operating the Apply program, on page 149
Do not use any of these techniques if you are replicating to replica target
tables. The master table and replica tables in update-anywhere configurations
replicate data back and forth to one another. Replica tables can have a subset
of the source table columns as long as the columns that are not used are
nullable. Otherwise, replica tables must contain the same columns as the
source table so you cannot subset columns, add new columns, or rename
columns.
This section discusses the following ways that you can subset data during
registration:
v Subsetting source data using views
v Defining triggers on CD tables to prevent specific rows from being
captured (UNIX, Windows, z/OS)
Subsetting source data using views
When you register a source, you choose the columns that you want to make
available for replication. The columns that you select are captured for
replication. In some cases, after you register a source for change replication,
you might want to register a view of the source.
For example, assume that the Human Resources department maintains a table
that contains personnel data, including salary information. To maintain a
backup database, the whole personnel table is registered and subscribed to at
the backup site. However, if another target site wants to subscribe to the
personnel table, you might want to hide the salary information from this
second subscriber. The solution is to register a view over the personnel table,
and allow access privileges on only the registered view for the second
subscriber, so that the salary information is protected from access. A
subscription can be created on this registered view.
You can also register views that include two or more source tables. For
example, if you have a customer table and a branch table, the only way to
adequately subset the customers to the target correctly might be by joining the
two tables so that only the customers for a certain branch are replicated to a
certain target. In this case, you must take care to avoid double-deletes.
Defining triggers on CD tables to prevent specific rows from being
captured (UNIX, Windows, z/OS)
When you register a source, the Replication Center lets you select which
columns you want captured, but it does not let you prevent certain changes in
those rows from being replicated. In some replication scenarios, you might
want to prevent certain changes in rows from being captured and replicated
to the target tables. For example, if you want your target tables to contain all
rows and you never want any rows deleted from them, you do not want to
replicate deletes from the source.
Example: Suppose that you want all source table DELETE operations to be
suppressed during replication from the table SAMPLE.TABLE, where the CD
table is SAMPLE.CD_TABLE. The following trigger suppresses any rows that
are DELETE operations from being inserted into the CD table:
CREATE TRIGGER SAMPLE.CD_TABLE_TRIGGER
NO CASCADE BEFORE INSERT ON SAMPLE.CD_TABLE
REFERENCING NEW AS CD
FOR EACH ROW MODE DB2SQL
WHEN (CD.IBMSNAP_OPERATION = D)
SIGNAL SQLSTATE 99999 (CD INSERT FILTER)
You might want to add the create trigger statement to the SQL that was
generated during registration. You must run the modified SQL to complete the
registration and to create the triggers on the CD tables.
These triggers execute every time the Capture program tries to insert a row in
the CD table, so you need to consider if using triggers here will give you the
best performance in your replication configuration. You can increase or
decrease data throughput by adding triggers to CD tables. Use triggers on the
CD table to suppress a significant number of changes at the source. If you
plan to capture most of the changes, but want to suppress some of them from
being replicated, you might want to suppress the unwanted rows during
subscription.
The Apply program uses predicates to determine what data to copy during
full refresh and change-capture replication. The Replication Center allows you
to specify predicate values for full refresh and change-capture replication. You
might want to add additional predicate information to use only for
change-capture replication because that information is not available during
full refresh. You must add this additional predicate information to the
subscription set member (IBMSNAP_SUBS_MEMBR) table in the
UOW_CD_PREDICATES column through SQL that you provide.
You cannot use the Replication Center to prevent deletes at the target table,
because the information about the type of operation is stored in the CD table
and is not available at the source table or view. Therefore, you must generate
the additional change-capture predicate by using an SQL statement that
includes the following information3:
UPDATE ASN.IBMSNAP_SUBS_MEMBR SET UOW_CD_PREDICATES = IBMSNAP_OPERATION <>"D"
WHERE APPLY_QUAL = apply_qual AND SET_NAME = set_name AND
SOURCE_OWNER = ALL AND SOURCE_TABLE = CUSTOMERS
By default, the Apply program does not join the UOW table and the CD table
for user-copy target tables; it fetches and applies data directly from the CD
table. If the predicate has to reference the UOW table, and the target table is a
user copy, you must set the value of the JOIN_UOW_CD column to Y in the
subscription members (IBMSNAP_SUBS_MEMBR) table. Setting this flag
ensures that the Apply program joins the UOW and CD tables.
If you want to specify predicates that exceed 1024 bytes (the capacity of the
PREDICATES column of the subscription-members
(IBMSNAP_SUBS_MEMBR) table) for a row subset, you must use a source
view.
| If you are using complex predicate statements for a subscription set, enclose
| the entire expression in parentheses. For example, when using the AND and
| OR clauses in a predicate statement, enclose the expression as follows:
| ((TOSOURCE = 101 AND STATUS IN (202,108,109,180,21,29,32,42))
| OR (SOURCE = 101))
3. Depending on your scenario, you might need to add columns to the update statement to ensure that you update a
single row in the subscription members (IBMSNAP_SUBS_MEMBR) table.
This chapter describes some advanced techniques that you can use to
transform your data.
You can manipulate data either before or after its captured from a registered
source. Manipulate your data at registration instead of at subscription if you
want to manipulate the data once and replicate transformed data to many
target tables. Manipulate your data during subscription instead of registration
if you want to capture all of the source data and selectively apply transformed
data to individual targets.
For example, if a particular value is missing in the source table, you might not
want the Capture program to capture null values.
You can use triggers on your CD table to specify conditions for the Capture
program to enhance the data when inserting data to the CD table. In this case,
you can specify that the Capture program should insert a default value in the
CD table when it encounters a null value in the source. You can use the
following code to create a trigger that supplies an unambiguous default if
data is missing from the source table update:
CREATE TRIGGER ENHANCECD
NO CASCADE BEFORE INSERT ON CD_TABLE
REFERENCING NEW AS CD
FOR EACH ROW MODE DB2SQL
WHEN (CD.COL1 IS NULL)
SET CD.COL1 =MISSING DATA
END
The Apply program can manipulate data, either before or after it applies data
to the target, in the following ways:
v Enhancing data using stored procedures or SQL statements
v Mapping source and target columns that have different names on page
123
v Creating computed columns on page 123
Stored procedures use the SQL CALL statement without parameters. The
procedure name must be 18 characters or less in length (for OS/400, the
maximum is 128). If the source or target table is in a non-DB2 relational
database, the SQL statements are executed against the federated DB2 database.
The SQL statements are never executed against a non-DB2 database. The
run-time procedures of each type are executed together as a single transaction.
You can also define acceptable SQLSTATEs for each statement.
Use the ASNDONE exit routine if you want to manipulate data after each set
completes (rather than after a specific set completes).
For example, assume that you have existing source table (SRC.TABLE) and
target table (TGT.TABLE):
CREATE TABLE SRC.TABLE (SRC_COL1 CHAR(12) NOT NULL, SRC_COL2 INTEGER,
SRC_COL3 DATE, SRC_COL4 TIME, SRC_COL5 VARCHAR(25))
Use the following steps to map the desired target table using computed
columns during subscription:
1. Use the Replication Center to map SRC_COL1 from the source table to
TGT_COL1 in the target table. Since these columns are compatible, you do
not have to use an expression to map one to the other.
2. Use the expression COALESCE(SRC_COL2, 0) to compute the column
values and map to provide TGT_COL2. Because SRC_COL2 is nullable
and TGT_COL2 is NOT NULL, you must perform this step to ensure that
a NOT NULL value is provided for TGT_COL2.
3. Use the expression TIMESTAMP(CHAR(SRC_COL3) CONCAT
CHAR(SRC_COL4)) to compute the column values and map to provide
TGT_COL3. This column expression provides data to map to the
timestamp column in the target database.
4. Use the expression SUBSTR(SRC_COL5, 1,5) to compute the column
values and map to provide TGT_COL4.
You have the option in the Replication Center to run a generated SQL script
immediately or to save the generated SQL script as a task or to a file and run
the script at a later time. Even if you choose to run the SQL from the
Replication Center, you might also want to save it as a task or to a file for
future reference. For example, if you save the definitions of a large replication
subscription set in an SQL file, you can rerun the definitions as necessary.
When editing the generated SQL scripts, be careful not to change the
termination characters. Also, do not change the script separators if there are
multiple scripts saved to a file.
You might want to customize the SQL scripts for your environment to
perform the following tasks:
v Create multiple copies of the same replication action, customized for
multiple servers.
v Set the size of the table spaces or databases of the CD tables.
v Define site-specific standards.
v Combine definitions together and run as a batch job.
v Defer the replication action until a specified time.
v Create libraries of SQL scripts for backup, site-specific customization, or to
run stand-alone at distributed sites, such as for an occasionally-connected
environment.
v Edit create table and index statements to represent database objects.
v For Informix and other non-DB2 relational databases, ensure that tables are
created in the table spaces that you want.
v For Microsoft SQL Server, create control tables on an existing segment.
v Review and edit subscription-set member predicates as a way of defining
multiple subscription sets at one time. You can use substitution variables in
your predicates and resolve the variables with programming logic.
Procedure:
Use one of the following methods to run the files containing SQL scripts from
a DB2 command line:
v Use this command if the SQL script has a semicolon ( ; ) as a termination
character:
db2 -tvf filename
v Use this command if the SQL script has some other character as the
delimiter (in this example, as in heterogeneous replication, the pound sign (
# ) is the termination character):
db2 -td# -vf filename
Recommendation: Always read the administration log file before running any
scripts.
Important: The Capture program does not capture any changes made by
some DB2 utilities, because the utilities do not log changes in a way that is
visible to the Capture program.
Notes:
| 1. The Capture control server is the value of the DB2DBDFT environment variable for
| Windows and UNIX, if that variable is specified. There is no default value for
| z/OS.
2. You cannot change the default for the Capture schema. To use another Capture
schema, use the capture_schema start-up parameter.
3. Yes
4. No
5. If Capture starts as a Windows service, its capture path is \sqllib\bin.
6. The Capture program warm starts. It switches to cold start only if this is the first
time that the program is starting.
For more information about these operational parameters and their defaults, see
Starting the Capture program (UNIX, Windows, z/OS) on page 132.
Notes:
1. You cannot change the default for the Capture schema. To use another Capture
schema, specify the CAPCTLLIB parameter when you start the Capture program.
The default values for most other operational parameters are shipped and are
stored in the Capture parameters (IBMSNAP_CAPPARMS) table.
2. The CLNUPITV has two sub-parameters. By default, the Capture program prunes
soon after it starts running and again after every prune interval is reached (which,
by default, is every 24 hours).
3. By default, the Capture program warm starts.
For more information about these operational parameters and their defaults, see
Chapter 18, System commands for replication (OS/400), on page 367
Example (UNIX, Windows): Assume that you do not want to use the default
settings for the Capture commit interval for Capture schema ASNPROD.
1. Update the Capture parameters table for the ASNPROD Capture schema.
Set the commit interval to 60 seconds; therefore, when you start the
Capture program in the future, the commit interval will default to 60
seconds.
update asnprod.ibmsnap_capparms set commit_interval=60;
2. Eventually you might want to do some performance tuning so you decide
to try starting Capture using a lower commit interval. Instead of changing
the value in the Capture parameters table, you simply start the Capture
program with the commit interval parameter set to 20 seconds. While the
Capture program runs using a 20-second commit interval, you monitor its
performance.
asncap capture_server=srcdb1 capture_schema=asnprod commit_interval=20
3. You decide that you want to try an even lower commit interval. Instead of
stopping the Capture program, you submit a change parameters request
Important: The parameter that you are changing must immediately follow
the chgparms command.
4. You can continue monitoring the performance and changing the commit
interval parameter without stopping the Capture program. Eventually,
when you find the commit interval that meets your needs, you can update
the Capture parameters tables (as described in step 1 on page 130) so that
the next time you start the Capture program it uses the new value as the
default commit interval.
Example (OS/400): Assume that you do not want to use the default settings
for the Capture commit interval for Capture schema ASNPROD.
1. Update the Capture parameters table for the ASNPROD Capture schema.
Set the commit interval to 90 seconds; therefore, when you start the
Capture program in the future the commit interval will default to 90
seconds.
CHGDPRCAPA CAPCTLLIB(ASNPROD) FRCFRQ(90)
2. Eventually you might want to do some performance tuning so you decide
to try starting Capture using a lower commit interval. Instead of changing
the value in the Capture parameters table, you simply start the Capture
program with the commit interval parameter set to 45 seconds. As the
Capture program runs using a 45-second commit interval, you monitor its
performance.
STRDPRCAP CAPCTLLIB(ASNPROD) FRCFRQ(45)
3. You decide that you want to try an even lower commit interval. Instead of
stopping the Capture program, you submit a change parameters request
that sets the commit interval to 30 seconds. The Capture program
continues to run, only now it commits data every 30 seconds. (Note: On
OS/400, you cant set the commit interval to less than 30 seconds.)
OVRDPRCAPA CAPCTLLIB(ASNPROD) FRCFRQ(30)
4. Eventually, when you find the commit interval that meets your needs, you
can update the Capture parameters tables (as described in step 1) so that
the next time you start the Capture program it will use the new value as
the default commit interval.
Important: The Capture program does not capture any changes made by DB2
utilities, because the utilities do not log changes in a way that is visible to the
Capture program.
After you start the Capture program, the Capture program might not start
capturing data right away. It will start capturing data only after the Apply
program signals the Capture program that it has refreshed a target table fully.
Then the Capture program starts capturing changes from the log for a given
source table.
Prerequisites:
Before you start the Capture program, ensure that the following prerequisites
are met:
v Connections are configured to the source server and the Capture control
server.
v You have the proper authorization.
v The control tables are created for the appropriate Capture schema, and
registrations are defined.
v The replication programs are configured.
Procedure:
Use one of the following methods to start the Capture program on DB2 for
UNIX, Windows, and z/OS:
Replication Center
Use the Start Capture window to run the Capture program identified
Regardless of which procedure you use to start the Capture program, you can
select start-up parameters. The following sections discuss the start-up
parameters and recommend when to choose one value over another for each
parameter.
v add_partition (UNIX, Windows)
v autoprune (UNIX, Windows, z/OS) on page 134
v autostop (UNIX, Windows, z/OS) on page 134
v capture_path (UNIX, Windows, z/OS) on page 135
v capture_schema (UNIX, Windows, z/OS) on page 135
v capture_server (UNIX, Windows, z/OS) on page 136
v commit_interval (UNIX, Windows, z/OS) on page 136
v lag_limit (UNIX, Windows, z/OS) on page 137
v logreuse (UNIX, Windows, z/OS) on page 137
v logstdout (UNIX, Windows, z/OS) on page 138
v memory_limit (UNIX, Windows, z/OS) on page 138
v monitor_interval (UNIX, Windows, z/OS) on page 138
v monitor_limit (UNIX, Windows, z/OS) on page 138
v prune_interval (UNIX, Windows, z/OS) on page 139
v retention_limit (UNIX, Windows, z/OS) on page 140
v sleep_interval (UNIX, Windows, z/OS) on page 140
v startmode (UNIX, Windows, z/OS) on page 141
v term (UNIX, Windows, z/OS) on page 142
v trace_limit (UNIX, Windows, z/OS) on page 142
| add_partition (UNIX, Windows)
| Default: add_partition=n
| Set add_partition=y to have the Capture program read the log files. On each
| new partition, when the Capture program is started in the warm start mode,
| Capture will read the log file starting from the first log sequence number
| (LSN) that DB2 used after the first database CONNECT statement is issued
| for the DB2 instance.
autoprune (UNIX, Windows, z/OS)
Default: autoprune=y
If you start Capture with autopruning on, set the prune interval to optimize
the pruning frequency for your replication environment. See prune_interval
(UNIX, Windows, z/OS) on page 139 for details.
The Capture program uses the following parameters to determine which rows
are old enough to prune:
v retention_limit (UNIX, Windows, z/OS) on page 140 for CD, UOW, and
signal tables
v monitor_limit (UNIX, Windows, z/OS) on page 138 for monitor tables
v trace_limit (UNIX, Windows, z/OS) on page 142 for the Capture trace
table
For more information about pruning your tables, see Pruning your control
tables on page 245.
autostop (UNIX, Windows, z/OS)
Default: autostop=n
You can change the Capture path to specify where you want the Capture
program to store its files. You can specify a path name, for example:
/home/db2inst/capture_files. On z/OS operating systems, you can specify
either a path name or a High Level Qualifier(HLQ), such as //CAPV8. When
you use a HLQ, sequential files are created that conform to the file naming
conventions for z/OS sequential data set file names. The sequential data sets
are relative to the user ID that is running the progam. Otherwise these file
names are similar to those stored in an explicitly named directory path, with
the HLQ concatenated as the first part of the file name. For example,
sysadm.CAPV8.filename.
capture_schema (UNIX, Windows, z/OS)
Default: capture_schema=ASN
If you already set up another schema, you can start the Capture program by
specifying that schema using the capture_schema parameter. See Creating
multiple sets of Capture control tables on page 28 for instructions.
The lag_limit parameter represents the number of minutes that the Capture
program can lag in processing records from the DB2 log.
By default, if log records are older than 10 080 minutes (seven days), the
Capture program will not start unless you specify a value for the startmode
parameter that allows the Capture program to switch to a cold start.
If the Capture program will not start because the lag limit is reached, you
should determine why the Capture program is behind in reading the log. If
you are in a test environment, where you have no practical use for the lag
limit parameter, you might want to set the lag limit higher and try starting
the Capture program again. Alternatively, if you have very little data in the
source table in your test environment, you might want to cold start the
Capture program and fully refresh the data in all the target tables.
logreuse (UNIX, Windows, z/OS)
Default: logreuse=n
On UNIX and Windows operating systems, the name of the log file is
db2instance.capture_server.capture_schema.CAP.log. For example,
DB2INST.SRCDB1.ASN.CAP.log.
On the z/OS operating system, the file name is similar except that it does not
contain a DB2 instance name. For example, SRCDB1.ASN.CAP.log. This file is
stored in the directory that is specified by the capture_path parameter. If the
capture_path parameter is specified as a High Level Qualifier (HLQ), the file
naming conventions of z/OS sequential data set files apply; therefore, the
capture_schema name that is used to build the log file name is truncated to
the first 8 characters of the name.
The logstdout parameter is available only if you use the asncap command, it
is not available in the Replication Center.
You can monitor the memory limit by using the Replication Alert Monitor.
You can also use the data in the CAPMON table to determine the number of
source system transactions spilled to disk due to memory restrictions. Sum the
values in the TRANS_SPILLED column of the CAPMON table.
monitor_interval (UNIX, Windows, z/OS)
Default: monitor_interval=300
By default, the Capture program inserts rows into the Capture monitor table
every 300 seconds (5 minutes). This operational parameter works in
conjunction with the commit interval. If you are interested in monitoring data
at a granular level, use a monitor interval that is closer to the commit interval.
monitor_limit (UNIX, Windows, z/OS)
Default: monitor_limit=10080
The prune_interval parameter specifies how often the Capture program tries
to prune old rows from some of its control tables. This parameter is valid only
if autoprune=y.
By default, the Capture program prunes the CD and UOW tables every 300
seconds (five minutes). If the tables are not pruned often enough, the table
space that they are in can run out of space, which forces the Capture program
to stop. If they are pruned too often or during peak times, the pruning can
interfere with application programs running on the same system. You can set
the optimal pruning frequency for your replication environment. Performance
will generally be best when the tables are kept small.
Before you lower the prune interval, ensure that data is being applied
frequently so that pruning can occur. If the Apply program is not applying
data frequently, it is useless to set the prune interval lower because the Apply
program must replicate the data to all targets before the CD and UOW tables
can be pruned.
The prune interval determines how often the Capture program tries to prune
the tables. It works in conjunction with the following parameters, which
determine when data is old enough to prune: trace_limit, monitor_limit,
retention_limit. For example, if the prune_interval is 300 seconds and the
trace_limit is 10080 seconds, the Capture program will try to prune every 300
seconds. If it finds any rows in the trace table that are older than 10080
minutes (7 days), it will prune them.
For more information about pruning your tables, see Pruning your control
tables on page 245.
The retention_limit parameter determines how long old data remains in the
CD, UOW, and signal (IBMSNAP_SIGNAL) tables before becoming eligible
for retention limit pruning.
Your target tables must be refreshed to synchronize them with the source if
any of the rows that are pruned are candidates for replication but for some
reason they were not yet applied to the target table. You can avoid a full refresh
from happening by using higher retention limits; however, your CD and
UOW tables will grow and use space on your system.
For details about pruning your control tables, see Pruning your control
tables on page 245.
sleep_interval (UNIX, Windows, z/OS)
Default: sleep_interval=5
The sleep interval is the number of seconds that the Capture program waits
before it reads the log again after it reaches the end of the log and the buffer
is empty. For data sharing on the z/OS operating system, the sleep interval
represents the number of seconds that the Capture program sleeps after the
buffer returns less than half full.
By default, the Capture program sleeps 5 seconds. Change the sleep interval if
you want to reduce the overhead of the Capture program reading the log. A
You can start Capture using one of the following start modes:
Warmsi (warm start, switch initially to cold start)
The Capture program warm starts; except if this is the first time
youre starting the Capture program then it switches to cold start. Use
this start mode if you want to ensure that cold starts only happen
when you start the Capture program initially.
Warmns (warm start, never switch to cold start)
The Capture program warm starts. If it cant warm start, it does not
switch to cold start. When you use warmns in your day-to-day
replication environment, you have an opportunity to repair any
problems (such as unavailable databases or table spaces) that are
preventing a warm start from occurring. Use this start mode to
prevent a cold start from occurring unexpectedly. When the Capture
program warm starts, it resumes processing where it ended. If errors
occur after the Capture program started, the Capture program
terminates and leaves all tables intact.
Tip: You cannot use warmns to start the Capture program for the first
time because there is no warm start information when you initially
start the Capture program. Use the cold startmode the first time you
start the Capture program, then use the warmns startmode. If you do
not want to switch startmodes, you can use warmsi instead.
Warmsa (warm start, always switch to cold as necessary)
If warm start information is available, the Capture program resumes
processing where it ended in its previous run. If the Capture program
cannot warm start, it switches to a cold start. Usually you do not
want to switch to a cold start because that requires all your target
tables to be refreshed.
Cold During cold start, the Capture program deletes all rows in its CD
tables and UOW table during initialization. All subscription sets to
these replication sources are fully refreshed during the next Apply
processing cycle (that is, all data is copied from the source tables to
the target tables). If the Capture program tries to cold start but you
disabled full refresh, the Capture program will start, but the Apply
program will fail and will issue an error message.
You rarely want to explicitly request that the Capture program
performs a cold start. Cold start is necessary only the first time the
Capture program starts, and warmsi is the recommended start mode.
The term parameter determines how the status of DB2 affects the operation of
the Capture program.
Use term=n if you want the Capture program to wait for DB2 to start if DB2
is not active. If DB2 quiesces, Capture does not terminate; it remains active
but it does not use the database.
trace_limit (UNIX, Windows, z/OS)
Default: trace_limit=10 080
The trace_limit specifies how old the rows must be in the Capture trace
(IBMSNAP_CAPTRACE) table before they are pruned.
After you start the Capture program, the Capture program might not start
capturing data right away. It will start capturing data only after the Apply
program signals the Capture program to start capturing changes from the log
for a given source table.
Prerequisites:
Before you start the Capture program, follow the instructions in Chapter 2,
Setting up for replication, on page 17 to ensure that the following
prerequisites are met:
Procedure:
Use one of the following methods to start the Capture program on OS/400:
Replication Center
Use the Start Capture window to run the Capture program identified
by a Capture schema on a selected Capture control server that is in
the Replication Center object tree. See the Replication Center help for
details.
STRDPRCAP system command (OS/400)
See STRDPRCAP: Starting Capture (OS/400) on page 456 for
command syntax and parameter descriptions.
On UNIX, Windows, and z/OS, you can change the following Capture
parameters while the Capture program is running:
v Autoprune
v Autostop
v Commit_interval
v Lag_limit
v Logreuse
v Logstdout
v Memory_limit
v Monitor_interval
v Monitor_limit
v Prune_interval
v Retention_limit
v Sleep_interval
v Term
On OS/400, you can override the values for the following operational
parameters for a given Capture schema:
v CLNUPITV
v FRCFRQ
v MEMLMT
v MONLMT
v MONITV
v PRUNE
v RETAIN
v TRCLMT
When you change the values, the effects might not be immediate for all
parameters.
Prerequisites:
The Capture program with the specific Capture schema must be started.
Procedure:
Use one of the following methods to see the current values for the parameters
and to change them for the current session:
Replication Center
In the Replication Center, use the Change Operational Parameters
window while the Capture program is running. See the Replication
Center help for details.
| chgparms system parameter (UNIX, Windows, z/OS)
See asnccmd: Operating Capture (UNIX, Windows, z/OS) on page
336.
OVRDPRCAPA system command (OS/400)
See OVRDPRCAPA: Overriding DPR capture attributes (OS/400) on
page 434.
The Capture program reads this table only during startup; therefore, you
should stop and start the Capture program if you want the Capture program
to run with the new settings. Changing the Capture parameters table while
the Capture program is running and reinitializing the Capture program will
not change the operation of the Capture program. See Chapter 23, Table
structures, on page 491 for descriptions of the columns in this table.
Procedure:
Use one of the following methods to change the global operating parameters
that are used by the Capture program and are stored in the Capture
parameters (IBMSNAP_CAPPARMS) table:
Replication Center
In the Replication Center, use the Manage Capture Parameters
window to view or change any of the values in the Capture
parameters table. See the Replication Center help for details.
CHGDPRCAPA system command (OS/400)
See CHGDPRCAPA: Changing DPR Capture attributes (OS/400) on
page 410.
The parameter changes take effect only after you stop and start the Capture
program.
OS/400: If you choose to reorganize the UOW table and all the CD tables that
were open at the time that the Capture program stopped, the Capture
program needs time to shut down (it does not shut down immediately).
Prerequisites:
The Capture program with the specific Capture schema must be started.
Procedure:
If you stop or suspend the Capture program during pruning, pruning is also
suspended. When you resume or restart the Capture program, pruning
resumes based on the autoprune parameter.
You do not need to stop the Capture program to drop a registration. Always
deactivate the registration before you drop it. For details, see Stop capturing
changes for registered objects on page 202.
Prerequisites:
The Capture program with the specific Capture schema must be started.
Procedure:
Use one of the following methods to suspend the Capture program while it is
running:
Replication Center
| In the Replication Center, use the Suspend Capture window to
| suspend the Capture program. See the Replication Center help for
details.
If you stop or suspend the Capture program during pruning, pruning is also
suspended. When you resume or restart the Capture program, pruning
resumes based on the autoprune parameter.
Prerequisites:
The Capture program with the specific Capture schema must be suspended.
Procedure:
If you stop or suspend the Capture program during pruning, pruning is also
suspended. When you resume or restart the Capture program, pruning
resumes based on the autoprune parameter.
Reinitializing Capture
Reinitialize the Capture program if you change any attributes of existing
registered objects while the Capture program is running. For example, if you
change the CONFLICT_LEVEL, CHGONLY, RECAPTURE,
CHG_UPD_TO_DEL_INS values in the register (IBMSNAP_REGISTER) table.
For Capture on OS/400, reinitialize is also needed to start capturing data for a
journal that was not being captured previously.
Prerequisites:
Procedure:
Use one of the following methods to reinitialize the Capture program while its
running:
Replication Center
| In the Replication Center, use the Reinitialize Capture window to
| reinitialize the Capture program. See the Replication Center help for
details.
asnccmd reinit system command
See Chapter 17, System commands for replication (UNIX, Windows,
z/OS), on page 317.
INZDPRCAP system command
See INZDPRCAP: Reinitializing DPR Capture (OS/400) on page
432.
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
v Chapter 20, Using the Windows Service Control Manager to issue system
commands (Windows), on page 479
Related reference:
v asnscrt: Creating a DB2 Replication Service to start Capture, Apply, or the
Replication Alert Monitor (Windows only) on page 353
v asnccmd: Operating Capture (UNIX, Windows, z/OS) on page 336
v asncap: Starting Capture (UNIX, Windows, z/OS) on page 329
v ENDDPRCAP: Stopping Capture (OS/400) on page 420
v STRDPRCAP: Starting Capture (OS/400) on page 456
| Notes:
| 1. If Apply starts as a Windows service, its path is sqllib\bin
| 2. The Apply control server is the value of the DB2DBDFT environment variable, if
| specified. For UNIX and Windows operating systems only.
| 3. no
| 4. The DB2 subsystem name can be a maximum of four characters. This parameter is
| required. The DB2 subsystem name is only applicable to z/OS operating systems.
| 5. yes
| 6. On z/OS operating systems, the default is MEM.
| For more information about these operational parameters and their defaults, see
| Starting the Apply program (UNIX, Windows, z/OS) on page 151.
|
|
| Changing operational parameters for the Apply program
| You can change the default values for the operational parameters to values
| that you typically use in your environment. You can also override these
| default values when you start the Apply program.
| Setting new default values in the IBMSNAP_APPPARMS table
|
| Example (UNIX, Windows): Assume that you do not want to use the default
| settings for errwait for the Apply qualifier ASNPROD. Update the Apply
| parameters table for the ASNPROD Apply qualifier. Set the errwait interval to
| 600 seconds.
| update asn.ibmsnap_appparms set errwait=600 where apply_qual=ASNPROD;
|
Starting the Apply program (UNIX, Windows, z/OS)
You can start an instance of the Apply program to begin applying data to
your targets.
After you start the Apply program, it runs continuously (unless you used the
copyonce start-up parameter) until one of the following events occurs:
v You stop the Apply program using the Replication Center or a command.
v The Apply program cannot connect to the Apply control server.
v The Apply program cannot allocate memory for processing.
Prerequisites:
Before you start the Apply program, follow the instructions in Chapter 2,
Setting up for replication, on page 17 to ensure that your system is set up
correctly:
Procedure:
Regardless of which procedure you use to start the Apply program, you must
set up the startup parameters. The following sections discuss the start-up
parameters and recommend when to choose one value over another for each
parameter.
v apply_path (UNIX, Windows, z/OS) on page 153
The Apply path is the directory where the Apply program stores its log and
work files. By default, the Apply path is the directory where you start the
program. You can change the Apply path to store the log and work files
elsewhere (for example /home/db2inst/apply_files on an AIX system). Keep
track of what directory you choose because you might need to go to this
| directory to access the Apply log file. On z/OS operating systems, see the
| SASNSAMP(ASNSTRA) job for information on how you can change the
| Apply path.
Important: Make sure that the directory that you choose has enough space for
the temporary files used by the Apply program. For details, see Planning
space requirements for spill files for the Apply program on page 10.
Starting instances of Apply on one Windows system: When you start the
Apply program using either the Replication Center or the asnapply command,
you must specify the Apply path if you have two or more Apply qualifiers
that are identical except for their capitalization. File names on Windows
systems are not case-sensitive. For example, assume that you have three
Important: The Apply qualifier is case-sensitive and the value that you enter
must match the value of the APPLY_QUAL column in the subscription sets
(IBMSNAP_SUBS_SET) table.
If you have more than one Apply qualifier defined, you can start another
instance of the Apply program. Each instance of the Apply program that you
start will process different subscription sets that are represented in the same
Apply control server. For example, assume that you have two subscription
sets defined and each set has a unique Apply qualifier: APPLY1 and APPLY2.
You can start two instances of the Apply program (one for each Apply
qualifier), and each instance uses the control tables on the Apply control
server called CNTRLSVR. Each instance of Apply processes its own
subscription sets independently, providing better performance than if a single
instance of Apply processes all the sets.
control_server (UNIX, Windows, z/OS)
Default (UNIX, Windows): The value of the DB2DBDFT environment
variable, if available
The Apply control server is the server on which the subscription definitions
and the Apply control tables reside. Specify only one control server per Apply
qualifier. If you do not specify a value, the Apply program will start on the
default server. The default depends on your operating system.
If the Apply program cannot connect to the control server, the Apply program
terminates. If it cant connect to other servers, it does not terminate. In this
case it issues an error message and continues processing.
copyonce (UNIX, Windows, z/OS)
Default: copyonce=n
The copyonce parameter determines the copy cycle for the Apply program.
Typically you want to start the Apply program using copyonce=n because
you want the Apply program to continue running and processing eligible
subscriptions.
If you are running the Apply program from a dial-in environment that is
occasionally connected to the network, use copyonce=y instead of
copyonce=n. You might also want to use copyonce=y if you are running the
Apply program in a test environment.
Tip: Use sleep=n instead of copyonce=y if you want the Apply program to
process each subscription set multiple times, as long as the set is eligible and
data is available for replication. Copyonce=y processes each set only once
even if there is more data to replicate.
db2_subsystem (z/OS)
The db2_subsystem parameter specifies the name of the DB2 subsystem, if
you are running Apply on z/OS. The DB2 subsystem name that you enter can
be a maximum of four characters. There is no default for this parameter. This
parameter is required.
delay (UNIX, Windows, z/OS)
Default: delay=6 seconds
The delay parameter sets an amount of time in seconds that the Apply
program waits at the end of the Apply cycle.
By default, during continuous replication (that is, when your subscription set
uses sleep=0 minutes), the Apply program waits 6 seconds after a
subscription set is processed successfully before retrying the subscription set.
Use a non-zero delay value to save CPU cycles when there is no database
activity to be replicated. Use a lower delay value for low latency.
The inamsg parameter specifies whether or not the Apply program issues a
message when it becomes inactive.
The loadxit parameter specifies whether or not the Apply program should
refresh target tables using the ASNLOAD exit routine.
By default, the Apply program does not use the ASNLOAD exit routine to
refresh target tables (loadxit=n). Use loadxit=y if you want the Apply
program to invoke the ASNLOAD exit routine to refresh target tables.
Consider using the ASNLOAD exit if there is a large amount of data to be
copied to the target tables during a full refresh. For information about when
The Apply program stores operational information in a log file. On UNIX and
Windows, the name of the log file is
db2instance.control_server.apply_qualifier.APP.log. On the z/OS operating
system, the file name is similar except it does not contain the DB2 instance
name.
The parameter specifies whether to append to the log file or to overwrite it.
By default, the Apply program appends messages to the log file (logreuse=n)
each time that you start the Apply program. Keep the default if you want the
history of the messages that are issued by the Apply program. In the
following situations you might want to use logreuse=y, where the Apply
program deletes the log and re-creates the log when it starts:
v The log is getting large, and you want to clean out the log to save space.
v You dont need the history that is stored in the log.
logstdout (UNIX, Windows, z/OS)
Default: logstdout=n
The logstdout parameter is available only if you use the asnapply command;
logstdout is not available in the Replication Center.
The notify parameter specifies whether the Apply program notifies the
ASNDONE exit routine after it processes a subscription.
By default, the Apply program does not notify the ASNDONE exit routine
after subscription processing completes. If you specify notify=y, after the
By default, the Apply program is optimized for many subscription sets. The
Apply program reads the information from the replication control tables at the
beginning of each copy cycle. If you have one subscription set for the Apply
qualifier, start the Apply program using opt4one=y so that the Apply
program caches in memory information about the subscription set members
and columns and reuses it. When you optimize the Apply program for one
subscription set, the Apply program uses less CPU, and you improve
throughput rates.
Important: When you use opt4one=y and you add a member to a set or
otherwise modify a set, you must stop the Apply program and start it again
so that the Apply program picks up the changes in the control tables.
pwdfile (UNIX, Windows)
Default: pwdfile=asnpwd.aut
If your data is distributed across servers, you can store user IDs and
passwords in an encrypted password file so that the Apply program can
access data on remote servers. For more information, see Storing user IDs
and passwords for replication (UNIX, Windows) on page 26.
sleep (UNIX, Windows, z/OS)
Default: sleep=y
The sleep parameter specifies whether the Apply program continues running
in sleep mode or terminates after it processes eligible subscription sets.
By default, the Apply program starts with sleep=y. It checks for eligible
subscription sets. If it finds an eligible subscription set, it processes it and
continues looking for another eligible set. Apply continues to process eligible
sets if it finds them. When it cannot find any more eligible sets, the Apply
program continues running in sleep mode and it wakes up periodically to
check if any subscription sets are eligible. Usually you want to start the Apply
When you start the Apply program with sleep=n, the Apply program checks
for eligible subscription sets and processes them. It continues processing
eligible subscription sets until it cant find any more eligible sets, and it
repeats the process for eligible sets until there is no more data to replicate;
then, the Apply program terminates. Typically you want to use sleep=n in a
mobile environment or in a test environment where you want the Apply
program to run only if it finds eligible subscription sets, and then you want it
to terminate. You dont want the Apply program to wait in sleep mode and
wake up periodically to check for more eligible sets. In these environments
you want to control when Apply runs rather than have it run endlessly.
Apply retrieves data from the source tables and places it in a spill file on the
system where the Apply program is running.
On UNIX and Windows operating systems, the only valid setting for spillfile
is disk because spill files are always on disk in the location specified by the
apply_path parameter.
On z/OS operating systems, including USS, the spill file is stored in memory
| by default. If you specify to store the spill file on disk, the Apply program
| uses the specifications on the ASNASPL DD statement to allocate spill files. If
| the ASNASPL DD statement is not specified, it uses VIO.
| sqlerrcontinue (UNIX, Windows, z/OS)
Default: sqlerrcontinue=n
The sqlerrcontinue parameter specifies how the Apply program should react
to certain SQL errors.
By default, when the Apply program encounters any SQL error, it stops
processing that subscription set and generates an error message. Typically you
would use the default in your production environment.
Before you start the Apply program using the sqlerrcontinue=y option, you
must create the apply_qualifier.sqs file and store it in the directory from which
you invoke the Apply program. List up to 20 five-byte values, one after the
other, in the file. If you change the contents of this file when the Apply
program is running, stop the Apply program and start it again so that it
recognizes the new values.
Example: Assume that you want the Apply program to continue processing a
subscription set if a target table gets the following error (sqlstate/code):
42704/-803
Duplicate index violation
You would create an SQL state file that contains the following SQL state:
42704
If the SQL state is returned when updating the target table, the Apply
program applies the changes to the other target tables within the set and
creates an error file indicating both the error and the rejected rows.
The term parameter determines how the status of DB2 affects the operation of
the Apply program.
Use term=n if you want the Apply program to wait for DB2 to start, if DB2 is
not active. On the z/OS operating system, if DB2 quiesces and Apply is
By default, when the Apply program starts, it appends entries to the Apply
trail table. This table contains the history of operations for all Apply instances
at the Apply control server. It is a repository of diagnostic and performance
statistics. Keep the default if you want the history of updates. In the following
situations you might want the Apply program to empty the Apply trail table
when it starts instead of appending to it (trlreuse=y):
v The Apply trail table is getting too large, and you want to clean it out to
save space.
v You dont need the history that is stored in the table.
Tip: Instead of using trlreuse=y, you can use SQL processing after the Apply
program successfully completes a subscription set (where status=0) to delete
rows from the Apply trail table.
After you start the Apply program, it runs continuously unless one of the
following conditions are true:
v You started the program using the COPYONCE(*YES) start-up parameter.
v You specified ALWINACT(*NO) and there is no data to be processed.
v You stop the Apply program using the Replication Center or a command.
v The Apply program cannot connect to the Apply control server.
v The Apply program cannot allocate memory for processing.
Prerequisites:
Procedure:
When you start the Apply program, you can use these default settings for the
operational parameters:
| Table 8. Default settings for Apply operational parameters (OS/400)
| Operational parameter Description of (*value)
| USER (*CURRENT) The user who signed on to the system.
| JOBD (*LIBL/QZSNDPR) Product library name / job description.
| APYQUAL (*USER) Current user name (from above).
| CTLSVR (*LOCAL) Local RDB server name.
| TRACE (*NONE) Do not generate a trace.
| FULLREFPGM (*NONE) Do not run the ASNLOAD exit routine.
| SUBNFYPGM (*NONE) Do not run the ASNDONE exit routine.
| Only one row is allowed for each apply_qualifier. If you want to change one or
| more of the default values, you can update columns instead of inserting rows.
| If you delete the row, the Apply program will still start using the shipped
| defaults, unless those defaults are overridden by the start-up parameters.
| The Apply program reads this table only during startup; therefore, you should
| stop and start the Apply program if you want the Apply program to run with
| the new settings. Changing the Apply parameters table while the Apply
| program is running will not change the operation of the Apply program. See
| Chapter 23, Table structures, on page 491 for descriptions of the columns in
| this table.
Prerequisites:
Procedure:
Use one of the following methods to stop an instance of the Apply program:
Replication Center
Use the Stop Apply window. See the Replication Center help for
details.
asnacmd stop system command (UNIX, Windows, z/OS)
See asnacmd: Operating Apply (UNIX, Windows, z/OS) on page
318 for details.
ENDDPRAPY system command (OS/400)
See ENDDPRAPY: Stopping Apply (OS/400) on page 416 for
details.
If you start the Apply program with the notify=y parameter, the Apply
program calls the ASNDONE exit routine after it finishes processing
subscriptions, regardless of whether the subscriptions were processed
successfully. The following list describes some examples of how you might
modify the ASNDONE exit routine to use it in your replication environment:
v Use the exit routine to examine the UOW table for rejected transactions and
initiate further actions (for example, send e-mail automatically to the
replication operator, issue a message, or generate an alert) if a rejected
transaction is detected.
v Use the exit routine to deactivate a failed subscription set so that the Apply
program avoids retrying that subscription set until it is fixed. To detect a
failed subscription set, modify the exit routine to look for STATUS= -1 in
the Apply trail (IBMSNAP_APPLYTRAIL) table. To deactivate the
subscription set, configure the exit routine so that it sets ACTIVATE=0 in
the subscription sets (IBMSNAP_SUBS_SET) table.
Procedure:
If you start the Apply program with the SUBNFYPGM parameter set to the
name of the ASNDONE exit routine, the Apply program calls the ASNDONE
exit routine after it finishes processing subscriptions, regardless of whether the
subscriptions were processed successfully. The following list describes some
examples of how you might modify the ASNDONE exit routine to use it in
your replication environment:
v Use the exit routine to examine the UOW table for rejected transactions and
initiate further actions (for example, send e-mail automatically to the
replication operator, issue a message, or generate an alert) if a rejected
transaction is detected.
v Use the exit routine to deactivate a failed subscription set so that the Apply
program avoids retrying that subscription set until it is fixed. To detect a
failed subscription set, modify the exit routine to look for STATUS= -1 in
the Apply trail (IBMSNAP_APPLYTRAIL) table. To deactivate the
subscription set, configure the exit routine so that it sets ACTIVATE=0 in
the subscription sets (IBMSNAP_SUBS_SET) table.
v Use the exit routine to manipulate data after it is applied for each
subscription set. (Alternatively, you can define run-time processing
statements using SQL statements or stored procedures that run before or
Procedure:
If an error occurs when the Apply program calls the ASNLOAD exit routine,
the Apply program issues a message, stops processing the current
subscription set, and processes the next subscription set.
Prerequisites:
Ensure that the following prerequisites are met before you use the ASNLOAD
exit routine:
v The target-table columns match both the order and data type of the source
tables.
v The target table contains only columns that are part of the replication
mapping.
| Restrictions:
| v On the z/OS operating system, the ASNLOAD exit routine calls the cross
| loader function that is available with the DB2 V7 (or higher) Utilities Suite.
| v On the Linux, UNIX, and Windows operating system, the ASNLOAD exit
| routine works with the export, import, and load utilities, including the
| crossloader. The crossloader is the default option used by the ASNLOAD
| exit if the source for a subscription-set member is actually a nickname, or if
| the target database is the same as the source database. The crossloader can
| also be used with DB2 data sources, if the following actions have been
| performed:
The following sections describe how to use the ASNLOAD exit routine on
various operating systems:
v Refreshing target tables with the ASNLOAD exit routine (UNIX,
Windows)
v Refreshing target tables with the ASNLOAD exit routine (z/OS) on page
169
v Refreshing target tables with the ASNLOAD exit routine (OS/400) on
page 172
Refreshing target tables with the ASNLOAD exit routine (UNIX, Windows)
The ASNLOAD exit routine offers many utility options, such as using the DB2
EXPORT utility with either the DB2 IMPORT utility or the DB2 LOAD utility,
or using the new LOAD FROM CURSOR utility. When you invoke the sample
exit routine, by default it chooses which utility to use based on the source
server, target server, and run-time environment.
You can use the compiled exit routine, you can configure its behavior by
customizing the replication configuration, or you can customize the exit code
itself. You can customize the replication configuration by either updating
columns in the subscription members (IBMSNAP_SUBS_MEMBR) table or by
updating a sample configuration file (asnload.ini).
Procedure:
To use the ASNLOAD routine as provided, start the Apply program using the
loadxit=y parameter.
These files are stored in the apply_path directory for the Apply instance that
invoked the ASNLOAD exit routine.
v asnload apply_qualifier.trc
This file contains trace information if the trace is turned on. The ASNLOAD
exit routine creates this file. If the file exists, information is appended to the
file.
v asnload apply_qualifier.msg
This file contains general exit failure, warning, and informational messages,
including load statistics. The ASNLOAD exit routine creates this file. If the
file exists, information is appended to the file.
v asnaEXPT apply_qualifier.msg
This file contains error, warning, or informational messages issued by the
DB2 EXPORT utility. The ASNLOAD exit routine creates this file. If the file
exists, information is appended to the file.
v asnaIMPT apply_qualifier.msg
This file contains error, warning, or informational messages issued by the
DB2 IMPORT utility. The ASNLOAD exit routine creates this file. If the file
exists, information is appended to the file.
v asnaLOAD apply_qualifier.msg
This file contains error, warning, or informational messages issued by the
DB2 LOAD utility. The ASNLOAD exit routine creates this file. If the file
exists, information is appended to the file.
Refreshing target tables with the ASNLOAD exit routine (z/OS)
The ASNLOAD exit routine calls the LOAD utility, which does cursor-based
fetches to get data from the source and loads the data to the target. The
Procedure:
To use the ASNLOAD routine as provided, start the Apply program using the
loadxit=y parameter.
| If you are replicating from a DB2 table to another DB2 table and the
| source and the target database are the same, or if you are replicating
| from a non-IBM source to a DB2 table where the registered source
| nickname is on the same database as the target database, no
| additional actions are needed to use the crossloader utility.
4 (UNIX and Windows only)
Use a combination of the EXPORT utility and the LOAD utility.
5 (UNIX and Windows only)
Use a combination of the EXPORT utility and the IMPORT utility.
On UNIX, and Windows operating systems, the configuration file must have
the file name asnload.ini. The ASNLOAD exit routine looks for this optional
configuration file in the apply_path directory. Edit the sample file
sqllib/samples/repl/asnload.ini and store it in the apply_path directory for
the Apply instance that invoked the ASNLOAD exit routine.
Refreshing target tables with the ASNLOAD exit routine (OS/400)
Use the exit routine instead of the Apply program to perform a full refresh
more efficiently. For example, if you are copying every row and every column
from a source table to a target table, you can design a full-refresh exit routine
that uses a Distributed Data Management (DDM) file and the Copy File
(CPYF) CL command to copy the entire file from the source table to the target
table.
Procedure:
2. Compile, link, and bind the program and place the executable in the
appropriate directory.
To avoid interference with the Apply program, compile the exit routine so
that it uses a new activation group (not the activation group of the caller).
You can compile the exit routine with a named activation group or with a
new activation group. To get better performance, use a named activation
group. With a named activation group, the exit routine must commit or
roll back changes as needed. The Apply program will not cause changes to
be committed or rolled back (unless it ends). The exit routine should either
explicitly commit changes, or it should be compiled to implicitly commit
changes when it completes. Any uncommitted changes when the exit
routine completes are not committed until either:
v The Apply program calls another exit routine with the same activation
group.
v The job started for the Apply program ends.
3. Start the Apply program with the FULLREFPGM parameter set to the
name of the ASNLOAD program.
When you start the Apply program, it uses the ASNLOAD exit routine
that you specified. If you want it to use another ASNLOAD exit routine,
end the Apply program and start it again.
When you run the ASNLOAD exit routine, it refreshes all the target tables,
table by table.
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
v Chapter 20, Using the Windows Service Control Manager to issue system
commands (Windows), on page 479
Use one of the following methods to check the current status of the replication
programs:
Replication Center (UNIX, Windows, z/OS)
Use the Query Status window to check the current status of the
Capture or Apply programs. (You cannot query the status of the
Replication Alert Monitor using the Replication Center.) See the
Replication Center help for details.
Command line (UNIX, Windows, z/OS)
v Capture program asnccmd system command, status parameter. See
asnccmd: Operating Capture (UNIX, Windows, z/OS) on page
336 for details.
v Apply program asnacmd system command, status parameter. See
asnacmd: Operating Apply (UNIX, Windows, z/OS) on page 318
for details.
v Replication Alert Monitor asnmcmd system command, status
parameter. See asnmcmd: Operating the Replication Alert Monitor
(UNIX, Windows, z/OS) on page 343 for details.
You can discern whether your programs are working correctly by the
messages you receive. Typically worker threads, administration threads, and
pruning threads are in a working state and are performing the tasks that they
were intended to perform. Serialization threads are typically in the waiting
state; they are global signal handlers and are usually waiting for signals. The
pruning thread prunes the CD tables and the following replication control
tables.
v Unit-of-work (IBMSNAP_UOW) table
v Capture trace (IBMSNAP_CAPTRACE) table
v Capture monitor (IBMSNAP_CAPMON) table
v Signal (IBMSNAP_SIGNAL) table
If the messages that you receive indicate that the program is working but you
find evidence in your environment to the contrary, you must do more
investigating. For example, if you query the status of the Apply program and
you find that the worker thread is working but you notice that data is not
being applied to the target tables as you expected, look in the Apply trail
(IBMSNAP_APPLYTRAIL) table for messages that might explain why the data
is not being applied. Perhaps there are some system resource problems
preventing the program from working.
If the messages you receive do not indicate a typical state, you might have to
take further action as described in Table 9.
Table 9. Suggested actions for problems related to status of processing threads
Status of processing Description and suggested action
thread
Exists The thread exists but cannot start. Contact IBM Software
Support.
Was started Investigate potential system resource problems, such as not
enough CPU.
Is initializing The thread is initialized but cannot work. Contact IBM
Software Support.
Checking the status of the Capture and Apply journal jobs (OS/400)
On DB2 for iSeries, use the Work with Subsystem Jobs (WRKSBSJOB) system
command to check the status of the journal jobs for the Capture and Apply
programs.
1. Enter the command:
WRKSBSJOB subsystem
Historical data is derived from the following control tables: Apply trail
(IBMSNAP_APPLYTRAIL), Apply trace (IBMSNAP_APPLYTRACE), Capture
You can select a range of time to identify how much data you want to
analyze. Specify the dates and times for both the beginning and the end of a
For example, from the Capture Messages window, you can review all the
error and warning messages that are recorded by the Capture program during
| one week. You can also print or save data to a file from the Capture Messages
| window.
Examining Capture program throughput
Use the Capture Throughput Analysis window to display the performance
results of a Capture program over a specific range of time. The Capture
program regularly records statistical information in the Capture monitor
(IBMSNAP_CAPMON) table, and during pruning it records pruning statistics
in the Capture trace (IBMSNAP_CAPTRACE) table. Using information from
these tables, the Capture Throughput Analysis window displays the calculated
results of the performance rates of four different tasks.
For example, from the Capture Throughput Analysis window, you can review
the average weekly performance of the Capture program throughput. To do
so, specify the dates and times for both the beginning and the end of a time
range, and then specify that the results be displayed as an average of the
calculated rates.
Displaying latency of data processed by the Capture program
Use the Capture Latency window to display the approximate length of time
between when data was updated at the source and when it was captured by
the Capture program. The elapsed time gives you an indication of the
currency of the data in those CD tables over time. This average latency is
derived from information the Capture monitor (CAPMON) table, which
derives its information from the register (IBMSNAP_REGISTER) table.
For example, using the values in Table 11, the current latency is 25 seconds:
10:30:25 - 10:30:00
The Capture latency changes as time goes by and the history of these changes
is stored in the Capture monitor (IBMSNAP_CAPMON) table. The Replication
Center uses the information in the Capture monitor table to calculate average
or historical latency. The formula for average latency is similar to the one used
for current latency; however, the MONITOR_TIME value is used instead of
the CURRENT_TIMESTAMP value. The MONITOR_TIME value is a
timestamp indicating when the Capture program inserted a row in the
Capture monitor table. You can show the average latency per second, minute,
| For example, from the Apply Messages window, you can review all the error
| and warning messages that are recorded by the Apply program during one
| week. You can also print or save data to a file from the Apply Messages
| window.
| Use the Apply Report window to check the success of a specific Apply
| program over a specific period of time by reviewing the data that was
| inserted into the Apply trail (IBMSNAP_APPLYTRAIL) table. The
| IBMSNAP_APPLYTRAIL table contains data about the execution of
| subscription sets, and includes the status of the subscription set, error
| messages, and the number of rows processed.
| In the Apply Report window, you can display the following data:
| v All subscription sets
| v Failed subscription sets
| v Successful subscription sets
| v Error summary per failed subscription set
| For example, from the Apply Report window, you can determine whether the
| Apply program successfully processed subscription sets during the last week.
| If there were subscription sets that could not be replicated, you can view the
| error messages issued by the Apply program for those sets. In addition, you
| can use the Apply Report window with the Apply Throughput Analysis
| window. After you use the Apply Report window to find out which sets were
| successfully replicated, you can use the Apply Throughput Analysis window
| to see the number of rows replicated and the length of time that replication
| took.
| You can also use the Apply Report window to display all the data from a
| particular row in the IBMSNAP_APPLYTRAIL table.
Examining Apply program throughput
Use the Apply Throughput Analysis window to examine the performance
statistics for a specific Apply qualifier. You can filter and group data without
From the End-to-End Latency window, for example, you can view the
approximate latency for a subscription set for each Apply cycle during a
range of time. You can also divide the time into intervals and display the
average latency for each interval.
The Replication Center uses the following formula to calculate the end-to-end
latency:
(ENDTIME - LASTRUN) + (SOURCE_CONN_TIME - SYNCHTIME)
where:
v ENDTIME is the time at which the Apply program finishes processing the
subscription set.
v LASTRUN is the time at which the Apply program starts processing a
subscription set.
v SOURCE_CONN_TIME is the time at which the Apply program connects to
the Capture control server to fetch data.
v SYNCHTIME is the time of the most current commit of data to the CD
tables by the Capture program.
Table 12. Example of values for calculating end-to-end latency
Parameter Column value
ENDTIME 2001102010:01:00
LASTRUN 2001102010:00:30
SOURCE_CONN_TIME 2001102010:00:32
SYNCHTIME 2001102010:00:00
For example, assume a particular subscription set has the values that are
shown in Table 12. Using the previous equation, the average end-to-end
latency for this subscription set is 62 seconds:
(10:01:00 - 10:00:30) + (10:00:32 - 10:00:00) = 62
| For example, from the Monitor Messages window, you can review all the
| error and warning messages that are recorded by the Monitor program during
| one week. You can also print or save data to a file from the Monitor Messages
| window.
The Replication Alert Monitor runs on DB2 UDB for UNIX, Windows, or
z/OS, and can monitor database servers on those operating systems as well as
on DB2 UDB for iSeries. For example, you might want to set up automatic
monitoring on a dedicated Windows server in your environment, and from
that Windows server you can run the Replication Alert monitor. The monitor
program can connect to all of your replication servers and monitor the activity
of all of the Capture and Apply programs on any operating system in your
enterprise. It stores information in monitor control tables on the Monitor
control server. A Monitor control server can be on DB2 UDB for UNIX,
Windows, or z/OS.
The Replication Alert Monitor can monitor the activity of the Capture and
Apply programs after you select the alert conditions that you want to monitor.
While the Replication Alert Monitor is running, it checks for those alert
conditions. It logs any detected alert conditions. You can set up contacts
(consisting of names and e-mail addresses), or groups of contacts, if you want
the Replication Alert Monitor to automatically notify those contacts by e-mail
when it detects an alert condition. You can also set up the monitor so that it
sends e-mail when an operational error occurs.
The Replication Alert Monitor does not monitor triggers associated with
non-DB2 relational databases used as sources in a federated database system.
The following sections describe how to use the Replication Alert Monitor for
automated monitoring of your replication environment:
Before you set up the monitor control tables, you must decide on your
monitoring strategy for your replication configuration. You can run a
Replication Alert Monitor on each server where you have replication
programs running (except on DB2 for iSeries servers), or you can define a
centralized Monitor control server. If you use a centralized Monitor control
server, it runs remotely from all of your replication programs, it obtains
information by performing remote connects, and it consolidates the
information in a central location. Evaluate the needs of your enterprise to
determine the appropriate monitoring configuration. For example, the
advantage of the centralized approach is its simple monitoring configuration
that consolidates data. The centralized approach also has its disadvantages: it
takes more time for the monitor to detect and report an alert condition, and
the monitor cannot detect problems if it loses connectivity with the remote
servers.
Procedure:
You can create Monitor control tables using the following method:
Replication Center
Use the Create Monitor Control Tables window. See the Replication
Center help for details.
You can drop Monitor control tables using the following method:
Replication Center
Use the Drop Monitor Control Tables window. See the Replication
Center help for details.
After you define contacts (by specifying the name and e-mail address of the
contact), you can group contacts as necessary. You group contacts by
specifying a name for the group (for example, DB2 administrators) and
selecting the contacts that you want to be part of that group.
Procedure:
To change the information for a defined contact or contact group use the
following method:
Replication Center
Use the Contact Properties window or the Contact Group Properties
window. See the Replication Center help for details.
To copy your contact information to another Monitor control server use the
following method:
Replication Center
Use the Copy Contacts and Contact Groups window. See the
Replication Center help for details.
These contacts are unique to the Replication Center. The Replication Center
does not recognize contacts that you created in the Task Center or the Health
Center.
Selecting alert conditions for the Replication Alert Monitor
You can use the Replication Alert Monitor to track the following information
or alert conditions:
Alert conditions for the status of the Capture or Apply programs
The Replication Alert Monitor can send an alert notification if a
Capture or Apply program terminates.
The Replication Alert Monitor can be used to monitor only Capture and
Apply programs whose control tables are at DB2 replication Version 8
architectural level or later. When you select alert conditions, you must provide
a Monitor qualifier.
The Replication Alert Monitor monitors the activity of the Capture and Apply
programs for all the alert conditions you specify, in the time intervals that you
specify when you start the Replication Alert Monitor. You can also change
alert conditions after the Replication Alert Monitor starts.
Procedure:
To select alert conditions for the Apply program or for subscription sets use
one of the following methods:
Replication Center
Use the Select Alert Conditions for Apply qualifiers or Subscription
Sets window, or the Properties window. See Replication Center help
for details.
Prerequisites:
Procedure:
To start the Replication Alert Monitor use one of the following methods:
You can start the Replication Alert Monitor to monitor more than one Capture
control server or Apply control server at a time. For example, you might
consider starting two Replication Alert Monitor programs to distribute the
workload among the Monitor control servers or to ensure that a
mission-critical application has a dedicated instance of the Replication Alert
monitor. For each instance of the Replication Alert Monitor, you must specify
a different Monitor qualifier. The Replication Alert Monitor runs in its own
processing thread, independently of the Capture and Apply programs.
The Monitor control server and the monitor qualifier are required to start the
Replication Alert Monitor. The following sections describe how you can
control the behavior of the Replication Alert Monitor when you start it:
v Specifying how the Replication Alert Monitor runs
v Selecting the output for log messages from the Replication Alert Monitor
on page 189
v Specifying prune intervals for data from the Replication Alert Monitor on
page 190
v Specifying notification criteria for selected alert conditions on page 191
runonce= n
When you start the Replication Alert Monitor, by default, it runs at intervals
to monitor any alert conditions that you selected. You can schedule the
Replication Alert Monitor to run hourly, at some other time interval, or even
just one time. Use the runonce parameter or the monitor_interval parameter
When you specify runonce=y, the Replication Alert Monitor checks one time
for all the alert conditions you selected and the monitor_interval parameter is
ignored. You can use runonce when you include in a batch process the
operation of the Replication Alert Monitor. For example, after the Apply
program completes, you can use runonce=y to determine if any subscription
sets failed. Then, if a subscription set did fail, the Replication Alert Monitor
sends notification to your contact person or group.
Selecting the output for log messages from the Replication Alert Monitor
Defaults:
logreuse= n
When you start the Replication Alert Monitor, it creates a log file in a
directory where it stores its work files and appends messages to that log file.
By default, the monitor_path directory is where you started the program. You
can change the monitor_path only when you start the Replication Alert
Monitor, not while it is operating. You can specify a different monitor_path
for the Replication Alert Monitor to store its log file.
By default, the Replication Alert Monitor appends messages to the log file,
even after the Replication Alert Monitor is restarted. Keep this default
(logreuse= n) if you want to maintain a history of messages in the program
log file. Ensure that there is enough space in the monitor_path directory for
the program log file to grow.
In some situations you might want the Replication Alert Monitor to delete the
log and recreate it when it restarts. In these cases, specify the parameter
variable logreuse=y:
v The log is getting large and you want to clean out the log.
v You do not need the history stored in the log.
The logstdout parameter is available only if you use the asnmon command, it
is not available in the Replication Center. By default, the Replication Alert
Monitor sends messages to the log file only (logstdout= n). If you are
troubleshooting or actively monitoring the operation of the Capture or Apply
program, you can specify that the Replication Alert Monitor send messages to
standard output (logstdout=y).
Specifying prune intervals for data from the Replication Alert Monitor
Defaults:
autoprune=y
When the Replication Alert Monitor starts a new monitor cycle, it prunes the
Monitor alerts (IBMSNAP_ALERTS) table if any rows are eligible for pruning.
By default, the Replication Alert Monitor prunes the rows that are older than
10080 minutes (seven days). By changing the value for the alert_prune_limit
parameter, you can control how much old data you want to store in the table
by specifying how old the data must be before it is pruned from the table.
A lower prune limit saves space, but increases processing costs. A higher
prune limit requires more CD and UOW table space, but decreases processing
costs.
max_notifications_minutes=60 minutes
If the Replication Alert monitor detects any alert conditions that you selected,
it stores them. You can set up notification parameters to ensure that someone
is notified of the alert conditions automatically via e-mail.
The number of notifications you receive also depends on the values you set
for the max_notifications_minutes and max_notifications_per_alert
parameters.
By default, if an alert condition is met more than once, the Replication Alert
Monitor sends a maximum of three notifications for that alert condition in a
period of 60 minutes. Use the max_notifications_per_alert parameter to
specify the maximum number of notifications you want to receive if a
particular alert condition occurs within the time period specified by the
max_notifications_minutes parameter. Using these parameters ensures that
repeated notification is limited if an alert condition persists for a long period
of time before the problem is fixed.
To enable notification, you must also set the email_server parameter. Set the
value of this parameter to the address of an e-mail server using the SMTP
protocol.
The content of the e-mail notification depends on whether the e-mail address
you provided is for a pager. The following examples show the type of
information you can expect in each case, for one set of alerts. The e-mail that
is sent to non-pager devices shows the time when each alert occurred (at the
specific server), the number of times it occurred, and the associated message.
The e-mail that is sent to pagers is similar except it contains a summary of the
parameters that triggered the alert instead of a complete message. If an alert
occurred many times, the timestamp reflects the last time the alert occurred.
----------
MONQUAL - MONDB
| Alerts are grouped by Capture and Apply control servers when notifications
| are sent. If a server is both a Capture and an Apply Control server, all
| conditions for both Capture and Apply are checked during one connection to
| the server and all alerts for that server are grouped together.
If the size of the e-mail notification exceeds the limit for the type of e-mail,
the notification is sent in multiple e-mail notifications. The size of a regular
e-mail notification is limited to 1024 characters. For a pager e-mail address the
limit is 250 characters.
where:
v email_server is the address of an e-mail server using the SMTP protocol. This
server address is passed from the EMAIL_SERVER parameter specified in at
the start of the asnmon command.
v to-address is the e-mail address of the contact to be notified.
Prerequisites:
The Replication Alert Monitor with the specific monitor qualifier must be
started.
You can specify if you want the Replication Alert Monitor to obtain values for
the contacts, alert conditions, and the Replication Alert Monitor parameters
that you changed while the Replication Alert Monitor was operating. For
example, reinitialize the Monitor if you add a new e-mail address for a
contact while the Replication Alert Monitor is running.
Procedure:
To reinitialize the Replication Alert Monitor use one of the following methods:
Prerequisites:
The Replication Alert Monitor with the specific Monitor qualifier must be
started.
Procedure:
To stop the Replication Alert Monitor use one of the following methods:
Replication Center (UNIX, Windows, z/OS)
In the operations tree, right click the Monitor qualifier and select Stop
Monitor. See the Replication Center help for details.
asnmcmd system command (Windows, UNIX, z/OS)
See asnmcmd: Operating the Replication Alert Monitor (UNIX,
Windows, z/OS) on page 343 for details about the asnmcmd system
command, stop parameter.
Windows Services (Windows)
See Chapter 20, Using the Windows Service Control Manager to issue
system commands (Windows), on page 479 for details.
MVS console or TSO (z/OS)
See Chapter 19, Operating the replication programs (z/OS), on page
473 for details.
| If the Replication Alert Monitor is shut down while your Capture and Apply
| programs are running, the Monitor verifies whether alert conditions were met
| while the Monitor is down and issues alerts as needed.
If the Capture program is still running, you can determine its progress using
the following steps:
1. For each source table being captured, open its CD table.
2. In the last row of the CD table, note the hex value in the COMMITSEQ
column.
3. Look in the Unit-of-work (IBMSNAP_UOW) table for a row with the same
COMMITSEQ value. If no matching COMMITSEQ exists in the
IBMSNAP_UOW table, repeat the same process with the second-to-last
row in the CD table. Proceed backward through the CD table until you
find a match.
4. When you find a matching COMMITSEQ, note the value in the
LOGMARKER column of the UOW row. This is the timestamp of the
processed journal entry. All changes to the source table up to that time are
ready to be applied.
5. Use the Display Journal (DSPJRN) system command to determine how
many journal entries remain to be processed by the Capture program.
Direct the output to an output file (or to a printer for a printed report), as
shown in the following example:
DSPJRN FILE(JRNLIB/DJRN1)
RCVRNG(*CURCHAIN)
FROMTIME(timestamp)
TOTIME(*LAST)
JRNCDE(J F R C)
OUTPUT(*OUTFILE)
ENTDTALEN(1) OUTFILE(library/outfile)
Procedure:
Procedure:
1. Use the following method to change the attributes:
Replication Center
From the Registered Tables folder, right-click the registered table in
the contents pane and select Properties. See the Replication Center
help for details.
Tip: If you need to keep the Capture program active during this
procedure, insert a USER signal in the signal
(IBMSNAP_SIGNAL) table after stopping activity against the
source table. Wait for the Capture program to process the USER
signal.
The Capture program stops capturing changes for the source objects that have
been deactivated; however, the change-data (CD) tables, registration attributes,
and subscription sets that are associated with these source objects remain on
the system.
Before you deactivate a registered object, you should deactivate all of the
subscriptions sets that are associated with this registered object. This ensures
that your Apply programs will not interfere with the deactivation process by
automatically reactivating the object before you delete it or before you are
ready to reactivate it.
All subscription sets that are associated with the registered object are affected
when the object is deactivated and when DB2 replication stops capturing
changes for that object. If you want to continue running these subscription
sets, you must remove the subscription-set members that use this registered
object as a source from the deactivated subscription sets.
Restrictions:
You can deactivate only DB2 registered objects that are defined as Capture
program sources.
You cannot deactivate non-DB2 relational database objects that are used by
Capture triggers.
Procedure:
Reactivating registrations
If you temporarily deactivate your registration and associated subscription
sets and then want to reactivate the registration to begin recapturing data, you
would simply reactivate these subscription sets through the Replication
Center. The Capture program reactivates the registration after the Apply
program sends a CAPSTART signal.
Use the following procedure to correct these unexpected errors and to make
the registration eligible for reactivation.
Prerequisites:
Read the error messages that were generated by the Capture program
regarding this deactivated registration.
Procedure:
1. Change your registration by using the information contained in the error
messages.
2. From the Capture control server, run the following SQL script to reset the
STATE column in the IBMSNAP_REGISTER table:
UPDATE Schema.IBMSNAP_REGISTER
SET STATE = I
WHERE
SOURCE_OWNER = SrcSchema AND
SOURCE_TABLE = SrcTbl AND
SOURCE_VIEW_QUAL = SrcVwQual AND
STATE = S;
Example: Suppose that the source table for an active registration was
inadvertently altered to DATA CAPTURE NONE (and should be DATA
CAPTURE CHANGES). Also, suppose that this registration was defined with
STOP_ON_ERROR = N, which specifies that the Capture program will not
stop when it encounters errors. At the next restart or reinitialization of the
Capture program, the Capture program will recognize this incorrect condition
of the source table and will set the STATE column to S (Stopped) in the
register (IBMSNAP_REGISTER) table for this registration. You will receive an
error message when the Apply program tries to process the corresponding
subscription set, because the registration will be in a stopped state. You must:
v Correct the setting of the source table through SQL by submitting an
ALTER TABLE statement that resets the table option to DATA CAPTURE
CHANGES.
v Manually reset the registration from a stopped state to an inactive state,
using the above SQL script.
The Apply program will then perform a full refresh of the entire subscription
set.
Prerequisite:
Deactivate the source object first to ensure that the Capture program finishes
any current processing of this object.
Procedure:
Use one of the following methods to remove a registration for a source table
or view:
Replication Center
Use the Delete Registered Tables or Delete Registered Views window.
See the Replication Center help for details.
RMVDPRREG system command (OS/400)
See RMVDPRREG: Removing a DPR registration (OS/400) on page
440 for parameter descriptions and command syntax.
Prerequisites:
Before running the following SQL statements, familiarize yourself with your
DB2 replication control tables and with the subscription sets that are defined
on your system.
Determine the new Capture schema name. See Chapter 16, Naming rules for
replication objects, on page 315 for more information.
Verify that your Capture control server and all of the Apply control servers
that are associated with this Capture control server have been migrated to
Version 8 before you use this procedure.
Restriction:
You should not use this procedure if your source server is a non-DB2
relational database.
Procedure:
1. Use one of the following methods to create control tables for a new
Capture schema:
Replication Center (UNIX, Windows, z/OS)
Use the Create Replication Control Tables notebook. See the
Replication Center help for details.
CRTDPRTBL system command (OS/400)
See CRTDPRTBL: Creating the replication control tables
(OS/400) on page 415 for parameter descriptions and command
syntax.
2. Use one of the following methods to stop the Capture program that is
using the existing Capture schema. (Skip this step if you do not have a
Capture program running.):
Replication Center
Use the Stop Capture window. See the Replication Center help for
details.
asnccmd system command (UNIX, Windows, z/OS)
Use the stop parameter. See asnccmd: Operating Capture (UNIX,
Windows, z/OS) on page 336 for parameter descriptions and
command syntax.
ENDDPRCAP system command (OS/400)
See ENDDPRCAP: Stopping Capture (OS/400) on page 420 for
parameter descriptions and command syntax.
3. Use the following method to deactivate all associated subscription sets:
Replication Center
From the Subscription Sets folder, right-click the active
Repeat this step for each existing Capture control table, including some or
all of the following tables:
v IBMSNAP_CAPMON
v IBMSNAP_CAPPARMS
v IBMSNAP_CAPTRACE
v IBMSNAP_PRUNCNTL
v IBMSNAP_PRUNE_SET
v IBMSNAP_REG_EXT (OS/400 only)
v IBMSNAP_REGISTER
(You do not need to repeat this step for the IBMSNAP_CAPENQ [on
UNIX, Windows, z/OS] or the IBMSNAP_PRUNE_LOCK control table,
because there are no rows in these tables.)
Prerequisites:
Before you create a new subscription set, register the tables or views that you
want to use as sources.
Procedure:
| Procedure:
| The Apply program will perform a full refresh on any new members that are
| added to the set on the next Apply cycle. Replication changes to all target
| tables will continue on subsequent cycles. If you are running the Apply
| program with the opt4one variable set to y, you must stop and restart the
| Apply program before the new member is processed by Apply.
Note: If you set the opt4one Apply program parameter to y, your changes are
not recognized unless you stop and then restart the Apply program (UNIX,
Windows, z/OS).
Prerequisites:
Before running these SQL statements, familiarize yourself with the structure of
the DB2 replication control tables and with the subscription sets defined on
your system.
Determine the new subscription set name that you want to use.
Procedure:
1. Use the following method to deactivate the subscription set that you want
to change:
where Schema is the name of the Capture schema, NewSetName is the new
subscription set name, ApplyQual is the Apply qualifier, ExistSetName is the
existing name of the subscription set, and Target_Server is the database
location of the target tables.
5. For UNIX, Windows, z/OS: If you are running the Apply program with
opt4one set to y, stop and then restart the Apply program.
6. Reactivate the subscription set using the following method:
Replication Center
From the Subscription Sets folder, right-click the deactivated
subscription set in the contents pane and select Activate. See the
Replication Center help for details.
Prerequisites:
Before running these SQL statements, familiarize yourself with the structure of
the DB2 replication control tables and with the subscription sets defined on
your system.
Identify the subscription-set members of the subscription set that you want to
split, and determine the source and target tables associated with these
subscription-set members.
Procedure:
1. Use the following method to deactivate the subscription set that you
want to split:
Replication Center
From the Subscription Sets folder, right-click the active
subscription set in the contents pane and select Deactivate. See
the Replication Center help for details.
2. Use one of the following methods to create a new subscription set:
Replication Center
Use the Create Subscription Set notebook. See the Replication
Center help for details.
ADDDPRSUB system command (OS/400)
Use the SRCTBL(*NONE), TGTTBL(*NONE), and
ACTIVATE(*NO) parameter options. See ADDDPRSUB: Adding
a DPR subscription set (OS/400) on page 378 for parameter
descriptions and command syntax.
where Schema is the name of the Capture schema, ApplyQual is the Apply
qualifier, NewName is the name of the new subscription set that you are
creating, and Target_Server is the database location of the target tables.
5. From the Capture control server, run the following SQL statement to
copy information from the existing subscription set row to the new
subscription set row in the IBMSNAP_PRUNE_SET table:
where Schema is the name of the Capture schema, ApplyQual is the Apply
qualifier, ExistName is the name of the existing subscription set that is
being split, Target_Server is the database location of the target tables, and
NewName is the name of the new subscription set that you are creating.
6. From the Apply control server, run the following SQL statements to
change the subscription set name in the subscription members
(IBMSNAP_SUBS_MEMBR) and the subscription columns
(IBMSNAP_SUBS_COLS) tables for each subscription-set member that you
are moving into the new subscription set:
UPDATE ASN.IBMSNAP_SUBS_MEMBR
SET SET_NAME = NewName
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = ExistName AND
WHOS_ON_FIRST = Val AND
SOURCE_OWNER = SrcSchema AND
SOURCE_TABLE = SrcTbl AND
SOURCE_VIEW_QUAL = SrcVwQual AND
TARGET_OWNER = TgtSchema AND
TARGET_TABLE = TgtTbl;
UPDATE ASN.IBMSNAP_SUBS_COLS
SET SET_NAME = NewName
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = ExistName AND
WHOS_ON_FIRST = Val AND
TARGET_OWNER = TgtSchema AND
TARGET_TABLE = TgtTbl;
where NewName is the name of the new subscription set that you are
creating, ApplyQual is the Apply qualifier, ExistName is the name of the
existing subscription set being split, Val is either F or S, SrcSchema is the
source table schema, SrcTbl is the source table name, SrcVwQual is the
source-view qualifier for this source table, TgtSchema is the schema of the
target table, and TgtTbl is the target table name.
where NewName is the name of the new subscription set that you are
creating, ApplyQual is the Apply qualifier, ExistName is the name of
the existing subscription set being split, Val is either F or S, and
Stmt1, Stmt2, and Stmtn correspond to the numbers of the statements
that you are moving to the new subscription set.
b. Adjust the AUX_STMTS column values in the IBMSNAP_SUBS_SET
table to reflect the new count of statements for both subscription sets.
Renumber the statements to eliminate any duplicates, if necessary.
8. From the Capture control server, run the following SQL statement to
change the name of the subscription set in the pruning control
(IBMSNAP_PRUNCNTL) table for each subscription-set member that you
moved:
UPDATE Schema.IBMSNAP_PRUNCNTL
SET SET_NAME = NewName
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = ExistName AND
TARGET_SERVER = Target_Server AND
SOURCE_OWNER = SrcSchema AND
SOURCE_TABLE = SrcTbl AND
SOURCE_VIEW_QUAL = SrcVwQual AND
TARGET_OWNER = TgtSchema AND
TARGET_TABLE = TgtTbl;
where Schema is the name of the Capture schema, NewName is the name
of the new subscription set that you created in step 2, ApplyQual is the
Apply qualifier, ExistName is the name of the existing subscription set
that was split, Target_Server is the database location of the target tables,
SrcSchema is the source table schema, SrcTbl is the source table name,
SrcVwQual is the source-view qualifier for this replication source table,
TgtSchema is the target table schema, and TgtTbl is the target table name.
Prerequisites:
Before running these SQL statements, familiarize yourself with the structure of
the DB2 replication control tables and with the subscription sets defined on
your system.
Identify the Capture control server, target server, and Apply control server of
each subscription set that you want to merge. Verify that all of the
subscription sets that you want to merge were created with the same Capture
control server, target server, and Apply control server.
Restriction:
The two subscription sets that you want to merge must derive their source
data from the same Capture server and through the same Capture schema.
Wait until both subscription sets reach the same synchpoint and synchtime
as indicated in the subscription sets (IBMSNAP_SUBS_SET) table.
Important: The two subscription sets must have processed the source data
up to the identical synchpoint value to prevent a loss of data when the
subscription sets are merged.
Tip: If you do not want to stop the Capture program, insert a USER signal
in the signal (IBMSNAP_SIGNAL) table, and generate an event with the
END_SYNCHPOINT (in the subscriptions events
[IBMSNAP_SUBS_EVENT] table) set to the value of the SIGNAL_LSN
column in the IBMSNAP_SIGNAL table so that only the data up to that
end point is applied.
2. Use the following method to deactivate the two subscription sets:
Replication Center
From the Subscription Sets folder, right-click the two active
subscription sets in the contents pane and select Deactivate. See
the Replication Center help for details.
3. From the Apply control server, run the following SQL statement to delete
the row from the IBMSNAP_SUBS_SET table that corresponds to the
subscription set that you are moving into the other subscription set:
DELETE FROM ASN.IBMSNAP_SUBS_SET
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = Subset_To_Move AND
WHOS_ON_FIRST = Val;
where Schema is the name of the Capture schema, ApplyQual is the Apply
qualifier, Subset_To_Move is the name of the subscription set that you are
moving into another existing subscription set, and Target_Server is the
database location of the target tables.
5. From the Apply control server, run the following SQL statements to
change the name of the subscription set that you are moving to the name
of the other subscription set in the subscription members
(IBMSNAP_SUBS_MEMBR) and subscription columns
(IBMSNAP_SUBS_COLS) tables:
UPDATE ASN.IBMSNAP_SUBS_MEMBR
SET SET_NAME = Existing_Merged_Subset
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = Subset_To_Move AND
WHOS_ON_FIRST = Val;
UPDATE ASN.IBMSNAP_SUBS_COLS
SET SET_NAME = Existing_Merged_Subset
WHERE
APPLY_QUAL = ApplyQual AND
SET_NAME = Subset_To_Move AND
WHOS_ON_FIRST = Val;
If you have several subscription sets using the same Apply qualifier, you
might want to move some of the subscription sets to a new Apply qualifier to
balance the work loads of the Apply programs.
You must run the SQL statements in this procedure for each subscription set
that you want to move.
Before running these SQL statements, familiarize yourself with the structure of
the DB2 replication control tables and with the subscription sets defined on
your system.
Procedure:
1. Deactivate the subscription sets that you want to change using the
following method:
Replication Center
From the Subscription Sets folder, right-click the active
subscription sets in the contents pane and select Deactivate. See
the Replication Center help for details.
2. From the Apply control server, run the following SQL statements to
change the Apply qualifier of the subscription set in the subscription sets
(IBMSNAP_SUBS_SET), subscription members
(IBMSNAP_SUBS_MEMBR), and subscription columns
(IBMSNAP_SUBS_COLS) tables:
UPDATE ASN.IBMSNAP_SUBS_SET
SET APPLY_QUAL = NewApplyQual
WHERE
APPLY_QUAL = ExistApplyQual AND
SET_NAME = Name AND
WHOS_ON_FIRST = Val;
If you deactivated all the subscription sets associated with a registered object,
you should also deactivate the registered object to prevent the Capture
program from capturing data unnecessarily.
Procedure:
1. To ensure that the Apply program has completed any current processing
for the subscription set, deactivate the subscription set before you remove
it by using the following method:
Replication Center
From the Subscription Sets folder, right-click the active
subscription set in the contents pane and select Deactivate. See the
Replication Center help for details.
2. Use one of the following methods to remove a deactivated subscription
set:
Replication Center
Use the Delete Subscription Set window. See the Replication
Center help for details.
RMVDPRSUB system command (OS/400)
See RMVDPRSUB: Removing a DPR subscription set (OS/400)
on page 441 for parameter descriptions and command syntax.
Important: The Capture program continues capturing data and writing rows
to the change-data (CD) table even if you remove all subscription sets for the
registered object. To prevent this continued processing by the Capture
program, deactivate or remove the registered object after removing its
subscription sets.
For example, if you are replicating online transaction processing (OLTP) data
to a separately maintained data warehouse, you might want to keep the
Procedure:
This trigger fires each time that the IBMSNAP_SIGNAL table is updated by
the Capture program. When a SIGNAL_SUBTYPE column is updated to
USER APPLY EVENT SIGNAL, the trigger inserts a row into the
IBMSNAP_SUBS_EVENT table. This row indicates to the Apply program that
it must fetch and apply the work from the latest business day (which has
been committed prior to the SIGNAL_LSN value as computed by the Capture
program) after two minutes have elapsed.
| Creating journal signal tables for remote journaling
| On iSeries operating systems, a signal table is associated with each journal
| used for source tables. These tables are called journal signal tables and have
| the same structure as the global signal table schema.IBMSNAP_SIGNAL.
| Procedure:
Procedure:
All log records for the changing source table are processed by the Capture
program when it terminates.
2. Depending on your scenario, drop and re-create your source table, or
reorganize and compress your source table without set the
KEEPDICTIONARY option to YES.
3. If you dropped or altered replicated columns, you should now alter the
corresponding registrations and subscription sets that you created for this
source table. Such changes, if necessary, can be further coordinated with
the Apply program by waiting for the affected subscription sets to catch
up to the currently stopped Capture program. A subscription set is in
synch with the Capture program when the SYNCHPOINT column value
in the subscription sets (IBMSNAP_SUBS_SET) table is equal to the
MAX_COMMITSEQ column value in the Schema.IBMSNAP_RESTART
table.
Prerequisites:
Before using this procedure, verify that your Apply control tables have been
created in the target database.
Also, verify that all activity against the source database has been quiesced
before inserting the row into the IBMSNAP_SIGNAL table. However, do not
create the backup or image copy of the database tables until after you insert
the row into the IBMSNAP_SIGNAL table.
If your subscription sets are not typically configured for event processing,
then you must temporarily set your subscription sets to event-based timing.
Use the following SQL statement to insert a row into the subscription events
(IBMSNAP_SUBS_EVENT) table:
Procedure:
All log records for the source database are processed by the Capture
program when it terminates.
2. Run the source database backup or image copy utilities.
3. Use the value in the SIGNAL_LSN column from the IBMSNAP_SIGNAL
table row that you inserted as an END_SYNCHPOINT value in the
IBMSNAP_SUBS_EVENT table. This value alerts the Apply program that
all the data committed prior to the backup point has been collected by the
Capture program and that the Apply program should fetch and apply data
only up to the value of the SIGNAL_LSN column.
The subscription sets process all data up to the SIGNAL_LSN value.
You can resume all source database activity as soon as the Apply events have
been set and the source database backup or image copy utility activity is
complete. You can also start the Capture program. After the target database
backup or image copy utility activity is complete, you can change the
scheduling options of your subscription sets back to their original settings
(time-based, event-based, or both).
| On iSeries operating systems, you can send the STOP signal to stop a single
| journal job or to stop all the journal jobs. To stop a single journal job, insert
| the signal into the signal table designated for that journal (the
| IBMSNAP_SIGNAL_xxxx_yyyy table, where xxxx is the journal library and
| yyyy is the journal name. To stop all the journal jobs, insert the signal into
| table schema.IBMSNAP_SIGNAL. To stop a single journal job in a remote
| journal configuration, insert the signal into the journal signal table on the
| source server. See Creating journal signal tables for remote journaling on
| page 228 for a description of how to create journal signal tables in a remote
| journal configuration.
Performing a CAPSTART handshake signal outside of the Apply program
Before any subscription set can be used by the Apply program to fetch and
apply changes from the CD tables, there must be a handshake (synchronized
communication) between the Capture and Apply programs of each
subscription-set member in that subscription set.
Procedure:
Note: Run this SQL INSERT statement before performing a full refresh of the
subscription-set member, if necessary.
The Capture program acts on this signal table log record after the Capture
program finds this record on the database recovery log and only when the
Capture program finds the corresponding commit record for this insert,
verifying that this event was committed.
Procedure:
The Capture program acts on this signal table log record after the Capture
program finds this record on the database recovery log and only when the
Capture program finds the corresponding commit record for this insert,
verifying that this event was committed.
If the registered table is in use, the Capture program clears the memory
associated with this registration and inactivates the registration (by setting
the STATE column in the IBMSNAP_REGISTER table to I). The Capture
program then stops capturing changes for this registered table.
| On iSeries operating systems, you can also send a CAPSTOP signal to stop
| capturing changes for a registration by inserting the signal into the
| IBMSNAP_SIGNAL_xxxx_yyyy table, where xxxx is the journal library and
| yyyy is the journal name of the subject journal. To stop capturing changes for
| a registration in a remote journal configuration, insert the CAPSTOP signal on
| the source server. See Creating journal signal tables for remote journaling on
| page 228 for a description of how to create journal signal tables in a remote
| journal configuration.
For example, use the promote functions to define subscription sets for remote
target databases. After you define a model target system in your test
environment, you can create subscription-set scripts (and modify which Apply
qualifier is used and so on) for your remote target systems, which are not
otherwise supported from a central control point.
Important: You can use the promote functions to promote registered objects
and subscription sets that reside on OS/400, UNIX, Windows, and z/OS
operating systems. The promote functions copy replication definitions
between like systems only, for example from one DB2 Universal Database for
z/OS system to another DB2 Universal Database for z/OS system.
Related concepts:
v Chapter 14, Using the DB2 Replication Center, on page 255
Related tasks:
v Chapter 3, Registering tables and views as replication sources, on page 43
v Chapter 4, Subscribing to sources, on page 71
Related reference:
v schema.IBMSNAP_SIGNAL on page 540
DB2 replication works with your database system and requires limited
changes to your existing database activities. However, to ensure that your
entire system continues to run smoothly and to avoid potential problems, you
should determine the processing requirements of your replication
environment and the potential impact of these requirements on your database
system. This chapter discusses the maintenance requirements of these three
functional components of DB2 replication:
v Maintaining your source systems
v Maintaining your control tables on page 243
v Maintaining your target tables on page 251
You need to consider the availability of these source tables to DB2 replication
so that the Capture and Apply programs are always able to proceed. DB2
replication does not require direct access to source tables during most
replication processing. However, DB2 replication must access your source
tables or table spaces directly when one of the following two actions occurs:
v The Apply program performs a full refresh.
v The log manager attempts to read compressed log records (z/OS only).
Make sure that read access is available to your source tables to avoid
disrupting your replication Apply program processing during a full refresh.
Also, on z/OS, make sure that your utilities run in an online mode so that
DB2 can obtain a latch against the compressed log record table space if your
Note: DB2 replication does not use log data from non-DB2 relational
databases.
For UNIX and Windows: You must configure your database to use user-exit
archiving for your Capture programs to retrieve data from archived logs.
If you run the Capture program whenever DB2 is running, the Capture
program is typically up to date with the recovery logs of DB2. If you run
Capture programs whenever DB2 is up or you retain log records for a week
or longer, you can continue to use your existing log retention procedures.
However, you should change your log retention procedures to accommodate
DB2 replication if:
v You typically delete log records as soon as DB2 completes a backup, and
these log records are no longer needed for forward recovery.
v You face storage constraints and need to delete your archived recovery logs
frequently.
Procedure:
To determine which log records must be retained for use by the Capture
program and which log records can be deleted:
00000000123456123456
123456123456
2. From a command line, type the db2 get db cfg command to obtain the
path for the active log files. For example:
where yourdbname is the database name. From the output displayed on the
screen, note the path for the active log files. For example:
3. From a DB2 command line, type the db2flsn command and enter the last
12 characters of the MIN_INFLIGHTSEQ value. For example:
C:\DB2\NODE0000\SQL00001\>db2flsn 123456123456
To run the db2flsn command, you must have access to the SQLLOGCTL.LFH
file, which is located one directory above (C:\DB2\NODE0000\SQL00001\) the
path to active log files.
The system retrieves and displays the name of the file that contains the log
record identified by the log sequence number. For example:
0000555551F031230000
Ignore the first four characters, which are always 0000. The next 12
characters correspond to the active log sequence number. (This
12character value is the relative byte address [RBA] in non-data sharing
environments and is the log record sequence number [LRSN] in data
sharing environments.) The last four characters are 0000 in non-data
sharing environments; these last four characters correspond to the member
ID in data sharing environments.
2. Use the DSNJU004 utility to invoke the Print Log Map utility. This utility
displays information about the bootstrap data sets (BSDS).
For example:
5. Note the corresponding Data Set Information for that active log number. In
the example:
DSNC710.LOGCOPY1.DS02
Consider the age of this log file or data set to be a benchmark. You must
retain this file and more recent log files but can delete any older logs to
ensure continuous operation of the Capture programs.
To make certain your Capture program can access all required journal
receivers, use the delete journal receiver exit program, which was registered
automatically when you installed DB2 DataPropagator for iSeries. This exit
program is invoked any time you or one of your applications programs
attempts to delete a journal receiver. This exit program then determines
whether or not a journal receiver can be deleted.
If the journal receiver is used by one or more source tables, the delete journal
receiver exit program checks that the receiver being deleted does not contain
entries that have not been processed by the Capture program. The exit
program disapproves the deletion of the receiver if the Capture program still
needs to process entries on that receiver. For more information, see
Managing journals and journal receivers (OS/400) on page 38.
The size of the following control tables changes frequently during normal
processing:
v Apply job (IBMSNAP_APPLY_JOB) (OS/400 only)
v Apply trace (IBMSNAP_APPLYTRACE)
v Apply trail (IBMSNAP_APPLYTRAIL)
v Capture monitor (IBMSNAP_CAPMON)
v Capture trace (IBMSNAP_CAPTRACE)
v Change data (schema.CD_table)
v Consistent-change data (schema.target_table)
v Replication Alert Monitor alerts (IBMSNAP_ALERTS)
v Replication Alert Monitor trace (IBMSNAP_MONTRACE)
v Replication Alert Monitor trail (IBMSNAP_MONTRAIL)
v Signal (IBMSNAP_SIGNAL)
v Subscription events (IBMSNAP_SUBS_EVENT)
v Unit-of-work (IBMSNAP_UOW)
The size and growth of these dynamic control tables can affect the
performance of your system.
This section discusses maintenance activities that you should perform on your
control tables.
Using the RUNSTATS utility (UNIX, Windows, z/OS)
The RUNSTATS utility updates statistics about the physical characteristics of
your tables and associated indexes. You should continue to run the
RUNSTATS utility on your existing tables at the same frequency as before you
used DB2 replication. However, you should run the RUNSTATS utility on
your change-data (CD), unit-of-work (IBMSNAP_UOW), and other dynamic
control tables only one time when these tables contain substantial amounts of
data. RUNSTATS reports meaningful information about these dynamic tables
when these tables are at their maximum production-level size, and the
optimizer gains the necessary statistics to determine the best strategy for
accessing data.
Procedure:
You can set your Capture programs to prune these tables automatically at
regular intervals. Or you can prune on demand by launching the pruning
process once; the Capture program does not prune again until you enter the
next prune command.
Procedure:
Pruning the CD and UOW tables: During each pruning cycle, whether
invoked automatically or on demand, the Capture program prunes the CD
and UOW tables based on the progress reported by the Apply programs.
Progress is indicated by the SYNCHPOINT column value in the prune set
(IBMSNAP_PRUNE_SET) table. This normal pruning is based on the minimum
synchpoint value over all Apply programs that subscribe to each CD table
and on the minimum overall synchpoint value for the UOW table.
Normal pruning, however, does not prune the CD and UOW tables effectively
if the associated subscriptions sets run very infrequently. Keep pruning
effectiveness in mind when deciding how often to run the associated Apply
programs, when stopping these Apply programs, and when deactivating the
subscription sets for more than a brief period of time.
If you run your subscription sets very infrequently or stop your Apply
programs, your CD and UOW tables can grow very large and become eligible
for retention limit pruning. The retention limit is an operational parameter of
the Capture program, with a default value of one week. It determines how
long old data remains in the tables before becoming eligible for retention limit
pruning.
Recommendation: Run your Apply programs at least once per day for all of
your subscription sets.
Pruning the Capture monitor and Capture trace tables: During each
pruning cycle, the Capture program prunes the Capture monitor
(IBMSNAP_CAPMON) and the Capture trace (IBMSNAP_CAPTRACE) tables
based on the values of the following operational parameters of the Capture
program:
v The monitor_limit parameter (on UNIX, Windows, z/OS) and the
MONLMT parameter (on OS/400) that indicate how long rows remain in
the IBMSNAP_CAPMON table
v The trace_limit parameter (on UNIX, Windows, z/OS) and the TRCLMT
parameter (on OS/400) that indicate how long rows remain in the
IBMSNAP_CAPTRACE table
Both the monitor limit and the trace limit parameters have a default value of
one week. You can change these values depending on how long you need to
preserve the historical Capture latency and throughput information in the
IBMSNAP_CAPMON table and the auditing and troubleshooting data from
the IBMSNAP_CAPTRACE table.
The Capture program performs pruning operations for only the tables that it
maintains. The Apply program maintains consistent-change data (CCD) tables;
therefore, the Capture program does not automatically prune these tables.
Some types of CCD tables do not require pruning. Complete condensed CCD
tables are updated in place.
The only records that you might want to remove from complete condensed
CCD tables are those with an IBMSNAP_OPERATION column value of D
(Delete) that have already been replicated to the dependent target tables.
Non-condensed CCD tables contain historical data and can grow very large.
Because you should preserve this data for auditing purposes, you should not
perform pruning operations on non-condensed CCD tables.
You should, however, consider pruning your internal CCD tables. These tables
can grow quickly if there is heavy update activity on your system. Only the
most recent changes are fetched from internal CCD tables, so you do not need
to retain the older rows.
The Apply program shuts down if it detects catastrophic errors on the control
tables. If the Apply program detects errors on target tables or errors with
This scenario becomes even more complex when there are multiple levels of
replication. You must either develop a mechanism that provides matching
recovery points among the various levels or use a full refresh as your
recovery method of choice.
Related concepts:
v Chapter 22, How the DB2 replication components communicate, on page
485
Related tasks:
v Chapter 1, Planning for replication, on page 3
v Chapter 2, Setting up for replication, on page 17
Chapter 14, Using the DB2 Replication Center, on page 255 describes the
Replication Center.
Chapter 15, Basic data replication scenario: DB2 for Windows, on page 283
describes how to use the Replication Center to perform a simple replication
scenario using sample data.
The Replication Center also has a launchpad that allows you to perform the
basic functions needed to set up a DB2 replication environment. The
launchpad shows you graphically how the different steps are related to one
another.
If you will use the Replication Center to operate the Capture, Apply, or
Replication Alert Monitor programs on remote systems, ensure that the DB2
Administration Server (DAS) is running on the local system that is running
the Replication Center and on each of the remote DB2 systems that will run
| the Capture or Apply programs. The DB2 Administration Server for z/OS is
| only available with DB2 for OS/390 and z/OS V7 or later. Once it is installed,
| it can also be used with DB2 for OS/390 V6 applications.
| Configuring the Replication Center for host RDBMSs
| If you are using the Replication Center or command-line tools to administer
| replication on a host database or subsystem, you must bind the Distributed
| Database Connection Services (DDCS) packages to the host DB2 UDB server
| on z/OS (MVS/ESA), VSE, VM, or AS/400.
| Prerequisites:
| Where dbname is the name of the host database or subsystem, xxx specifies
| the platform of the host system (the choices for Replication are MVS,
| VSE, VM, or AS/400), and CS specifies the cursor stability isolation level.
On Windows systems, you can also start the Replication Center by using the
Windows Start menu:
1. Click Start.
2. Select Programs.
3. Select IBM DB2.
4. Select General Administration Tools.
5. Click Replication Center.
If you already have the DB2 Control Center running, you can start the
Replication Center by selecting Replication Center from the Tools menu or by
clicking the icon for the Replication Center.
The launchpad gives you central access to the most common functions in the
Replication Center, but you can also access these functions from the object tree
in the Replication Center. You can use the object tree to view or manipulate
anything that you create using the launchpad. Many other, more advanced,
functions are available in the Replication Center that are not accessible from
the launchpad.
Recommendation: The launchpad does not require that you perform these
tasks in sequence, but if you are new to DB2 replication, follow the sequence
that is presented on the launchpad. You can also skip or repeat steps in the
launchpad if the necessary replication or database objects already exist. Use
the launchpad or the object tree in the Replication Center to create the
necessary replication and database objects.
You can use the launchpad at any time by selecting Launchpad from the
Replication Center menu, or by right-clicking the Replication Center folder in
the object tree and selecting Start Launchpad.
In each object profile, you specify naming conventions for database objects
such as CD tables, indexes, and table spaces, and you specify common
attributes for these objects, such as page sizes and buffer pools. The values
that you specify in each profile become the default values displayed in the
Create Control Tables window, the Register Tables window, the Register Views
window, or the Create Subscription Set window. You can override these
You can define a unique control-table profile for each type of operating
system that DB2 supports. You can also define profiles for each type of
non-DB2 database that DB2 replication supports. The Replication Center does
not provide a control-table profile for OS/400 systems because the
replication control tables are created when you install DB2 DataPropagator
for iSeries.
You can define a naming convention that the Replication Center uses when it
creates the CD table, the table space for the CD table, and the index for the
CD table. You can also define truncation rules for each of these objects if the
name should exceed the operating-system-specific length limit (for example,
128 characters for UNIX and Windows databases) after the Replication Center
applies the prefix and suffix that you specify. For example, you can create a
profile that names your CD tables CD_sourcetablename (where
sourcetablename varies for each registered source table) and places them in a
table space named CD_repltablespace.
You must add a Capture control server to the Replication Center before you
can create a source-object profile for that server.
You must catalog a target server in the local DB2 database before you can
create a target-object profile for it. However, you do not need to add the
target server to the Replication Center as a Capture control server, an Apply
control server, or a Monitor control server.
You cannot use the Replication Center to create replication control tables for
OS/400 systems because the replication control tables are created when you
install DB2 DataPropagator for iSeries. If you want to recreate the control
tables, or create the control tables using an alternate Capture schema, use the
OS/400 CRTDPRTBL command.
A Capture control server can also act as an Apply control server if you create
all of the replication control tables in the same database. Likewise, a Capture
or Apply control server can also act as a Monitor control server.
You can specify a unique schema name for the Capture control
tables; the default is ASN. A separate schema name is necessary if
you plan to run more than one instance of the Capture program for
the selected database.
c. When you have defined all of the control tables, click OK.
Important: Before you can add a database server to the Replication Center,
you must first catalog the server in the local DB2 database and ensure that
replication control tables exist in the database.
For each server that you add, you must enter a valid user ID and password
that the Replication Center can use to connect to the selected database. The
Replication Center uses the saved password information for each server, if it
has any.
Registering sources
To register one or more tables for replication:
1. Expand the Capture Control Servers folder.
2. Expand the database server that contains the source tables that you want
to register.
3. Right-click the Registered Tables folder and select Register Tables. The
Add Registrable Tables window opens.
Because the database could contain many hundreds of tables, you can
prefilter the list of tables so that the Register Tables window shows only
those tables that you are interested in.
4. From the Add Registrable Tables window, specify the search criteria, if
any, and click Retrieve. If you want to include all tables, click Retrieve
All.
5. Select one or more tables from the filtered list that you want to register as
a replication source and click OK. The Register Tables window remains
open.
6. From the Selected tables list, select the first table that you want to register
as a replication source. You can define the following information for a
replication source:
v The row-capture rule that specifies when the Capture program writes a
row to the CD table (or when the Capture triggers write a row to the
consistent-change data (CCD) table).
v The specific columns that you want to make available for replication,
including before-image and after-image columns.
Any column that you do not register will not be available for any
subscription set.
| Recommendation: Consider the potential target tables that you might
| define using this table as a source. If the key columns for the target
| table can be updated at the source, register the before-image values of
| the columns at the source that will make up the key columns at the
| target. When you define which targets subscribe to this source (by
For each registered source table, you also specify information about the
CD table and the index for the CD table. If you created a source-object
profile for this database server, you can accept the defaults that you
defined in the profile, or you can override them.
To register a view, right-click the Registered Views folder and select Register
Views. The view must already exist before you can register it as a replication
source. If it does not exist, click Create View in the Register Views window. In
the Create View window, specify the view name and the SQL statement that
defines the view. You can click SQL Assist to use the SQL Assist window to
create the SQL statement that defines the view.
You can register an OS/400 table that is journaled remotely in the same way
as you register any table, except that you must specify the source-table name
as well as the journal library and journal-receiver name. However, you do not
need to specify the journal library and journal name if they are the same as
the journal library and journal name used by the source table or file.
You can register a nickname in the same way as you register a table, except
that you must specify the nickname for the table (stored in DB2) instead of
the actual table name (stored in the non-DB2 database).
As an alternative, you can also create a subscription set using the following
steps:
1. Expand the Apply Control Servers folder.
2. Expand a specific Apply control server.
3. Right-click the Subscription Sets folder, and select Create. The Create
Subscription Set window opens.
For more information about creating subscription sets, see the online help for
the Replication Center.
Defining the information for the subscription set
In the Create Subscription Set window, you can define the following
information for the subscription set:
v The alias for the Apply control server
v The subscription-set name
For replica target types you also specify the replica definition (row-capture
rule, whether to recapture changes, and how to handle updates), the CD
table for the replica table, and the index for the CD table.
For CCD tables you also specify the properties of the CCD table, including
whether it is complete or noncomplete, condensed or noncondensed, and
whether you want to register it as a replication source.
In the Add SQL Statement or Procedure Call window, you can enter an SQL
statement or use SQL Assist to define the statement. You can specify that
these statements or procedures should run at the target server, before or after
processing the subscription set, or at the Capture control server before
processing the subscription set. You can also add SQLSTATE values that the
Apply program will accept as successful, such as 02000 when attempting to
delete a row that does not exist. Because these SQLSTATE values are treated
as successful, the error condition does not appear in the Apply trail table
(IBMSNAP_APPLYTRAIL), and the Replication Alert Monitor does not
generate an alert for them.
Restrictions:
v You can use the Promote functions to copy replication definitions only
between like systems, for example from one DB2 for UNIX and Windows
system to another DB2 for UNIX and Windows system, but not from a DB2
for UNIX and Windows system to a DB2 for z/OS system. As long as the
systems are all the same type of operating-system platform, you can use the
Promote functions for OS/400, UNIX, Windows, or z/OS systems.
v You cannot use the Promote functions to copy replication definitions for
non-DB2 databases or federated database objects.
v You cannot use the Promote functions to copy replication definitions that
include OS/400 remote journals.
Promoting registered tables or views
To promote registered tables:
1. Click the Registered Tables folder to display the registered source tables
in the contents pane.
2. Right-click a source table and select Promote. The Promote Registered
Tables window opens.
3. In the Promote Registered Tables window, specify the information for the
database server to which you want to copy the registration information:
v Capture control server alias
Select the new Capture control server for the registered source table.
v Capture schema
To promote registered views, click the Registered Views folder to display the
registered source views in the contents pane, right-click a source view and
select Promote.
Promoting subscription sets
To promote subscription sets:
1. Click the Subscription Sets folder to display the subscription sets in the
contents pane.
2. Right-click a subscription set and select Promote. The Promote
Subscription Set window opens.
3. In the Promote Subscription Set window, specify the information for the
database server to which you want to copy the subscription-set
information:
v Apply control server alias
Select the new Apply control server for the subscription set. You can
select the Apply control server that is already defined for the
subscription set.
v Capture control server alias
Select the new Capture server for the subscription set. You can select the
Capture control server that is already defined for the subscription set.
v Target server alias
Select the new target server for the subscription set. You can select the
target server that is already defined for the subscription set.
v Apply qualifier
Type a new Apply qualifier for the subscription set.
v Subscription set name
Type a new name for the subscription set.
v Capture schema
Type a new Capture schema for the source tables in the subscription set.
v Schema name for the source table or view
Type a new schema name for the source tables in the subscription set.
v Schema name for the target table or view
Using the Replication Center, you can bypass the full refresh that is normally
done by the Apply program so that you can perform an unload or extract
from the source table and a load to the target table. The Replication Center
makes the necessary changes to the replication control tables to ensure that
replication continues to run after the load is complete.
The Full Refresh Manual window helps you perform the following steps:
1. Disable current subscriptions for the selected subscription sets.
After the subscription sets are disabled, you can unload the source table
and load the target table.
2. Re-enable the subscriptions for the selected subscription sets.
You can run the generated SQL scripts for steps 1 and 2 immediately, or at a
later time. Be sure to perform these steps in the order suggested by the Full
Refresh Manual window, or your replication environment might produce
unpredictable results.
To perform an automatic full refresh, so that the Apply program will initiate
the full refresh during the next Apply cycle:
1. Click the Subscription Sets folder to display the subscription sets in the
contents pane.
2. Right-click a subscription set and select Full Refresh Automatic.
You can perform any of these tasks for a Capture program that is running
anywhere in your replication network.
You can perform any of these tasks for an Apply program that is running
anywhere in your replication network.
To create contacts that will be notified when the Replication Alert Monitor
detects any of the specified alert conditions:
1. Expand the Operations folder.
2. Expand the Monitor Control Servers folder.
3. Expand a Monitor control server.
You can perform any of these tasks for a Replication Alert Monitor that is
running anywhere in your replication network.
The steps in this chapter use the data in the DEPARTMENT table from the
SAMPLE database. The fully qualified name is schema.DEPARTMENT; where
schema is the user ID that created the table. Table 13 on page 284 shows the
For the remainder of this scenario, use the user ID with which you created the
SAMPLE and COPYDB databases. Because you created the databases, you
have the required authority (DBADM or SYSADM) to perform replication
tasks.
You require a simple data distribution configuration, with changes from one
replication source being replicated to a single read-only copy. This section
describes the design and planning issues that you need to consider before you
perform any replication tasks.
Replication source
You already know that the replication source is the schema.DEPARTMENT
table in the SAMPLE database. Before you set up your environment, you must
decide what you want to replicate from that table; you decide to register all
columns and subscribe to all columns.
Assume that you want the target table in COPYDB to contain the columns of
information shown in Table 14.
Table 14. Columns for the COPYDB table
DEPTNO Information from the DEPTNO column in the replication source
table. This column will be the primary key of the target table.
DEPTNAME Information from the DEPTNAME column in the replication
source table.
MGRNO Information from the MGRNO column in the replication source
table.
ADMRDEPT Information from the ADMRDEPT column in the replication
source table.
LOCATION Information from the LOCATION column in the replication
source table.
Because the columns in the target table simply reflect the data from the source
table, and because there will be only one row in the target table for each row
in the source table, you can use a user copy type of target table.
Replication options
For the purpose of this scenario, you decide to store the CD table, the target
table, and the replication control tables in their respective default table spaces,
as shown in Table 15. Although the SAMPLE and COPYDB databases exist in
the same machine, their table spaces are in separate containers.
Table 15. Tables and table spaces used in this scenario
Database Tables Table spaces Contents
SAMPLE schema.DEPARTMENT USERSPACE1 Source table
schema.CDDEPARTMENT TSCDDEPARTMENT The CD table for the
DEPARTMENT table
Capture control tables TSASNCA and The replication control tables for
TSASNUOW the Capture program
Chapter 15. Basic data replication scenario: DB2 for Windows 285
Table 15. Tables and table spaces used in this scenario (continued)
Database Tables Table spaces Contents
COPYDB schema.TGDEPTCOPY TSTGDEPTCOPY Target table
Apply control tables TSASNAA The replication control tables for
the Apply program
Monitor control tables REPLMONTS1, The replication control tables for
REPLMONTS2, and the Replication Alert Monitor
REPLMONTS3
Typically, you should create the CD table in a separate table space from the
source table to reduce potential contention at the table-space level. You should
accept the defaults (or define a profile within the Replication Center) for the
table spaces of the replication control tables. For a production environment, it
is best if you create each table space on a separate device, to reduce potential
contention.
For scheduling replication, assume that you want DB2 replication to check for
any changes from the source table every minute and replicate them to the
target table. Although a report-generating application doesnt require that
kind of response time, you want to test the replication environment to make
sure that everything is working correctly.
Also, you decide that after each replication cycle, you want to delete any
records from the Apply trail table that are older than one week (seven days).
This pruning prevents the table from growing too large.
Chapter 15. Basic data replication scenario: DB2 for Windows 287
After you backup the database, you could start the Capture program, but do
not start it yet. If you want to start the Capture program, see Step 7:
Replicate the scenario data on page 298.
Step 3: Register a replication source
After you create the Capture control tables and enable the database for
replication, register the DEPARTMENT table as a replication source.
6. In the Register Tables window, click the CD Table notebook tab. Specify
the following information for the CD table space:
v In the Specification for table space area, click the Container name
field to specify the container name for the TSCDDEPARTMENT table
space.
v In the Specification for table space area, change the Size field to 1.
v In the Specification for table space area, change the Unit field to MB.
v Specify the other information for this new table space; for example, set
the buffer pool to IBMDEFAULTBP.
After you have entered the table-space information, click OK.
| 7. Click Close on the Message Dialog window. This window shows the
| result of generating the SQL script that will register the source table. If
there were any errors, they would be displayed in this window.
8. Click OK on the Run Now or Save SQL window to run the SQL script
immediately.
Chapter 15. Basic data replication scenario: DB2 for Windows 289
9. You should see a message in the DB2 Message window that the script ran
successfully. Click Close.
10. The contents pane for the SAMPLE database folder should now show the
DEPARTMENT table as a registered table. See Figure 9 for an example of
the contents pane for the SAMPLE database folder with the
DEPARTMENT table as a registered table.
Figure 9. The DEPARTMENT table is listed as a registered table for the SAMPLE database
Chapter 15. Basic data replication scenario: DB2 for Windows 291
Tip: The Apply qualifier is case-sensitive. If you want the Apply
qualifier to be in lowercase characters, you must delimit it when
you type it; for example, "deptqual". If you simply type
deptqual, the Replication Center converts the value to uppercase
characters by default.
c. Click the browse button for the Capture control server alias field. In
the Select a Capture Control Server window, select the SAMPLE
database and click OK.
d. Click the browse button for the Target server alias field. In the Select
a Target Server window, select the COPYDB database and click OK.
The COPYDB database is both the target server and the Apply control
server.
e. Select the Activate the subscription set check box.
You do not need to change the settings of the other fields in the Set
Information page. The Create Subscription Set window should look
similar to the window shown in Figure 10.
Chapter 15. Basic data replication scenario: DB2 for Windows 293
Figure 11. The Member Properties window
This statement deletes any records in the Apply trail table that are
older than seven days.
The Apply program will execute the SQL statement that you added at
the target server after the subscription set is processed. The SQL
statement must run at the target server because the Apply control
server and target server are co-located and the Apply trail table is in
the Apply control server.
Chapter 15. Basic data replication scenario: DB2 for Windows 295
Tip: The Apply program runs SQL statements or procedures that you
add to a subscription set during every subscription cycle. This
example is inefficient because the Apply program will execute
this statement every minute, even though the statement will only
delete data from the APPLYTRAIL table at most once every 24
hours.
b. In the SQLSTATE field, enter 02000 and click Add. This SQL state
indicates that row not found error is acceptable and that the Apply
program should ignore these errors.
Tip: You can define up to ten SQL states that you want the Apply
program to ignore for this subscription set.
c. Click OK to close the Add SQL Statement or Procedure Call window.
13. Click OK to close the Create Subscription Set window.
14. Click Close on the Message Dialog window. This window shows the
result of generating the SQL script that will update the Apply control
tables and create the target table. If there were any errors, they would be
displayed in this window.
15. Click OK on the Run Now or Save SQL window to run the SQL script
immediately.
You could save the SQL script to a file for future use and also run it
immediately:
a. Select Save to file.
b. Fill in the information in the Save specifications area, such as the file
name.
| c. Click Apply to save the file. If the script has multiple parts and you
| did not select the Save multiple scripts in one file checkbox, then
| each part is saved to a separate file using the name that you specify
| plus a number. The Run Now or Save SQL window remains open.
d. Select Run now.
e. Click OK to run the script and close the Run Now or Save SQL
window.
You can also save the SQL script to a file to run it later, or you can save
the SQL script and run it
16. You should see a message in the DB2 Message window that the script ran
successfully at both the SAMPLE and COPYDB servers. Click Close.
17. Expand the Apply Control Servers folder and the COPYDB folder, then
click the Subscription Sets folder. The contents pane for the Subscription
Sets folder should now show the DEPTSUB subscription set. See
Figure 12 on page 297 for an example of the contents pane for the
Subscription Sets folder with the DEPTSUB subscription set.
where path is the fully specified directory path and file name that you
want to use when you create the password file. You should see message
ASN1981I that confirms that the command completed successfully.
For example, if you want to store the password file in the c:\sqllib\repl
directory and name the file asnpwd.aut, enter the following command:
Chapter 15. Basic data replication scenario: DB2 for Windows 297
asnpwd init using "c:\sqllib\repl\asnpwd.aut"
Tip: Create the password file in the directory in which you will start the
Apply program. When you start the Apply program, you specify the
file name for the password file (using the PWDFILE keyword) and
the value for the directory in which the Apply program will store its
log and work files (using the APPLY_PATH keyword). One of the
Apply programs work files is the password file.
3. Enter the following command to add the user ID and password
information for each database to which the Apply program must connect:
asnpwd add alias SAMPLE id userid password password using "path"
where userid is a valid DB2 user ID with sufficient authority to update the
Capture and Apply control tables. You should see message ASN1981I that
confirms that the command completed successfully.
Step 7: Replicate the scenario data
After you register the replication source and create the subscription set, start
the Capture and Apply programs to perform the initial full refresh for the
target table and begin change-capture replication.
Tip: You can specify the LOADXIT keyword to call the ASNLOAD
program. The default ASNLOAD program uses the DB2
EXPORT utility to export data from the source table and uses the
DB2 LOAD utility to perform the full refresh for the target table.
You can modify ASNLOAD to call any IBM or vendor utility.
7. Click OK on the Start Apply window.
8. If necessary, type a valid user ID and password for the system on which
you will run the Apply program in the Run Now or Save Command
window.
9. Click OK on the Run Now or Save Command window to run the
command immediately.
10. You should see a message in the DB2 Message window that the
command ran successfully. Click Close. The Apply program is now
running.
If you view the TGDEPTCOPY target table after one replication cycle, you
| should see results that match the data shown in Table 16 on page 300. You can
| use any of the following methods to view the contents of the table:
| v Use the Replication Center:
| 1. Expand the Replication Definitions folder.
| 2. Expand the Apply Control Servers folder.
| 3. Expand the COPYDB folder.
Chapter 15. Basic data replication scenario: DB2 for Windows 299
| 4. Right-click the Dependent Targets folder and select View Selected
| Contents.
v Use the DB2 Control Center:
1. Expand the databases folder for your DB2 instance.
2. Expand the COPYDB folder.
3. Select the Tables folder.
4. Right-click the TGDEPTCOPY table in the contents pane and select
Sample Contents.
v Use the DB2 Command Center or a DB2 command window to issue the
following SQL statement:
SELECT * FROM schema.TGDEPTCOPY
Table 16. The TGDEPTCOPY table
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
E01 SUPPORT SERVICES 000050 A00 -
E11 OPERATIONS 000090 E01 -
E21 SOFTWARE SUPPORT 000100 E01 -
Table 17 shows the results of the replication, with two new rows appended to
the table.
Table 17. The TGDEPTCOPY table after changes are replicated
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
E01 SUPPORT SERVICES 000050 A00 -
E11 OPERATIONS 000090 E01 -
E21 SOFTWARE 000100 E01 -
SUPPORT
F01 TECHNICAL 000110 F01 -
WRITING
G01 PUBLIC RELATIONS 000120 G01 -
Chapter 15. Basic data replication scenario: DB2 for Windows 301
3. Right-click the SAMPLE database in the contents pane and select Query
Status.
4. Click Retrieve to view current information.
Chapter 15. Basic data replication scenario: DB2 for Windows 303
2. Select the Capture Control Servers folder.
3. Right-click the SAMPLE database in the contents pane and select Stop
Capture.
4. Click OK on the Stop Capture window.
5. Click OK on the Run Now or Save Command window to run the
command immediately.
6. You should see a message in the DB2 Message window that the command
ran successfully. Click Close. The Capture program is now stopped.
You can run DB2 utilities on your database now that you have stopped the
Capture and Apply programs. Running utilities is beyond the scope of this
scenario.
Monitoring replication
After the replication environment is up and running, there will be times when
you want to understand how well the Capture and Apply programs are
running. You might also want to set up automatic notifications in the event of
certain kinds of replication errors.
You can use the Replication Center to query the status of the Capture and
Apply programs and to view certain statistics that can tell you how well
Chapter 15. Basic data replication scenario: DB2 for Windows 305
Figure 13. The Create Monitor Control Tables window
To create a contact:
1. Expand the Operations folder.
2. Expand the Monitor Control Servers folder.
3. Expand the COPYDB folder.
| 4. Right-click the Contacts folder and select Create Contact Person.
5. In the Create Contact window, enter your name and e-mail address. Click
OK to close the window.
6. Click Close on the Messages and SQL Scripts window. This window
shows the result of generating the SQL script to update the Monitor
control tables. If there were any errors, they would be displayed in this
window.
7. Click OK on the Run Now or Save SQL window to run the SQL script
immediately.
8. You should see a message in the DB2 Message window that the script ran
successfully. Click Close.
9. Click the Contacts folder. The contact that you defined should be
displayed in the contents pane for Contacts.
Step 3: Select alert conditions for the Capture program
The Replication Alert Monitor program can monitor specific activity of the
Capture program. You must select which activities you want to monitor. For
each of these activities, you select an alert condition. When the Capture
program encounters the condition, the Replication Alert Monitor sends an
alert to those contacts that you define for the alert condition.
Chapter 15. Basic data replication scenario: DB2 for Windows 307
b. Click the browse button for the Capture control server field to select
the Capture control server that you want to monitor. In the Select a
Capture Control Server window, select the SAMPLE database and click
OK.
c. Click Add to add ASN to the Selected Capture schemas list.
d. In the Select Capture Schemas window, click Retrieve All. Select ASN
from the list, and click OK to close the window.
| e. In the Alert Conditions list, select Errors.
f. In the Value area, click the browse button for the Contact field to select
the contact for this alert condition.
g. In the Select Contact or Contact Group window, select the contact that
you created in step 2 and click OK to close the window.
h. Click OK to close the Select Alert Conditions for Capture Schemas
window.
6. Click Close on the Messages and SQL Scripts window. This window
shows the result of generating the SQL script to update the Monitor
control tables. If there were any errors, they would be displayed in this
window.
7. Click OK on the Run Now or Save SQL window to run the SQL script
immediately.
8. You should see a message in the DB2 Message window that the script ran
successfully. Click Close.
9. Expand the COPYDB folder, expand the Monitor Qualifiers folder, and
select the MON1 folder. The alert conditions that you defined should be
displayed in the contents pane for Monitor qualifiers.
Step 4: Select alert conditions for the Apply program
The Replication Alert Monitor program can monitor specific activity of the
Apply program. You must select which activities you want to monitor. For
each of these activities, you select an alert condition. When the Apply
program encounters the condition, the Replication Alert Monitor sends an
alert to those contacts that you define for the alert condition.
Chapter 15. Basic data replication scenario: DB2 for Windows 309
Figure 14. The MON1 monitor qualifier is listed for the COPYDB database
Chapter 15. Basic data replication scenario: DB2 for Windows 311
9. You should see a message in the DB2 Message window that the command
ran successfully. Click Close.
Chapter 16, Naming rules for replication objects, on page 315 describes how
to specify valid names for replication objects.
Chapter 20, Using the Windows Service Control Manager to issue system
commands (Windows), on page 479 describes how to start replication
programs as services on Windows operating systems.
Chapter 23, Table structures, on page 491 describes the table structures for
the replication tables that reside on the various replication servers.
Chapter 24, Replication messages, on page 601 lists all of the replication
messages for UNIX, Windows, and z/OS operating systems.
| Notes:
| 1. For Capture schemas, Apply qualifiers, and Monitor qualifiers, ensure that you use
| only the following valid characters in the names of these objects:
| v A through Z (uppercase letters)
| v a through z (lowercase letters)
| v Numerals (0 through 9)
| v The underscore character _
| Blanks are not allowed; neither are other special characters such as the colon :
| and the plus sign +.
All of these commands have a prefix of asn and are entered at an operating
system command prompt or in a shell script. One of the commands,
asnanalyze, also works with remote data residing on OS/400 operating
systems.
This chapter contains a section for each command. Each section contains a
brief description of the command, a syntax diagram, and a table of parameters
with corresponding definitions. The end of each section has examples of
command usage and cross-references to related information.
Example 1
To receive messages about the state of each Apply thread:
asnacmd apply_qual=AQ1 control_server=dbx status
Example 2
To stop the Apply program:
asnacmd apply_qual=AQ1 control_server=dbx stop
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
Related reference:
v ENDDPRAPY: Stopping Apply (OS/400) on page 416
v STRDPRAPY: Starting Apply (OS/400) on page 447
You must type a space between the asnanalyze command and the first
parameter to invoke the command. If you issue the command without any
parameters, you receive command help on the screen.
-ct n -cm n -sg n
-aq apply_qualifier
-cs capture_schema -od output_directory -fn output_filename
-pw password_filepath
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 319
asnanalyze
Table 20. asnanalyze invocation parameter definitions for UNIX and Windows operating
systems (continued)
Parameter Definition
-aq apply_qualifier Specifies the Apply qualifier that identifies the specific
subscription sets to be analyzed.
Example 1
To analyze the replication control tables on a database called proddb1:
asnanalyze -db proddb1
Example 2
To obtain a detailed level of analysis about the replication control tables on
the proddb1 and proddb2 databases:
asnanalyze -db proddb1 proddb2 -la detailed
Example 3
To analyze the last two days of information from the
IBMSNAP_APPLYTRAIL, IBMSNAP_APPLYTRACE, IBMSNAP_CAPTRACE,
IBMSNAP_CAPMON, and IBMSNAP_SIGNAL tables on the proddb1 and
proddb2 databases:
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 321
asnanalyze
Example 4
To obtain a simple level of analysis about the last two days of information
from the IBMSNAP_APPLYTRAIL, IBMSNAP_APPLYTRACE,
IBMSNAP_CAPTRACE, IBMSNAP_CAPMON, and IBMSNAP_SIGNAL tables
on the proddb1 and proddb2 databases for only the qual1 and qual2 Apply
qualifiers:
asnanalyze -db proddb1 proddb2 -la simple -tl 2 -at 2 -ct 2 -cm 2 -sg 2
-aq qual1 qual2 -od c:\mydir -fn anzout -pw c:\SQLLIB
This command example writes the analyzer output to a file named anzout
under the c:\mydir directory and uses the password information from the
c:\SQLLIB directory.
Example 5
To analyze a specific Capture schema:
asnanalyze -db proddb1 proddb2 -cs BSN
Example 6
To display command help:
asnanalyze
Related reference:
v ANZDPR: Operating the Analyzer (OS/400) on page 406
control_server=db_name apply_path=pathname
n n n y
logreuse= y logstdout= y loadxit= y inamsg= n
n n y n
notify= y copyonce= y sleep= n trlreuse= y
n delay=n errwait=n y
opt4one= y term= n
z/OS parameter:
mem
spillfile= disk
Notes:
1 Use the db2_subsystem parameter only on z/OS operating systems.
The value that you enter must match the value of the
APPLY_QUAL column in the subscription sets
(IBMSNAP_SUBS_SET) table. The Apply qualifier name
is case sensitive and can be a maximum of 18
characters.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 323
asnapply
Table 21. asnapply invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
| db2_subsystem=name For z/OS only: Specifies the name of the DB2 subsystem
| where the Apply program will run. The DB2 subsystem
name that you enter can be a maximum of four
characters. There is no default for this parameter. This
parameter is required.
control_server=db_name Specifies the name of the Apply control server on which
the subscription definitions and Apply program control
tables reside.
For z/OS: The log file name does not contain the DB2
instance name
(control_server.apply_qualifier.APP.log).
Table 21. asnapply invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
| logstdout=y/n Specifies where the Apply program directs the log file
| messages:
n (default)
| The Apply program directs most log file
| messages to the log file only. Initialization
| messages go to both the log file and the
| standard output (STDOUT).
| y The Apply program directs log file messages to
| both the log file and the standard output
| (STDOUT).
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 325
asnapply
Table 21. asnapply invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
copyonce=y/n Specifies whether the Apply program executes one copy
cycle for each subscription set that is eligible at the time
the Apply program is invoked. Then the Apply program
terminates. An eligible subscription set meets the
following criteria:
v (ACTIVATE > 0) in the subscription sets
(IBMSNAP_SUBS_SET) table. When the ACTIVATE
column value is greater than zero, the subscription set
is active indefinitely or is used for a one-time-only
subscription processing.
v (REFRESH_TYPE = R or B) or (REFRESH_TYPE = E
and the specified event occurred). The
REFRESH_TYPE column value is stored in the
IBMSNAP_SUBS_SET table.
The MAX_SYNCH_MINUTES limit from the
subscription sets table and the END_OF_PERIOD
timestamp from the subscription events
(IBMSNAP_SUBS_EVENT) table are honored if
specified.
n (default)
The Apply program does not execute one copy
cycle for each eligible subscription set.
y The Apply program executes one copy cycle for
each eligible subscription set.
Table 21. asnapply invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
trlreuse=y/n Specifies whether the Apply program empties the Apply
trail (IBMSNAP_APPLYTRAIL) table when the Apply
program starts.
n (default)
The Apply program appends entries to the
IBMSNAP_APPLYTRAIL table. The Apply
program does not empty the table.
y The Apply program empties the
IBMSNAP_APPLYTRAIL table during program
startup.
delay=n Specifies the delay time (in seconds) at the end of each
Apply cycle when continuous replication is used, where
n=0, 1, 2, 3, 4, 5, or 6. The default is 6.
| errwait=n Specifies the number of seconds (1 to 65535) that the
Apply program waits before retrying after the program
encounters an error condition. The default value is 300
seconds (five minutes).
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 327
asnapply
Table 21. asnapply invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
term=y/n Specifies how the status of DB2 affects the operation of
the Apply program.
y (default)
The Apply program terminates if DB2
terminates.
n The Apply program waits for DB2 to start, if
DB2 is not active.
| Return codes
| The asnapply command returns a zero return code upon successful
| completion. A nonzero return code is returned if the command is
| unsuccessful.
Examples for asnapply
The following examples illustrate how to use the asnapply command.
Example 1
To start an Apply program using an Apply qualifier named AQ1, a control
server named dbx with work files located in the /home/files/apply/
directory:
asnapply apply_qual=AQ1 control_server=dbx apply_path=/home/files/apply/
pwdfile=pass1.txt
Example 2
To start an Apply program that invokes the ASNLOAD exit routine:
asnapply apply_qual=AQ1 control_server=dbx pwdfile=pass1.txt loadxit=y
In this example, the Apply program searches the current directory for the
password file named pass1.txt.
Example 3
To start an Apply program that executes one copy cycle for each eligible
subscription set:
asnapply apply_qual=AQ1 control_server=dbx apply_path=/home/files/apply/
copyonce=y
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
Related reference:
v STRDPRAPY: Starting Apply (OS/400) on page 447
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 329
asncap
After you start the Capture program, it runs continuously until you stop it or
it detects an unrecoverable error.
|
capture_path=path n y
add_partition= y autoprune= n
n commit_interval=n lag_limit=n n
autostop= y logreuse= y
n memory_limit=n monitor_interval=n
logstdout= y
|
monitor_limit=n asnpwd.aut prune_interval=n
pwdfile= filename
retention_limit=n sleep_interval=n warmsi
startmode= warmns
warmsa
cold
y trace_limit=n
term= n
Table 22. asncap invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
| add_partition=y/n For UNIX and Windows only: Specifies whether the
| Capture program starts reading the log file for the newly
| added partitions since the last time the Capture program
| was restarted.
| n (default)
| No new partitions have been added since the last
| time the Capture program was restarted.
| y The Capture program starts reading the log file
| on one or more of the new partitions. On each
| partition, the Capture program starts reading the
| log from the log sequence number (LSN) that
| was initially used the last time the database was
| started.
|
capture_schema=schema Specifies the name of the Capture schema that is used to
identify a particular Capture program. The schema name
that you enter must be 1 to 30 characters in length. The
default is ASN.
capture_path=path Specifies the location of the work files used by the
Capture program. The default is the directory where the
asncap command was invoked.
autoprune=y/n Specifies whether automatic pruning of the rows in the
change-data (CD), unit-of-work (UOW), Capture monitor
(IBMSNAP_CAPMON), Capture trace
(IBMSNAP_CAPTRACE), and signal
(IBMSNAP_SIGNAL) tables is enabled.
y (default)
The Capture program automatically prunes the
eligible rows at the interval specified in the
Capture parameters (IBMSNAP_CAPPARMS)
table. The Capture program prunes the CD,
UOW, and IBMSNAP_SIGNAL rows that are
older than the retention limit, regardless of
whether the rows have been replicated.
n Automatic pruning is disabled.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 331
asncap
Table 22. asncap invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
autostop=y/n Specifies whether the Capture program terminates after
retrieving all the transactions that were logged before the
Capture program started.
n (default)
The Capture program does not terminate after
retrieving the transactions.
y The Capture program terminates after retrieving
the transactions.
commit_interval=n Specifies the number of seconds that the Capture program
waits before committing rows to the unit-of-work (UOW)
and change-data (CD) tables. The default is 30 seconds.
| lag_limit=n Specifies the number of minutes that the Capture program
| is allowed to lag in processing log records. The default is
| 10080 minutes (seven days). The Capture program checks
| the value of this parameter only during a warm start. If
| this limit is exceeded, the Capture program will not start.
logreuse=y/n Specifies whether the Capture program reuses or appends
messages to the log file
(db2instance.capture_server.capture_schema.CAP.log).
n (default)
The Capture program appends messages to the
log file, even after the Capture program is
restarted.
y The Capture program reuses the log file by first
truncating the current log file and then starting a
new log when the Capture program is restarted.
For z/OS: The log file name does not contain the DB2
instance name (capture_server.capture_schema.CAP.log).
logstdout=y/n Specifies where the Capture program directs the log file
messages:
n (default)
The Capture program directs most log file
messages to the log file only. Initialization
messages go to both the log file and the standard
output (STDOUT).
y The Capture program directs log file messages to
both the log file and the standard output
(STDOUT).
Table 22. asncap invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
memory_limit=n Specifies the maximum size (in megabytes) of memory
that the Capture program can use to build transactions.
After reaching this memory limit, the Capture program
spills transactions to a file. The default is 32 megabytes.
monitor_interval=n Specifies how frequently (in seconds) the Capture
program inserts rows into the Capture monitor
(IBMSNAP_CAPMON) table. The default is 300 seconds
(five minutes).
monitor_limit=n Specifies how long (in minutes) a row can remain in the
Capture monitor (IBMSNAP_CAPMON) table before it
becomes eligible for pruning. All IBMSNAP_CAPMON
rows that are older than the value of the monitor_limit
parameter are pruned at the next pruning cycle. The
default is 10 080 minutes (seven days).
| pwdfile=filename Specifies the name of the password file. If you do not
| specify a password file, the default is asnpwd.aut.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 333
asncap
Table 22. asncap invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
startmode=mode Specifies the processing procedure used by the Capture
program during a Capture startup.
warmsi (default)
The Capture program resumes processing where
it ended in its previous run if warm start
information is available. If this is the first time
that you are starting the Capture program, it
automatically switches to a cold start.
During a warm start, the Capture program leaves
the Capture trace (IBMSNAP_CAPTRACE),
change-data (CD), unit-of-work (UOW), and
restart (IBMSNAP_RESTART) tables intact. If
errors occur after the Capture program started,
the Capture program terminates.
warmns
The Capture program resumes processing where
it ended in its previous run if warm start
information is available. If errors occur after the
Capture program started, the Capture program
terminates. If the Capture program cannot warm
start, it does not switch to a cold start.
warmsa
The Capture program resumes processing where
it ended in its previous run if warm start
information is available. If the Capture program
cannot warm start, it switches to a cold start.
| cold The Capture program starts by deleting all rows
| in its CD and UOW tables. Most registrations are
| reset so that all subscriptions to those sources are
| fully refreshed during the next Apply processing
| cycle. Registrations for external CCDs and those
| subscriptions whose targets are noncomplete
| CCDs are not fully refreshed.
Table 22. asncap invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
term=y/n Specifies whether the Capture program terminates if DB2
terminates.
y (default)
The Capture program terminates if DB2
terminates.
n The Capture program continues running if DB2
terminates with MODE(QUIESCE). When DB2
initializes, the Capture program starts in warm
mode and begins capturing at the point it left off
when DB2 terminated.
| Return codes
| The asncap command returns a zero return code upon successful completion.
| A nonzero return code is returned if the command is unsuccessful.
Examples for asncap
The following examples illustrate how to use the asncap command.
Example 1
To start a Capture program for the first time using a Capture control server
named db and a Capture schema of ASN with work files located in the
/home/files/capture/logs/ directory:
asncap capture_server=db capture_schema=ASN
capture_path=/home/files/capture/logs/ startmode=cold
Example 2
To restart a Capture program without pruning after the Capture program was
stopped:
asncap capture_server=db autoprune=n sleep_interval=10 startmode=warmsa
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 335
asncap
The Capture program in this example retains all rows in the corresponding
control tables and sleeps for ten seconds after it finishes processing the active
log and determines that the buffer is empty. The Capture program resumes
processing where it ended in its previous run and switches to a cold start if
warm start information is unavailable.
Example 3
To restart a Capture program with the warmns startmode and changed
parameter settings:
asncap capture_server=db autoprune=y prune_interval=60 retention_limit=1440
startmode=warmns
This command restarts the Capture program and uses new parameter settings
to decrease the amount of time before the CD, UOW, and IBMSNAP_SIGNAL
tables become eligible for pruning and to increase the frequency of pruning
from the default parameter settings. The Capture program resumes processing
where it ended in its previous run but does not automatically switch to a cold
start if warm start information is unavailable.
Example 4
To start a Capture program that sends all of its work files to a new
subdirectory called capture_files:
1. Go to the appropriate directory, and then create a new subdirectory called
capture_files:
cd /home/db2inst
mkdir capture_files
2. Start the Capture program, and specify a Capture path that is located in
the new subdirectory that you just created:
asncap capture_server=db capture_schema=ASN
capture_path=/home/db2inst/capture_files startmode=warmsi
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
Related reference:
v STRDPRCAP: Starting Capture (OS/400) on page 456
asnccmd
capture_server=db_name capture_schema=schema
chgparms parameters
prune
qryparms
reinit
resume
status
stop
suspend
Parameters:
y n commit_interval=n
autoprune= n autostop= y
n n memory_limit=n
logreuse= y logstdout= y
monitor_interval=n monitor_limit=n prune_interval=n
retention_limit=n sleep_interval=n y trace_limit=n
term= n
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 337
asnccmd
Table 23. asnccmd invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
chgparms Specify to change the parameter values of a Capture
program while it is running. You can specify new
parameter values or override the values that were passed
to the Capture program when it started. To determine
which parameters can be overridden, see Table 24 on
page 339.
prune Specify this parameter if you want to prune the
change-data (CD), unit-of-work (UOW), Capture monitor
(IBMSNAP_CAPMON), Capture trace
(IBMSNAP_CAPTRACE), and signal
(IBMSNAP_SIGNAL) tables once. The Capture program
issues a message when the command is successfully
queued.
qryparms Specify if you want the current operational parameter
values written to the standard output (stdout).
reinit Specify to have the Capture program obtain newly
added replication sources from the register
(IBMSNAP_REGISTER) table. For example, use this
parameter if you add a new replication source or if you
use ALTER ADD to add a column to a replication source
and change-data (CD) table while the Capture program
is running.
resume Specify to have a suspended Capture program resume
capturing data.
status Specify to receive messages that indicate the state of each
Capture thread (administration, pruning, serialization,
and worker).
stop Specify to stop the Capture program in an orderly way
and commit the log records processed up to that point.
suspend Specify to relinquish operating system resources to
operational transactions during peak periods without
destroying the Capture program environment.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 339
asnccmd
Table 24. asnccmd chgparms parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
logreuse=y/n Specifies whether the Capture program reuses or appends
messages to the log file
(db2instance.capture_server.capture_schema.CAP.log).
n (default)
The Capture program appends messages to the
log file, even after the Capture program is
restarted.
y The Capture program reuses the log file by first
truncating the current log file and then starting a
new log when the Capture program is restarted.
For z/OS: The log file name does not contain the DB2
instance name (capture_server.capture_schema.CAP.log).
logstdout=y/n Specifies where messages are sent by the Capture
program.
n (default)
The Capture program sends messages to the log
file only.
y The Capture program sends messages to both the
log file and the standard output (stdout).
memory_limit=n Specifies the maximum size (in megabytes) of memory
that the Capture program can use to build transactions.
After reaching this memory limit, the Capture program
spills transactions to a file. The default is 32 megabytes.
monitor_interval=n Specifies how frequently (in seconds) the Capture
program inserts rows into the Capture monitor
(IBMSNAP_CAPMON) table. The default is 300 seconds
(five minutes).
monitor_limit=n Specifies how long (in minutes) a row can remain in the
Capture monitor (IBMSNAP_CAPMON) table before it
becomes eligible for pruning. All IBMSNAP_CAPMON
rows that are older than the value of the monitor_limit
parameter are pruned at the next pruning cycle. The
default is 10 080 minutes (seven days).
Table 24. asnccmd chgparms parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
prune_interval=n Specifies how frequently (in seconds) the change-data
(CD), unit-of-work (UOW), Capture monitor
(IBMSNAP_CAPMON), Capture trace
(IBMSNAP_CAPTRACE), and signal
(IBMSNAP_SIGNAL) tables are pruned. This parameter is
ignored if you set the autoprune parameter to n. The
default is 300 seconds (five minutes).
retention_limit=n Specifies how long (in minutes) a row can remain in the
change-data (CD), unit-of-work (UOW), or signal
(IBMSNAP_SIGNAL) table before it becomes eligible for
pruning. Each row that is older than the value of the
retention_limit parameter is pruned at the next pruning
cycle. The default is 10 080 minutes (seven days).
sleep_interval=n Specifies the number of seconds that the Capture program
sleeps when it finishes processing the active log and
determines that the buffer is empty. The default is five
seconds.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 341
asnccmd
Table 24. asnccmd chgparms parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
trace_limit=n Specifies how long (in minutes) a row can remain in the
Capture trace (IBMSNAP_CAPTRACE) table before it
becomes eligible for pruning. All IBMSNAP_CAPTRACE
rows that are older than the value of the trace_limit
parameter are pruned at the next pruning cycle. The
default is 10 080 minutes (seven days).
Example 1
To enable a running Capture program to recognize newly added replication
sources:
asnccmd capture_server=db capture_schema=ASN reinit
Example 2
To prune the CD, UOW, IBMSNAP_CAPMON, IBMSNAP_CAPTRACE, and
IBMSNAP_SIGNAL tables once:
asnccmd capture_server=db capture_schema=ASN prune
Example 3
To receive messages about the state of each Capture thread:
asnccmd capture_server=db capture_schema=ASN status
Example 4
To send the current operational values of a Capture program to the standard
output:
asnccmd capture_server=db capture_schema=ASN qryparms
Example 5
To disable the automatic pruning in a running Capture program:
asnccmd capture_server=db capture_schema=ASN chgparms autoprune=n
Example 6
To stop a running Capture program:
asnccmd capture_server=db capture_schema=ASN stop
Related tasks:
v Chapter 19, Operating the replication programs (z/OS), on page 473
Related reference:
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 343
asnmcmd
Table 25. asnmcmd invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
status Specify to receive messages that indicate the state of
each thread (administration, serialization, and worker)
in the Replication Alert Monitor.
stop Specify to stop the Replication Alert Monitor in an
orderly way.
Example 1
To stop the Replication Alert Monitor for the specified monitor qualifier:
asnmcmd monitor_server=wsdb monitor_qual=monqual stop
Example 2
To receive messages that indicate the status of the Replication Alert Monitor
threads:
asnmcmd monitor_server=wsdb monitor_qual=monqual status
Example 3
To refresh the Replication Alert Monitor with current values from the monitor
control tables:
asnmcmd monitor_server=wsdb monitor_qual=monqual reinit
Related tasks:
v Chapter 11, Monitoring replication, on page 175
Related reference:
v asnmon: Starting the Replication Alert Monitor (UNIX, Windows, z/OS)
on page 344
monitor_interval=n n y
runonce= y autoprune= n
n n alert_prune_limit=n
logreuse= y logstdout= y
trace_limit=n max_notifications_per_alert=n
max_notifications_minutes=n asnpwd.aut
pwdfile= filepath
monitor_path=path ,
monitor_errors= address
email_server=servername
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 345
asnmon
Table 26. asnmon invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
monitor_qual=mon_qual Specifies the monitor qualifier that the Replication
Alert Monitor program uses. The monitor qualifier
identifies the server to be monitored and the
associated monitoring conditions.
Table 26. asnmon invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
logreuse=y/n Specifies whether the Replication Alert Monitor
program reuses or appends messages to the log file (
db2instance.monitor_server.mon_qual.MON.log ).
n (default)
The Replication Alert Monitor program
appends messages to the log file.
y The Replication Alert Monitor program reuses
the log file by deleting it and then re-creating
it when the Replication Alert Monitor
program is restarted.
logstdout=y/n Specifies where messages are sent by the Replication
Alert Monitor program.
n (default)
The Replication Alert Monitor program sends
messages to the log file only.
y The Replication Alert Monitor program sends
messages to both the log file and the standard
output (stdout).
alert_prune_limit=n Specifies how long (in minutes) rows are kept in the
Replication Alert Monitor alerts (IBMSNAP_ALERTS)
table. Any rows older than this value are pruned. The
default is 10 080 minutes (seven days).
trace_limit=n Specifies how long (in minutes) a row can remain in
the Replication Alert Monitor trace
(IBMSNAP_MONTRACE) table before it becomes
eligible for pruning. All IBMSNAP_MONTRACE rows
that are older than the value of this trace_limit
parameter are pruned at the next pruning cycle. The
default is 10 080 minutes (seven days).
max_notifications_per_alert=n Specifies the maximum number of the same alerts that
are sent to a user when the alerts occurred during the
time period specified by the
max_notifications_minutes parameter value. Use this
parameter to avoid re-sending the same alerts to a
user. The default is 3.
max_notifications_minutes=n This parameter works with the
max_notifications_per_alert parameter to indicate the
time period when alert conditions occurred. The
default is 60 minutes.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 347
asnmon
Table 26. asnmon invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
pwdfile=filepath Specifies the fully qualified name of the password file.
You define this file using the asnpwd command. The
default file name is asnpwd.aut.
monitor_path=path Specifies the location of the log files used by the
Replication Alert Monitor program. The default is the
directory where the asnmon command was invoked.
monitor_errors=address Specifies the e-mail address to which notifications are
sent if a fatal error is detected before the alert monitor
connects to the monitor control server. Use this
parameter to send a notification that the monitor
control server connection failed because of invalid
start parameters, an incorrect monitor qualifier, a
down database, or other error.
| Return codes
| The asnmon command returns a zero return code upon successful completion.
| A nonzero return code is returned if the command is unsuccessful.
Examples for asnmon
The following examples illustrate how to use the asnmon command.
Example 1
To start the Replication Alert Monitor with the default parameters:
asnmon monitor_server=wsdb monitor_qual=monqual
Example 2
To start a Replication Alert Monitor that runs every 120 seconds (two minutes)
for the specified monitor qualifier:
asnmon monitor_server=wsdb monitor_qual=monqual monitor_interval=120
Example 3
To start the Replication Alert Monitor and specify that it run only once for the
specified monitor qualifier:
Example 4
To start a Replication Alert Monitor that sends e-mail notifications if it detects
monitoring errors:
asnmon monitor_server=wsdb monitor_qual=monqual
monitor_errors="repladm@company.com, dbadmin@company.com"
Example 5
To start a Replication Alert Monitor that runs every 120 seconds (two minutes)
and waits 1 440 minutes (24 hours) before sending alerts:
asnmon monitor_server=wsdb monitor_qual=monqual monitor_interval=120
max_notifications_per_alert=2 max_notifications_minutes=1440
This Replication Alert Monitor program sends a maximum of two alerts when
the alerts occurred during the time period specified by the
max_notifications_minutes parameter value (1 440 minutes).
Related tasks:
v Chapter 11, Monitoring replication, on page 175
Related reference:
v asnmcmd: Operating the Replication Alert Monitor (UNIX, Windows,
z/OS) on page 343
Command help appears if you enter the asnpwd command without any
parameters, followed by a ?, or followed by incorrect parameters.
Init parameters:
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 349
asnpwd
|
encrypt all asnpwd.aut
password using filepath_name
Add parameters:
Modify parameters:
Delete parameters:
| alias db_alias
asnpwd.aut
using filepath_name
List parameters:
|
asnpwd.aut
using filepath_name
Table 27. asnpwd invocation parameter definitions for UNIX and Windows operating
systems (continued)
Parameter Definition
| list Specify to list the aliases and user ID entries in a
| password file. This parameter can be used only if the
| password file was created using the encrypt parameter.
| Passwords are never displayed by the list command.
| encrypt Specifies which entries in a file to encrypt.
| all (default)
| Encrypt all entries in the specified file such that you
| cannot list the database aliases, user names, and
| passwords that are in the file. This option reduces
| the exposure of information in password files.
| password
| Encrypt the password entry in the specified file. This
| option allows users to list the database aliases and
| user names stored in their password file. Passwords
| can never be displayed.
using filepath_name Specifies the path and name of the password file. Follow
the file naming conventions of your operating system.
An example of a valid password file on Windows is
C:\sqllib\mypwd.aut.
| Return codes
| The asnpwd command returns a zero return code upon successful completion.
| A nonzero return code is returned if the command is unsuccessful.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 351
asnpwd
Example 1
To create a password file with the default name of asnpwd.aut in the current
directory:
asnpwd INIT
Example 2
To create a password file named pass1.aut in the c:\myfiles directory:
| asnpwd INIT USING c:\myfiles\pass1.aut
| Example 3
| To create a password file named mypwd.aut using the encrypt all parameter:
| asnpwd INIT ENCRYPT ALL USING mypwd.aut
| Example 4
| To create a password file named mypwd.aut using the encrypt password
| parameter:
| asnpwd INIT ENCRYPT PASSWORD USING mypwd.aut
| Example 5
| To create a default password file using the encrypt password parameter:
| asnpwd INIT ENCRYPT PASSWORD
| Example 6
To add a user ID called oneuser and its password to the password file named
pass1.aut in the c:\myfiles directory and to grant this user ID access to the
db1 database:
asnpwd ADD ALIAS db1 ID oneuser PASSWORD mypwd using c:\myfiles\pass1.aut
Example 7
To modify the user ID or password of an entry in the password file named
pass1.aut in the c:\myfiles directory:
asnpwd MODIFY AliaS sample ID chglocalid PASSWORD chgmajorpwd
USING c:\myfiles\pass1.aut
Example 8
To delete the database alias called sample from the password file named
pass1.aut in the c:\myfiles directory:
| asnpwd delete alias sample USING c:\myfiles\pass1.aut
| Example 9
To see command help:
asnpwd
| Example 10
| To list the entries in a default password file:
| asnpwd LIST
| Example 11
| To list the entries in a password file named pass1.aut:
| asnpwd LIST USING pass1.aut
| The output from this command depends on how the password file was
| initialized:
| v If it was initialized using the encrypt all parameter, the following message
| is issued:
| ASN1986E "Asnpwd" : "". The password file "pass1.aut" contains
| encrypted information that cannot be listed.
| v If it was not initialized using the encrypt all parameter, the following
| details are listed:
| asnpwd LIST USING pass1.aut
| Alias: SAMPLE ID: chglocalid
| Number of Entries: 1
| Related reference:
v GRTDPRAUT: Authorizing users (OS/400) on page 422
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 353
asnscrt
Example 1
To create a DB2 Replication Service that invokes a Capture program under a
DB2 instance called inst1:
asnscrt -C inst1 .\joesmith password asncap capture_server=sampledb
capture_schema=ASN capture_path=X:\logfiles
Example 2
To create a DB2 Replication Service that invokes an Apply program under a
DB2 instance called inst2 using a logon account of .\joesmith and a password
of my$pwd:
asnscrt -A inst2 .\joesmith my\$pwd asnapply control_server=db2 apply_qual=aq2
apply_path=X:\sqllib
Example 3
To create a DB2 Replication Service that invokes a Replication Alert Monitor
program under a DB2 instance called inst3:
asnscrt -M inst3 .\joesmith password asnmon monitor_server=db3 monitor_qual=mq3
monitor_path=X:\logfiles
Example 4
To create a DB2 Replication Service that invokes a Capture program under a
DB2 instance called inst4 and overrides the default work file directory with a
fully qualified capture_path:
asnscrt -C inst4 .\joesmith password X:\sqllib\bin\asncap capture_server=scdb
capture_schema=ASN capture_path=X:\logfiles
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 355
asnscrt
Related tasks:
v Chapter 20, Using the Windows Service Control Manager to issue system
commands (Windows), on page 479
Related reference:
v asnsdrop: Dropping a DB2 Replication Service (Windows only) on page
356
v asnapply: Starting Apply (UNIX, Windows, z/OS) on page 322
v asncap: Starting Capture (UNIX, Windows, z/OS) on page 329
v asnmon: Starting the Replication Alert Monitor (UNIX, Windows, z/OS)
on page 344
Example 1
To drop a DB2 Replication Service:
asnsdrop DB2.SAMPLEDB.SAMPLEDB.CAP.ASN
Example 2
To drop a DB2 Replication Service with a schema named A S N:
asnsdrop "DB2.SAMPLEDB.SAMPLEDB.CAP.A S N"
Related tasks:
v Chapter 20, Using the Windows Service Control Manager to issue system
commands (Windows), on page 479
Related reference:
v asnscrt: Creating a DB2 Replication Service to start Capture, Apply, or the
Replication Alert Monitor (Windows only) on page 353
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 357
asntrc
-help
-listsymbols
On parameters:
-b buffer_size -fn filename -fs filesize -d diag_mask
-df function_name|component_name diag_mask
Format parameters:
-fn filename -d diag_mask
-df function_name|component_name diag_mask -holdlock
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 359
asntrc
Table 30. asntrc invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
kill Specify to force an abnormal termination of the trace
facility.
Table 30. asntrc invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
statlong Specify to display the status of a trace facility with
additional z/OS version level information. This
additional information includes the service levels of
each module in the application and appears as long
strings of text.
-fn filename Specifies the file name containing the mirrored trace
information, which includes all the output from the
trace facility.
-help Displays the valid command parameters with
descriptions.
-listsymbols Displays the valid function and component
identifiers to use with the -df parameter.
-b buffer_size Specifies the size of the trace buffer (in bytes). You
can enter a K or an M after the number to indicate
kilobytes or megabytes, respectively; these letters are
not case sensitive.
-fs filesize Specifies the size limit (in bytes) of the mirrored
trace information file.
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 361
asntrc
Table 30. asntrc invocation parameter definitions for UNIX, Windows, and z/OS
operating systems (continued)
Parameter Definition
-d diag_mask Specifies the types of trace records to be recorded by
the trace facility. Trace records are categorized by a
diagnostic mask number:
1 Flow data, which includes the entry and
exit points of functions.
2 Basic data, which includes all major events
encountered by the trace facility.
3 Detailed data, which includes the major
events with descriptions.
4 Performance data.
Example 1
To trace a running Capture program:
1. Start the trace facility, specifying a trace file name with a maximum buffer
and file size:
asntrc on -db mydb -cap -schema myschema -b 256k -fn myfile.trc -fs 500m
2. Start the Capture program, and let it run for an appropriate length of time.
3. While the trace facility is on, display the data directly from shared
memory.
To display the summary process and thread information from the trace
facility:
asntrc flw -db mydb -cap -schema myschema
To view the flow, basic, detailed, and performance data records only from
the Capture log reader:
asntrc fmt -db mydb -cap -schema myschema -d 0
-df "Capture Log Read" 1,2,3,4
4. Stop the trace facility:
asntrc off -db mydb -cap -schema myschema
The trace file contains all of the Capture program trace data that was
generated from the start of the Capture program until the trace facility
was turned off.
5. After you stop the trace facility, format the data from the generated binary
file:
asntrc flw -fn myfile.trc
and
asntrc fmt -fn myfile.trc -d 0 -df "Capture Log Read" 1,2,3,4
Example 2
To start a trace facility of a Replication Alert Monitor program:
asntrc on -db mydb -mon -qualifier monq
Example 3
To trace only performance data of an Apply program:
asntrc on -db mydb -app -qualifier aq1 -b 256k -fn myfile.trc -d 4
Example 4
To trace all flow and performance data of a Capture program:
asntrc on dbserv1 -cap -schema myschema -b 256k
-fn myfile.trc -d 1,4
Example 5
To trace all global performance data and the specific Capture log reader flow
data of a Capture program:
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 363
asntrc
Example 6
To trace a running Capture program and then display and save a
point-in-time image of the trace facility:
1. Start the trace command, specifying a buffer size large enough to hold the
latest records:
asntrc on -db mydb -cap -schema myschema -b 4m
2. Start the Capture program, and let it run for an appropriate length of time.
3. View the detailed point-in-time trace information that is stored in shared
memory:
asntrc fmt -db mydb -cap -schema myschema
4. Save the point-in-time trace information to a file:
asntrc dmp myfile.trc -db mydb -cap -schema myschema
5. Stop the trace facility:
asntrc off -db mydb -cap -schema myschema
| With the Capture program, the database specified by the -db parameter with
| the asntrc command needs to match the database specified by the
| capture_server parameter with the asncap command:
| asntrc -db DSN6 -schema JAY -cap
| asncap capture_server=DSN6 capture_schema=JAY
| With the Apply program, the database specified by the -db parameter with
| the asntrc command needs to match the database specified by the
| control_server parameter with the asnapply command:
| asntrc -db SVL_LAB_DSN6 -qualifier MYQUAL -app
| asnapply control_server=SVL_LAB_DSN6 apply_qual=MYQUAL
| With the Alert Monitor program, the database specified by the -db parameter
| with the asntrc command needs to match the database specified by the
| monitor_server parameter with the asnmon command:
| asntrc -db DSN6 -qualifier MONQUAL -mon
| asnmon monitor_server=DSN6 monitor_qual=MONQUAL
| Related reference:
v WRKDPRTRC: Using the DPR trace facility (OS/400) on page 466
Chapter 17. System commands for replication (UNIX, Windows, z/OS) 365
asntrc
This chapter contains a section for each command. Each section contains a
brief description of the command, a syntax diagram, and a table of parameters
with corresponding definitions. The end of each section has examples of
command usage and cross-references to related information.
| Restriction: You can register a table only if the ASN (Capture schema) library
is in the same Auxiliary Pool (either base or independent ASP) where the ASN
library is located.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
ASN *SRCTBL
CAPCTLLIB ( library-name ) CDLIB ( library-name )
*DEFAULT *USERTABLE
CDNAME ( cdname ) SRCTYPE ( *POINTINTIME )
*BASEAGR
*CHANGEAGR
*REPLICA
*USERCOPY
*CCD
*YES *NONE
REFRESH ( *NO ) TEXT ( description )
*ALL *NO
*NONE CAPRRN ( *YES )
(1)
CAPCOL ( column-name )
*AFTER
IMAGE ( *BOTH ) *DEFAULT
PREFIX ( *NULL )
character
*YES
*YES COMPLETE ( *NO )
CONDENSED ( *NO )
*AGGREGATE
*LOCAL *SRCTBL
SRCTBLRDB ( rdbname ) RMTJRN ( library-name/journal-name )
*NO
*NONE UPDDELINS ( *YES )
CONFLICT ( *STANDARD )
*ENHANCED
*ALLCHG *YES
GENCDROW ( *REGCOLCHG ) RECAP ( *NO )
*NO
STOPONERR ( *YES )
Notes:
1 You can specify up to 300 column names.
REFRESH Specifies whether the full-refresh capability is enabled. You can use
this value to turn off the capability of the Apply program to
perform a full refresh from the source database.
*YES (default)
Full refreshes are allowed.
*NO
Full refreshes are not allowed.
If the target table is a base aggregate or change aggregate, you
should set this parameter to *NO.
TEXT Specifies the textual description that is associated with this
registration.
*NONE (default)
No description is associated with the entry.
description
The textual description of this registration. You can enter a
maximum of 50 characters and must enclose the text in single
quotation marks.
The source table must be journaled with *BOTH images even if you
specify *AFTER on this parameter.
*AFTER (default)
The Capture program records only after images of the source
table in the CD table.
*BOTH
The Capture program records both before images and after
images of the source table in the CD table.
| Notes:
| 1. If this parameter is set to Yes (Y), the Capture journal job stops while other journal
| jobs continue to run. If this parameter is set to No (N), the Capture program stops
| the registration file that contains the error.
| This parameter also sets the columns in the register table rows. The STATE column
| is set to S and the STATE_INFO column to is set 200Axxxx where xxxx is the
| reason code. To set the registration back to the Action (A) state, perform the
| following steps:
| v Correct the ASN200A message. Refer to the appropriate OS/400 documentation
| for the corrected action.
| v Use the Replication Center or the OS/400 command STRSQL to set the columns
| in the IBMSNAP_REGISTER table row. Set the STATE column to A, and the
| STATE_INFO column to null.
| v If Capture is running, issue the INZDPRCAP command to reinitialize data
| replication for that journal.
Example 1
To register a source table named EMPLOYEE from the HR library under the
default Capture schema:
ADDDPRREG SRCTBL(HR/EMPLOYEE)
Example 2
To register a source table named EMPLOYEE from the HR library under the
BSN Capture schema and to create a CD table named CDEMPLOYEE under
the HRCDLIB library:
ADDDPRREG SRCTBL(HR/EMPLOYEE) CAPCTLLIB(BSN) CDLIB(HRCDLIB) CDNAME(CDEMPLOYEE)
Example 3
To register a source table with a source type of point-in-time that is named
SALES from the DEPT library under the BSN Capture schema:
ADDDPRREG SRCTBL(DEPT/SALES) CAPCTLLIB(BSN) SRCTYPE(*POINTINTIME)
Example 4
To register a source table named SALES from the DEPT library and to specify
that the CD table contains both before and after images of source table
changes:
ADDDPRREG SRCTBL(DEPT/SALES) IMAGE(*BOTH)
Example 5
To register a source table named SALES from the DEPT library of the
relational database named RMTRDB1 using remote journals:
ADDDPRREG SRCTBL(DEPT/SALES) SRCTBLRDB(RMTRDB1) RMTJRN(RMTJRNLIB/RMTJRN)
Example 6
To register the EMPLOYEE source table from the HR library and to capture
changes only for the EMPNO, NAME, DEPT, and NETPAY columns:
ADDDPRREG SRCTBL(HR/EMPLOYEE) CAPCOL(EMPNO NAME DEPT NETPAY)
Related tasks:
v Chapter 3, Registering tables and views as replication sources, on page 43
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*NONE *NONE
SRCTBL ( library-name/file-name ) TGTTBL ( library-name/file-name )
*LOCAL *LOCAL
CTLSVR ( rdb-name ) SRCSVR ( rdb-name )
*USERCOPY *INTERVAL
TGTTYPE ( *POINTINTIME ) TIMING ( *EVENT )
*BASEAGR *BOTH
*CHANGEAGR
*CCD
*REPLICA
*NONE
EVENT ( event-name )
INTERVAL ( num *MIN) (num *HOUR) (num *DAY) (num *WEEK )
*YES *YES *YES
ACTIVATE ( *NO ) CRTTGTTBL ( *NO ) CHKFMT ( *NO )
ASN *CAPCTLLIB
CAPCTLLIB ( library-name ) TGTCCLIB ( library-name )
*NONE
FEDSVR ( server-name ) *DEFAULT
CMTCNT ( *NULL )
num-transactions
*NO *ALL
TGTKEYCHG ( *YES ) COLUMN ( *NONE )
(1)
column-name
*YES *SRCTBL
UNIQUE ( *NO ) KEYCOL ( *RRN )
*NONE
(2)
column-name
*COLUMN
(3)
TGTCOL ( (column-name new-name) )
*NONE *NO
ADDREG ( *YES )
(4)
CALCCOL ( (column-name expression) )
*ALL
ROWSLT ( WHERE-clause )
0
MAXSYNCH
(num *MIN) (num *HOUR) (num *DAY) (num *WEEK)
*NONE *NONE
*NONE *NONE
Notes:
1 You can specify up to 300 column names.
2 You can specify up to 120 column names.
3 You can specify up to 300 column names.
4 You can specify up to 100 column names and expressions.
5 You can specify up to 3 SQL statements.
6 You can specify up to 10 SQLSTATES.
7 You can specify up to 3 SQL statements.
8 You can specify up to 10 SQLSTATES.
If the table or view exists and you set CHKFMT to *YES, the
ADDDPRSUB command ensures that the format of the existing
table matches the subscription-set definition that you set. If
CHKFMT is *NO, you must ensure that the format of the existing
table matches the subscription-set definition.
If you use a column as a key more than once and with different
ordering, the target table key is defined with ascending order.
*RRN
The key column in the target table is the IBMQSQ_RRN
column. The target table is created with an IBMQSQ_RRN
column, and this column is used as the key. When the Apply
program runs, if the source table is a user table and the target
table is a point-in-time or user copy, the IBMQSQ_RRN column
in the target table is updated with the relative record number of
the associated record in the source table. Otherwise, the
IBMQSQ_RRN column in the target table is updated with the
value of the IBMQSQ_RRN column in the source table.
*NONE
The target copy does not contain a target key. You cannot
specify *NONE if the target table type is *POINTINTIME,
*REPLICA, or *USERCOPY.
column-name
The names of the target columns that you want to use as the
target key columns. You can specify up to 120 column names.
Separate the column names with spaces.
You must specify a column name for each SQL expression. If you
want to define any column as an SQL expression without a GROUP
BY statement, you must set the COLUMN parameter to *NONE.
*NONE (default)
No user-defined or calculated columns are included in the
target table.
column-name
The column names of the user-defined or calculated columns in
the target table. You can list up to 100 column names.
expression
The expressions for the user-defined or calculated columns in
the target table. You can list up to 100 SQL column expressions.
If you set the CRTTGTTBL parameter to *NO, you must create the
target table before attempting to register it as a source.
ROWSLT Specifies the predicates to be placed in an SQL WHERE clause. The
Apply program uses these predicates to determine which rows in
the change-data (CD) table of the source to apply to the target table.
Use this parameter if you want only a subset of the source changes
to be replicated to the target table.
*ALL (default)
The Apply program applies all changes in the CD table to the
target table.
WHERE-clause
The SQL WHERE clause that specifies which rows from the CD
table the Apply program applies to the target table. Do not
include the WHERE keyword; it is implied on this parameter.
This WHERE clause must be valid on the data server you are
using to run the clause.
The default is zero (0), which indicates that all of the change data is
to be applied.
Example 1
To create a subscription set named SETHR under the AQHR Apply qualifier:
ADDDPRSUB APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/EMPLOYEE)
TGTTBL(TGTLIB/TGTEMPL)
Example 2
To create a subscription set named SETHR with only two columns, EMPNO
(the key) and NAME, from the registered source table named EMPLOYEE and
replicate these columns to an existing target table named TGTEMPL:
ADDDPRSUB APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/EMPLOYEE)
TGTTBL(TGTLIB/TGTEMPL) CRTTGTTBL(*NO) COLUMN(EMPNO NAME) KEYCOL(EMPNO)
Example 3
To create a subscription set named SETHR with data from the registered
source table named EMPLOYEE and to replicate this data to a replica type
target table named TGTREPL:
ADDDPRSUB APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/EMPLOYEE)
TGTTBL(TGTLIB/TGTREPL) TGTTYPE(*REPLICA)
Example 4
To create a subscription set named NOMEM with no subscription-set
members:
ADDDPRSUB APYQUAL(AQHR) SETNAME(NOMEM) SRCTBL(*NONE) TGTTBL(*NONE)
Related tasks:
v Chapter 4, Subscribing to sources, on page 71
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*LOCAL *LOCAL
CTLSVR ( rdb-name ) SRCSVR ( rdb-name )
*USERCOPY *ALL
TGTTYPE ( *POINTINTIME ) ROWSLT ( WHERE-clause )
*BASEAGR
*CHANGEAGR
*CCD
*REPLICA
*YES *YES
CRTTGTTBL ( *NO ) CHKFMT ( *NO )
*NO *ALL
TGTKEYCHG ( *YES ) COLUMN ( *NONE )
(1)
column-name
*YES *SRCTBL
UNIQUE ( *NO ) KEYCOL ( *RRN )
*NONE
(2)
column-name
*COLUMN
(3)
TGTCOL ( (column-name new-name) )
*NONE
(4)
CALCCOL ( (column-name expression) )
*NO
ADDREG ( *YES )
Notes:
1 You can specify up to 300 column names.
2 You can specify up to 120 column names.
3 You can specify up to 300 column names.
If the table or view exists and you set CHKFMT to *YES, the
ADDDPRSUBM command ensures that the format of the existing
table matches the subscription-set definition that you set. If
CHKFMT is *NO, you must ensure that the format of the existing
table matches the subscription-set definition.
If you use a column as a key more than once and with different
ordering, the target table key is defined with ascending order.
*RRN
The key column in the target table is the IBMQSQ_RRN
column. The target table is created with an IBMQSQ_RRN
column, and this column is used as the key. When the Apply
program runs, if the source table is a user table and the target
table is a point-in-time table or user copy, the IBMQSQ_RRN
column in the target table is updated with the relative record
number of the associated record in the source table. Otherwise,
the IBMQSQ_RRN column in the target table is updated with
the value of the IBMQSQ_RRN column in the source table.
*NONE
The target copy does not contain a target key. You cannot
specify *NONE if the target table type is *POINTINTIME,
*REPLICA, or *USERCOPY.
column-name
The names of the target columns that you want to use as the
target key columns. You can specify up to 120 column names.
Separate the column names with spaces.
You must specify a column name for each SQL expression. If you
want to define any column as an SQL expression without a GROUP
BY clause, you must set the COLUMN parameter to *NONE.
*NONE (default)
No user-defined or calculated columns are included in the
target table.
column-name
The column names of the user-defined or calculated columns in
the target table. You can list up to 100 column names.
expression
The expressions for the user-defined or calculated columns in
the target table. You can list up to 100 SQL column expressions.
If you set the CRTTGTTBL parameter to *NO, you must create the
target table before attempting to register it as a source.
Example 1
To add a subscription-set member to a subscription set named SETHR under
the AQHR Apply qualifier:
ADDDPRSUBM APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/YTDTAX) TGTTBL(TGTHR/TGTTAX)
Example 2
To add a subscription-set member with only two columns, AMOUNT and
NAME, from the registered source table named YTDTAX and to replicate
these columns to an existing target table named TGTTAX:
ADDDPRSUBM APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/YTDTAX) TGTTBL(TGTLIB/TGTTAX)
CRTTGTTBL(*NO) COLUMN(AMOUNT NAME) CHKFMT(*YES)
This command verifies that the AMOUNT and NAME columns defined for
this subscription-set member match the columns in the target table.
Example 3
To add a subscription-set member to subscription set named SETHR and to
replicate this data to a consistent-change data target table named TGTYTD:
ADDDPRSUBM APYQUAL(AQHR) SETNAME(SETHR) SRCTBL(HR/YTDTAX) TGTTBL(TGTLIB/TGTYTD)
TGTTYPE(*CCD) ADDREG (*YES)
This command registers the target table as a source table for DB2
DataPropagator for iSeries.
Related tasks:
v Chapter 4, Subscribing to sources, on page 71
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
(1)
RDB ( rdb-name )
*CURLIB ANZDPR
OUTFILE ( library-name file-name )
3
*STANDARD CAPTRC ( no-of-days )
ANZLVL ( *SIMPLE )
*DETAILED
3 3
APYTRC ( no-of-days ) APYTRAIL ( no-of-days )
3 3
SIGTBL ( no-of-days ) CAPMON ( no-of-days )
*ALL *ALL
APYQUAL ( apply-qualifier ) CAPCTLLIB ( library-name )
Notes:
1 You can specify up to 10 databases.
If the file name already exists, the file is overwritten. If the file name
does not exist, the command creates the file with attributes of
RCDLEN(512) and SIZE(*NOMAX).
Example 1
To run the Analyzer on both your local database and a remote database
named RMTRDB1 using a standard level of analysis:
ANZDPR RDB(*LOCAL RMTRDB1) OUTFILE(MYLIB/ANZDPR) ANZLVL(*STANDARD) CAPTRC(1)
APYTRC(1) APYTRAIL(1) SIGTBL(1) CAPMON(1) APYQUAL(*ALL)
Example 2
To run the Analyzer with all default values:
ANZDPR
Related reference:
v asnanalyze: Operating the Analyzer (UNIX and Windows) on page 319
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*SAME *SAME
RETAIN ( retention-limit ) LAG ( lag-limit )
*SAME *SAME
FRCFRQ ( force-frequency ) CLNUPITV ( prune-interval )
*SAME *SAME
TRCLMT ( trace-limit ) MONLMT ( monitor-limit )
*SAME *SAME
MONITV ( monitor-interval ) MEMLMT ( memory-limit )
This value works with the CLNUPITV parameter value. When the
CLNUPITV value is reached, the CD, UOW, IBMSNAP_SIGNAL,
and IBMSNAP_AUTHTKN data is removed if this data is older
than the retention limit.
When the lag limit is reached (that is, when the timestamp of the
journal entry is older than the current timestamp minus the lag
limit), the Capture program initiates a cold start for the tables that
it is processing for that journal. The Apply program then performs
a full refresh to provide the Capture program with a new starting
point.
Example 1
To change the frequency of row insertion to 6 000 seconds (100 minutes) by
the Capture program into the IBMSNAP_CAPMON table:
CHGDPRCAPA CAPCTLLIB(ASN) MONITV(6000)
Example 2
To change the retention limit, lag limit, trace limit, and monitor limit in the
IBMSNAP_CAPPARMS table located in a Capture control library called LIB1:
CHGDPRCAPA CAPCTLLIB(LIB1) RETAIN(6000) LAG(3000) TRCLMT(3000) MONLMT(6000)
Example 3
To change the commit interval, which indicates how frequently the Capture
program writes changes to the CD and UOW tables:
CHGDPRCAPA CAPCTLLIB(ASN) FRCFRQ(360)
Related tasks:
v Chapter 9, Operating the Capture program, on page 127
Important: The CRTDPRTBL command is the only command that you should
use to create OS/400 control tables. Do not use the Replication Center to
create the control tables.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
CRTDPRTBL
ASN
CAPCTLLIB ( library-name )
Example 1
To create new replication control tables in the default ASN library:
CRTDPRTBL CAPCTLLIB(ASN)
Example 2
To create new replication control tables for a Capture schema called
DPRSALES:
CRTDPRTBL CAPCTLLIB(DPRSALES)
Related tasks:
v Chapter 2, Setting up for replication, on page 17
You should stop the Apply program before any planned system down time.
You might also want to end the Apply program during periods of peak
system activity.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*USER *LOCAL
APYQUAL( apply-qualifier ) CTLSVR( rdb-name )
Usage notes
The ENDDPRAPY command uses the value of the APYQUAL and CTLSVR
parameters to search the Apply job (IBMSNAP_APPLY_JOB) table for the job
name, job number, and job user for the referenced Apply program, and ends
that job.
Example 1
To end the Apply program that uses the AQHR Apply qualifier:
ENDDPRAPY OPTION(*CNTRLD) APYQUAL(AQHR)
The Apply program ends after all of its tasks are completed.
Example 2
To end the Apply program immediately:
ENDDPRAPY OPTION(*IMMED) APYQUAL(AQHR)
The tasks of the Apply program end immediately, without any cleanup.
Example 3
To end an Apply program that uses Apply control tables that reside on a
relational database named DB1X:
ENDDPRAPY OPTION(*CNTRLD) APYQUAL(AQHR) CTLSVR(DB1X)
Related tasks:
v Chapter 10, Operating the Apply program, on page 149
Use this command to stop the Capture program before shutting down the
system. You might also want to stop the program during periods of peak
system use to increase the performance of other programs that run on the
system.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*NO
RGZCTLTBL ( *YES )
Usage notes
If you use the ENDJOB command, temporary objects might be left in the
QDP4 library. These objects have the types *DTAQ and *USRSPC, and are
named QDP4nnnnnn, where nnnnnn is the job number of the job that used
them. You can delete these objects when the job that used them (identified by
the job number in the object name) is not active.
If the job under the Capture control library will not end after issuing this
command, use the ENDJOB command with *IMMED option to end this job
and all the journal jobs running in the DB2 DataPropagator for iSeries
subsystem. Do not end Apply jobs running in the same subsystem if you
want to end only the Capture program.
In rare cases when the Capture control job ends abnormally, the journal jobs
created by Capture control job (which is named according to the CAPCTLLIB
parameter) might still be left running. The only way to end these jobs is to
use the ENDJOB command with either the *IMMED or *CNTRLD option.
Examples for ENDDPRCAP
The following examples illustrate how to use the ENDDPRCAP command.
Example 1
To end the Capture program, which uses Capture control tables in the ASN
library, after all processing tasks are completed:
ENDDPRCAP OPTION(*CNTRLD) CAPCTLLIB(ASN) RGZCTLTBL(*NO)
Example 2
To end the Capture program immediately for the Capture schema BSN:
ENDDPRCAP OPTION(*IMMED) CAPCTLLIB(BSN) RGZCTLTBL(*NO)
Example 3
To end the Capture program after all processing tasks are completed and to
reorganize the Capture control tables:
ENDDPRCAP OPTION(*CNTRLD) CAPCTLLIB(ASN) RGZCTLTBL(*YES)
Related tasks:
v Chapter 9, Operating the Capture program, on page 127
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*REGISTRAR *ALL
AUT( *SUBSCRIBER ) APYQUAL( *USER )
*CAPTURE apply-qualifier
*APPLY
Usage notes
You cannot use the GRTDPRAUT command while the Capture or Apply
programs are running, or when applications that use the source tables are
active because authorizations cannot be changed on files that are in use.
The following tables list the authorities granted when you specify:
v AUT(*REGISTRAR)
v AUT*(SUBSCRIBER)
v AUT(*CAPTURE)
v AUT(*APPLY)
on the GRTDPRAUT command.
The following table lists the authorities granted when you specify the
AUT(*REGISTRAR) parameter on the GRTDPRAUT command.
Notes:
1. The entry capctllib in the Library column refers to the value passed to the
CAPCTLLIB parameter of the GRTDPRAUT command; this command updates
authority to only one Capture control library at a time.
The following table lists the authorities granted when you specify the
AUT(*SUBSCRIBER) parameter on the GRTDPRAUT command.
Notes:
1. The entry capctllib in the Library column refers to the value passed to the
CAPCTLLIB parameter of the GRTDPRAUT command; this command updates
authority to only one Capture control library at a time.
The following table lists the authorities granted when you specify the
AUT(*CAPTURE) parameter on the GRTDPRAUT command.
Table 42. Authorities granted with GRTDPRAUT AUT(*CAPTURE)
Library Object Type Authorizations
QSYS capctllib *LIB *OBJOPR,
*OBJMGT, *READ,
*EXECUTE
QSYS QDP4 *LIB *OBJOPR, *ADD,
*READ,
*EXECUTE
capctllib1 QZSN *MSGQ *CHANGE
Notes:
1. The entry capctllib in the Library column refers to the value passed to the
CAPCTLLIB parameter of the GRTDPRAUT command; this command updates
authority to only one Capture control library at a time.
The following table lists the authorities granted when you specify the
AUT(*APPLY) parameter on the GRTDPRAUT command.
Table 43. Authorities granted with GRTDPRAUT AUT(*APPLY)
Library Object Type Authorizations
QSYS ASN *LIB *OBJOPR, *READ,
*EXECUTE
QSYS capctllib *LIB *OBJOPR, *READ,
*EXECUTE
Notes:
1. The entry capctllib in the Library column refers to the value passed to the
CAPCTLLIB parameter of the GRTDPRAUT command; this command updates
authority to only one Capture control library at a time.
Example 1
To authorize a user named USER1 to define and modify registrations:
GRTDPRAUT CAPCTLLIB(ASN) USER(USER1) AUT(*REGISTRAR)
Example 2
To authorize a user named USER1 to define and modify subscription sets:
GRTDPRAUT CAPCTLLIB(ASN) USER(USER1) AUT(*SUBSCRIBER)
Example 3
To authorize a user named USER1 to run Capture programs:
GRTDPRAUT CAPCTLLIB(ASN) USER(USER1) AUT(*CAPTURE)
Example 4
To authorize a user named USER1 to define and modify existing subscription
sets that are associated with Apply qualifier A1:
Example 5
To authorize a user to run the Apply program on the control server system for
all subscription sets associated with Apply qualifier A1, where the target
server is the same as the control server:
1. Run the following command on the system where the Apply program will
run:
GRTDPRAUT CAPCTLLIB(ASN) USER(USER1) AUT(*APPLY) APYQUAL(A1)
2. Run the appropriate GRTDPRAUT command on the source server system:
v If the application server job on the source server used by the Apply
program runs under user profile USER1, run the following command on
the source server systems:
GRTDPRAUT CAPCTLLIB(ASN) USER(USER1) AUT(*APPLY) APYQUAL(A1)
v If the application server job on the source server used by the Apply
program runs under a different user profile, for example, QUSER, the
command is:
GRTDPRAUT CAPCTLLIB(ASN) USER(QUSER) AUT(*APPLY) APYQUAL(A1)
Related tasks:
v Chapter 2, Setting up for replication, on page 17
Related reference:
v asnpwd: Maintaining password files (UNIX and Windows) on page 349
v RVKDPRAUT: Revoking authority (OS/400) on page 446
Source tables under the control of a Capture program can change while the
Capture program is running. Use the INZDPRCAP command to ensure that
the Capture program processes the most up-to-date replication sources.
The Capture program must be running before you can run this command.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*ALL
JRN( library-name/journal-name )
Example 1
To initialize a Capture program using the QSQJRN journal under a library
named TRAINING:
INZDPRCAP CAPCTLLIB(ASN) JRN(TRAINING/QSQJRN)
Example 2
To initialize a Capture program that works with all the journals:
INZDPRCAP CAPCTLLIB(BSN) JRN(*ALL)
Related tasks:
v Chapter 9, Operating the Capture program, on page 127
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*SAME *SAME
RETAIN ( retention-limit ) FRCFRQ ( force-frequency )
*SAME *SAME
CLNUPITV ( prune-interval ) TRCLMT ( trace-limit )
*SAME *SAME
MONLMT ( monitor-limit ) MONITV ( monitor-interval )
*SAME *SAME
MEMLMT ( memory-limit ) PRUNE ( *IMMED )
*DELAYED
*NO
This value works with the CLNUPITV parameter value from the
Start DPR Capture (STRDPRCAP) command. First, the Capture
program deletes any CD, UOW, IBMSNAP_SIGNAL, or
IBMSNAP_AUTHTKN rows that are older than the oldest currently
running Apply program. Then, a new or remaining row from the
CD, UOW, IBMSNAP_SIGNAL, or IBMSNAP_AUTHTKN table is
subsequently deleted when its age reaches the value of the RETAIN
parameter.
Ensure that the Apply intervals are set to copy changed information
before the data reaches this RETAIN parameter value to prevent
inconsistent data in your tables. If the data becomes inconsistent, the
Apply program performs a full refresh.
Example 1
To change the pruning parameters of the CD, UOW, IBMSNAP_SIGNAL,
IBMSNAP_CAPMON, IBMSNAP_CAPTRACE, and IBMSNAP_AUTHTKN
tables (which reside under the default ASN library) and to change the
IBMSNAP_CAPMON monitor interval and memory limit of Capture journal
jobs in a running Capture program:
OVRDPRCAPA CAPCTLLIB(ASN) CLNUPITV(12) MONITV(600) MEMLMT(64)
Example 2
To initiate pruning of the CD, UOW, IBMSNAP_SIGNAL,
IBMSNAP_CAPMON, IBMSNAP_CAPTRACE, and IBMSNAP_AUTHTKN
tables, which reside in the BSN library:
Related tasks:
v Chapter 9, Operating the Capture program, on page 127
Related reference:
v asnccmd: Operating Capture (UNIX, Windows, z/OS) on page 336
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
ASN
CAPCTLLIB ( library-name )
Example 1
To remove the registration for the source table named EMPLOYEE of the HR
library in the default ASN Capture schema:
RMVDPRREG SRCTBL(HR/EMPLOYEE)
Example 2
To remove the registration for the source table named SALES of the DEPT
library under a Capture schema called BSN:
RMVDPRREG SRCTBL(DEPT/SALES) CAPCTLLIB(BSN)
Related tasks:
v Chapter 12, Making changes to your replication environment, on page 197
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*LOCAL *NO
CTLSVR ( rdb-name ) RMVREG ( *YES )
*NO *NO
DLTTGTTBL ( *YES ) RMVMBRS ( *YES )
Example 1
To remove a subscription set named SETHR that contains no subscription-set
members:
RMVDPRSUB APYQUAL(AQHR) SETNAME(SETHR)
Example 2
To remove a subscription set named SETHR and all its subscription-set
members:
RMVDPRSUB APYQUAL(AQHR) SETNAME(SETHR) RMVMBRS(*YES)
Example 3
To remove a subscription set named SETHR, all its subscription-set members,
and the associated registrations:
RMVDPRSUB APYQUAL(AQHR) SETNAME(SETHR) RMVREG(*YES) RMVMBRS(*YES)
Related tasks:
v Chapter 12, Making changes to your replication environment, on page 197
v Chapter 4, Subscribing to sources, on page 71
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
TGTTBL ( library-name/file-name )
*LOCAL
CTLSVR ( rdb-name )
*NO *NO
RMVREG ( *YES ) DLTTGTTBL ( *YES )
Example 1
To remove a subscription-set member, which uses a target table named EMP,
from the SETEMP subscription set on the relational database named
RMTRDB1:
RMVDPRSUBM APYQUAL(AQHR) SETNAME(SETEMP) TGTTBL(TGTEMP/EMP) CTLSVR(RMTRDB1)
Example 2
To remove a subscription-set member from the SETHR subscription set,
remove the registration, and then drop the table:
RMVDPRSUBM APYQUAL(AQHR) SETNAME(SETHR) TGTTBL(TGTHR/YTDTAX) RMVREG(*YES)
DLTTGTTBL(*YES)
Related tasks:
v Chapter 4, Subscribing to sources, on page 71
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
Usage notes
The command returns an error message if any of the following conditions
exist:
v A specified user does not exist.
v The user running the command is not authorized to the specified user
profiles.
v The user running the command does not have permission to revoke
authorities to the DB2 DataPropagator for iSeries control tables.
v The DB2 DataPropagator for iSeries control tables do not exist.
v The Capture or Apply programs are running.
Examples for RVKDPRAUT
The following examples illustrate how to use the RVKDPRAUT command.
Example 1
To revoke the authority from a user named HJONES to the control tables
under the ASN library:
RVKDPRAUT CAPCTLLIB(ASN) USER(HJONES)
Example 2
To revoke the authority from all users that were not specified in the
GRTDPRAUT command so that they cannot access the control tables in the
ASN library:
RVKDPRAUT CAPCTLLIB(ASN) USER(*PUBLIC)
Related tasks:
v Chapter 2, Setting up for replication, on page 17
Related reference:
v GRTDPRAUT: Authorizing users (OS/400) on page 422
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*LIBL/QZSNDPR
JOBD( library-name/job-description-name )
*USER *LOCAL
APYQUAL( apply-qualifier ) CTLSVR( rdb-name )
*NONE *NONE
TRACE( *ERROR ) FULLREFPGM( library-name/program-name )
*ALL
*PRF
*REWORK
*NONE *YES
SUBNFYPGM( library-name/program-name ) INACTMSG( *NO )
*YES 6
ALWINACT( *NO ) DELAY( delay-time )
300 *NO
RTYWAIT( retry-wait-time ) COPYONCE( *YES )
*NO *NO
TRLREUSE( *YES ) OPTSNGSET( *YES )
JOBD Specifies the name of the job description to use when submitting the
Apply program.
*LIBL/QZSNDPR (default)
The default job description provided with DB2 DataPropagator
for iSeries.
library-name/job-description-name
The name of the job description used for the Apply program.
CTLSVR Specifies the relational database name of the system that contains
the Apply control tables.
*LOCAL (default)
The Apply control tables reside locally (on the machine where
you are running the STRDPRAPY command).
rdb-name
The name of the relational database where the Apply control
tables reside. You can use the Work with RDB Directory Entries
(WRKRDBDIRE) command to find this name.
When prompting on the STRDPRAPY command, you can press
the F4 key to see a list of available RDB names.
ALWINACT Specifies whether the Apply program can run in an inactive (sleep)
state.
*YES (default)
The Apply program sleeps if there is nothing to process.
*NO
If the Apply program has nothing to process, the job that
submitted and started the Apply program ends.
RTYWAIT Specifies how long (in seconds) the Apply program is to wait after it
encounters an error before it retries the operation that failed.
300 (default)
The retry wait time is 300 seconds (five minutes).
retry-wait-time
The wait time, entered as a number between 0 and 35000000
inclusive, before the Apply program retries the failed operation.
COPYONCE Specifies whether the Apply program executes one copy cycle for
each subscription set that is eligible at the time the Apply program
is invoked. Then the Apply program terminates. An eligible
subscription set meets the following criteria:
v (ACTIVATE > 0) in the subscription sets (IBMSNAP_SUBS_SET)
table. When the ACTIVATE column value is greater than zero, the
subscription set is active indefinitely or is used for a
one-time-only subscription processing.
v (REFRESH_TYPE = R or B) or (REFRESH_TYPE = E and the
specified event occurred). The REFRESH_TYPE column value is
stored in the IBMSNAP_SUBS_SET table.
The MAX_SYNCH_MINUTES limit from the IBMSNAP_SUBS_SET
table and the END_OF_PERIOD timestamp from the subscription
events (IBMSNAP_SUBS_EVENT) table are honored if specified.
*NO (default)
The Apply program does not execute one copy cycle for
each eligible subscription set.
*YES The Apply program executes one copy cycle for each
eligible subscription set and then terminates.
If you set this parameter to *YES, the Apply program fetches the
members and columns of a subscription set only once and reuses
this fetched information when processing the same subscription set
in two or more consecutive processing cycles.
*NO (default)
The performance of the Apply program is not optimized if
only one subscription set is processed.
*YES The performance of the Apply program is optimized if only
one subscription set is processed. The Apply program
reuses the subscription set information during subsequent
processing cycles, requiring less CPU resources and
improving throughput rates.
Usage notes
You can set up the system to start the subsystem automatically by adding the
command that is referred to in the QSTRUPPGM value on your system. If you
use the QDP4/QZSNDPR subsystem, it is started as part of the STRDPRAPY
command processing.
v If the user running the command is not authorized to the user profile
specified on the command or the job description.
v If an instance of the Apply program is already active on the local system
for this combination of Apply qualifier and control server.
v If the RDB name specified by the CTLSVR parameter is not in the
relational database directory.
v If the control tables do not exist on the RDB specified by the CTLSVR
parameter.
v If no subscription sets are defined for the Apply qualifier specified by the
APYQUAL parameter.
An Apply program must be started for each unique Apply qualifier in every
subscription sets (IBMSNAP_SUBS_SET) table. You can start multiple Apply
programs by specifying a different Apply qualifier each time that you issue
the STRDPRAPY command. These Apply programs will run under the same
user profile.
Example 1
To start the Apply program that uses the AQHR Apply qualifier and Apply
control tables that reside locally and to generate a trace file that contains error
and execution flow information:
STRDPRAPY APYQUAL(AQHR) CTLSVR(*LOCAL) TRACE(*ALL)
Example 2
To start an Apply program with Apply control tables that reside locally and to
specify that the job that started this Apply program automatically end when
the Apply program has nothing left to process:
STRDPRAPY APYQUAL(AQHR) CTLSVR(*LOCAL) ALWINACT(*NO)
Example 3
To start an Apply program that empties the IBMSNAP_APPLYTRAIL table
during program startup:
STRDPRAPY APYQUAL(AQHR) CTLSVR(*LOCAL) TRLREUSE(*YES)
Example 4
To start an Apply program with all default values:
STRDPRAPY
Related tasks:
v Chapter 10, Operating the Apply program, on page 149
Related reference:
v asnapply: Starting Apply (UNIX, Windows, z/OS) on page 322
After you start the Capture program, it runs continuously until you stop it or
it detects an unrecoverable error.
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
*LIBL/QZSNDPR 120
JOBD( library-name/job-description-name ) WAIT ( value )
*DFT *IMMED
CLNUPITV ( hours-to-wait *DELAYED )
*NO
ASN
CAPCTLLIB ( library-name )
*ALL
(1)
JRN ( library-name/journal-name )
*DFT *DFT
TRCLMT ( trace-limit ) MONLMT ( monitor-limit )
*DFT *DFT
MONITV ( monitor-interval ) MEMLMT ( memory-limit )
*DFT *DFT
RETAIN ( retention-limit ) LAG ( lag-limit )
*DFT
FRCFRQ ( force-frequency )
Notes:
1 You can specify up to 50 journals.
A low value reduces the time that the Capture program takes
before ending or initializing, but can have a negative effect on
system performance. A higher value increases the time that the
Capture program takes before ending or initializing, but can
improve system performance. A value that is too high can result in
decreased responsiveness while the Capture program is
performing periodic processing. The amount of the decrease in
responsiveness depends on the amount of change activity to
source tables and the amount of other work occurring on the
system.
120 (default)
The Capture program waits 120 seconds.
value
The maximum number of seconds that the Capture program
waits.
TRCLMT Specifies the trace limit (in minutes). The Capture program prunes
any Capture trace (IBMSNAP_CAPTRACE) table rows that are
older than the trace limit. The default is 10 080 minutes (seven
days of trace entries).
*DFT (default)
The Capture program uses the TRACE_LIMIT column value
from the Capture parameters (IBMSNAP_CAPPARMS) table.
trace-limit
The number of minutes of trace data kept in the
IBMSNAP_CAPTRACE table after pruning.
MONITV Specifies how frequently (in seconds) the Capture program inserts
rows into the Capture monitor (IBMSNAP_CAPMON) table. The
default is 300 seconds (five minutes).
*DFT (default)
The Capture program uses the MONITOR_INTERVAL column
value from the Capture parameters (IBMSNAP_CAPPARMS)
table.
monitor-interval
The number of seconds between row insertion into the
IBMSNAP_CAPMON table. The monitor interval must be at
least 120 seconds (two minutes). If you type a number that is
less than 120, this parameter value is set to 120.
MEMLMT Specifies the maximum size (in megabytes) of memory that the
Capture journal job can use. The default is 32 megabytes.
*DFT (default)
The Capture program uses the MEMORY_LIMIT column
value from the Capture parameters (IBMSNAP_CAPPARMS)
table.
memory-limit
The maximum number of megabytes for memory.
LAG Specifies the new lag limit, which is the number of minutes that
the Capture program can fall behind in processing before
restarting.
When the lag limit is reached (that is, when the timestamp of the
journal entry is older than the current timestamp minus the lag
limit), the Capture program initiates a cold start for the tables that
it is processing in that journal. The Apply program then performs
a full refresh to provide the Capture program with a new starting
point.
Usage notes
The CLNUPITV parameter on the STRDPRCAP command specifies the
maximum number of hours that the Capture program waits before pruning
old records from the change-data (CD), unit-of-work (UOW), signal
(IBMSNAP_SIGNAL), Capture monitor (IBMSNAP_CAPMON), Capture trace
(IBMSNAP_CAPTRACE), and Apply qualifier cross-reference
(IBMSNAP_AUTHTKN) tables.
You can run the STRDPRCAP command manually, or you can run the
command automatically as a part of the initial program load (IPL startup
program).
If the job description specified with the JOBD parameter uses job queue
QDP4/QZSNDPR and the DB2 DataPropagator for iSeries subsystem is not
active, the STRDPRCAP command starts the subsystem. If the job description
is defined to use a different job queue and subsystem, you must start this
subsystem manually with the Start Subsystem (STRSBS) command either
before or after running the STRDPRCAP command:
STRSBS QDP4/QZSNDPR
You can set up the system to start the subsystem automatically by adding the
STRSBS command to the program that is referred to in the QSTRUPPGM
system value on your system.
For more information about how the Capture program processes different
journal entry types, see Table 105 on page 713.
Examples for STRDPRCAP
The following examples illustrate how to use the STRDPRCAP command.
Example 1
To initiate a warm start of a Capture program for two different journals:
STRDPRCAP RESTART(*YES) JRN(HR/QSQJRN ACCTS/QSQJRN)
Example 2
To start a Capture program for one specified journal:
STRDPRCAP CAPCTLLIB(BSN) JRN(MARKETING/QSQJRN)
Example 3
To start a Capture program without pruning for two journals:
STRDPRCAP RESTART(*YES) CLNUPITV(*DFT *NO) JRN(HR/QSQJRN ACCTS/QSQJRN)
Example 4
To start a Capture program for one specified journal under the default
Capture control library and to change the default trace limit pruning, monitor
limit pruning, IBMSNAP_CAPMON table insertion, and memory limit
parameters:
Example 5
To initiate a cold start of a Capture program:
STRDPRCAP RESTART(*NO)
Example 6
To start a Capture program with all default values:
STRDPRCAP
Related tasks:
v Chapter 9, Operating the Capture program, on page 127
After you type the command name on the command line, you can press the
F4 key to display the command syntax.
* *NONE
BUFSZ ( buffer-size ) FILE ( file-name )
* ID ( *APPLY )
FSZ ( file-size )
APYQUAL ( apply-qualifier )
(1)
DIALVL ( 1 )
2
3
4
*SAME
(2) *ALL
FNCLVL ( function-name/diagnostic-level )
component-name/diagnostic-level
Notes:
1 You can specify multiple values.
2 You can specify up to 20 functions or components.
Example 1
To start an Apply trace on the Apply qualifier AQ1 for all functions and
components with output written to a file called TRCFILE:
WRKDPRTRC OPTION(*ON) FILE(TRCFILE) ID(*APPLY) APYQUAL(AQ1)
Example 2
To end an Apply trace on the Apply qualifier AQ1:
WRKDPRTRC OPTION(*OFF) ID(*APPLY) APYQUAL(AQ1)
Example 3
To change an Apply trace on the Apply qualifier AQ1 to diagnostic levels 3
and 4 (detailed and performance data) for all functions and components:
WRKDPRTRC OPTION(*CHG) ID(*APPLY) APYQUAL(AQ1) DIALVL(34)
Example 4
To display the status of an Apply trace on the Apply qualifier AQ1:
WRKDPRTRC OPTION(*STC) ID(*APPLY) APYQUAL(AQ1)
Example 5
To display the function calls on the Apply qualifier AQ1 at diagnostic levels 3
and 4:
WRKDPRTRC OPTION(*FMT) FMTOPT(*FLW) ID(*APPLY) APYQUAL(AQ1) DIALVL (34)
Example 6
To write the Apply trace information of the Apply qualifier AQ1 to a dump
file named DMPFILE:
WRKDPRTRC OPTION(*DMP) FILE(DMPFILE) ID(*APPLY) APYQUAL(AQ1)
Related reference:
v asntrc: Operating the replication trace facility (UNIX, Windows, z/OS) on
page 357
| The DB2 DataPropagator V8 samples library contains sample JCL and scripts.
For z/OS operating systems, an example of this line in the invocation JCL is:
//apyasn EXEC PGM=ASNAPPLY,PARM=control_server=CTLDB1
DB2_SUBSYSTEM=DSN
apply_qual=myqual spillfile=disk
For UNIX and Window operating systems, an example of this line in the
invocation JCL is:
//apyasn EXEC PGM=ASNAPPLY,PARM=control_server=CTLDB1
apply_qual=myqual spillfile=disk
Prepare the JCL for z/OS by specifying the appropriate invocation parameters
in the PARM field of the Replication Alert Monitor job. Customize the JCL to
| meet your sites requirements. A sample of invocation JCL in library
| SASNSAMP(ASNMON#) is included with the Replication Alert Monitor for
| z/OS.
Notes:
1 For descriptions of the parameters, see Chapter 17, System commands
for replication (UNIX, Windows, z/OS), on page 317.
Prerequisites:
Ensure that ARM is installed and that the replication programs are set up
correctly. If you are going to use ARM with a replication program, ensure that
the replication program is APF authorized. For example, to use ARM for the
Apply program or the Replication Alert Monitor, you must copy the
appropriate load module into an APF authorized library. (The Capture
program must be APF authorized regardless of whether or not you are using
ARM.)
When you configure ARM, use the following element names for the
replication programs:
Capture program
ASNTCxxxxyyyy
Apply program
ASNTAxxxxyyyy
Replication Alert Monitor
ASNAMxxxxyyyy
where, xxxx is the DB2 subsystem name and yyyy is the data-sharing member
name (the latter is needed only for data-sharing configurations). The element
name is always 16 characters long, padded with blanks. Element names must
be unique in the entire sysplex; therefore, to use ARM, you may run only one
instance of a particular program per subsystem.
The replication programs use the element name to register with ARM during
initialization. They do not provide ARM with an event exit when they register.
(The event exit is not needed because the replication programs do not run as
an MVS subsystem.) ARM restarts registered programs for you if they
terminate abnormally (for example, if a segment violation occurs). A
Tip: If you start the Capture or Apply program using parameter NOTERM=Y,
the program does not stop when DB2 is quiesced. In this case, the program
does not de-register from ARM. It continues to run but does not capture data
until DB2 is restarted.
Prerequisites:
Use either the same user ID that you use to run the Capture program, or one
that has the same privileges. Ensure that the ASNPLXFY utility is APF
authorized. The ASNPLXFY plan must be bound to the subsystem. Also, the
subsystem must be running in data sharing mode. For details about binding
this utility, see the Program Directory.
Procedure:
where the name of the subsystem is required and the Capture schema is
optional. The default Capture schema is ASN.
3. Warm-start the Capture program.
Tip: If your replication service is set up correctly, the service name is sent to
stdout after the service is started successfully. If the service does not start,
check the log files for the program that you were trying to start. By default,
the log files are in the directory specified by the DB2PATH environment
variable. You can override this default by specifying the path parameter
(capture_path, apply_path, monitor_path) for the program that is started as a
service. Also, you can use the Windows Service Control Manager (SCM) to
view the status of the service.
When you create a service, you must specify the account name that you use to
log on to Windows and the password for that account name.
where:
v instance is the name of the DB2 instance.
v alias is the database alias of the Capture control server, Apply
control server, or Monitor control server.
v program is one of the following values: CAP (for Capture program),
APP (for Apply program), or MON (for Replication Alert Monitor
program)
v qualifier_or_schema is one of the following identifiers: Apply
qualifier, Monitor qualifier, or Capture schema
Example: The following service name is for a Capture program that
has the schema ASN and is working with database DB1 under the
instance called INST1:
DB2.INST1.DB1.CAP.ASN
Display name for the replication service
The display name is a text string that you see in the Services window
and it is a more readable form of the service name. For example:
DB2 - INST1 DB1 CAPTURE ASN
If you want to add a description for the service, use the Service Control
Manager (SCM) after you create a replication service. You can also use the
SCM to specify a user name and a password for a service.
Important: When you stop a replication service, the program associated with
that service is stopped automatically. However, if you stop a program using a
replication system command (asnacmd, asnccmd, or asnmcmd), the service
that you used to start that program continues running until you stop it
explicitly.
Use one of the following methods to start a service for replication commands:
v SCM
v net start command
v Replication Center
Important: If you started a replication program from a service, you will get an
error if you try to start the program using the same schema or qualifier.
Related reference:
v asnscrt: Creating a DB2 Replication Service to start Capture, Apply, or the
Replication Alert Monitor (Windows only) on page 353
v asnsdrop: Dropping a DB2 Replication Service (Windows only) on page
356
Chapter 20. Using the Windows Service Control Manager to issue system commands (Windows) 481
482 DB2 Replication Guide and Reference
Chapter 21. Scheduling replication programs on various
operating systems
You might want to schedule the Capture program, the Apply program, or the
Replication Alert Monitor program to start at a prescribed time using the
commands that are available on your operating system.
See MVS/ESA JES2 Commands for more information about using the $TA JES2
command, and the NetView for MVS Command Reference for more information
about using the AT NetView command.
Use the SBMJOB command to schedule the start of the Capture program on
OS/400:
SBMJOB CMD(STRDPRCAP...)SCDDATE(...)SCDTIME(...)
The Replication Center, the Capture program or triggers, and the Apply program
When you register a table, view, or nickname as a replication source, the
Replication Center creates an SQL script that stores the information for this
source in the replication control table that contains all registration information,
the register (IBMSNAP_REGISTER) table. The SQL script generated by the
Replication Center also creates the CD tables for the registered sources.
The IBMSNAP_REGISTER table contains one row for every registered source
table, and one row for every underlying table in a registered view. This table
contains the following kinds of information about each registered source:
v The schema name and name of the source table
v The structure type of each registered source table
v The schema name and name of the CD table
v For registered views, the names of the CD tables for the underlying tables
in this view (if the underlying tables are registered)
v The schema name and name of the internal CCD table, if there is one
v The conflict-detection level for update-anywhere sources
The Capture and Apply programs use the information in the
IBMSNAP_REGISTER table to communicate their respective status to each
For OS/400 sources, including tables that are journaled remotely, there is
also an extension to the IBMSNAP_REGISTER table, IBMSNAP_REG_EXT,
which contains extra information that is unique to iSeries systems, for
example, the journal library and the journal name.
When you create a subscription set and add members to it, the Replication
Center creates an SQL script that stores the information for this subscription
set in the replication control tables that contain all subscription-set
information: the subscription set (IBMSNAP_SUBS_SET), subscription-set
member (IBMSNAP_SUBS_MEMBR), subscription-set columns
(IBMSNAP_SUBS_COLS), and subscription-set statements
(IBMSNAP_SUBS_STMTS) tables. The SQL script generated by the Replication
Center also creates the target tables if they do not already exist.
The following process describes how the Capture triggers and the Apply
program communicate, in a typical replication scenario, to ensure data
integrity:
Capturing data from a source
1. Whenever a DELETE, UPDATE, or INSERT operation occurs at the
registered replication source table, a Capture trigger records the change in
the CCD table for that source table.
Applying data to a target
2. For all newly defined subscription sets, the Apply program first signals the
Capture triggers to mark a valid starting point within the CCD table from
which to start fetching changed data. Then a full refresh is performed for
each member of the set (unless it is not a complete target table).
3. When the Apply program processes a subscription set for a non-DB2
relational source, it updates the register synchronization
(IBMSNAP_REG_SYNCH) table, which causes an UPDATE trigger on that
table to fire. The trigger updates the SYNCHPOINT value in the
IBMSNAP_REGISTER table to mark the highest SYNCHPOINT value in
the CCD tables that it copied to the targets. During the next cycle, the
Apply program will process new data in the CCD table that has a
SYNCHPOINT value that is less than or equal to this SYNCHPOINT.
Because the IBMSNAP_REG_SYNCH table is in the non-DB2 database, the
Apply program writes to the table using the nickname for it that was
created by the Replication Center.
4. The Apply program checks the IBMSNAP_REGISTER table to determine
whether there are changes that need to be replicated.
5. The Apply program copies the changes from the CCD table to the target
table.
6. The Apply program updates the subscription set (IBMSNAP_SUBS_SET)
table to record how much data the Apply program copied for each
subscription set.
The main monitor alert table, the Monitor conditions table, contains one row
for each condition that you want to be monitored. The table contains the
following kinds of information about each alert condition:
v The Monitor qualifier
v The name and aliases of the Capture server or Apply server you want
monitored
v The component that you want monitored (the Capture program or the
Apply program)
v The Capture schema or Apply qualifier
v The name of the subscription set (if you want to monitor a set)
v The alert condition that you want monitored
v The contact to be notified if the condition occurs
This table has several more columns for related information. See
ASN.IBMSNAP_CONDITIONS on page 579 for more information about this
table.
The other tables for the Replication Alert Monitor contain information about
who will be notified if the alert condition occurs (either an individual contact
or a group of contacts), how that contact will be notified (through e-mail or
pager), and how often the contact will be notified if the condition continues.
The following process describes how the Replication Alert Monitor monitors
conditions for the Capture or Apply program and notifies contacts when the
alert condition occurs:
1. The Replication Alert Monitor reads the alert conditions and the contact
for each condition (for a Monitor qualifier) in the Monitor conditions
(IBMSNAP_CONDITIONS) table.
2. For each Capture control server or Apply control server that has a defined
alert condition, the Replication Alert Monitor performs the following tasks:
a. The Replication Alert Monitor connects to the server and reads the
replication control tables associated with each alert condition for that
server to see if any of the conditions are met.
b. If any condition is met, the Replication Alert Monitor stores the data
that is related to that condition in memory and continues processing
the remaining alert conditions for that server.
c. When it is finished processing all the alert conditions for that server,
the Replication Alert Monitor disconnects from the Capture control or
Apply control server, inserts the alerts in the Monitor alerts
(IBMSNAP_ALERTS) table, and notifies the contacts for that condition.
Related concepts:
v Chapter 14, Using the DB2 Replication Center, on page 255
Related reference:
v List of tables used at the Apply control server on page 502
v List of tables used at the Capture control server on page 499
v List of tables used at the Monitor control server on page 504
In each section, the control tables are listed in alphabetical order by the actual
table name (for example, ASN.IBMSNAP_APPLYTRACE), and the target
tables are listed in alphabetical order by their English table name (for
example, replica table). The columns for each table are listed in the order in
which they appear in the table.
Some of the control tables require that you not use SQL to update them (see
particular table descriptions for details). Altering control tables
inappropriately can cause problems such as unexpected results, loss of data,
and reduced replication performance.
schema.IBMSNAP_PRUNE_LOCK
1 VARCHAR(30) for DB2 for z/OS V8 compatibility mode or earlier; (no index)
VARCHAR(128) for DB2 for z/OS V8 new-function mode. DUMMY CHAR(1)
Figure 15. Tables used at the Capture control server. These tables are used by the Capture
| program, Apply program, and Capture triggers at the Capture control server. The columns that
| make up each tables main index are listed in parentheses under the table name.
Figure 16. Tables used at the Capture control server (continued). These tables are used by the
| Capture program, Apply program, and Capture triggers at the Capture control server. The columns
| that make up each tables main index are listed in parentheses under the table name.
schema.IBMSNAP_SEQTABLE
Informix only
(SEQ) 1 VARCHAR(30) for DB2 for z/OS V8 compatibility mode or earlier;
SEQ INTEGER NOT NULL VARCHAR(128) for DB2 for z/OS V8 new-function mode.
|
| Figure 17. Tables used at the Capture control server (continued). These tables are used by the
| Capture program, Apply program, and Capture triggers at the Capture control server. The columns
| that make up each tables main index are listed in parentheses under the table name.
Figure 18. Tables used at the Apply control server. These tables are used by the Apply program at
| the Apply control server. The columns that make up each tables main index are listed in
| parentheses under the table name.
Figure 19. Tables used at the Apply control server (continued). These tables are used by the Apply
| program at the Apply control server. The columns that make up each tables main index are listed
| in parentheses under the table name.
ASN.IBMSNAP_CONTACTGRP
(GROUP_NAME, CONTACT_NAME)
1 VARCHAR(30) for DB2 for z/OS V8 compatibility mode or earlier;
GROUP_NAME VARCHAR(127) NOT NULL
CONTACT_NAME VARCHAR(127) NOT NULL VARCHAR(128) for DB2 for z/OS V8 new-function mode.
Figure 20. Tables used at the Monitor control server. These tables are used by the Replication
| Alert Monitor program at the Monitor control server. The columns that make up each tables main
| index are listed in parentheses under the table name.
|
| Figure 21. Tables used at the Monitor control server (continued). These tables are used by the
| Replication Alert Monitor program at the Monitor control server. The columns that make up each
| tables main index are listed in parentheses under the table name.
Related reference:
v ASN.IBMSNAP_CAPSCHEMAS on page 506
v schema.IBMSNAP_AUTHTKN (OS/400) on page 507
v schema.IBMSNAP_CAPENQ (UNIX, Windows, z/OS) on page 508
v schema.IBMSNAP_CAPMON on page 509
v schema.IBMSNAP_CAPPARMS on page 511
v schema.IBMSNAP_CAPTRACE (DB2 only) on page 515
v schema.CCD_table (non-DB2) on page 517
v schema.CD_table on page 518
v schema.IBMSNAP_PRUNCNTL on page 520
v schema.IBMSNAP_PRUNE_LOCK on page 523
v schema.IBMSNAP_PRUNE_SET on page 524
v schema.IBMSNAP_REG_EXT (OS/400) on page 525
v schema.IBMSNAP_REGISTER on page 527
v schema.IBMSNAP_REG_SYNCH (non-DB2 relational) on page 536
v schema.IBMSNAP_RESTART on page 537
v schema.IBMSNAP_SEQTABLE (Informix) on page 539
v schema.IBMSNAP_SIGNAL on page 540
v schema.IBMSNAP_UOW on page 544
v schema.IBMSNAP_PARTITIONINFO on page 519
Related reference:
Related reference:
v ASN.IBMSNAP_ALERTS on page 577
v ASN.IBMSNAP_CONDITIONS on page 579
v ASN.IBMSNAP_CONTACTGRP on page 584
v ASN.IBMSNAP_MONTRAIL on page 591
v ASN.IBMSNAP_CONTACTS on page 584
v ASN.IBMSNAP_GROUPS on page 586
v ASN.IBMSNAP_MONENQ on page 585
v ASN.IBMSNAP_MONSERVERS on page 589
v ASN.IBMSNAP_MONTRACE on page 590
v ASN.IBMSNAP_MONPARMS on page 586
Related reference:
v Base aggregate table on page 593
v Change aggregate table on page 594
v Consistent-change data (CCD) table on page 594
v Point-in-time table on page 597
v Replica table on page 598
v User copy table on page 598
| Index: CAP_SCHEMA_NAME
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results while using the
administration tools.
The Capture schemas table holds the names of all Capture schemas. It allows
the Replication Center and other utilities to quickly find all of the tables for a
given Capture control server. A row is automatically inserted each time you
create a new Capture schema.
The name of a Capture schema. A row exists for each Capture schema.
The name of a Capture schema. A row exists for each Capture schema.
| STATUS Data type: CHAR(1); Nullable: Yes.
schema.IBMSNAP_AUTHTKN (OS/400)
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The Apply qualifier that identifies which Apply program processed the
transaction. This qualifier is used during update-anywhere replication to
prevent the Apply program from replicating the same changes
repeatedly.
| IBMSNAP_AUTHTKN Data type: CHAR(26); Nullable: No.
The job name that is associated with the transaction. Capture for iSeries
matches the name in this column with the name of the job that issued
the transaction to determine whether the transaction was issued by
either the Apply program or a user application. If the job names match,
then Capture for iSeries copies the Apply qualifier thats in the
APPLY_QUAL column of this table to the APPLY_QUAL column in the
corresponding row of the UOW table. If the names do not match, then
Capture for iSeries sets the APPLY_QUAL column of the UOW row to
null. This column is not automatically copied to other tables; you must
select it and copy it as a user data column.
| JRN_LIB Data type: CHAR(10); Nullable: No.
The library name of the journal from which the transactions came.
| JRN_NAME Data type: CHAR(10); Nullable: No.
| Index: None
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
For a single Capture schema, the Capture enqueue table ensures that:
v For DB2 for UNIX and Windows, only one Capture program is running per
database
v For non-data-sharing DB2 for z/OS, only one Capture program is running
per subsystem
v For data-sharing DB2 for z/OS, only one Capture program is running per
data-sharing group
While running, the Capture program exclusively locks this table.
schema.IBMSNAP_CAPMON
Server: Capture control server
| Index: MONITOR_TIME
The Capture program inserts a row in the Capture monitor table after each
interval to provide you with operational statistics. The Replication Center uses
information in this table (and in other tables) so you can monitor the status of
the Capture program. In the Capture parameters (IBMSNAP_CAPPARMS)
table, the value that you specify for MONITOR_INTERVAL indicates how
frequently the Capture program makes inserts into the Capture monitor table,
and the value that you specify for the MONITOR_LIMIT indicates the number
of minutes that rows remain in the table before they are eligible for pruning.
The timestamp (at the Capture control server) when the row was
inserted into this table.
| RESTART_TIME Data type: TIMESTAMP; Nullable: No.
| The amount of memory (in bytes) that the Capture program used.
| CD_ROWS_INSERTED Data type: INT; Nullable: No.
The number of rows that the Capture program inserted into the CD
table for all source tables.
| RECAP_ROWS_SKIPPED Data type: INT; Nullable: No.
The number of rows that the Capture program processed but did not
insert into the CD table. The rows were skipped because you defined a
trigger on the registration for the Capture program to suppress certain
rows.
| CHG_ROWS_SKIPPED Data type: INT; Nullable: No.
The number of rows that the Capture program processed but did not
insert into the CD table. The rows were skipped because the registration
was defined for the Capture program to only capture changes that
occur in registered columns.
| TRANS_PROCESSED Data type: INT; Nullable: No.
The largest transaction that occurred at the source system. Knowing the
transaction size might influence you to change the memory parameters.
| LOCKING_RETRIES Data type: INT; Nullable: No.
The library name of the journal that the Capture program was
processing.
| JRN_NAME (OS/400) Data type: CHAR(10); Nullable: Yes.
The name of the journal that the Capture program was processing.
| LOGREADLIMIT Data type: INT; Nullable: No.
| The number of times that the Capture program paused from reading
| log records because 1000 records had been read, but no completed
| transactions had yet been encountered within those 1000 records.
| CAPTURE_IDLE Data type: INT; Nullable: No.
The number of times that the Capture program slept because it didnt
have any work to process.
| SYNCHTIME Data type: TIMESTAMP; Nullable: No.
The current value of SYNCHTIME read from the global row of the
register table when the monitor record was inserted into this table.
schema.IBMSNAP_CAPPARMS
Server: Capture control server
| Index: None
This table contains information that you can update by using SQL.
The Capture parameters table contains parameters that you can modify to
control the operations of the Capture program. You can define these
parameters to set values such as the length of time that the Capture program
retains data in the CD and UOW tables before pruning and the amount of
time that the Capture program is allowed to lag in processing log records. If
you make changes to the parameters in this table, the Capture program reads
your modifications only during startup.
The length of time that rows remain in the CD, UOW, and signal tables
before they become eligible for pruning, in cases where they have not
been pruned based on the normal criteria. Normally, CD and UOW
rows are pruned after they are applied to all targets, and signal rows
are pruned when their cycle is complete (SIGNAL_STATE = C).
| LAG_LIMIT Data type: INT; Nullable: Yes.
How often, in seconds, that the monitor thread adds a row to the
Capture monitor (IBMSNAP_CAPMON) table. For Capture for iSeries,
enter an interval greater than 120 seconds.
| MEMORY_LIMIT Data type: SMALLINT; Nullable: Yes.
A flag that indicates where the Capture program directs the log file
messages:
Y The Capture program directs log file messages to both the
standard out (STDOUT) and the log file.
N The Capture program directs most log file messages to the log
file only. Initialization messages go to both the standard out
(STDOUT) and the log file.
| SLEEP_INTERVAL (UNIX, Data type: SMALLINT; Nullable: Yes.
Windows, z/OS)
The number of seconds that the Capture program sleeps when it
reaches the end of the active logs (in UNIX and Windows, or in z/OS
non-data-sharing environments), or when an inefficient amount of data
has been returned (in z/OS data-sharing environments).
| CAPTURE_PATH Data type: VARCHAR(1040); Nullable: Yes.
The path where the output from the Capture program is sent.
| Index: TRACE_TIME
The Capture trace table contains important messages from the Capture
program.
The time at the Capture control server that the row was inserted in the
Capture trace table.
| DESCRIPTION Data type: VARCHAR(1024); Nullable: No.
The time that the row was inserted in the Capture trace table.
TRACE_TIME rows that are eligible for trace limit pruning will be
deleted when the Capture program prunes the CD and UOW tables.
| JOB_NAME Data type: CHAR(26); Nullable: No.
The fully qualified name of the job that wrote this trace entry.
Position
Description
| 110 The Capture schema name or the journal job name
1120 The ID of the user who started the Capture program
2126 The job number
| JOB_STR_TIME Data type: TIMESTAMP; Nullable: No.
The starting time of the job that is named in the JOB_NAME column.
Table 65. Columns in the Capture trace table for OS/400 (continued)
Column name Description
| DESCRIPTION Data type: VARCHAR(298); Nullable: No.
schema.CCD_table (non-DB2)
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause a loss of data.
Table 66 on page 518 provides a brief description of the columns in the CCD
table.
Related reference:
v Consistent-change data (CCD) table on page 594
schema.CD_table
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause a loss of data.
Table 67 on page 519 provides a list and a brief description of the columns in
the CD table.
| schema.IBMSNAP_PARTITIONINFO
| Server: Capture control server
| Important: Use caution when you update this table using SQL. Altering this
| table inappropriately can cause unexpected results and loss of data. If you
| delete the row from this table, the Capture program is forced to cold start.
| If you have never started the Capture program, then this table is empty, and
| the Capture program must perform a cold start.
| The restart LSN for the node that has the partition ID.
| STATUS Data type: CHAR(1); Nullable: Yes.
| The timestamp when the restart LSN for the node that has the partition
| ID was last updated.
|
| schema.IBMSNAP_PRUNCNTL
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
For DB2 sources, you can invoke pruning by issuing the prune command or
have it done automatically. See schema.IBMSNAP_CAPPARMS on page 511
for more information about using the Capture parameters table to set
AUTOPRUNE.For non-DB2 relational sources, pruning is done by the pruning
trigger that was created when you registered the source.
The server name where target table or view for this member resides.
| TARGET_OWNER Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode; Nullable: No.
The high-level qualifier for the target table or view for this member.
| TARGET_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
The Capture program sets this value during the initialization handshake
process with the Apply program. The value comes from the log
sequence number of the commit log record that is associated with the
transaction of the CAPSTART signal insert. It will not be updated again
unless a subsequent initialization process takes place.
| SOURCE_OWNER Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode; Nullable: No.
The high-level qualifier of the source table or view for this member.
| SOURCE_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
The name of the server where the Apply control tables reside for this
Apply program, which is identified by the APPLY_QUAL.
A uniqueness factor that provides a shorter, more easily used index into
this table. It is also used to associate CAPSTART inserts into the signal
table with the appropriate row in the pruning control table.
schema.IBMSNAP_PRUNE_LOCK
Server: Capture control server
| Index: None
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The prune lock table is used to serialize the access of CD tables during a cold
start or retention-limit pruning. This table ensures that the Apply program
does not access the CD table during these critical phases. There are no rows in
this table.
schema.IBMSNAP_PRUNE_SET
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The prune set table tracks the progress of the Capture and Apply programs
for each subscription set to help coordinate the pruning of the CD and UOW
tables. Unlike the pruning control (IBMSNAP_PRUNCNTL) table, which has
one row for each source-to-target mapping, the prune set table has one row
for each subscription set.
Table 70 provides a brief description of the columns in the prune set table.
Table 70. Columns in the prune set table
Column name Description
| TARGET_SERVER Data type: CHAR(18); Nullable: No.
The server name where target tables or views for this set reside.
| APPLY_QUAL Data type: CHAR(18); Nullable: No.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this timestamp for the subscription set.
| SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: No.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this synchpoint value for the
subscription set.
schema.IBMSNAP_REG_EXT (OS/400)
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The information from this table is used to track where and how you defined
your replication sources on an OS/400 server.
The name of the source table member, which is used for issuing
Receive Journal Entry (RCVJRNE) commands and ALIAS support.
| SOURCE_TABLE_RDB Data type: CHAR(18); Nullable: Yes.
When using remote journals, this column contains the database name
of the system where the source table actually resides. For local
journals, this column is null.
| JRN_LIB Data type: CHAR(10); Nullable: Yes.
The library name of the journal that the source table uses.
| JRN_NAME Data type: CHAR(10); Nullable: Yes.
The time when the Apply program began to perform a full refresh.
| SOURCE_VIEW_QUAL Data type: SMALLINT; Nullable: No.
The maximum number of rows that the Capture program can process
before it commits data to the CD table.
schema.IBMSNAP_REGISTER
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The register table contains information about replication sources, such as the
names of the replication source tables, their attributes, and the names of the
CD and CCD tables associated with them. A row is automatically inserted into
this table every time you define a new replication source table or view for the
Capture program to process.
The register table is the place you should look if you need to know how you
defined your replication sources.
The high-level qualifier of the source table or view that you registered.
| SOURCE_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
A flag that indicates how the source table stores rows of primary key
values:
Y The source table contains a row for every primary key value of
interest.
N The source table contains a subset of rows of primary key
values.
| CD_OWNER Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode subsystems; Nullable: Yes.
The high-level qualifier of the table or view that the Apply program
uses for change-capture replication:
For tables as sources
For all registered source tables that are not external CCD
tables, this column contains the high-level qualifier of the
physical CD table that is associated with that source table.
For views as sources
This column contains the high-level qualifier of the physical
CD table that is associated with that source view.
For external CCD tables as sources
This column contains the high-level qualifier of the external
CCD table.
| PHYS_CHANGE_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: Yes.
The name of the table or view that the Apply program uses for
change-capture replication:
For tables as sources
For all registered source tables that are not external CCD
tables, this column contains the name of the physical CD table
that is associated with that source table.
For views as sources
This column contains the name of the physical CD table that is
associated with that source view.
For external CCDs as sources
This column contains the name of the external CCD table.
| CD_OLD_SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
This column is used for the initial handshake between the Apply
program and the Capture program. The Capture program then begins
capturing data from this log sequence number in the source log. This
column is also used to show that retention-limit pruning has occurred
for a CD table. If this value is null, then the registration is inactive.
| CD_NEW_SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
The Capture program advances this column as it inserts new rows into
the CD table. The Apply program uses this column to see if there are
new changes to be replicated.
For a source that has an internal CCD table associated with it, this
column contains the high-level qualifier of the internal CCD. For an
external CCD table, this column is null.
| CCD_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: Yes.
For a source that has an internal CCD table associated with it, this
column contains the name of the internal CCD. For an external CCD
table, this column is null.
| CCD_OLD_SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
The log sequence number when the CCD table was reinitialized. This
column is related to full-refresh processing against CCD tables. The
value in this column needs to be changed only when the CCD table is
initially or subsequently fully refreshed. This value can be much older
than any row remaining in the CCD table. If this column is not
maintained, the Apply program using the CCD table as a replication
source will not know that the CCD table was reinitialized, so it will fail
to reinitialize complete copies of the CCD source.
| SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
A flag that indicates whether the internal CCD that is associated with
this source is condensed, meaning that all rows with the same key are
condensed to one row:
Y The internal CCD is condensed.
N The internal CCD is not condensed.
NULL No internal CCD table is defined for this source.
| CCD_COMPLETE Data type: CHAR(1); Nullable: Yes.
A flag that indicates whether the internal CCD table that is associated
with this source is complete, meaning that it initially contained all the
rows from the source table:
N The internal CCD is not complete.
NULL No internal CCD table is defined for this source.
| ARCH_LEVEL Data type: CHAR(4); Nullable: No.
A flag that indicates the level of conflict detection for this source:
0 The Apply program does not check for conflicts. Data
consistency must be enforced by your application to avoid
potential conflicting updates.
1 Standard detection with cascading transaction rejection. The
Apply program checks for conflicts based on the changes
captured to this point. The Apply program will reverse any
conflicting transaction at the replica, as well as any transactions
with dependencies on the conflicting transaction. Changes
captured after the Apply program begins conflict detection will
not be checked during this Apply cycle.
2 Enhanced detection with cascading transaction rejection. The
Apply program waits until the Capture program captures all
changes from the log or journal (see description of the
SYNCHTIME column) and then does a standard conflict
detection as when set to 1. During the wait time, the Apply
program holds a LOCK on the source tables to ensure that no
changes are made during the conflict detection process.
A flag that indicates how the Capture program stores updates in the CD
table.
Y The Capture program stores updates using two rows in the CD
table, one for the delete and one for the insert. The Apply
program processes the delete first and the insert second. When
this Y flag is set, every update to a replication source is stored
in the CD table using two rows. This flag ensures that updates
made to partitioning columns or columns referenced by a
subscription-set predicate are processed correctly.
N Each update to the source table is stored in a single row in the
CD table.
| CHGONLY Data type: CHAR(1); Nullable: Yes.
A flag that indicates whether the Capture program captures all changes
that occur at the source or only changes that occur in registered
columns. Typically you should have this option set to Y to minimize the
number of rows that the Capture program inserts into the CD table, but
you may want to set this option to N in order to track exactly which
rows in the source table were updated. For example, you may just be
capturing the primary key column values to audit which rows have
been changed in a source table.
Y The Capture program only captures changes that occur in
registered columns in the source table.
N The Capture program captures changes from all columns in the
source table.
A flag that indicates whether the Capture program will terminate or just
stop processing the registration if it encounters errors while trying to
start, initiate, reinitiate, or insert a row into the CD table:
Y The Capture program terminates when an error occurs while it
is trying to start, initiate, reinitiate, or insert a row into the CD
table.
N The Capture program stops the registration but does not
terminate when an error occurs while it is trying to start,
initiate, reinitiate, or insert a row into the CD table; it continues
to process other registrations.
| Index: TRIGGER_ME
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
schema.IBMSNAP_RESTART
Server: Capture control server
| Index: None
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data. If you
delete the row from this table, the Capture program is forced to cold start.
The restart table contains information that enables the Capture program to
restart from the earliest required log or journal record. This table replaces the
warm start table from DB2 replication Version 7 and earlier versions. It
contains one row, which is updated at every commit point; therefore, the
Capture program can always restart from exactly the right place without
recapturing information that it already processed and inserted into the CD
and UOW tables.
If you have never started the Capture program, then this table is empty and
the Capture program must perform a cold start.
The following two tables show operating system-specific layouts of the restart
table:
Table 74. Columns in the restart table for UNIX, Windows, and z/OS
Column name Description
| MAX_COMMITSEQ Data type: CHAR(10) for bit data; Nullable: No.
The timestamp that is associated with the log sequence number in the
MAX_COMMITSEQ column.
| MIN_INFLIGHTSEQ Data type: CHAR(10) for bit data; Nullable: No.
| The logical log sequence number at which the Capture program starts
| during a warm restart. This value represents the earliest log sequence
number that the Capture program found for which a commit or abort
record has not yet been found.
Table 74. Columns in the restart table for UNIX, Windows, and z/OS (continued)
Column name Description
| CURR_COMMIT_TIME Data type: TIMESTAMP; Nullable: No.
The local current timestamp when this table was updated by the
Capture program.
| CAPTURE_FIRST_SEQ Data type: CHAR(10) for bit data; Nullable: No.
| The logical log sequence number that is associated with the recovery
| log that the Capture program started from during the last cold start that
| the Capture program performed. This value is used to detect if a
database RESTORE occurred, which might require the Capture program
to perform a cold start because the database log manager might reuse
the log sequence numbers during certain RESTORE operations.
For OS/400, the restart table is used to determine the starting time of the
RCVJRNE (Receive Journal Entry) command. A row is inserted into the
restart table for each journal that is used by a replication source or a group of
replication sources.
The journal record number of the most current commit from the UOW
table.
| MAX_COMMIT_TIME Data type: TIMESTAMP; Nullable: No.
The timestamp that is associated with the journal record number in the
MAX_COMMITSEQ column, or the current timestamp if the Capture
program is caught up with the logs and has no work to perform.
| MIN_INFLIGHTSEQ Data type: CHAR(10) for bit data; Nullable: No.
| The logical log sequence number that the Capture program starts from
| during a warm restart.
| CURR_COMMIT_TIME Data type: TIMESTAMP; Nullable: No.
The journal record number that the Capture program starts from after a
cold start.
The sequence number of the last journal entry that the Capture program
processed.
| JRN_LIB Data type: CHAR(10); Nullable: No.
The library name of the journal that the Capture program is processing.
| JRN_NAME Data type: CHAR(10); Nullable: No.
schema.IBMSNAP_SEQTABLE (Informix)
Server: Capture control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
schema.IBMSNAP_SIGNAL
Server: Capture control server
| Index: SIGNAL_TIME
This table contains information that you can update by using SQL.
The signal table stores signals that prompt the Capture program to perform
certain actions. The signals are entered by either you or the Apply program.
The signal table is created with the DATA CAPTURE CHANGES attribute,
which means that all insert, update, and delete operations performed on this
table are visible to the Capture program as log records read from the DB2
recovery log. The Capture program ignores all update and delete log records
for the signal table, but it recognizes all validly created and committed log
records of signal inserts as signals that require its attention. The actions that
the Capture program performs for a log record from a signal insert depends
on what is specified in the signal table for that insert. The values in the signal
table provide the instructions to the Capture program regarding the desired
action.
Table 77 on page 541 provides a brief description of the columns in the signal
table.
The action that the Capture program performs when a signal from a
system command (SIGNAL_TYPE = CMD) occurs.
CAPSTART
| The Capture program starts capturing changes at the registered
| source for a particular subscription-set member, which is
| identified by the MAP_ID (from the IBMSNAP_PRUNCNTL
| table) in the SIGNAL_INPUT_IN column. For example, the
Apply program issues this signal before it performs a full
refresh on all target tables in the set to let the Capture program
know that the set is ready to begin change-capture replication.
The Apply program posts this signal.
STOP The Capture program stops capturing changes and terminates.
This command can only be issued by you, not the Apply
program.
CAPSTOP
The Capture program stops capturing changes for a particular
registered source, which is identified by
source_owner.source_table in the SIGNAL_INPUT_IN column.
This command can only be issued by you, not the Apply
program.
UPDANY
The Apply program (identified by the Apply qualifier in the
SIGNAL_INPUT_IN column) lets the Capture program know
that it is working with two Capture programs in an
update-anywhere configuration. The Apply program posts this
signal.
When the signal type is USER, the signal subtype is not used or
recognized by the Capture program and therefore is not a required
field. It can be set to any value that you want.
The log sequence number of the commit record. This value is set only
by the Capture program.
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
For OS/400: Because Capture for iSeries can start capturing data for a subset
of the replication sources, it does not delete all the rows in the UOW table if
you do a partial cold start.
The Capture program requires that there is one UOW table for each Capture
schema. The Capture program inserts one new row into this table for every
log or journal record that is committed at the replication source.
For OS/400: There are some user programs that do not use commitment
control. In such cases, Capture for iSeries arbitrarily inserts a new UOW row
after a number of rows are written to the CD table. This artificial commitment
boundary helps reduce the size of the UOW table.
The Capture program also prunes the UOW table based on information that
the Apply program inserts into the prune set (IBMSNAP_PRUNE_SET) table.
For OS/400: The UOW table is pruned by retention limits, not information
from the prune set (IBMSNAP_PRUNE_SET) table.
Table 78 on page 545 provides a brief description of the columns in the UOW
table.
The unit-of-work identifier from the log record header for this unit of
work. You can select that this column be part of a noncomplete CCD
target table.
| IBMSNAP_COMMITSEQ Data type: CHAR(10) for bit data; Nullable: No.
The log record sequence number of the captured commit statement. For
all target table types other than user copy, the Apply program joins the
UOW and CD tables based on the values in this column when it applies
changes to the target tables.
| IBMSNAP_LOGMARKER Data type: TIMESTAMP; Nullable: No.
The time (at the Capture control server) that the data was committed.
| IBMSNAP_AUTHTKN Data type: VARCHAR(30); Nullable: No.
A flag that indicates whether any rows were rejected and rolled back.
This value is set only during update-anywhere replication if conflict
detection is specified as standard or enhanced when you defined your
replication source. You can select that this column be part of a
noncomplete CCD target table.
0 No known conflicts occurred in the transaction.
1 A conflict occurred because the same row in the master and
replica was updated. The transaction at the replica was rejected
and rolled back.
2 The transaction was rejected and rolled back because it was
dependent on a prior transaction that was rejected. The prior
transaction was rejected because the same row in the master
and replica was updated, and the transaction at the replica was
rejected and rolled back.
3 The transaction was rejected and rolled back because it
contained at least one referential-integrity constraint violation.
Because this transaction violates the referential constraints
defined on the source table, the Apply program will mark this
subscription set as failed. Updates cannot be copied until you
correct the referential integrity definitions.
4 The transaction was rejected and rolled back because it was
dependent on a prior transaction that was rejected. The prior
transaction was rejected because it contained at least one
referential-integrity constraint violation.
| IBMSNAP_APPLY_QUAL Data type: CHAR(18); Nullable: No, with default; Default: current user
name.
The Apply qualifier that identifies which Apply program applied the
changes. You can select that this column be part of a noncomplete CCD
target table.
ASN.IBMSNAP_APPENQ
Server: Apply control server
| Index: APPLY_QUAL
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The Apply enqueue table is used to ensure that only one Apply program is
running per Apply qualifier. The Apply program exclusively locks a row in
this table until the Apply program is shut down. This table is not used in
OS/400.
ASN.IBMSNAP_APPLY_JOB (OS/400)
Server: Apply control server
| Index: None
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
Table 80 on page 548 provides a brief description of the columns in the Apply
job table.
The name of the database where the Apply control tables and view are
defined.
| JOB_NAME Data type: CHAR(10); Nullable: No.
The fully qualified name of the job that wrote this trace entry:
Position 110
APPLY_QUAL
Position 11-20
The ID of the user who started the Apply program
Position 21-26
The job number
| USER_NAME Data type: CHAR(10); Nullable: No.
The name of the user who started a new instance of the Apply program.
| JOB_NUMBER Data type: CHAR(6); Nullable: No.
The job number of the current job for a particular journal. If the journal
is not active, this column contains the job number of the last job that
was processed.
| ASN.IBMSNAP_APPPARMS
| Server: Apply control server
| Index: APPLY_QUAL
| This table contains information that you can update by using SQL.
| The Apply parameters table contains parameters that you can modify to
| control the operations of the Apply program. You can define these parameters
| to set values such as the name of the Apply control server on which the
| subscription definitions and Apply program control tables reside. If you make
| changes to the parameters in this table, the Apply program reads your
| modifications only during startup.
| The location of the work files used by the Apply program. The default
| is the directory where the program was started.
| COPYONCE Data type: CHAR(1); Nullable: Yes, with default; Default: N.
| A flag that indicates whether the Apply program executes one copy
| cycle for each subscription set that is eligible at the time the Apply
| program is invoked.
| Y The Apply program executes one copy cycle for each eligible
| subscription set.
| N The Apply program does not execute one copy cycle for each
| eligible subscription set.
| DELAY Data type: INT; Nullable: Yes, with default; Default: 6.
| The delay time (in seconds) at the end of each Apply cycle when
| continuous replication is used. This parameter is ignored if copyonce is
| specified.
| ERRWAIT Data type: INT; Nullable: Yes, with default; Default: 300.
| The number of seconds (1 to 300) that the Apply program waits before
| retrying after the program encounters an error condition. This
| parameter is ignored if copyonce is specified.
| INAMSG Data type: CHAR(1); Nullable: Yes, with default; Default: Y.
| A flag that indicates whether the Apply program overwrites the Apply
| log file or appends to it.
| Y The Apply program reuses the log file by first deleting it and
| then re-creating it when the Apply program is restarted.
| N The Apply program appends new information to the Apply log
| file.
| LOGSTDOUT Data type: CHAR(1); Nullable: Yes, with default; Default: N.
| A flag that indicates where the Apply program directs the log file
| messages:
| Y The Apply program directs log file messages to both the
| standard out (STDOUT) and the log file.
| N The Apply program directs most log file messages to the log
| file only. Initialization messages go to both the standard out
| (STDOUT) and the log file.
| NOTIFY Data type: CHAR(1); Nullable: Yes, with default; Default: N.
| A flag that indicates whether the Apply program should invoke the exit
| routine (ASNDONE) that returns control to you after the Apply
| program finishes copying a subscription set.
| Y The Apply program invokes ASNDONE.
| N The Apply program does not invoke ASNDONE.
| OPT4ONE Data type: CHAR(1); Nullable: Yes, with default; Default: N.
| A flag that indicates whether the Apply program terminates when DB2
| terminates:
| Y The Apply program terminates when DB2 terminates.
| N The Apply program stays active and waits for DB2 to be
| restarted.
| This parameter is ignored if copyonce is specified.
The Apply trace table contains important messages from the Apply program.
The Apply program does not automatically prune this table, but you can
easily automate pruning by adding an SQL statement that runs after one of
the subscription sets.
Table 82 provides a brief description of the column in the Apply trace table.
Table 82. Columns in the Apply trace table
Column name Description
| APPLY_QUAL Data type: CHAR(18); Nullable: No.
The time at the Apply control server when the row was inserted into
this table.
| OPERATION Data type: CHAR(8); Nullable: No.
ASN.IBMSNAP_APPLYTRAIL
Server: Apply control server
The Apply trail table contains audit trail information of all subscription set
cycles performed by the Apply program. This table records a history of
updates that are performed against subscriptions. It is a repository of
diagnostic and performance statistics. The Apply trail table is one of the best
places to look if a problem occurs with the Apply program. The Apply
program does not automatically prune this table, but you can easily automate
pruning by adding an after SQL statement to one of the subscription sets.
Table 83 provides a brief description of the columns in the Apply trail table.
Table 83. Columns in the Apply trail table
Column name Description
| APPLY_QUAL Data type: CHAR(18); Nullable: No.
The name of the subscription set that the Apply program was
processing.
| SET_TYPE Data type: CHAR(1); Nullable: No.
The total number of rows that the Apply program reworked during the
last cycle. The Apply program reworks changes under the following
conditions:
v If an insert fails because the row already exists in the target table, the
Apply program converts the insert to an update of the existing row.
v If the update fails because the row does not exist in the target table,
the Apply program converts the update to an insert.
| SET_REJECTED_TRXS Data type: INT; Nullable: No.
A value that represents the work status for the Apply program after a
given cycle:
-1 The replication failed. The Apply program backed out the
entire set of rows that it had applied, and no data was
committed. If the startup parameter SQLERRCONTINUE = Y,
the SQLSTATE that is returned to the Apply program during
the last cycle is not one of the acceptable errors you indicated
in the input file for SQLERRCONTINUE (apply qualifier.SQS).
0 The Apply program processed the subscription set successfully.
If the startup parameter SQLERRCONTINUE = Y, the Apply
program did not encounter any SQL errors that you indicated
for the SQLERRCONTINUE startup parameter (in
apply_qualifier.SQS) and did not reject any rows.
2 The Apply program is processing the subscription set in
multiple cycles. It successfully processed a single logical
subscription that was divided according to the
MAX_SYNCH_MINUTES control column.
16 The Apply program processed the subscription set successfully
and returned a status of 0; however, it encountered some SQL
errors that you indicated for the SQLERRCONTINUE startup
parameter (in apply_qualifier.SQS) and rejected some of the
rows. See the apply_qualifier.ERR file for details about the rows
that failed.
Example: You set SQLERRCONTINUE = Y and indicate that
the allowable SQL state is 23502 (SQL code 407). A 23502
error occurs, but no other errors occur. The Apply program
finishes processing the subscription set, and it sets the status to
16. On the next execution, a 23502 error occurs, but then a
07006 (SQL code 301) occurs. Now the Apply program stops
processing the subscription set, backs out the entire set of rows
it had applied, and sets the status to 1 (because no data was
committed).
18 The Apply program is processing the subscription set in
multiple cycles and returned a status of 2, which means that it
successfully processed a single logical subscription that was
divided according to the MAX_SYNCH_MINUTES control
column. However, it encountered some SQL errors that you
indicated for the SQLERRCONTINUE startup parameter (in
apply_qualifier.SQS) and rejected some of the rows. See the
apply_qualifier.ERR file for details about the rows that failed.
The estimated time that the last subscription began. The Apply program
sets the LASTRUN value each time a subscription set is processed. It is
the approximate time at the Apply control server that the Apply
program begins processing the subscription set.
| LASTSUCCESS Data type: TIMESTAMP; Nullable: Yes.
The Apply control server timestamp for the beginning of the last
successful processing of a subscription set.
| SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this synchpoint value for the
subscription set.
| SYNCHTIME Data type: TIMESTAMP; Nullable: Yes.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this timestamp for the subscription set.
| SOURCE_SERVER Data type: CHAR(18); Nullable: No.
The DB2 Universal Database database name where the source tables
and views are defined.
| SOURCE_ALIAS Data type: CHAR(8); Nullable: Yes.
The high-level qualifier of the source table or view that the Apply
program was processing. This value is set only when the Apply cycle
fails.
| SOURCE_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: Yes.
The name of the source table or view that the Apply program was
processing. This value is set only when the Apply cycle fails.
| SOURCE_VIEW_QUAL Data type: SMALLINT; Nullable: Yes.
The value of the source view qualifier for the source table or view that
the Apply program was processing. This value is set only when the
Apply cycle fails.
The database name of the server where target tables or views are stored.
| TARGET_ALIAS Data type: CHAR(8); Nullable: Yes.
The high-level qualifier of the target table that the Apply program was
processing. This value is set only when the Apply cycle fails.
| TARGET_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
The name of the target table that the Apply program was processing.
This value is set only when the Apply cycle fails.
| CAPTURE_SCHEMA Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode subsystems; Nullable: No.
The schema name of the Capture server tables for this subscription set.
| TGT_CAPTURE_SCHEMA Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode subsystems; Nullable: Yes.
If the target table is also the source for another subscription set (such as
an external CCD table in a multi-tier configuration or a replica table in
an update-anywhere configuration), this column contains the Capture
schema that will be used when the table is acting as a source.
| FEDERATED_SRC_SRVR Data type: VARCHAR(18); Nullable: Yes.
The name of the federated remote server that is the source for the
subscription set, which applies only to non-DB2 relational sources.
| FEDERATED_TGT_SRVR Data type: VARCHAR(18); Nullable: Yes.
The name of the federated remote server that is the target for the
subscription set, which applies only to non-DB2 relational target servers.
| JRN_LIB Data type: CHAR(10); Nullable: Yes.
The value of the COMMIT_COUNT from the last Apply cycle, which is
recorded in the subscription sets (IBMSNAP_SUBS_SET) table.
| OPTION_FLAGS Data type: CHAR(4); Nullable: No.
A unique character string used to represent the event that triggered the
set to be processed.
| ENDTIME Data type: TIMESTAMP; Nullable: No, with default; Default: current
timestamp.
The timestamp at the Apply control server when the Apply program
finished processing the subscription set. To find out how long a set took
to process, subtract LASTRUN from ENDTIME.
| SOURCE_CONN_TIME Data type: TIMESTAMP; Nullable: Yes.
The timestamp at the Capture control server when the Apply program
first connects to fetch source data.
| SQLSTATE Data type: CHAR(5); Nullable: Yes.
ASN.IBMSNAP_SUBS_COLS
Server: Apply control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The subscription columns table contains information about the columns of the
subscription-set members that are copied in a subscription set. Rows are
automatically inserted into or deleted from this table when information
changes in one or more columns of a source and target table pair.
The name of the target table or view column. It does not need to match
the source column name.
A flag that indicates whether the column is part of the target key, which
can be either a unique index or primary key of a condensed target table:
Y The column is all or part of the target key.
N The column is not part of the target key.
| COLNO Data type: SMALLINT; Nullable: No.
The source column name or an SQL expression used to create the target
column contents.
ASN.IBMSNAP_SUBS_EVENT
Server: Apply control server
This table contains information that you can update using SQL.
The subscription events table contains information about the event triggers
that are associated with a subscription set. It also contains names and
timestamps that are associated with the event names. You insert a row into
this table when you create a new event to start an Apply program. See
Event-based scheduling on page 83.
A log sequence number that tells the Apply program to apply only data
that has been captured up to this point. You can find the exact
END_SYNCHPOINT that you want to use by referring to the signal
table and finding the precise log sequence number associated with a
timestamp. Any transactions that are committed beyond this point in
the log are not replicated until a later event is posted. If you supply
values for END_SYNCHPOINT and END_OF_PERIOD, the Apply
program uses the END_SYNCHPOINT value because it then does not
need to perform any calculations from the control tables to find the
maximum log sequence number to replicate.
| END_OF_PERIOD Data type: TIMESTAMP; Nullable: Yes.
A timestamp used by the Apply program, which applies only data that
has been logged up to this point. Any transactions that are committed
beyond this point in the log are not replicated until a later event is
posted.
ASN.IBMSNAP_SUBS_MEMBR
Server: Apply control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
Use this table to identify a specific source and target table pair within a
subscription set.
The name of the subscription set that this member belongs to.
| WHOS_ON_FIRST Data type: CHAR(1); Nullable: No.
The high-level qualifier for the source table or view for this member.
| SOURCE_TABLE Data type: VARCHAR(128); VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
The high-level qualifier for the target table or view for this member.
| TARGET_TABLE Data type: VARCHAR(128), VARCHAR(18) for DB2 UDB for z/OS
| Version 8 compatibility mode subsystems or earlier; Nullable: No.
Lists the predicates to be placed in a WHERE clause for the table in the
TARGET_TABLE column. This WHERE clause creates a row subset of
the source table. Predicates are recognized only when
WHOS_ON_FIRST is set to S. The predicate cannot contain an ORDER
BY clause because the Apply program cannot generate an ORDER BY
clause. Aggregate tables require a dummy predicate followed by a
GROUP BY clause.
Because the Apply program uses these predicates for both full-refresh
and change-capture replication, this column cannot contain predicates
that involve columns in the CD or UOW table. Predicates that contain
CD or UOW table references are stored in the UOW_CD_PREDICATES
column.
| MEMBER_STATE Data type: CHAR(1); Nullable: Yes.
A flag that indicates how the Apply program handles updates when, at
the source table, you change the source columns for the target key
columns of a target table:
Y The Apply program updates the target table based on the
before images of the target key column, meaning that the
Apply program changes the predicate to the old values instead
of the new. Make sure you have registered each before-image
column of the target key so it is present in the CD table. For
the corresponding registration entry in the register table, make
sure the value in the CHG_UPD_TO_DEL_INS column is set to
N.
N The Apply program uses logic while processing updates and
deletes that assume that the columns that make up the target
key are never updated.
| UOW_CD_PREDICATES Data type: VARCHAR(1024); Nullable: Yes.
A flag that indicates whether the Apply program does a join of the CD
and UOW tables when processing a user copy target table. This flag is
needed when you define a subscription-set member with predicates that
use columns from the UOW table that are not in the CD table. If the
target table type is anything except user copy, then the Apply program
uses a join of the CD and UOW tables when processing the member,
and it ignores this column when processing the member.
Y The Apply program uses a join of the CD and UOW tables
when processing the member.
N The Apply program does not use a join of the CD and UOW
tables when processing the member; it reads changes only from
the CD table.
NULL The Apply program ignores this column when processing the
member. If the target table is a user copy and the value in this
column is null, then the Apply program does not do a join of
the CD and UOW tables when processing the member.
The type of load for this member. The value in this column is used to
override the defaults.
NULL
For z/OS: The cross loader function (available with the DB2
Utilities Suite) is used for this member.
For UNIX and Windows: The ASNLOAD exit determines the
most appropriate utility for this member (option 3, 4, or 5).
1 ASNLOAD is not used for this member. This effectively turns
ASNLOAD option off for a particular subscription-set member
even if you specified LOADX on startup.
2 A user-defined or user-modified ASNLOAD exit code is used.
3 The cross loader function (available with the DB2 Utilities
Suite) is used for this member.
4 For UNIX and Windows only: EXPORT/LOAD is used for this
member.
5 For UNIX and Windows only: EXPORT/IMPORT is used for
this member.
| Restriction for UNIX and Windows: The LOAD utility is not supported
| for range-clustered tables. To do a full refresh of a range-clustered table,
| you can either use the DB2 IMPORT utility or the Apply program to do
| a full refresh of the table through SQL.
| LOADX_SRC_N_OWNER Data type: VARCHAR(30); Nullable: Yes.
| The user-created nickname owner. This value is required when all of the
| following conditions exist:
v The cross loader function is used for this member (LOADX_TYPE is
3)
v The target server is UNIX or Windows
v The source is not a nickname
| LOADX_SRC_N_TABLE Data type: VARCHAR(128); Nullable: Yes.
| The user-created nickname table. This value is required when all of the
| following conditions exist:
v The cross loader function is used for this member (LOADX_TYPE is
3)
v The target server is UNIX or Windows
v The source is not a nickname
ASN.IBMSNAP_SUBS_SET
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data.
The subscription sets table lists all of the subscription sets that are defined at
the Apply control server and documents the replication progress for these
sets. Rows are inserted into this table when you create your subscription set
definition.
A flag that indicates whether the Apply program will process the set
during its next cycle:
0 The subscription set is deactivated. The Apply program will
not process the set.
1 The subscription set is active indefinitely. The Apply program
will process the set during each Apply cycle until you
deactivate the set or until the Apply program is unable to
process it.
2 The subscription set is active for only one Apply cycle. The
Apply program will process the set once and then deactivate
the set.
| SOURCE_SERVER Data type: CHAR(18); Nullable: No.
The database name of the Capture control server where the source
tables and views are defined.
| SOURCE_ALIAS Data type: CHAR(8); Nullable: Yes.
The database name of the server where target tables or views are stored.
| TARGET_ALIAS Data type: CHAR(8); Nullable: Yes.
A value that represents the work status for the Apply program after a
given cycle:
-1 The replication failed. The Apply program backed out the
entire set of rows it had applied, and no data was committed.
If the startup parameter SQLERRCONTINUE = Y, the
SQLSTATE that is returned to the Apply program during the
last cycle is not one of the acceptable errors you indicated in
the input file for SQLERRCONTINUE (apply qualifier.SQS).
0 The Apply program processed the subscription set successfully.
If the startup parameter SQLERRCONTINUE = Y, the Apply
program did not encounter any SQL errors that you indicated
for the SQLERRCONTINUE startup parameter (in
apply_qualifier.SQS) and did not reject any rows.
2 The Apply program is processing the subscription set in
multiple cycles. It successfully processed a single logical
subscription that was divided according to the
MAX_SYNCH_MINUTES control column.
16 The Apply program processed the subscription set successfully
and returned a status of 0; however, it encountered some SQL
errors that you indicated for the SQLERRCONTINUE startup
parameter (in apply_qualifier.SQS) and rejected some of the
rows. See the apply_qualifier.ERR file for details about the rows
that failed.
Example: You set SQLERRCONTINUE = Y and indicate that
the allowable SQL state is 23502 (SQL code 407). A 23502
error occurs, but no other errors occur. The Apply program
finishes processing the subscription set, and it sets the status to
16. On the next execution, a 23502 error occurs, but then a
07006 (SQL code 301) occurs. Now the Apply program stops
processing the subscription set, backs out the entire set of rows
it had applied, and sets the status to 1 (because no data was
committed).
18 The Apply program is processing the subscription set in
multiple cycles and returned a status of 2, meaning that it
successfully processed a single logical subscription that was
divided according to the MAX_SYNCH_MINUTES control
column. However, it encountered some SQL errors that you
indicated for the SQLERRCONTINUE startup parameter (in
apply_qualifier.SQS) and rejected some of the rows. See the
apply_qualifier.ERR file for details about the rows that failed.
The estimated time that the last subscription set began. The Apply
program sets the LASTRUN value each time a subscription set is
processed. It is the approximate time at the Apply control server when
the Apply program begins processing the subscription set.
| REFRESH_TYPE Data type: CHAR(1); Nullable: No.
The Apply control server timestamp for the beginning of the last
successful processing of a subscription set.
| SYNCHPOINT Data type: CHAR(10) for bit data; Nullable: Yes.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this synchpoint value for the
subscription set.
The Apply program uses this column to record its progress, indicating
that it has processed data up to this timestamp for the subscription set.
| CAPTURE_SCHEMA Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode subsystems; Nullable: No.
The schema name of the Capture control tables that process the source
for this subscription set.
| TGT_CAPTURE_SCHEMA Data type: VARCHAR(30), VARCHAR(128) for DB2 UDB for z/OS
| Version 8 new-function mode subsystems; Nullable: Yes.
If the target table is also the source for another subscription set (such as
an external CCD table in a multi-tier configuration or a replica table in
an update-anywhere configuration), then this column contains the
Capture schema that is used when the table is acting as a source.
| FEDERATED_SRC_SRVR Data type: VARCHAR(18); Nullable: Yes.
The name of the federated remote server that is the source for the
subscription set, which applies only to non-DB2 relational sources.
| FEDERATED_TGT_SRVR Data type: VARCHAR(18); Nullable: Yes.
The name of the federated remote server that is the target for the
subscription set, which applies only to non-DB2 relational targets.
| JRN_LIB Data type: CHAR(10); Nullable: Yes.
A flag that indicates the type of processing that the Apply program
performs for a subscription set:
NULL This is the default setting for a read-only subscription set. The
Apply program will process fetched answer sets for the n
subscription-set members one member at a time, until all data
has been processed, and then will issue a single commit at the
end of the data processing for the whole set. The advantage of
using this COMMIT_COUNT setting is that the processing
might complete faster.
Integer not NULL
The Apply program processes the subscription set in a
transactional mode. After all answer sets are fetched, the
contents of the spill files will be applied in the order of commit
sequence, ordering each transaction by the
IBMSNAP_INTENTSEQ value order. This type of processing
allows all spill files to be open and processed at the same time.
A commit will be issued following the number of transactions
specified in this column. For example, 1 means commit after
each transaction, 2 means commit after each two transactions,
and so on. An integer of 0 means that a single commit will be
issued after all fetched data is applied. The advantage to using
transactional mode processing is that the processing allows for
referential integrity constraints at the target, and interim
commits can be issued.
| MAX_SYNCH_MINUTES Data type: SMALLINT; Nullable: Yes.
ASN.IBMSNAP_SUBS_STMTS
Server: Apply control server
Important: Use caution when you update this table using SQL. Altering this
table inappropriately can cause unexpected results and loss of data. The
number of entries for a subscription should be reflected in the
ASN.IBMSNAP_SUBS_SET.AUX_STMTS column. If AUX_STMTS is zero for a
subscription set, the corresponding entries in the subscription statements table
are ignored by the Apply program.
This table is populated when you define a subscription set that uses SQL
statements or stored procedure calls.
The name of the subscription set that the SQL statement or stored
procedure is associated with.
| WHOS_ON_FIRST Data type: CHAR(1); Nullable: No.
One to ten five-byte SQLSTATE values that you specified when you
defined the subscription set. These non-zero values are accepted by the
Apply program as a successful execution. Any other values will cause a
failed execution.
The Monitor alerts table contains a record of all the alerts issued by the
Replication Alert Monitor. It keeps track of what alert conditions occur, at
which servers they occur, and when they were detected.
The time at the Monitor control server when the alert was inserted into
this table.
| COMPONENT Data type: CHAR(1); Nullable: No.
The name of the Capture control server or Apply control server where
the alert condition occurred.
| SERVER_ALIAS Data type: CHAR(8); Nullable: Yes.
If you set an alert condition for the Apply program, this column
specifies the name of the subscription set that is being monitored. If you
do not specify a set name, then monitoring is done at the
Apply-qualifier level, meaning that every set within the given Apply
qualifier is monitored.
| CONDITION_NAME Data type: CHAR(18); Nullable: No.
The condition code that was tested when the alert was triggered.
| OCCURRED_TIME Data type: TIMESTAMP; Nullable: No.
The time that the alert condition occurred at the Capture control or
Apply control server.
| ALERT_COUNTER Data type: SMALLINT; Nullable: No.
The number of times that this alert has been previously detected in
consecutive monitor cycles.
| ALERT_CODE Data type: CHAR(10); Nullable: No.
The message code that was issued when the alert occurred.
The text of the message that was sent, including the message code.
ASN.IBMSNAP_CONDITIONS
Server: Monitor control server
The Monitor conditions table contains the alert conditions for which the
Replication Alert Monitor will contact someone, and it contains the group or
individuals name to contact if a particular condition occurs. The Replication
Alert Monitor can monitor a combination of conditions on Capture control
and Apply control servers.
The name of the Capture control or Apply control server where this
condition is being monitored.
| COMPONENT Data type: CHAR(1); Nullable: No.
If you set an alert condition for the Apply program, this is the name of
the subscription set you want monitored. If you do not specify a set
name, the monitoring is done at the Apply qualifier level, meaning that
every set within the Apply qualifier is monitored.
| MONITOR_QUAL Data type: CHAR(18); Nullable: No.
A flag that indicates whether the Replication Alert Monitor will process
this condition during the next monitoring cycle:
Y The Replication Alert Monitor will process this definition
during the next cycle.
N The Replication Alert Monitor will ignore this definition during
the next cycle.
The integer parameter for the condition. The value of this column
depends on the value of the CONDITION_NAME column.
CAPTURE_LASTCOMMIT
Threshold in seconds.
CAPTURE_CLATENCY
Threshold in seconds.
CAPTURE_HLATENCY
Threshold in seconds.
CAPTURE_MEMORY
Threshold in megabytes.
APPLY_SUBSDELAY
Threshold in seconds.
APPLY_REWORKED
Threshold in rows reworked.
APPLY_LATENCY
Threshold in seconds.
| PARM_CHAR Data type: VARCHAR(128); Nullable: Yes.
The character parameter for the condition. This column holds additional
strings used by the condition.
If the value is NULL or a zero length string, the Monitor program uses
the following defaults:
v The CURRENT SERVER value from the Capture or Apply control
server.
v The remote DB2 instance name value On UNIX servers, this value is
the name of the user ID that was used when the server was
connected. On Windows servers, the value is DB.
v The value of the hostname in the db2 node directory.
ASN.IBMSNAP_CONTACTGRP
Server: Monitor control server
The Monitor group contacts table contains the individual contacts that make
up contact groups. You can specify for the Replication Alert Monitor to
contact these groups of individuals if an alert condition occurs. An individual
can belong to multiple contact groups (the columns are not unique).
A contact name that is part of the group. These individuals are specified
in the Monitor contacts (IBMSNAP_CONTACTS) table.
ASN.IBMSNAP_CONTACTS
Server: Monitor control server
| Index: CONTACT_NAME
The Monitor contacts table contains the necessary information for the
Replication Alert Monitor to use to notify individuals when an alert condition
that is associated with the individuals (or their group) occurs. One individual
per row is specified.
A flag that indicates whether the e-mail address for this contact is an
e-mail account or a pager address:
E The e-mail address is for an e-mail account.
P The e-mail address is for a pager.
| DELEGATE Data type: VARCHAR(127); Nullable: Yes.
ASN.IBMSNAP_MONENQ
Server: Monitor control server
| Index: MONITOR_QUAL
The Monitor enqueue table is reserved for future options of DB2 replication.
ASN.IBMSNAP_GROUPS
Server: Monitor control server
| Index: GROUP_NAME
The Monitor groups table contains the name and description of each contact
group. One group per row is specified.
| ASN.IBMSNAP_MONPARMS
| Server: Monitor control server
| Index: MONITOR_QUAL
| This table contains information that you can update by using SQL.
| The Monitor parameters table contains parameters that you can modify to
| control the operations of the Monitor program. You can define these
| parameters to set values such as the length of time that the Monitor program
| retains data in the CD and UOW tables before pruning and the number of
| notification messages that the Monitor program will receive whenever an alert
| condition is met. If you make changes to the parameters in this table, the
| Monitor program reads your modifications only during startup.
| A flag that indicates how old the data is before it will be pruned from
| the table.
| AUTOPRUNE Data type: CHAR(1); Nullable: No, with default; Default: Y.
| A flag that indicates where the Monitor program directs the log file
| messages:
| Y The Monitor program directs log file messages to both the
| standard out (STDOUT) and the log file.
| N The Monitor program directs most log file messages to the log
| file only. Initialization messages go to both the standard out
| (STDOUT) and the log file.
| The path where the output from the Monitor program is sent.
| RUNONCE Data type: CHAR(1); Nullable: No, with default; Default: N.
| A flag that indicates whether the Monitor program will check for the
| alert conditions that were selected:
| Y The Monitor program checks for any alert conditions.
| N The Monitor program does not check for any alert conditions.
|
| ASN.IBMSNAP_MONSERVERS
Server: Monitor control server
The Monitored servers table contains information about the last time that the
Replication Alert Monitor monitored a Capture control or Apply control
server.
The name of the Capture control or Apply control server that the
Replication Alert Monitor was monitoring.
| SERVER_ALIAS Data type: CHAR(8); Nullable: Yes.
The DB2 UDB alias of the Capture control or Apply control server that
the Replication Alert Monitor was monitoring.
| LAST_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The time (at the Capture control or Apply control server) that the
Replication Alert Monitor program last connected to this server. This
value is used as a lower bound value to fetch messages from the control
tables and is the same value that START_MONITOR_TIME from the last
successful monitor cycle.
| START_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The time (at the Capture control or Apply control server) that the
Replication Alert Monitor connected to the Capture control or Apply
control server. This value is used as a upper bound value to fetch alert
messages from the control tables.
| END_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The time (at the Capture control or Apply control server) that the
Replication Alert Monitor ended monitoring this server.
The last time (at the Monitor control server) when the Replication Alert
Monitor started to process the Capture control or Apply control server.
| LASTSUCCESS Data type: TIMESTAMP; Nullable: Yes.
The value from the LASTRUN column of the last time (at the Monitor
control server) when the Replication Alert Monitor successfully
completed processing the Capture control or Apply control server. If the
monitoring of this server keeps failing, the value could be the same (the
history of this columns is stored in the IBMSNAP_MONTRAIL table).
| STATUS Data type: SMALLINT; Nullable: No.
ASN.IBMSNAP_MONTRACE
Server: Monitor control server
The Monitor trace table contains audit trail information for the Replication
Alert Monitor. Everything that the Replication Alert Monitor does is recorded
in this table, which makes it one of the best places for you to look if a
problem with the Replication Alert Monitor program occurs.
Table 97 provides a brief description of the columns in the Monitor trace table.
Table 97. Columns in the Monitor trace table
Column name Description
| MONITOR_QUAL Data type: CHAR(18); Nullable: No.
The timestamp when the message was inserted into this table.
ASN.IBMSNAP_MONTRAIL
Server: Monitor control server
| Index: None
The Monitor trail table contains information about each monitor cycle. The
Replication Alert Monitor inserts one row for each Capture control or Apply
control server that it monitors.
Table 98 provides a brief description of the columns in the Monitor trail table.
Table 98. Columns in the Monitor trail table
Column name Description
| MONITOR_QUAL Data type: CHAR(18); Nullable: No.
The name of the Capture control or Apply control server that the
Replication Alert Monitor was monitoring.
| SERVER_ALIAS Data type: CHAR(8); Nullable: Yes.
The time (at the Monitor control server) when the Replication Alert
Monitor program last started to process the Capture control server or
Apply control server.
| LASTSUCCESS Data type: TIMESTAMP; Nullable: Yes.
The last time (at the Monitor control server) when the Replication Alert
Monitor successfully completed processing the Capture control or Apply
control server.
| ENDTIME Data type: TIMESTAMP; Nullable: No, with default; Default: current
timestamp.
The time when this row was inserted into this table.
| LAST_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The time (at the Capture control or Apply control server) when the
Replication Alert Monitor last connected to the Capture control or
Apply control server. This value is used as a lower bound value to fetch
messages from the control tables and is the same value as
START_MONITOR_TIME from the previous successful monitor cycle.
| START_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The last time when the Replication Alert Monitor started to monitor the
Capture control or Apply control server.
| END_MONITOR_TIME Data type: TIMESTAMP; Nullable: Yes.
The last time when the Replication Alert Monitor finished monitoring
the Capture control or Apply control server.
| SQLCODE Data type: INT; Nullable: Yes.
The SQLCODE of any errors that occurred during this monitor cycle.
The SQLSTATE of any errors that occurred during this monitor cycle.
| NUM_ALERTS Data type: INT; Nullable: No.
The number of alert conditions that occurred during this monitor cycle.
| NUM_NOTIFICATIONS Data type: INT; Nullable: No.
The number of notifications that were sent during this monitor cycle.
Important: If you use SQL to update this table, you run the risk of losing
your updates if a full refresh is performed by the Apply program.
A base aggregate table is a target table that contains the results of aggregate
functions that are performed on data located at the source table.
Important: If you use SQL to update this table, you run the risk of losing
your updates if a full refresh is performed by the Apply program.
A change aggregate table is a target table that contains the results of aggregate
functions that are performed on data in the change-data (CD) table. This table
is similar to the base aggregate table, except that the functions being
performed at the CD table are done only for changes that occur during a
specific time interval.
Table 100 provides a brief description of the columns in the change aggregate
table.
Table 100. Columns in the change aggregate table
Column name Description
user key columns The columns that make up the target key.
user nonkey columns The nonkey data columns from the source table. The column names
in this target table do not need to match the column names in the
source table, but the data types must match.
user computed columns User-defined columns that are derived from SQL expressions. You can
use computed columns with SQL functions to convert source data
types to different target data types.
IBMSNAP_LLOGMARKER The oldest IBMSNAP_LOGMARKER or IBMSNAP_LLOGMARKER
value present in the (CD+UOW) or CCD table rows being aggregated.
IBMSNAP_HLOGMARKER The newest IBMSNAP_LOGMARKER or IBMSNAP_HLOGMARKER
value present in the (CD+UOW) or CCD table rows being aggregated.
This table contains information that you can update by using SQL.
Important: If you use SQL to update this table, you run the risk of losing
your updates if a full refresh is performed by the Apply program.
For more information on the uses for CCD tables as targets, see Selecting a
target type on page 87.
The Capture program does not insert data into CCD tables and does not
prune them. Instead, your application requirements should determine the
history retention period for CCD tables. Therefore, pruning of CCD tables is
not automatic by default, but can be easily automated using an SQL statement
to be processed after the subscription cycle.
For external CCDs, you can choose to include several columns from the UOW
table: APPLY_QUAL, IBMSNAP_AUTHID, IBMSNAP_AUTHTKN,
IBMSNAP_REJ_CODE, and IBMSNAP_UOWID.
For information on CCD tables that are populated by Capture triggers or that
contain non-relational data, see schema.CCD_table (non-DB2) on page 517.
Table 101 on page 596 provides a brief description of the columns in the CCD
table.
Related reference:
v schema.CCD_table (non-DB2) on page 517
Point-in-time table
schema.point_in_time
Important: If you use SQL to update this table, you run the risk of losing
your updates if a full refresh is performed by the Apply program.
The point-in-time table contains a copy of the source data, with an additional
system column (IBMSNAP_LOGMARKER) containing the timestamp of
approximately when the particular row was inserted or updated at the source
server.
Table 102 on page 598 provides a brief description of the columns in the
point-in-time table.
Replica table
schema.replica
This table contains information that you can update by using SQL.
The replica table must have the same key columns as the source table.
Because of these similarities, the replica table can be used as a source table for
further subscription sets. Converting a target table into a source table is done
automatically when you define a replica target type and specify the CHANGE
DATA CAPTURE attribute. See Defining read-write targets
(update-anywhere) on page 97 for more information.
Table 103 provides a brief description of the columns in the replica table.
Table 103. Columns in the replica table
Column name Description
user key columns The columns that make up the target key, which must be the same
primary key as the master table.
user nonkey columns The nonkey data columns from the source table. The column names in
this target table do not need to match the column names in the source
table, but the data types must match.
Important: If you use SQL to update this table, you run the risk of losing
your updates if a full refresh is performed by the Apply program.
The user copy table is a target table that contains a copy of the columns in the
source table. This target table can be a row or column subset of the source
table, but it cannot contain any additional columns.
Except for subsetting and data enhancement, a user copy table reflects a valid
state of the source table, but not necessarily the most current state. References
to user copy tables (or any other type of target table) reduce the risk of
contention problems that results from a high volume of direct access to the
source tables. Accessing local user copy tables is much faster than using the
network to access remote source tables for each query.
Table 104 provides a brief description of the columns in the user copy table.
Table 104. Columns in the user copy table
Column name Description
user key columns The columns that make up the target key.
user nonkey columns The nonkey data columns from the source table or view. The column
names in this target table do not need to match the column names in
the source table, but the data types must match.
user computed columns User-defined columns that are derived from SQL expressions. You can
use computed columns with SQL functions to convert source data types
to different target data types.
Unless otherwise stated, all error codes in this chapter are internal error codes
used by IBM Software Support to locate the code where the particular
message was issued. Also, unless otherwise stated, error messages are issued
with a nonzero return code.
Tips for Capture errors: If you receive a Capture program error, verify that
your DB2 maintenance is at the most current level. The Capture program is an
application program that uses DB2 APIs. Many Capture program errors are
due to DB2 maintenance that is not current.
| For messages that you receive while migrating replication, see the Migration
| Guide: Migrating to DB2 Replication Version 8.
Note for iSeries: The replication messages issued by DB2 for iSeries are
| available online only, from the library of replication message files (MSGF). To
| display a message from the command line, type [DSPMSGD
| RANGE(message_number) MSGF(QDP4/QDPRMSG)].
Replication messages
This section contains the messages issued by DB2 replication for the
replication programs on all of the database management systems except DB2
for iSeries. The messages are listed in numeric sequence.
v alter table regress.table3 data capture changes Explanation: A required column in the change
2. If the registration has been deactivated by the data table is not defined.
Capture program (state = stopped), update User Response: Ensure that the change data
the registration to set the state to inactive. table definition is correct. Refer to the Tables
3. Use the Replication Center to force the Apply structures documentation in the DB2 Replication
program to perform a full refresh for all Guide and Reference for more information.
subscription sets that replicate from this
source table.
ASN0019E CAPTURE capture_schema. The
Capture program libraries are not
ASN0011E CAPTURE capture_schema. The authorized for the Authorized
Capture program log read failed Program Facility (APF).
because the DB2 compression
Explanation: The Capture program cannot start.
dictionary that was used to create
the compressed log record no User Response: Authorize the Capture link
longer exists. The log record that library for APF, and restart the program.
could not be read was for the
registered source table
ASN0020I CAPTURE capture_schema. Netview
src_owner.src_table. The reason
Generic Alerts Interface failure.
code is reason_code.
The Netview return code is
Explanation: The Capture program received a return_code.
nonzero response code from the DB2 log read
Explanation: The Network Major Vector
IFI. The response code indicates that the data on
Transport (NMVT) could not be sent to Netview
a log record cannot be processed because the
by the program because the program interface
compression dictionary for the corresponding
failed. This is a secondary informational
DB2 table space is not available.
message.
The compressed table space containing this
User Response: See the Netview programming
source table was probably reorganized by the
documentation for a description of the return
REORG utility that ran without the
code to determine the interface error. The
KEEPDICTIONARY option. The Capture
Capture program alerts are not received by the
program must deactivate this registration,
System Services Control Point (SSCP) until the
because the remaining compressed log records
error is corrected.
cannot be read. The Capture program cannot
continue unless this registration is deactivated or
removed. This error does not cause the Capture ASN0021I CAPTURE capture_schema. Netview
program to terminate. Program to Program Interface
unavailable. The Netview return
User Response: See the Maintaining your
code is return_code.
replication environment chapter for restrictions
about compressed table spaces and for more Explanation: Netview is unavailable. This is a
information about deactivated registrations and secondary informational message.
corresponding full refreshes by the Apply
programs. User Response: See the Netview programming
documentation for a description of the return
User Response: Re-evaluate this registration User Response: See the documentation
definition. Either alter the registration so that the regarding Capture program operations in the
lengths of the source table column and the CD DB2 Replication Guide and Reference.
table column match or add a trigger to the CD
table to truncate the data. ASN0102W CAPTURE capture_schema. The
Capture program switches to cold
ASN0084E CAPTURE capture_schema. The start because the warm start
registration with the source table information is insufficient.
source_owner.source_table and the Explanation: A problem occurred during the
CD table retrieval of the restart information. The restart
phys_chg_owner.phys_chg_tbl has table data is not valid. A cold start is performed.
been stopped by the Capture
v For DB2 Universal Database, an Asynchronous
program.
Read Log API error occurred during warm
Explanation: This error message is issued any start while DB2 was reading the log.
time that a registration is placed in the stopped v For z/OS, an Instrumentation Facility
state (with the STATE column set to a value of Information (IFI) error occurred during warm
S in the IBMSNAP_REGISTER table) by the start while DB2 was reading the log.
Capture program. The reason for this action is
described in one or more of the preceding User Response: See the documentation
messages. regarding Capture program operations in the
DB2 Replication Guide and Reference.
User Response: Examine the preceding error
messages to determine the cause of the failure,
and follow the suggested user response to repair
the failing registration definition. After you
repair the registration definition, you must
ASN0183E CAPTURE capture_schema. The User Response: This message is for your
Capture program detected an information only, and no action is required.
inconsistency between the
IBMSNAP_PARTITIONINFO ASN0186W CAPTURE capture_schema. The
table and DB2 partition Capture program cannot find the
information. source database database on
Explanation: This error message occurred due partition partition_ID. The Capture
to one of the following reasons: program cannot process the log
for this partition.
v A new database partition was added to the
database. Explanation: This partition is not known to the
v The IBMSNAP_PARTITIONINFO control table source database. The Capture program captures
is corrupted. data only from the partitions that are known to
the source database.
User Response: If a new partition was added,
restart the Capture program with the User Response: Add the partition to the
add_partition=Y option. database and restart the Capture program using
the ADD_PARTITION=Y option. If the partition
If the IBMSNAP_PARTITIONINFO control table is not needed, remove it.
is corrupted, cold start the Capture program or
call IBM Software Support.
User Response: Review the reason codes in the User Response: See the DB2 for z/OS messages
explanation, and respond with the following and codes documentation for an explanation of
options: the SQLCODE and for information about
corrective actions that might need to be taken in
1 This is an internal error on Windows. DB2. If the SQLCODE is -551, do one of the
See the Windows Reference. following:
User Response: Use the information from the User Response: Refer to your database message
EEE error condition and from the specified error reference.
codes to determine the cause of the error.
Contact IBM Software Support if you cannot ASN1003E APPLY apply_qualifier. The Apply
resolve the error. program could not connect to the
server server.
ASN0999E pgmname : program_qualifier : Error Explanation: The Apply program attempted to
condition message_text, error connect to the database and received a failing
code(s): rc1, rc2, rc3. return code. There are many possible reasons
Explanation: The Error condition shown in this why the Apply program could not connect to the
message is the description of an error that database. For example, the Apply program
occurred in the specified program with the would receive a failing return code if the
specified qualifier (if displayed). The error codes database was down or too many users were
provide supplemental information related to this accessing it.
message text. If an error code field is not User Response: Look up the SQLCODE (from
applicable, it contains * (an asterisk).
ASN1022E APPLY apply_qualifier. The Apply ASN1026I APPLY apply_qualifier. The Apply
program cannot write to the work program encountered an error
file filename. The error code is while trying to bind. SQLSTATE
error_code. is sqlstate, SQLCODE is sqlcode.
Explanation: Either the user does not have the Explanation: An error occurred during the
proper access authority for one or all of the files, execution of bind.
or there is insufficient space remaining after
User Response: Refer to your database message
writing to the target file.
reference.
User Response: Determine whether the problem
is caused by a lack of access authority or a lack
ASN1027E APPLY apply_qualifier. There are
of space, and contact your system administrator
too many large object (LOB)
to obtain what is needed.
columns specified. The error code
is error_code.
ASN1023E APPLY apply_qualifier. The Apply
Explanation: Too many large object (BLOB,
program cannot open the work
CLOB, or DBCLOB) columns are specified for a
file filename. The error code is
subscription set member. The maximum number
error_code.
of columns allowed is 10.
Explanation: The Apply program cannot open
User Response: Remove the excess large object
the work file.
columns from the subscription set member.
User Response: Contact IBM Software Support.
ASN1028I APPLY apply_qualifier. The
ASN1024E APPLY apply_qualifier. The Apply before-image column for a key
program cannot close the work column is not found. The error
file filename. The error code is code is error_code.
error_code.
Explanation: The subscription set up for a
Explanation: The Apply program cannot close member with TARGET_KEY_CHG=Y is
the work file. incorrect.
User Response: Contact IBM Software Support. User Response: For each key column
(IS_KEY=Y), there must be a before-image
column included in the IBMSNAP_SUBS_COLS
table. It can be a col_type=B (specified by the
user), or col_type=P (provided by Replication). If
the subscription is set up manually, then you
must correct the problem yourself. If the
ASN1040E APPLY apply_qualifier. The Apply ASN1044I APPLY apply_qualifier. The Apply
program encountered an z/OS program will become inactive for
error. The error code is error_code, number minutes and number
and the return code is return_code. seconds.
Explanation: Execution of a z/OS system Explanation: The Apply program is inactive.
operation failed.
User Response: This message is for your
User Response: Refer to your z/OS system information only, and no action is required.
library information.
ASN1045I APPLY apply_qualifier. The Apply
ASN1041I APPLY apply_qualifier. The Apply program was started using
program was started using database database.
subsystem name: subsystem.
Explanation: This message informs you from
Explanation: This message informs you that the which database the Apply program is running.
Apply program started using the specified
User Response: This message is for your
subsystem name.
information only, and no action is required.
User Response: This message is for your
information only, and no action is required.
ASN1047I APPLY apply_qualifier. There are
too many columns specified. The
error code is error_code.
Explanation: There are too many columns
specified for a member in the subscription.
Explanation: The Apply program has detected The arguments passed to the ASNDLCOPY
an error while reading the temporary work file. program are not valid.
User Response: Verify that the ASNDONE The number of entries in the ASNDLSRVMAP
program is located in the correct directory. configuration file exceeds the maximum limit.
103
ASN1073E APPLY apply_qualifier. The An entry that is not valid has been found in the
execution of the ASNDONE ASNDLSRVMAP configuration file.
program failed. The return code is
return_code. 104
Explanation: An error occurred while calling No user login information was found in the
the user exit program, ASNDONE. ASNDLUSER configuration file for a given file
server.
User Response: Contact IBM Software Support.
105
ASN1074E APPLY apply_qualifier. The Apply An entry that is not valid has been found in the
program could not find the ASNDLPARM configuration file.
ASNDLCOPY program. 106
Explanation: The Apply program did not find Unable to open the ASNDLUSER configuration
the ASNDLCOPY program in the current search file.
path.
107
User Response: Add the ASNDLCOPY program
to the search path and run the Apply program An entry that is not valid has been found in the
again. ASNDLUSER configuration file.
108
ASN1075E APPLY apply_qualifier. The
An I/O error occurred when reading from the
ASNDLCOPY program failed. The
input file.
return code is return_code.
Additional information can be 109
found in the ASNDL file
An entry that is not valid has been found in the
Explanation: The ASNDLCOPY program input file.
detected an error and passed the error
110
information back to the Apply program. The
following values are valid return codes: Unable to open the input file.
121
ASN1077E APPLY apply_qualifier. The Apply
Cannot find the path mapping for the given file program encountered an
reference. DATALINK column value that is
not valid while updating the
122
target table. The error code is
An error occurred when executing the FTP error_code.
BINARY command.
Explanation: The DATALINK column field of a
123 row fetched from the source table is not valid.
An error occurred when executing the FTP SIZE User Response: Contact IBM Software Support.
command.
19 The CONFLICT_LEVEL must be User Response: Provide valid values for the
between 0 and 2. input parameters and rerun the replication
action. See the online help for details.
20 The CHGONLY value must be Y or
N.
21 The RECAPTURE value must be Y or
N.
ASN1573E The number of columns ASN1576W The DB2 index index_name will be
number_columns for the database created in the DB2 default
object objectowner.objectname of Indexspace or Table space.
type object_type exceeds the
Explanation: A table space (for workstation
database limit db2_limit. The
operating systems) or an indexspace (for z/OS
database object cannot be created.
operating systems) was not provided into which
Explanation: The number of columns that a the specified index might be created. Therefore,
database object (table or index) can contain the index is created using the DB2 defaults. This
depends on the DB2 platform but cannot exceed might be a problem if the default specifications
a predefined number. No script is generated. The are not appropriate for the specified index.
following values are valid for object type: table,
User Response: Refer to the SQL Reference for
index.
the DB2 defaults. If you require the index to be
User Response: Redesign the DB2 object. in its own table space or indexspace, then reissue
the Replication task with the appropriate
specifications. No action is required if the default
ASN1574E The DB2 PageSize page_size for
is appropriate for the index.
Table space tablespace_name is not
valid. Reason code reason_code.
ASN1577W The DB2 table space tablespace will
Explanation: The PageSize must be valid for the
be created in the DB2 default
table space to be created successfully. The
database.
following values are valid for reason code:
Explanation: For z/OS operating systems only,
0 PageSize is not equal to the PageSize of
a database was not provided into which the
the given buffer pool.
specified table space might be created. Therefore,
1 PageSize is not equal to one of the the table space is created using the DB2 defaults.
following: 4K, 8K, 16K, 32K. This might be a problem if the default
specifications are not appropriate for the
User Response: Refer to the DB2 SQL Reference specified table space.
for appropriate PageSize ranges or values.
User Response: Refer to the SQL Reference for
the DB2 defaults. If you require the table space
19 The source object type is not a valid 15 A view on view cannot be registered.
object type for replication. 16 The given source object is not a view.
User Response: Check the Reason Code to 17 This source view is a duplicate for this
determine why the table cannot be registered for session.
change-capture replication. Refer to the DB2
Replication Guide and Reference for additional 18 The view definition cannot be
explanations and restrictions. supported.
19 The view has an asterisk (*) instead of a
ASN1704E The view viewowner.viewname specific column name in the view
cannot be registered. Reason code definition.
reason_code. 20 The view contains the join of a CCD
Explanation: The view cannot be supported by and a non-CCD table.
the Replication Capture mechanism, as defined. 21 The view defined at the CCD table must
No script is generated. The following values are be complete and condensed.
valid for the reason code:
22 The dependent table is a nickname.
0 None of the dependent tables for the
view are registered. 23 A federated registration expects a
nickname to be registered as a source.
1 The source-table columns on which the
view is dependent are not registered. User Response: Check the Reason Code to
determine why the view cannot be registered.
2 The view is on an internal ccd. Refer to the DB2 Replication Guide and
3 The view is already registered. Reference for additional explanations and
restrictions.
4 The view has an OUTER JOIN syntax.
5 The view includes more than one table ASN1705E The change data object,
or view column with a function, and no objectowner.objectname already exists
correlation is provided in the view in the server.
definition for each table.
Explanation: The change data table or view
6 The view contains a reference to an cannot be used for the current source to be
aggregate function. registered, because it already exists at the
7 The view contains a subselect/subquery. Capture server. No script is generated.
8 The view contains a reference to another User Response: Provide a different name for the
view. change data object.
User Response: This message is for your Explanation: The asnscrt command cannot
information only, and no action is required. create the specified service, because another
service with the same service name already exists
in the service control manager.
ASN5209I ASNSCRT: The replication service
service_name started successfully. User Response: Remove the existing service
with the same service name. Then re-enter the
Explanation: The asnscrt command successfully command.
started the specified service.
User Response: This message is for your
information only, and no action is required.
User Response: Make sure the specified path is User Response: Verify that the service startup
correct. Then re-enter the command. type is set to either automatic or manual in the
service control manager. Then re-enter the
command.
ASN5214E ASNSCRT: The replication service
service_name did not start, because
an instance of the service is ASN5218E ASNSCRT: The replication service
already running. service_name did not start, because
the service cannot log on. This
Explanation: The asnscrt command cannot start error occurs if the service starts
the specified service, because the service is from an account that does not
already running. have the proper Log on as a
service access right.
User Response: This message is for your
information only, and no action is required. Explanation: The asnscrt command cannot start
the specified service, because the corresponding
DB2 instance service cannot log on.
ASN5215E ASNSCRT: The replication service
service_name did not start, because User Response: Go to service control manager,
the service depends on a DB2 and locate the specified service. Verify that the
instance service that does not exist provided account name and passwords are
or has been marked for deletion. correct. Then re-enter the command.
Explanation: The asnscrt command cannot start
the specified service, because the corresponding ASN5219E ASNSCRT: The replication service
DB2 instance service does not exist or has been service_name was not created,
deleted. because the service is marked for
deletion.
User Response: Verify that the corresponding
DB2 instance service exists in the service control Explanation: The asnscrt command cannot
manager. Then re-enter the command. create the specified service, because the service
was deleted.
ASN5216E ASNSCRT: The replication service User Response: Close the service control
service_name did not start, because manager window. Then re-enter the command.
this service depends on another
service that failed to start.
Explanation: The asnscrt command cannot start
the specified service, because the corresponding
If you do not follow the single CCSID rule, DB2 will detect the violation and
return SQLCODE -873 during bind or execution.
Notes:
1. The following values are used for the journal codes:
C Commitment control operation
F Database file operation
J Journal or journal receiver operation
R Operation on specific record
2. The R-UP image and the R-UB image form a single UPD record in the CD table if
the PARTITION_KEYS_CHG column in the register table is N. Otherwise, the R-UB
image inserts a DLT record in the CD table and the R-UP image inserts an ADD
record in the CD table.
3. The R-UR image and the R-BR image form a single UPD record in the CD table if
the PARTITION_KEYS_CHG column in the register table is N. Otherwise, the R-BR
image inserts a DLT record in the CD table and the R-UR image inserts an ADD
record in the CD table.
All other journal entry types are ignored by the Capture program.
Appendix B. How the Capture program processes journal entry types (iSeries) 715
716 DB2 Replication Guide and Reference
Appendix C. Starting the replication programs from within
an application (UNIX, Windows)
You can start any of the replication programs (Capture program, Apply
program, Replication Alert Monitor) for one replication cycle from within
your application by calling routines. To use these routines you must specify
the AUTOSTOP option for the Capture program and the COPYONCE option
for the Apply program because the API support only synchronous execution.
Samples of the API and their respective makefiles are in the following
directories:
For Windows
sqllib\samples\repl
For UNIX
sqllib/samples/repl
Those directories contain the following files for starting the Capture program:
capture_api.c
The sample code for starting the Capture program on Windows or
UNIX.
capture_api_nt.mak
The makefile for sample code on Windows.
capture_api_unix.mak
The makefile for sample code on UNIX.
Those directories contain the following files for starting the Apply program:
apply_api.c
The sample code for starting the Apply program on Windows or
UNIX.
apply_api_nt.mak
The makefile for sample code on Windows.
apply_api_unix.mak
The makefile for sample code on UNIX.
Those directories contain the following files for starting the Replication Alert
Monitor:
blocking. An option that is specified when change aggregate table. A type of replication
binding an application. It allows caching of target table that contains data aggregations based
multiple rows of information by the on the contents of a CD table. It includes two
communications subsystem so that each FETCH timestamps to mark the time interval for when
statement does not require the transmission of the changes were written to the CD table.
one row for each request across the network. See Contrast with base aggregate table.
also block fetch.
change-capture replication. The process of
capturing changes made to a replication source
C table and applying them to a replication target
table. Contrast with full refresh.
| capture. To gather changes from a source
| database and store them for replication to a change data (CD) table. A replication table at
| target database. These changes can come from the Capture control server that contains changed
| the DB2 log or journal or they can come from data for a replication source table.
| source transactions in a non-DB2 relational
| database. character large object (CLOB). A sequence of
characters (single-byte, multibyte, or both) with a
Capture control server. (1) A database that size ranging from 0 bytes to 2 gigabytes less 1
contains the Capture control tables, which store byte. In general, character large object values are
information about registered replication source used whenever a character string might exceed
tables. (2) A system where the Capture program the limits of the VARCHAR type. Also called
is running. character large object string. See also binary large
object and double-byte character large object.
Capture latency. An approximate measurement
of how recently the Capture program committed client. Any program (or workstation that a
data to a CD table. See also Apply latency. program is running on) that communicates with
and accesses a database server.
Capture program. A program that reads
database log or journal records to capture CLOB. Character large object.
complete CCD table. A CCD table that initially control table. See replication control table.
contains all the rows from the replication source
table or view and any predicates from the source D
table or view. Contrast with noncomplete CCD
table. See also consistent-change data (CCD) table. database log. A set of primary and secondary
log files consisting of log records that record all
condensed. A table attribute indicating that the changes to a database. The database log is used
table contains current data rather than a history to roll back changes for transactions (units of
of changes to the data. A condensed table work) that are not committed and to recover a
includes no more than one row for each primary database to a consistent state.
key value in the table. As a result, a condensed
table can be used to supply current information database management system (DBMS).
for a refresh. Synonym for database manager.
condensed CCD table. A CCD table that database manager. A computer program that
contains only the most current value for a row manages data by providing the services of
and has only one row for each key value. centralized control, data independence, and
Contrast with noncondensed CCD table. See also complex physical structures for efficient access,
consistent-change data (CCD) table. integrity, recovery, data currency control, privacy,
and security.
conflict detection. In update-anywhere
replication configurations, conflict detection database server. The target of a request from a
refers to either of the following processes: local application or an intermediate database
v The process of detecting constraint errors. server. In the DB2 environment, the database
v The process of detecting whether the same server function is provided by the distributed
row was updated by users or application data facility to access DB2 data from local
programs in both the source and target tables applications or a remote database server that is
during the same replication cycle. When a acting as an intermediate database server.
conflict is detected, the transaction that caused
data blocking. The process of replicating a
the conflict is rejected.
specific number of minutes worth of change
consistent-change data (CCD) table. A type of data during an Apply cycle.
replication target table that is used for storing
data consolidation replication. A replication
history, for auditing, or for staging data. A CCD
configuration that contains one read-only target
table can also be a replication source. See also
database. The target table contains rows of data
complete CCD table, condensed CCD table, external
from one or more source tables.
CCD table, internal CCD table, noncomplete CCD
table, and noncondensed CCD table. data distribution replication. A replication
configuration that contains a single source table,
Control Center. The DB2 graphical interface
from which changes are replicated to one or
that shows database objects (such as databases
Glossary 721
more read-only target tables. Before replication to register table, where it is identified by the
the target tables can occur, the tables must SOURCE_OWNER and SOURCE_TABLE
contain a complete set of data from the source columns. See also consistent-change data table.
table. Contrast with internal CCD table.
G
E
gap. A situation in which the Capture program
end-to-end latency. An approximate is not able to read a range of log or journal
measurement of the time that replication requires records, so there is potential loss of change data.
to capture changes and apply those changes to a
target database. See also Apply latency and global record. The row in the register table that
Capture latency. defines global replication characteristics for a
particular instance of the Capture program.
event timing. The most precise method of
controlling when to start a replication
subscription cycle. To use event timing, you must H
specify an event name and the time that you
want the event to be processed. Contrast with heterogeneous replication. Replication between
interval timing. DB2 and non-DB2 relational databases. See also
federated database system.
external CCD table. A CCD table that can be
subscribed to directly because it is a registered | high-availability replication. (1) A
replication source. It has its own row in the | data-distribution replication configuration in
| which the Apply program runs as frequently as
J K
join. An SQL relational operation that allows key. A column or an ordered collection of
retrieval of data from two or more tables based columns that is identified in the description of a
on matching column values.
Glossary 723
table, index, or referential constraint. The same rejected. See also update-anywhere replication,
column can be part of more than one key. replica table, and conflict detection.
locking. The mechanism used by the database noncomplete CCD table. A CCD table that is
manager to ensure the integrity of data. Locking initially empty and has rows appended to it as
prevents concurrent users from accessing changes are made to the replication source.
inconsistent data. Contrast with complete CCD table. See also
consistent-change data (CCD) table.
log. (1) A file used to record changes made in a
system. (2) A collection of records that describe noncondensed CCD table. A CCD table that
the events that occur during DB2 Universal can contain more than one row for each key
Database for OS/390 execution and that indicate value. These duplicate rows represent the history
their sequence. The information thus recorded is of changes for the values in rows of a table.
used for recovery in the event of a failure during Contrast with condensed CCD table. See also
DB2 Universal Database for OS/390 execution. consistent-change data (CCD) table.
(3) See database log.
non-DB2 relational database server. An
Informix database server or a relational database
M server from a vendor other than IBM.
master table. In update-anywhere replication, nullable. The condition in which a value for a
the original source table for data in the replica column, function parameter, or result can have
table. If replication conflict detection is enabled, an absence of a value.
changes made to the master table are retained,
whereas changes made to the replica table are
O P
object. (1) Anything that can be created or package. A control structure produced during
manipulated with SQLfor example, tables, program preparation that is used to execute SQL
views, indexes, or packages. (2) In object-oriented statements.
design or programming, an abstraction that
consists of data and operations associated with peer table. A replication source or target table
that data. (3) For NetWare, an entity that is defined as part of a peer-to-peer replication
defined on the network and thus given access to configuration.
the file server. (4) In the Information Catalog
Center, an item that represents a unit or distinct peer-to-peer replication. A replication
grouping of information. Each Information configuration in which all peer tables are both
Catalog Center object identifies and describes registered sources and read-write targets, and
information but does not contain the actual there is no primary source table for full refresh.
information. For example, an object can provide In this configuration, there is no replication
the name of a report, list its creation date, and hierarchy among the peer tables. Contrast with
describe its purpose. update-anywhere replication. See also multi-tier
replication.
occasionally connected. A replication
configuration that contains target servers which point-in-time table. A type of replication target
are not always connected to the network. This table whose content matches all or part of a
configuration allows users to connect to a source table, with an added column that
primary data source for a short time to identifies the approximate time when the
synchronize their local database with the data at particular row was inserted or updated at the
the source. source system.
ODBC. See Open Database Connectivity (ODBC). predicate. An element of a search condition that
expresses or implies a comparison operation.
ODBC driver. A driver that implements ODBC
function calls and interacts with a data source. primary key. A unique key that is part of the
definition of a table. A primary key is the default
Open Database Connectivity (ODBC). An API parent key of a referential constraint definition. It
that allows access to database management is a column or combination of columns that
systems using callable SQL, which does not uniquely identifies a row in a table.
require the use of an SQL preprocessor. The
ODBC architecture allows users to add modules, promote. To copy replication definitions for
called database drivers, that link the application to subscription sets or registered sources from one
their choice of database management systems at database to another database, without having to
run time. Application programs do not need to re-register the sources or re-create the
be linked directly to the modules of all the subscription sets.
supported database management systems.
pruning. The task of removing obsolete data
ordinary identifier. (1) In SQL, a letter followed from replication control tables, CD tables, CCD
by zero or more characters, each of which is a tables, or Capture or Apply log files.
letter (a-z and A-Z), a symbol, a number, or the
pull configuration. A replication configuration
underscore character, used to form a name. (2) In
in which the Apply program runs at the target
DB2 Universal Database for z/OS and OS/390,
server; the Apply program pulls updates from
an uppercase letter followed by zero or more
Glossary 725
the source server to apply them to the target. remote database. A database that is physically
Contrast with push configuration. located on a workstation other than the one in
use. Contrast with local database.
push configuration. A replication configuration
in which the Apply program runs at the source replica table. In update-anywhere replication, a
server or a replication server other than the type of target table that can be updated locally
target server; the Apply program pushes updates and also receives updates from the master table
from the source server to apply them to the through a subscription-set definition. If
target. Contrast with pull configuration. replication conflict detection is enabled, changes
made to the replica table are rejected, whereas
R changes made to the master table are retained.
See also update-anywhere replication, master table,
RDBMS. See relational database management and conflict detection.
system (RDBMS).
replication. The process of maintaining a
real-time replication. See synchronous replication. defined set of data in more than one location. It
involves copying designated changes for one
recapture. In update-anywhere replication, to location (a source) to another (a target), and
capture changes at a replica table and forward synchronizing the data in both locations.
these changes to the master table or to other
replica tables. replication administrator. The user responsible
for registering replication sources and creating
referential constraints. The referential integrity subscription sets. This user can also run the
rule that the non-null values of the foreign key Capture and Apply programs.
are valid only if they also appear as values of a
parent key. Replication Alert Monitor. A set of programs
that can monitor the activity of the Capture and
referential integrity. The state of a database in Apply programs, and depending on user-defined
which all values of all foreign keys are valid. alert conditions, can send notifications to specific
Maintaining referential integrity requires the users.
enforcement of referential constraints on all
operations that change the data in a table upon Replication Analyzer. A program that can
which the referential constraints are defined. analyze a replication environment for setup
problems, configuration errors, and performance
| register. To define a DB2 table, view, or issues.
| nickname as a replication source.
Replication Center. A graphical user interface
registration. (1) The process of registering a for DB2 Replication that shows Capture and
DB2 table, view, or nickname as a replication Apply control servers, registered sources,
source. Contrast with subscription. (2) See subscription sets, and Monitor control servers.
replication source. From the Replication Center, a replication
administrator can also perform operational tasks
rejected transaction. A transaction containing for the Capture and Apply programs.
one or more updates from replica tables that are
in conflict with the master table. replication control table. A table in which
replication definitions or control information is
relational database management system stored.
(RDBMS) . A collection of hardware and
software that organizes and provides access to a replication source. A database table, view, or
relational database. nickname that is registered as a source for
replication. Changes made to this type of table
are captured and copied to a target table defined
signal. A communication mechanism for synchpoint. A replication control table value for
replication that allows the Capture, Apply, and the DB2 log or journal record sequence number
Monitor programs to communicate with each of the last change applied during the most recent
other asynchronously. Apply cycle. This value is also used to
coordinate the pruning of CD tables.
source server. A database that contains
registered replication sources. synchronous replication. Also known as
real-time replication, a type of replication that
source table. A table that contains data that is delivers updates continuously and within the
to be replicated to a target table. Contrast with scope of source transactions.
target table.
Glossary 727
target table. A table that is the target for transaction-mode processing. A type of
replicated changes from a registered replication replication subscription-set processing in which
source. It can be a user copy table, a the Apply program retrieves data from the
point-in-time table, a base aggregate table, a source CD table, then applies the data to the
change aggregate table, a CCD table, or a replica target table in the same commit sequence used at
table. the source. The Apply program processes
transactions for all subscription-set members
temporary table. A table that holds temporary together, rather than sequentially. Contrast with
data. For example, temporary tables are useful table-mode processing.
for holding or sorting intermediate results from
queries that contain a large number of rows. The trigger. (1) An object in a database that is
two kinds of temporary tables, which are created invoked indirectly by the database manager
by different SQL statements, are the created when a particular SQL statement is run. See also
temporary table and the declared temporary Capture trigger. (2) A set of SQL statements that is
table. stored in a DB2 database and executed when a
certain event occurs in a DB2 table.
timestamp. A seven-part value that consists of a
date and time expressed in years, months, days,
hours, minutes, seconds, and microseconds.
U
trace. (1) A DB2 Universal Database for z/OS UDT. See user-defined type (UDT).
and OS/390 facility that provides the ability to
uncommitted read (UR). An isolation level that
monitor and collect monitoring, auditing,
allows an application to access uncommitted
performance, accounting, statistics, and
changes of other transactions. The application
serviceability (global) data. (2) For DB2
does not lock other applications out of the row
replication, a facility that provides the ability
that it is reading unless the other application
collect monitoring, auditing, and performance
attempts to drop or alter the table.
data for the Capture program, Apply program,
or Replication Alert Monitor. Unicode. An international character encoding
scheme that is a subset of the ISO 10646
transaction. (1) An exchange between a
standard. Each character supported is defined
workstation and a program, two workstations, or
using a unique 2-byte code.
two programs that accomplishes a particular
action or result. An example of a transaction is unique index . An index that ensures that no
the entry of a customers deposit and the identical key values are stored in a table.
subsequent update of the customers balance.
Synonym for unit of work. (2) One Net.Data unique key. A key that is constrained so that no
invocation. If persistent Net.Data is used, then a two of its values are equal.
transaction can span multiple Net.Data
invocations. unit of work. (1) A recoverable sequence of
operations within an application process. At any
transaction-based replication. A type of time, an application process is a single unit of
replication processing in which every transaction work, but the life of an application process can
is replicated to the target table when it is involve many units of work as a result of commit
committed in the source table. Contrast with or rollback operations. In a DB2 Universal
transaction-consistent replication. Database for z/OS and OS/390 multisite update
operation, a single unit of work can include
transaction-consistent replication. A type of several units of recovery. Synonym for
replication processing in which the net result of transaction. (2) In the Information Catalog Center,
all transaction updates is replicated to the target a recoverable sequence of operations within an
table. Contrast with transaction-based replication. application process. At any time, an application
unit-of-work (UOW) table. A replication control work file. A temporary file used by the Apply
table stored in the Capture control server that program when processing a subscription set.
contains commit records read from the database
log or journal. The records show that a
transaction or UOW committed successfully and
include a unit-of-recovery ID that can be used to
join the unit-of-work table and the CD table to
produce transaction-consistent change data.
V
view. (1) A logical table that consists of data
that is generated by a query. A view is based on
an underlying set of base tables, and the data in
a view is determined by a select type query that
is run on the base tables. (2) A way of looking at
the information about, or contained in objects.
Each view might reveal different information
about its objects.
W
warm start. (1) A restart that allows reuse of
previously initialized input and output work
Glossary 729
730 DB2 Replication Guide and Reference
Index
APPLHEAPSZ configuration Apply program (continued)
Special characters parameter 30 for OS/400
; delimiter 126
applications ALWINACT parameter 452
$TA JES2 command 484
starting replication programs APYQUAL parameter 450
*.APP.log file 157
from 717 checking status 177
*.CAP.log file 137
Apply control server COPYONCE parameter 453
*.err file 160
adding to Replication creating SQL packages 34
*.sqs file 160
Center 267 CTLSVR parameter 450
# delimiter 126
control tables at 546 DELAY parameter 453
A Apply control tables
APPENQ (Apply enqueue) 547
FULLREFPGM
parameter 451
abstract data types 107
activating subscription sets 76, 274 APPLY_JOB (Apply job) 547 INACTMSG parameter 452
add_partition parameter APPLYTRACE (Apply JOBD parameter 449
overview 133 trace) 552 OPTSNGSET parameter 454
use with asncap command 331 APPLYTRAIL (Apply trail) 553 RTYWAIT parameter 453
ADDDPRREG command 367 APPPARMS (Apply scheduling 484
parameters) 548 setting up 33, 36
ADDDPRSUB command 378
ADDDPRSUBM command 395 changing 163 starting 161, 447
ADDEXITPGM command 40 using 151 stopping 164, 416
ADDJOBSCDE command 484 list of 546 SUBNFYPGM parameter 452
SUBS_COLS (subscription TRACE parameter 451
administration
columns) 560 TRLREUSE parameter 454
authorization requirements 19
after-image columns 50 SUBS_EVENT (subscription USER parameter 449
aggregate tables events) 562 for UNIX
SUBS_MEMBR (subscription apply_path parameter 153,
base aggregate 91, 593
members) 563 324
change aggregate 91, 594
SUBS_SET (subscription apply_qual parameter 154,
alert conditions
sets) 569 318, 323
for Replication Alert
Monitor 185 SUBS_STMTS (subscription binding 32
statements) 575 checking status 175
Alert Monitor
Apply enqueue (APPENQ) configuring 31
See Replication Alert Monitor
alert_prune_limit parameter 190 table 547 control_server
Apply job (APPLY_JOB) table 547 parameter 154, 318, 324
ALERTS (Monitor alerts) table 577
Apply parameters (APPPARMS) copyonce parameter 154, 326
ALWINACT parameter 452
Analyzer table 548 default parameters 149
changing 163 delay parameter 155, 327
for OS/400
using 151 errwait parameter 155, 327
creating SQL packages 34
Apply program inamsg parameter 156, 325
invocation parameters 407
for UNIX, invocation authorization requirements 23 loadxit parameter 156, 325
changing parameter values 150 logreuse parameter 157, 324
parameters 320
for Windows, invocation commands 317 logstdout parameter 157, 325
communicating with notify parameter 157, 325
parameters 320
Capture program 485, 486 operating 318
Analyzer report
Capture triggers 485, 488 opt4one parameter 158, 327
ANZDPR command 406
asnanalyze command 319 Replication Alert password file 26
ANZDPR command 406 Monitor 490 pwdfile parameter 158, 324
ANZDPRJRN command 39 Replication Center 485 setting up 29
APPENQ (Apply enqueue) connectivity 17 sleep parameter 158, 326
data blocking 77 spillfile parameter 159, 328
table 547
Index 733
Capture program (continued) Capture program (continued) Capture program (continued)
for OS/400 for UNIX (continued) for Windows (continued)
authorization configuring 30 cold start parameters 141,
requirements 21 default parameters 127 334
CAPCTLLIB parameter 461 lag_limit parameter 137, 332 commit_interval
changing attributes 410 logreuse parameter 137, 332, parameter 136, 332, 339
checking status 177 340 configuring 30
CLNUPITV parameter 460 logstdout parameter 138, default parameters 127
cold start parameters 458 332, 340 lag_limit parameter 137, 332
cold start, automatic 465 memory_limit logreuse parameter 137, 332,
creating SQL packages 34, 35 parameter 138, 333, 340 340
default parameters 129 monitor_interval logstdout parameter 138,
FRCFRQ parameter 464 parameter 138, 333, 340 332, 340
JOBD parameter 458 monitor_limit parameter 138, memory_limit
journal entry types 713 333, 340 parameter 138, 333, 340
journals and journal receivers, operating 127, 336 monitor_interval
managing 38 prune_interval parameter 138, 333, 340
JRN parameter 461 parameter 139, 333, 341 monitor_limit parameter 138,
LAG parameter 463 pruning 336 333, 340
MEMLMT parameter 462 pwdfile parameter 333 operating 127, 336
MONITV parameter 462 reinitializing 147, 336 prune_interval
MONLMT parameter 462 resuming 147, 336 parameter 139, 333, 341
operating 127 retention_limit pruning 336
overriding attributes of 434 parameter 140, 333, 341 pwdfile parameter 333
progress of 195 setting up 29 reinitializing 147, 336
reinitializing 432 sleep_interval resuming 147, 336
RESTART parameter 458 parameter 140, 333, 341 retention_limit
RETAIN parameter 463 starting 132, 330, 717 parameter 140, 333, 341
scheduling 484 startmode parameter 141, setting up 29
setting up 33, 36 334 sleep_interval
starting 142, 456 status of 336 parameter 140, 333, 341
stopping 145, 420 stopping 145, 336 starting 132, 330, 717
TRCLMT parameter 461 suspending 146, 336 startmode parameter 141,
WAIT parameter 459 term parameter 142, 335, 341 334
warm start parameters 458 trace_limit parameter 142, status of 336
for UNIX 335, 342 stopping 145, 336
add_partition parameter 133, warm start parameters 141, suspending 146, 336
331 334 term parameter 142, 335, 341
autoprune parameter 134, for Windows trace_limit parameter 142,
331, 339 add_partition parameter 133, 335, 342
autostop parameter 134, 332, 331 warm start parameters 141,
339 autoprune parameter 134, 334
binding 31 331, 339 for z/OS
capture_path parameter 135, autostop parameter 134, 332, add_partition parameter 133,
331 339 331
capture_schema binding 31 autoprune parameter 134,
parameter 135, 331, 337 capture_path parameter 135, 331, 339
capture_server 331 autostop parameter 134, 332,
parameter 136, 330, 337 capture_schema 339
changing parameters 336 parameter 135, 331, 337 capture_path parameter 135,
checking status 175 capture_server 331
cold start parameters 141, parameter 136, 330, 337 capture_schema
334 changing parameters 336 parameter 135, 331, 337
commit_interval checking status 175 capture_server
parameter 136, 332, 339 parameter 136, 330, 337
Index 735
columns (continued) connecting (continued) control tables (continued)
registering in source table 48 to z/OS server 18 CAPENQ (Capture
relative record numbers on connectivity enqueue) 508
OS/400 64 between DB2 operating CAPMON (Capture monitor)
renaming 102, 123 systems 17, 18 pruning 248
subsetting failure recovery for control structure 509
at the source 48 tables 250 CAPPARMS (Capture
at the target 101 consistent-change-data (CCD) tables parameters)
commands adding UOW columns 92 structure 511
See replication commands external CAPSCHEMAS (Capture
commit_interval parameter multi-tier replication 94 schemas) 506
overview 136 internal CAPTRACE (Capture trace)
tuning 4 multiple targets 93 pruning 248
use with asncap command 332 locks on 13 structure 515
use with asnccmd non-DB2 relational data sources Capture
command 339 using CCD tables 46 creating 265
compression dictionaries nonrelational data sources Capture server 499
(z/OS) 241 maintaining CCD tables 68 CCD (consistent-change-data)
computed columns using CCD tables 43 Capture control server 517
CD table 91 replication sources 94 target server 594
creating 123 structure CD (change-data) 518
source table 91 Capture control server 517 CONDITIONS (Monitor
CONDITIONS (Monitor conditions) target server 594 conditions) 579
table 579 usage connectivity failure recovery 250
configuration parameters for DB2 history or audit 92 CONTACTGRP (Monitor group
APPLHEAPSZ 30 multi-tier replication 94 contacts) 584
DBHEAP 30 CONTACTGRP (Monitor group CONTACTS (Monitor
LOGBUFSZ 30 contacts) table 584 contacts) 584
LOGFILSIZ 30 contacts creating
LOGPRIMARY 30 for Replication Alert for Apply 266
LOGSECOND 30 Monitor 185 for Capture 265
MAXAPPLS 30 CONTACTS (Monitor contacts) for non-DB2 relational
configuring table 584 sources 27
Apply program control servers, adding to for Replication Alert
for UNIX 31 Replication Center 267 Monitor 184, 266
for Windows 31 control tables in IASP groups 27
Capture program ALERTS (Monitor alerts) 577 multiple database operating
for UNIX 30 APPENQ (Apply enqueue) 547 system 26
for Windows 30 Apply multiple database
connectivity 17 creating 266 partitions 29
Replication Alert Monitor Apply control server 502 multiple sets 28
for UNIX 32 APPLY_JOB (Apply job) 547 on OS/400 27, 415
for Windows 32 APPLYTRACE (Apply on UNIX, Windows 26
Replication Center 257 trace) 552 on z/OS 27
conflict detection APPLYTRAIL (Apply trail) 553 dropping
levels of 62 APPPARMS (Apply for Replication Alert
overview 61 parameters) 548 Monitor 184
peer-to-peer replication 11 at Apply control server 546 dynamic 243
planning 11 at Capture control server 506 granting authority for
requirements 52 at Monitor control server 577 OS/400 21, 422
update-anywhere replication 11 authorization requirements for GROUPS (Monitor groups) 586
conflicts OS/400 36 I/O error recovery 250
preventing 11 AUTHTKN (Apply-qualifier maintaining 243
connecting cross-reference) 507 MONENQ (Monitor
to iSeries server 18 enqueue) 585
Index 737
differential refresh replication horizontal (row) subsetting
See change-capture replication
F (continued)
FIELDPROC clauses
disk space at the target 101
restrictions, compression 107
requirements 6
temporary files 9
file-copy daemons
ASNDLCOPYD 115
I
display names 480 I/O error recovery, control
DLFM_ASNCOPYD 113 tables 250
distinct data types 108
files IASP groups 27
distributed recovery points 230
*.APP.log 157 IMS data sources
DLFM_ASNCOPYD file-copy
*.CAP.log 137
daemon 113 maintaining CCD tables 68
*.err 160 registering 43
double-byte character large object
*.sqs 160 using CCD tables 43
(DBCLOB)
asndone.smp 165
replication considerations 108 IMS DataPropagator 43
asnload.ini 172
double-deletes 67 inactive subscription sets 76
spill 9 INACTMSG parameter 452
DPR registrations (OS/400)
fragmentation inamsg parameter 156, 325
adding 367
horizontal Independent Auxiliary Storage Pool
removing 440
at the source 49 (IASP) groups 27
DSPJRN command 195
at the target 101
dynamic control tables 243 indexes
peer-to-peer replication 11
target tables 104
E update-anywhere replication 11
vertical
inner-joins as sources 65
editing, SQL scripts 125 internal CCD tables
EDITPROC clauses at the source 48 multiple targets 93
at the target 101
restrictions, compression 107 interval timing 83
email_server parameter 191 FRCFRQ parameter 464 invocation parameters
ENDDPRAPY command 416 full-refresh copying Analyzer
ENDDPRCAP command 145, 420 Apply for iSeries 64, 451 for OS/400 407
ENDJOB command 421 forcing 277 for UNIX 320
environment variables registration option 48 for Windows 320
Capture program 30 FULLREFPGM parameter 451 Apply program
DB2CODEPAGE 14, 30 for OS/400 161, 448
DB2DBDFT 30
G for UNIX 152, 323
gap detection 92
DB2INSTANCE 30 for Windows 152, 323
generated SQL scripts 125
LIBPATH 30 for z/OS 152, 323
global record 528
errwait parameter 155, 327 Capture program
GROUPS (Monitor groups)
event-based scheduling 83 for OS/400 127, 142, 410, 457
table 586
events, coordinating 226 for UNIX 133, 330
GRTDPRAUT command
existing tables as targets 99 for Windows 133, 330
granting privileges to SQL
exit routines for z/OS 133, 330
packages 35
ASNDLCOPY 111 Replication Alert Monitor
syntax 422
ASNDONE for UNIX 345
GRTOBJAUT command 35
using 164, 165 for Windows 345
ASNLOAD
customizing 171
H for z/OS 345
replication commands
heterogeneous replication
for OS/400 172 for OS/400 369, 380, 397,
registering sources 46
for UNIX 168 416, 417, 420, 423, 433, 435,
restrictions
for Windows 168 440, 441, 444, 446, 448, 457,
aggregate tables 91
for z/OS 169 CCD tables 51 467
using 167 INZDPRCAP command 432
multi-tier replication 94
delete journal receiver update-anywhere 56, 97 iSeries server
(OS/400) 39 history data connecting to 18
external CCD tables CCD tables 92
multi-tier replication 94 source data 52
J
JCL
horizontal (row) subsetting
starting the Apply program 473
at the source 49
Index 739
Monitor control server monitoring (continued)
adding to Replication status of programs 177
O
objects
Center 267 MONITV parameter 462
changing attributes 198
control tables at 577 MONLMT parameter 462
deactivating 202
creating control tables 184 MONPARMS (Monitor parameters)
reactivating 203
Monitor control tables table 586
registering 198
ALERTS (Monitor alerts) 577 MONSERVERS (Monitor servers)
stop capturing changes 202
CONDITIONS (Monitor table 589
operating
conditions) 579 MONTRACE (Monitor trace)
Apply program 279, 318
CONTACTGRP (Monitor group table 590
Capture program 278, 336
contacts) 584 MONTRAIL (Monitor trail)
Replication Alert Monitor 279,
CONTACTS (Monitor table 591
343
contacts) 584 multi database partition
opt4one parameter 158, 327
GROUPS (Monitor groups) 586 log records 239
OPTSNGSET parameter 454
list of 577 multi-tier replication
OS/400 data sources
MONENQ (Monitor defining subscription sets 94
with remote journaling 63
enqueue) 585 multiple database partitions
overriding attributes (OS/400)
MONPARMS (Monitor Capture 35
Capture program 434
parameters) 586 multiple target tables 93
OVRDPRCAPA command 434
MONSERVERS (Monitor MVS console 473, 474
servers) 589
MONTRACE (Monitor N P
packages, rebinding 244
trace) 590 names
parameters, invocation
MONTRAIL (Monitor trail) 591 Apply qualifier rules 315
Analyzer
Monitor enqueue (MONENQ) Capture schema rules 315
for OS/400 407
table 585 display names 480
for UNIX 320
Monitor group contacts for Windows services 316
for Windows 320
(CONTACTGRP) table 584 Monitor qualifier rules 315
Apply program
Monitor groups (GROUPS) of Capture triggers 13
for OS/400 161, 448
table 586 of replication services 480
for UNIX 152, 323
Monitor parameters (MONPARMS) subscription sets 211
for Windows 152, 323
table 586 national language support (NLS) 14
for z/OS 152, 323
Monitor program network connectivity 17
Capture program
messages 183 nicknames
for OS/400 410, 457
printing 183 for crossloader utility 171
for UNIX 133, 330
Monitor qualifiers, naming registering 46
for Windows 133, 330
rules 315 restrictions
for z/OS 133, 330
Monitor servers (MONSERVERS) aggregate tables 91
Replication Alert Monitor
table 589 multi-tier replication 94
for UNIX 345
Monitor trace (MONTRACE) update-anywhere 56, 97
for Windows 345
table 590 with CCD tables 51
for z/OS 345
Monitor trail (MONTRAIL) NLS (national language support) 14
replication commands
table 591 non-DB2 relational data sources
for OS/400 369, 380, 397,
monitor_errors parameter 193 locks 13
416, 417, 420, 423, 433, 435,
monitor_interval parameter (for registering 46
440, 441, 444, 446, 448, 457,
Capture) 138, 333, 340 restrictions
467
monitor_interval parameter (for aggregate tables 91
partition information
Replication Alert Monitor) 188 multi-tier replication 94
(PARTITIONINFO) table 519
monitor_limit parameter 138, 333, update-anywhere 56, 61, 97
Partition information
340 source servers 12
(PARTITIONINFO) table 519
monitor_path parameter 189 using CCD tables 46
PARTITIONINFO (partition
monitoring nonrelational data sources
information) table 519
automated 183 maintaining CCD tables 68
password files
for OS/400 195 using CCD tables 43
asnpwd command 349
historical trends 177 notify parameter 157, 325
storing 26
Index 741
Replication Alert Monitor (continued) Replication Center (continued) replication commands (continued)
ASNMAIL exit 192 control tables 264 for OS/400 (continued)
authorization requirements 24 control-table profiles 262 GRTDPRAUT 35, 422
changing contacts 185 creating subscription sets 271 GRTOBJAUT 35
communicating with deactivating subscription INZDPRCAP 432
Apply program 490 sets 274 OVRDPRCAPA 434
Capture 490 deleting definitions 278 RCVJRNE 38
Replication Center 489 description 255 RMVDPRREG 440
control tables 184 enabling databases for change RMVDPRSUB 441
copying contacts 185 capture 268 RMVDPRSUBM 443
defining contacts 185 forcing full refresh 277 RMVEXITPGM 40
for UNIX launchpad 259 RVKDPRAUT 446
binding 32 operating Apply program 279 SBMJOB 484
checking status 175 operating Capture program 278 STRDPRAPY 162, 447
operating 343 operating Replication Alert STRDPRCAP 456
starting 187, 345, 717 Monitor 279 STRJRNPF 37
for Windows profiles 261 WRKDPRTRC 466
binding 32 promote functions 235 WRKJOB 177
checking status 175 promoting registered tables or WRKREGINF 40
operating 343 views 275 WRKSBMJOB 177
starting 187, 345, 717 promoting subscription sets 276 WRKSBSJOB 177
for z/OS registering sources 269 for UNIX
checking status 175 removing definitions 278 asnacmd 318
operating 343 source-object profiles 262 asnanalyze 319
starting 187, 345, 473 starting 258 asnapply 322
memory usage 5 target-object profiles 263 asncap 330
operating 279 user IDs and passwords 260 asnccmd 336
pruning 190 replication commands asnmcmd 343
reinitializing 193 $TA JES2 asnmon 345
scheduling 193, 483, 484 Apply for z/OS 484 asnpwd 349
selecting alert conditions 185 Capture for z/OS 484 asntrc 357
setting notification 191, 193 ADDJOBSCDE 484 for Windows
specifying run times 188 ASNL2RNx 473 asnacmd 318
stopping 194 AT 483, 484 asnanalyze 319
storing output from 189 AT NetView asnapply 322
tracing 190 Apply for z/OS 484 asncap 330
Replication Analyzer Capture for z/OS 484 asnccmd 336
for OS/400 backup database 30 asnmcmd 343
creating SQL packages 34 CRTJRNRCV 36 asnmon 345
invocation parameters 407 db2rc 258 asnpwd 349
for UNIX, invocation DSPJRN 195 asnscrt 353
parameters 320 for OS/400 asnsdrop 356
for Windows, invocation ADDDPRREG 367 asntrc 357
parameters 320 ADDDPRSUB 378 for z/OS
Replication Center ADDDPRSUBM 395 asnacmd 318
activating subscription sets 274 ADDEXITPGM 40 asnapply 322
adding servers 267 ANZDPR 406 asncap 330
communicating with ANZDPRJRN 39 asnccmd 336
Apply program 485 CHGDPRCAPA 410 asnmcmd 343
Capture program 485 CHGJRN 39 asnmon 345
Capture triggers 485 CRTDPRTBL 415 asntrc 357
Replication Alert CRTJRN 37 MODIFY 474
Monitor 489 ENDDPRAPY 416 update database
configuring 257 ENDDPRCAP 145, 420 configuration 30
connectivity 17 ENDJOB 421
Index 743
setting up (continued) sources (continued) starting (continued)
Capture programs registration options (continued) Capture program (continued)
for OS/400 33 change-capture using Windows services 479
for UNIX 29 replication 48 Replication Alert Monitor
for Windows 29 column (vertical) for UNIX 187, 345, 717
journals 36 subsetting 48 for Windows 187, 345, 717
Replication Alert Monitor 32 conflict detection 61 for z/OS 187, 345, 473
signal (SIGNAL) table full-refresh copying 48 starting Replication Center 258
pruning 248 recapturing changes startmode parameter 141, 334
structure 540 (update-anywhere) 56 static control tables 245
SIGNAL (signal) table relative record numbers 64 status
pruning 248 row (horizontal) Apply program 175, 177
structure 540 subsetting 49 Capture program 175, 177
signals stop Capture on error 54 journal jobs 177
CAPSTART 232 updates as deletes and Replication Alert Monitor 175
CAPSTOP 233 inserts 55 stop Capture on error option 54
setting distributed recovery using remote journals 63 stop capturing changes 202
points 230 subscribing to 74 STOP signals 229, 230
STOP 229, 230 spatial data types 107 stopping
USER 226 special data types Apply program
sleep parameter 158, 326 replicating for OS/400 164, 416
sleep_interval parameter 140, 333, DATALINK values 109 for UNIX 164, 318
341 large objects (LOB) 108 for Windows 164, 318
source logs, maintaining 238 spill files for z/OS 164, 318
source servers storage for Apply 10 Capture program
DB2 storage for Capture 10 for OS/400 145, 420
log impact 6 storage for diagnostic files 9 for UNIX 145, 336
non-DB2 relational spillfile parameter 159, 328 for Windows 145, 336
log impact 12 splitting for z/OS 145, 336
source systems, maintaining 237 subscription sets 213 Replication Alert Monitor
source tables SQL files, editing 125 for UNIX 194, 343
adding columns 199 SQL packages for Windows 194, 343
creating journals for 36 creating for Apply program 34 for z/OS 194, 343
maintaining 237 creating for Capture storage
retrieving lost data 251 program 34, 35 Apply diagnostic files 10
sources creating for Replication Apply spill files 10
CCD (consistent-change-data) Analyzer 34 Capture diagnostic files 10
tables 94 SQL scripts 125 Capture spill files 10
maintaining CCD tables 68 SQL statements CD table 9
mapping to targets 85 defining for subscription set 81 control tables 8
profiles 262 run-time processing 122 database log and journal data 6
promoting 275 sqlerrcontinue parameter 159, 328 diagnostic files 9
registering staged replication 95 requirements 6
DB2 tables 43 staging data 94 target tables 8
IMS data sources 43 starting temporary files 9
non-DB2 relational 46 Apply program UOW table 9
Replication Center 269 for OS/400 161, 447 stored procedures
views 65, 67 for UNIX 151, 322, 717 defining for subscription set 81
registering columns 48 for Windows 151, 322, 717 manipulating data 122
registering rows 49 for z/OS 151, 322, 473 STRDPRAPY command 162, 447
registration options Capture program STRDPRCAP command 456
after-image columns 50 for OS/400 142, 456 STRJRNPF command 37
before-image columns 50 for UNIX 132, 330, 717 SUBNFYPGM parameter 452
before-image prefix 53 for Windows 132, 330, 717 SUBS_COLS (subscription columns)
for z/OS 132, 330, 473 table 560
Index 745
tables (continued) target tables (continued) tips (continued)
PRUNCNTL (pruning change aggregate (continued) using stored procedures for
control) 520 usage 91 additional processing of
PRUNE_LOCK (prune lock) 523 defining columns 101 sets 165
PRUNE_SET (prune set) 524 defining rows 101 using stored procedures with
reactivating 203 defining target key 104 ASNDONE 166
REG_EXT (register fragmenting 101 verifying a service is set up
extension) 525 list of 593 correctly 479
REG_SYNCH (register maintaining 251 verifying change capture
synchronization) 536 mapping to sources 85 began 132
REGISTER (register) 527 new columns for 123 trace facility
registering point-in-time for OS/400 466
DB2 43 definition 87 for UNIX 357
non-DB2 relational 46 structure 597 for Windows 357
procedure 198 usage 90 for z/OS 357
removing registrations 205 replica TRACE parameter 451
replica 11, 598 conflict detection for 11 trace_limit parameter
RESTART (restart) 537 definition 87 overview 142
SEQTABLE (sequencing) 539 structure 598 pruning from the Replication
SIGNAL (signal) 540 usage 97 Alert Monitor 190
stop capturing changes 202 storage requirements 8 use with asncap command 335
structures 491 table structures, quick use with asnccmd
SUBS_COLS (subscription reference 505 command 342
columns) 560 user copy use with asnmon command 347
SUBS_EVENT (subscription definition 87 transaction throughput rates
events) 562 structure 598 Capture triggers 12
SUBS_MEMBR (subscription usage 90 transaction-mode processing 7, 80
members) 171, 563 user defined 89, 99 transactions
SUBS_SET (subscription target-key columns memory used by 3
sets) 569 updating 105 transforming data
SUBS_STMTS (subscription targets at registration 121
statements) 575 forcing full refresh 277 at subscription 122
target tables profiles 263 creating computed columns 123
See also target tables term parameter (for Apply) 160, renaming columns 102, 123
maintaining 251 328 translating data 14
UOW (unit-of-work) 544 term parameter (for Capture) 142, TRCLMT parameter 461
user copy 598 335, 341 triggers
target indexes 104 termination characters, in generated capturing data 12
target keys 104 SQL scripts 126 merging 13
target servers three-tier replication on CD tables 118
log impact 7 configuration 95 suppressing data capture 118
tables at 593 throughput trlreuse parameter 161, 327
target tables Apply program 181 TRLREUSE parameter 454
applying subset of columns 101 Capture program 179 troubleshooting commands
applying subset of rows 101 throughput rates asntrc 357
base aggregate Capture triggers 12 WRKDPRTRC 466
definition 87 time-based scheduling 83 TSO 473, 474
structure 593 tips tuning
usage 91 checking if Apply processed a set commit_interval parameter 4
CCD (consistent-change-data) successfully 160 memory_limit parameter 4
overview 87 deleting rows from the Apply performance 16
structure 594 trail table 161
change aggregate estimating use of space 6 U
definition 87 using sleep versus copyonce Unicode tables 711
structure 594 parameters 155, 159
V
VALIDPROC clauses 107
vertical (column) subsetting
at the source 48
at the target 101
views
changing attributes 198
registering
as sources 67
overview 65
procedure 198
restrictions 65, 67, 68
Index 747
748 DB2 Replication Guide and Reference
Notices
IBM may not offer the products, services, or features discussed in this
document in all countries. Consult your local IBM representative for
information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or
imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not infringe
any IBM intellectual property right may be used instead. However, it is the
users responsibility to evaluate and verify the operation of any non-IBM
product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give
you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any
other country/region where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY,
OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow
disclaimer of express or implied warranties in certain transactions; therefore,
this statement may not apply to you.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those
Web sites. The materials at those Web sites are not part of the materials for
this IBM product, and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information that has been exchanged, should contact:
IBM Canada Limited
Office of the Lab Director
8200 Warden Avenue
Markham, Ontario
L6G 1C7
CANADA
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer
Agreement, IBM International Program License Agreement, or any equivalent
agreement between us.
This information may contain examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the examples
include the names of individuals, companies, brands, and products. All of
these names are fictitious, and any similarity to the names and addresses used
by an actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
Each copy or any portion of these sample programs or any derivative work
must include a copyright notice as follows:
(your company name) (year). Portions of this code are derived from IBM
Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All
rights reserved.
Notices 751
Trademarks
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both, and have been used
in at least one of the documents in the DB2 UDB documentation library.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Intel and Pentium are trademarks of Intel Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and
other countries.
Notices 753
754 DB2 Replication Guide and Reference
Contacting IBM
In the United States, call one of the following numbers to contact IBM:
v 1-800-IBM-SERV (1-800-426-7378) for customer service
v 1-888-426-4343 to learn about available service options
v 1-800-IBM-4YOU (426-4968) for DB2 marketing and sales
Product information
Information regarding DB2 Universal Database products is available by
telephone or by the World Wide Web at
www.ibm.com/software/data/db2/udb
This site contains the latest information on the technical library, ordering
books, client downloads, newsgroups, FixPaks, news, and links to web
resources.
If you live in the U.S.A., then you can call one of the following numbers:
v 1-800-IBM-CALL (1-800-426-2255) to order products or to obtain general
information.
v 1-800-879-2755 to order publications.
For information on how to contact IBM outside of the United States, go to the
IBM Worldwide page at www.ibm.com/planetwide
Printed in USA
SC27-1121-01
Spine information:
IBM DB2 Universal Database DB2 Replication Guide and Reference Version 8