To replicate transactions against tables in a primary database, the primary table (the table that contains the data affected by the transactions in the primary database) must be marked for replication and replication must be enabled for that table.
Marking a table for replication is separate from enabling
replication for the table. If the value of the pdb_dflt_object_repl parameter
is true, replication is enabled automatically
at the time a table is marked. See “Enabling and disabling replication for marked tables” for more information on enabling
and disabling replication for a marked table.
If you need to temporarily suspend replication from a marked object, for example, when database maintenance operations are performed in the primary database, you can disable replication for the marked object. See “Enabling and disabling replication for marked tables” for more information.
Log-based Replication Agents (for DB2 Universal Database) and trigger-based Replication Agents (for Informix, Microsoft SQL Server, and Oracle) have different table marking and unmarking behavior in the primary database.
When a primary table is marked for replication with a log-based Replication Agent, such as Replication Agent for UDB, the following events occur:
The value of the table’s DATA CAPTURE option is set to DATA CAPTURE CHANGES (DB2 Universal Database).
A row is added to the Replication Agent marked objects table in the primary database. Each row in the marked objects table lists attributes of a table marked for replication in the primary database.
If you need to change the schema of a marked table in the primary database, you must:
Lock the table so that no new transactions occur.
Wait for the Replication Agent to complete its processing of any transactions on the table.
Quiesce the Replication Agent instance.
Change the table’s schema, without changing the DATA CAPTURE option.
Unlock the table to allow user transactions to continue.
Use the Replication Agent resume command to restart replication.
If you change the schema of a primary table, you may
need to rematerialize the replicate table.
When you unmark a table that is marked for replication with a log-based Replication Agent, such as Replication Agent for UDB, the following events occur:
The value of the table’s DATA CAPTURE option is restored to the value it had before the table was marked (DB2 Universal Database).
The table’s row in the marked objects table is deleted.
When a table is unmarked with a log-based Replication Agent, any subsequent operations that affect the data in that table are ignored.
In the event that a log-based Replication Agent must re-read
any part of the transaction log, such as when recovering from a
replication system failure, transactions that were recorded prior
to a table being unmarked will not be replicated.
When a primary table is marked for replication, a trigger-based Replication Agent creates several transaction log objects to support replication for that table:
shadow table – prefixSH_xxx
blob shadow table – prefixBSH_xxx
shadow-row procedure – prefixSRP_xxx
blob shadow-row procedure – prefixBSRP_xxx
insert trigger – prefixINSTRG_xxx
update trigger – prefixUPDTRG_xxx
delete trigger – prefixDELTRG_xxx
where prefix is the one- to three-character transaction log prefix string specified by the pdb_xlog_prefix parameter and xxx is an alphanumeric counter string that is incremented each time an object is marked in the primary database.
The prefix string defined by the pdb_xlog_prefix parameter
is used for all Replication Agent transaction log database objects.
For example, if the prefix string defined by the pdb_xlog_prefix parameter is ra_ (the default value) and three tables have been marked, the following names are used for the transaction log objects for the third marked table:
shadow table – ra_SH_c
blob shadow table – ra_BSH_c
shadow-row procedure – ra_SRP_c
blob shadow-row procedure – ra_BSRP_c
insert trigger – ra_INSTRG_c
update trigger – ra_UPDTRG_c
delete trigger – ra_DELTRG_c
If triggers already exist for the primary table, the Replication Agent attempts
to insert its trigger code, leaving the existing trigger code intact.
You can configure the Replication Agent instance to simply build the script
to mark the table, but not execute it, by setting the value of the pdb_auto_run_scripts parameter
to false. To complete the table marking, you
have to manually execute the script.
If you need to change the schema of a marked table in the primary database, you must first unmark the table to remove the shadow table, stored procedure, and triggers that Replication Agent creates for the primary table, then change the primary table’s schema and re-mark the table.
If you change the schema of a primary table, you may
need to rematerialize the replicate table.
When you unmark an object that is marked for replication with a trigger-based Replication Agent, the transaction log objects (shadow table, stored procedure, and triggers) that were created to facilitate the replication for that table are removed from the primary database.
Sybase Replication Agent provides two ways to unmark an object:
Normal – The Replication Agent first checks to see if replication is disabled for the object, then checks for any unprocessed transactions in the transaction log. If replication is not disabled for the object, or if any unprocessed transactions remain in the transaction log, the unmarking fails.
Force – The Replication Agent unmarks the object immediately, without checking for disabled status and unprocessed transactions.
In general, the force option should be used only when you are removing the entire transaction log and discontinuing replication from the primary database, or during troubleshooting procedures.
