On the secondary server, an assertion failure would look like
this:
08:31:36 Log record (OLDRSAM:HINSERT) failed, partnum 0x1001f0
rowid 0x203 iserrno 126
Log Record: log = 20, pos = 0x10018, type = OLDRSAM:HINSERT(40),
trans = 28
...
08:31:36 Assert Failed: Logical log replay error.
08:31:36 Who: Session(21, informix@server, 0, 0x44c56fa8)
Thread(39, xchg_1.2, 44c19c68, 1)
File: rsprecvr.c Line: 7585
08:31:36 Results: The secondary server cannot continue.
08:31:36 Action: Reestablish the secondary server.
...
08:31:36 Stack for thread: 39 xchg_1.2
base: 0x0000000046237000
len: 69632
pc: 0x00000000018e5867
tos: 0x0000000046246de0
state: running
vp: 1
afstack
afhandler
afcrash_interface
rollfwd_error
rlogm_redo
next_recvr
prod_loop2
producer_thread
startup
The problem can happen when inserting via a prepared statement
into a table that had been truncated previously (to encounter
the problem the truncate table would happen after the statement
had been prepared and rows would have needed to be inserted with
the prepared statement as well). So any newly prepared
statement after a table is truncated would not cause a problem.
The problem seems to be that in some cases, the prepared
statement can retain information about the last page it inserted
a row into, and this info is used during inserts to hint/speed
up the insert process. So using this information after a
truncate can cause a row to get inserted into a page of the
table well past the partitions npused count, which is what then
causes the recovery problem.
Another detail to hit the problem is the session doing the
insert on the primary seems to need to have the table that's
being truncated opened multiple times (so it would need to show
up for more then one isfd in onstat -g opn output). |
