当alter table里面某些属性的时候,Db2会生成新的version的table,并且在alter发生之后,insert第一条记录,Db2会生成新的system page来存储新version的table, 这样在data page里面有属于不同version的data record,当select发生的时候,Db2就会按照不同version table的定义去format不同version的data record。当发现某个vesion的data record不能被对应table的version format出来,query就会报DSNIRNXT:53CD abend。
通过dump分析,发现select * 不能format record 42-01
DDL显示TB REP.TRANNX当前的version是V2
OBDREC: 0000005C_CA2875F4 (0335.0179)
OBDRX: 0000005C_CA2877C8
OBDRX2: 0000005C_CA287818
Current version number: 0002 <--- REP.TRANNX V2 TB
CREATE TABLE REP.TRANNX
(
C1 CHAR( 2) NOT NULL
C2 CHAR( 2) NOT NULL
C3 CHAR( 3) NOT NULL
C4 CHAR( 3) NOT NULL
C5 CHAR( 6) NOT NULL
C6 CHAR( 3) NOT NULL
C7 CHAR( 6) NOT NULL
C8 VARCHAR( 250) NOT NULL
C9 DATE NOT NULL
C10 DATE NOT NULL
C11 INTEGER NOT NULL
C12 VARCHAR( 1000) NOT NULL
C13 INTEGER NOT NULL
C14 VARCHAR( 250) NOT NULL
C15 TIMESTAMP NOT NULL
C16 TIMESTAMP
C17 CHAR( 10) NOT NULL
C18 CHAR( 1) NOT NULL
)
DSN1PRNT page 42 显示42-01是一个V2的data record
PAGE: # 00000042 -------------------------------------------------------------------------------------------
DATA PAGE: PGCOMB='00'X PGBIGRBA='00000000000000000000'X PGNUM='00000042'X PGFLAGS='00'X
PGFREE=849 PGFREE='0351'X PGFREEP=3209 PGFREEP='0C89'X PGHOLE1='0000'X
PGMAXID='09'X PGNANCH=0
PGBIGTAIL: PGPRETAIL='000000000000000000000000000000000000'X PGIDFREE='00'X PGEND='42'X
ID-MAP FOLLOWS:
01 0014 0184 02F4 0464 05D4 0744 08B4 0A24
09 0B94
RECORD: XOFFSET='0014'X PGSFLAGS='01'X PGSLTH=368 PGSLTH='0170'X PGSOBD='0000'X PGSBID='02'X <---V2 record
D9C5C3E9 C3E240D9 C5D5E7D1 C1F8F7F2 D2F9D220 19030120 29123180 00000180 RECZCS RENXJA872K9K.............
00000120 19070916 27030600 00002019 07091627 03060000 A5F0F0F6 F5F6F340 ........................v006563
4040E500 49004C00 70E7D1C1 F14B05C9 D5C6D6D9 D4C1C3C5 40D640E9 D7D9C1C3 V...<..XJA1..INFORMACE O ZPRAC
C8 C12
D6E565D5 7540FEC4 C1D1507B F3F6F65E F14BF14B 05E585BD 92859951 40A99799 OV.N. .DAJŮ.1.1..Ve.ker. zpr
818396A5 45955540 96A29682 95558388 40DE8481 91507BF3 F6F75E40 979996A2 acov.n. osobn.ch .dajů. pros
A3507BF3 F4F55E85 84958983 A3A55594 40A2A8A2 A35194A4 4085C381 93934097 tř.ednictv.m syst.mu eCall p
999640A5 96934595 55409581 40938995 92A440F1 F1F240A5 85A2A381 A5507BF2 ro vol.n. na linku 112 vestav
F8F35E95 51889640 A58540A5 96A98984 93854097 99968255 884540A5 40A296A4 83.n.ho ve vozidle prob.h. v sou
938184A4 40A24097 9981A589 8493A840 97999640 96838899 8195A440 96A29682 ladu s pravidly pro ochranu osob
95558388 40DE8481 91507BF3 F6F75E40 A2A38195 96A58595 8D948940 A5409581 n.ch .dajů. stanoven.mi v na
507BF3F4 F55E55A9 85955540 4DC5E45D 40F2F0F1 F661F6F7 F940A985 40849585 ř..zen. (EU) 2016/679 ze dne
40F2F74B 40C4A482 9581 27. Dubna
但是并不能被V2 TB的DDL format出来,NOT NULL的C7没有值
C1:D9C5
C2:C3E9
C3:C3E240
C4:D9C5D5
C5:E7D1C1F8F7F2
C6:D2F9D2
C7:
C9:20190301
C10:20291231
C11:80000001
C13:80000001
C15:20 19070916 27030600 00
C16:002019 07091627 03060000
C17:A5F0F0F6 F5F6F340 4040
C18:E5
C8 offset:0049 length is 3
C12 offset:004C length is 36
C14 offset:0070 length is 250
通过跟客户要column history,实际上客户对这个TB做了三次alter操作,而每次alter的操作又会生成新的version,所以当前的version正确是应该是3而不是2,所以需要进一步追踪客户是如何从V0变化到V2的,但是Report Recovery显示客户把近期所有的SYSCOPY都删掉了,因此无法追踪table version的变化。对于只有若干条DDL不能format数据的情况,我们一般建议客户做REPAIR DELETE把这些corrupted record删掉,但是对于这个case,客户又1万多条这样corrupted record,我们也无能为力,好在这个不是生产系统的数据,客户最后会drop table。