Possible Issues when Dropping Primary Objects

Drop primary tables or stored procedures from an Adaptive Server with caution because doing so affects data replication.

If updates are made to the primary table and the table is then dropped from the Adaptive Server, Adaptive Server error 9104 is displayed in the Adaptive Server error log (for the RepAgent) :

Message: 9104 ’Cannot identify the object on the INSERT
log record for database ’MY_PDB1’, XACT ID Rid pageid =
0xa0f; row num = 0x5, RID Rid pageid = 0xa0f; row num =
0x6. Information associated with the INSERT log record
is not replicated.

The log record for a replicated data operation references another log page, called the oampage, that has information about the replicated object. Since the table was dropped, the oampage is deallocated and the data cannot be replicated. If the oampage is assigned to a newly created object, the Adaptive Server may associate log records for the dropped object with the new object.

In this example, the oampage for foo may be allocated to foo_bar after foo is dropped:

update table foo
 drop table foo
create table foo_bar
 update foo_bar

Adaptive Server sends the first update record as an update to foo_bar instead of foo. If the new table has a much larger row size, then an Adaptive Server segmentation fault may occur.

Dropping or re-creating replicated stored procedures leads to unpredictable results; schema alterations have the same effect. Make these type of changes only after the RepAgent has processed all the records for the stored procedure.

Also, check the Replication Server for error messages.