This level includes all DML operations performed on index data. Known operations include:
|
The most common index operations are described in the following sections:
These operations are described in more detail in the following sections
This operation inserts a row into an index.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following code:
CREATE TABLE team
(
team_code VARCHAR2(3),
team_name VARCHAR2(30),
country_code VARCHAR2(3)
);
CREATE INDEX team_pk ON team (team_code);
INSERT INTO team VALUES ('MCL','McLaren','GBR');
COMMIT;
The statement
INSERT INTO team VALUES ('FER','Ferrari','GER');
generates the following index redo
CHANGE #2 TYP:2 CLS: 1 AFN:4 DBA:0x01001b84 OBJ:53058 SCN:0x0000.0017bd28 SEQ: 1 OP:10.2 index redo (kdxlin): insert leaf row KTB Redo op: 0x11 ver: 0x01 op: F xid: 0x0005.02e.000001d7 uba: 0x00800932.016c.09 Block cleanout record, scn: 0x0000.0017bd66 ver: 0x01 opt: 0x02, entries follow... itli: 2 flg: 2 scn: 0x0000.0017bd28 REDO: SINGLE / -- / -- itl: 2, sno: 0, row size 15 insert key: (11): 03 46 45 52 06 01 00 1b 7c 00 01
index redo (kdxlin): insert leaf row
kdxlin: operation code 10.2
KTB Redo op: 0x11 ver: 0x01 op: F xid: 0x0005.02e.000001d7 uba: 0x00800932.016c.09
See KTBRedo
Block cleanout record, scn: 0x0000.0017bd66 ver: 0x01 opt: 0x02, entries follow...
If the ITL has not been updated out since the last transaction changes where committed or rolled back then a block cleanout is performed
scn System change number of block cleanout. Format is wrap#.base#
ver Version number
opt Option number
itli: 2 flg: 2 scn: 0x0000.0017bd28
ITL element being cleaned out.
itli ITL element number (1 based)
flg Flag
scn System Change Number of entry
REDO: SINGLE / -- / --
Redo for single row (as opposed to array)
itl: 2, sno: 0, row size 15
ITL slot number 2
Index block slot number 0
Row size 15 bytes
insert key: (11): 03 46 45 52 06 01 00 1b 7c 00 01
insert key: hex dump of key to be inserted
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:26 AFN:2 DBA:0x00800932 OBJ:4294967295 SCN:0x0000.0017bd66 SEQ: 1 OP:5.1
ktudb redo: siz: 100 spc: 6498 flg: 0x0022 seq: 0x016c rec: 0x09
xid: 0x0005.02e.000001d7
ktubu redo: slt: 46 rci: 8 opc: 10.22 objn: 53058 objd: 53058 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index undo for leaf key operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0006.025.000001ed uba: 0x008004ab.0164.02
flg: C--- lkc: 0 scn: 0x0000.0017bd28
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x1001b83 block=0x01001b84
(kdxlpu): purge leaf row
key :(11): 03 46 45 52 06 01 00 1b 7c 00 01
This operation deletes a row from an index.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following code:
CREATE TABLE team
(
team_code VARCHAR2(3),
team_name VARCHAR2(30),
country_code VARCHAR2(3)
);
CREATE INDEX team_pk ON team (team_code);
INSERT INTO team VALUES ('MCL','McLaren','GBR');
INSERT INTO team VALUES ('FER','Ferrari','GER');
COMMIT;
The statement
DELETE FROM team WHERE team_code = 'FER';
generates the following index redo
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001b84 OBJ:53058 SCN:0x0000.0017c1e9 SEQ: 1 OP:10.4 index redo (kdxlde): delete leaf row KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.015.000001ae uba: 0x008009a5.02e6.2a REDO: SINGLE / -- / -- itl: 2, sno: 0, row size 15
index redo (kdxlde): delete leaf row
kdxlde: operation code 10.4
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.015.000001ae uba: 0x008009a5.02e6.2a
See KTBRedo
REDO: SINGLE / -- / --
Redo for single row (as opposed to array)
itl: 2, sno: 0, row size 15
ITL slot number 2
Index block slot number 0
Row size 15 bytes
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:32 AFN:2 DBA:0x008009a5 OBJ:4294967295 SCN:0x0000.0017c1e9 SEQ: 1 OP:5.1
ktudb redo: siz: 100 spc: 3276 flg: 0x0022 seq: 0x02e6 rec: 0x2a
xid: 0x0008.015.000001ae
ktubu redo: slt: 21 rci: 41 opc: 10.22 objn: 53058 objd: 53058 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index undo for leaf key operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0005.02e.000001d7 uba: 0x00800932.016c.09
flg: C--- lkc: 0 scn: 0x0000.0017bd67
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x1001b83 block=0x01001b84
(kdxlre): restore leaf row (clear leaf delete flags)
key :(11): 03 46 45 52 06 01 00 1b 7c 00 01
This operation restores a leaf row to an index block, normally following an index block split.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo when an index block split occurs
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001bc0 OBJ:53071 SCN:0x0000.00181068 SEQ: 3 OP:10.5 index redo (kdxlre): restore leaf row KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0009.000.000001e2 uba: 0x008002fb.0193.03 REDO: SINGLE / -- / -- itl: 2, sno: 0, row size 22
index redo (kdxlre): restore leaf row
kdxlre: operation code 10.5
KTB Redo op: 0x11 ver: 0x01 op: F xid: 0x0005.02e.000001d7 uba: 0x00800932.016c.09
See KTBRedo
REDO: SINGLE / -- / --
Redo for single row (as opposed to array)
itl: 2, sno: 0, row size 22
ITL slot number 2
Index block slot number 0
Row size 22 bytes
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:34 AFN:2 DBA:0x008002fb OBJ:4294967295 SCN:0x0000.00181068 SEQ: 3 OP:5.1
ktudb redo: siz: 84 spc: 7962 flg: 0x0022 seq: 0x0193 rec: 0x03
xid: 0x0009.000.000001e2
ktubu redo: slt: 0 rci: 2 opc: 10.22 objn: 53071 objd: 53071 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index undo for leaf key operations
KTB Redo
op: 0x03 ver: 0x01
op: Z
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x1001bbb block=0x01001bc0
(kdxlpu): purge leaf row
key :(18): 0a 41 30 30 30 30 30 30 33 36 34 06 01 00 1b b7 01 6b
This operation locks an index block, normally as part of an index block split.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo when an index block split occurs
CHANGE #3 TYP:0 CLS: 1 AFN:4 DBA:0x01001bbc OBJ:53071 SCN:0x0000.00181068 SEQ:112 OP:10.6 index redo (kdxlok): lock block, count=2 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0009.020.000001e1 uba: 0x008002fc.0193.01 lock itl 1 operation = 0x5, pre-split
index redo (kdxlok): lock block, count=2
kdxlok: operation code 10.6
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0009.020.000001e1 uba: 0x008002fc.0193.01
See KTBRedo
lock itl 1
Lock ITL slot #1
operation = 0x5, pre-split
Operation code = 5 - pre-split
The above statement generated the following undo
CHANGE #2 TYP:1 CLS:34 AFN:2 DBA:0x008002fc OBJ:4294967295 SCN:0x0000.00181068 SEQ: 1 OP:5.1
ktudb redo: siz: 108 spc: 0 flg: 0x000a seq: 0x0193 rec: 0x01
xid: 0x0009.020.000001e1
ktubl redo: slt: 32 rci: 0 opc: 10.21 objn: 53071 objd: 53071 tsn: 4
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x008002f2.0193.10
prev ctl max cmt scn: 0x0000.00180495 prev tx cmt scn: 0x0000.001804a7
txn start scn: 0xffff.ffffffff logon user: 59 prev brb: 8389349 prev bcl: 0 index general undo (branch) operations
KTB Redo
op: 0x03 ver: 0x01
op: Z
Dump kdige : block dba :0x01001bbc, seghdr dba: 0x01001bbb
unlock block
(1): 01
This operation resets a block during index leaf block deletion
Consider the following code:
CREATE TABLE t1
(
c1 VARCHAR2(10),
c2 NUMBER
);
CREATE INDEX i1 ON t1 (c1);
-- Insert some rows
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
COMMIT;
-- Delete the rows again
DECLARE
l_c1 VARCHAR2(10);
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
DELETE FROM t1 WHERE c1 = l_c1;
END LOOP;
END;
COMMIT;
/
The DDL statement
ALTER INDEX i1 COALESCE; /
generates the following index redo each time an index block is deleted:
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001bdd OBJ:53093 SCN:0x0000.001919a8 SEQ: 3 OP:10.7 index redo (kdxulo): clear block opcode during commit
index redo (kdxulo): clear block opcode during commit
kdxulo: operation code 10.7
The above statement does not generate any undo. It is, however, immediately preceded by a commit (5.4) of the recursive transaction
This operation initializes the header of a new leaf block, normally as part of an index block split. In general an index block split will result in two 10.8 changes, one for each of the two new leaf blocks.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo when an index block split occurs
CHANGE #3 TYP:0 CLS: 1 AFN:4 DBA:0x01001bbf OBJ:53071 SCN:0x0000.00181068 SEQ: 2 OP:10.8 index redo (kdxlne): (count=4) init header of newly allocated leaf block KTB Redo op: 0x05 ver: 0x01 op: R itc: 2 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0009.020.000001e1 0x008002fe.0193.01 -B-- 0 fsc 0x0000.00000000 0x02 0x0009.000.000001e2 0x008002fb.0193.01 ---- 0 fsc 0x0000.00000000 kdxlnitl = 1 kdxlnnco = 2 kdxlndsz = 0 kdxlncol = 56 kdxlnflg = 0 kdxlnnxt = 0x0 kdxlnprv = 0x0 new block has 363 rows dumping row index Dump of memory from 0xB78E2278 to 0xB78E2550 B78E2270 00160000 0042002C [....,.B.] B78E2280 006E0058 009A0084 00C600B0 00F200DC [X.n.............] B78E2290 011E0108 014A0134 01760160 01A2018C [....4.J.`.v.....] ..... B78E2540 1EAE1E98 1EDA1EC4 1F061EF0 1F321F1C [..............2.] dumping rows Dump of memory from 0xB78E2550 to 0xB78E41AC B78E2550 410A0200 30303030 30303030 00010631 [...A000000001...] B78E2560 0000B71B 410A0200 30303030 30303030 [.......A00000000] B78E2570 00010632 0100B71B 410A0200 30303030 [2..........A0000] B78E2580 30303030 00010633 0200B71B 410A0200 [00003..........A] B78E2590 30303030 30303030 00010634 0300B71B [000000004.......] ..... B78E4170 410A0200 30303030 36333030 00010631 [...A000000361...] B78E4180 6801B71B 410A0200 30303030 36333030 [...h...A00000036] B78E4190 00010632 6901B71B 410A0200 30303030 [2......i...A0000] B78E41A0 36333030 00010633 6A01B71B [00363......j]
Note that lines have been omitted from the block dumps
index redo (kdxlne): (count=4) init header of newly allocated leaf block
kdxlne: operation code 10.8
KTB Redo op: 0x05 ver: 0x01 op: R itc: 2 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0009.020.000001e1 0x008002fe.0193.01 -B-- 0 fsc 0x0000.00000000 0x02 0x0009.000.000001e2 0x008002fb.0193.01 ---- 0 fsc 0x0000.00000000
See KTBRedo
kdxlnitl = 1
ITL slot number
kdxlnnco = 2
Number of columns in index key - includes ROWID for non-unique indexes
kdxlndsz = 0
Size of data - 0 for non-unique indexes
kdxlncol = 56
Unknown
kdxlnflg = 0
Flag - values unknown
kdxlnnxt = 0x0
Address of next block
kdxlnprv = 0x0
Address of previous block
new block has 363 rows
Number of leaf rows in new block
The above statement generated the following undo
CHANGE #2 TYP:1 CLS:34 AFN:2 DBA:0x008002fe OBJ:4294967295 SCN:0x0000.00181068 SEQ: 1 OP:5.1
ktudb redo: siz: 120 spc: 0 flg: 0x000a seq: 0x0193 rec: 0x01
xid: 0x0009.020.000001e1
ktubu redo: slt: 32 rci: 0 opc: 10.21 objn: 53071 objd: 53071 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x008002fd
index general undo (branch) operations
KTB Redo
op: 0x05 ver: 0x01
op: R itc: 2
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
Dump kdige : block dba :0x01001bbf, seghdr dba: 0x01001bbb
make leaf block empty
(2): 01 00
This operation sets a flag in the ITL of a current leaf block prior to that leaf block being split. A side effect of this operation is that the entire contents of the leaf block is written to undo. Therefore, although this operation only generates around 80 bytes of redo, it generates undo roughly equivalent to the block size of the index tablespace.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo when an index block split occurs
CHANGE #3 TYP:0 CLS: 1 AFN:4 DBA:0x01001bbc OBJ:53071 SCN:0x0000.00181068 SEQ:113 OP:10.9 index redo (kdxair): apply xat do to itl 1 (count=2) KTB Redo op: 0x05 ver: 0x01 op: R itc: 1 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0009.020.000001e1 0x008002fd.0193.01 -B-- 1 fsc 0x0000.00000000
index redo (kdxair): apply xat do to itl 1 (count=2)
kdxair: operation code 10.9
KTB Redo op: 0x05 ver: 0x01 op: R itc: 1 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0009.020.000001e1 0x008002fd.0193.01 -B-- 1 fsc 0x0000.00000000
See KTBRedo
The above statement generated the following undo
CHANGE #2 TYP:1 CLS:34 AFN:2 DBA:0x008002fd OBJ:4294967295 SCN:0x0000.00181068 SEQ: 1 OP:5.1
ktudb redo: siz: 8148 spc: 8040 flg: 0x000a seq: 0x0193 rec: 0x01
xid: 0x0009.020.000001e1
ktubu redo: slt: 32 rci: 0 opc: 10.21 objn: 53071 objd: 53071 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x008002fc
index general undo (branch) operations
KTB Redo
op: 0x05 ver: 0x01
op: R itc: 2
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.020.000001e1 0x008002fc.0193.01 ---- 1 fsc 0x0000.00000000
0x02 0x0009.000.000001e2 0x008002fb.0193.01 ---- 363 fsc 0x0000.00000000
Dump kdige : block dba :0x01001bbc, seghdr dba: 0x01001bbb
restore block before image
(8032):
00 01 85 02 00 00 00 00 6b 01 fa 02 04 03 0a 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 60 1f 00 00 4c 1f 38 1f 24 1f 10 1f fc 1e e8 1e d4 1e
c0 1e ac 1e 98 1e 84 1e 70 1e 5c 1e 48 1e 34 1e 20 1e 0c 1e f8 1d e4 1d d0
1d bc 1d a8 1d 94 1d 80 1d 6c 1d 58 1d 44 1d 30 1d 1c 1d 08 1d f4 1c e0 1c
......
00 04 00 02 0a 41 30 30 30 30 30 30 30 30 34 06 01 00 1b b7 00 03 00 02 0a
41 30 30 30 30 30 30 30 30 33 06 01 00 1b b7 00 02 00 02 0a 41 30 30 30 30
30 30 30 30 32 06 01 00 1b b7 00 01 00 02 0a 41 30 30 30 30 30 30 30 30 31
06 01 00 1b b7 00 00
Note that lines have been omitted from the block dumps
This operation sets a pointer to the next leaf block in an existing leaf block. Usually executed immediately after an 10.8 operation
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo after index block split occurs
CHANGE #1 TYP:0 CLS: 1 AFN:4 DBA:0x01001bbf OBJ:53071 SCN:0x0000.00181068 SEQ: 3 OP:10.10 index redo (kdxlnx): set kdxlenxt = 0x1001bc0 (count=1, len[0]=4)
index redo (kdxlnx): set kdxlenxt = 0x1001bc0 (count=1, len[0]=4)
kdxlnx: operation code 10.10
kdxlenxt DBA of next leaf block in index
This operation did not generate any undo
This operation sets a pointer to the previous leaf block in an existing leaf block.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit). This example occured during an index COALESCE operation and shows the redo generated when an index leaf block is deleted. The change is applied to the next index leaf block in the list if and only if it exists.
Consider the following code:
CREATE TABLE t1
(
c1 VARCHAR2(10),
c2 NUMBER
);
CREATE INDEX i1 ON t1 (c1);
-- Insert some rows
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
COMMIT;
-- Delete the rows again
DECLARE
l_c1 VARCHAR2(10);
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
DELETE FROM t1 WHERE c1 = l_c1;
END LOOP;
END;
COMMIT;
/
The DDL statement
ALTER INDEX i1 COALESCE; /
generates the following index redo when an index leaf block is deleted:
CHANGE #2 TYP:2 CLS: 1 AFN:4 DBA:0x01001bdd OBJ:53093 SCN:0x0000.001918de SEQ: 1 OP:10.11 index redo (kdxlpr) : (REDO) set kdxleprv=0x0, itl=1, count=2 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.011.000001c6 uba: 0x00800cf6.02eb.2c
index redo (kdxlpr): (REDO) set kdxleprv=0x0, itl=1, count=2
kdxlpr: operation code 10.11
kdxleprv DBA of previous leaf block in index - in this case 0 because leaf block is being deleted
itl ITL slot number
count Number of elements in change vector
This operation generated the following undo:
CHANGE #1 TYP:0 CLS:32 AFN:2 DBA:0x00800cf6 OBJ:4294967295 SCN:0x0000.001919a7 SEQ: 1 OP:5.1
ktudb redo: siz: 88 spc: 4008 flg: 0x0022 seq: 0x02eb rec: 0x2c
xid: 0x0008.011.000001c6
ktubu redo: slt: 17 rci: 43 opc: 10.21 objn: 53093 objd: 53093 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index general undo (branch) operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0008.02a.000001c5 uba: 0x00800cee.02eb.01
flg: CB-- lkc: 0 scn: 0x0000.001918d5
Dump kdige : block dba :0x01001bdd, seghdr dba: 0x01001bdb
set leaf block previous link
(8): 01 01 00 00 e0 1b 00 01
This operation initializes an index root block after an index split. Initially an index only contains one leaf block. When this block is full it will be split into two new leaf blocks and the original leaf block will be converted into a branch block. The 10.12 operation initializes this branch block which is also known as the root block as it is the top level block in the index.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..512
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo after index block split occurs
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001bbc OBJ:53071 SCN:0x0000.00181068 SEQ:114 OP:10.12 index redo (kdxrsp): initialize root block after split,count=3 service itl 1 lmc 0x1001bbf rmc 0x1001bc0 seperator key: (12): 0a 41 30 30 30 30 30 30 33 36 34 fe
index redo (kdxrsp): initialize root block after split,count=3
kdxrsp: operation code 10.12
service itl 1
service itl Unknown
lmc 0x1001bbf
lmc DBA of left hand leaf block
rmc 0x1001bc0
rmc DBA of right hand leaf block
seperator key: (12): 0a 41 30 30 30 30 30 30 33 36 34 fe
separator key Unique prefix of first key in right hand leaf block. Note that only the prefix of the key is stored in the branch block. The prefix must be suffiiciently long to identify the first row in the block. However, it does not necessarily need to contain all the bytes in the key. In this case the ROWID has been omitted; if the index contained many duplicate rows, all or part of the ROWID may be included to ensure that the prefix is unique.
In this example the first byte of the separator key is the length (0x0a = 10)
The next ten bytes are the key (A000000364)
The final byte terminates the separator key (0xfe = 254)
The above statement does not generate any undo. A copy of the block will have been previously written to undo as part of the 10.9 operation
Note however that this operation is immediately preceded by a commit operation (5.4) for the recursive transaction
This operation empties an index leaf block that currently contains no rows
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit). This example occured during an index COALESCE operation.
Consider the following code:
CREATE TABLE t1
(
c1 VARCHAR2(10),
c2 NUMBER
);
CREATE INDEX i1 ON t1 (c1);
-- Insert some rows
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
COMMIT;
-- Delete the rows again
DECLARE
l_c1 VARCHAR2(10);
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
DELETE FROM t1 WHERE c1 = l_c1;
END LOOP;
END;
COMMIT;
/
The DDL statement
ALTER INDEX i1 COALESCE; /
generates the following index redo when an index leaf block is deleted:
CHANGE #3 TYP:0 CLS: 1 AFN:4 DBA:0x01001be0 OBJ:53093 SCN:0x0000.001919a7 SEQ: 1 OP:10.13 index redo (kdxlem): (REDO) make leaf block empty,itl=1,count=2 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.011.000001c6 uba: 0x00800cf6.02eb.2b
index redo (kdxlem): (REDO) make leaf block empty,itl=1,count=2
kdxlem: operation code 10.13
itl ITL slot number
count Number of elements in change vector
This operation generated the following undo:
CHANGE #2 TYP:0 CLS:32 AFN:2 DBA:0x00800cf6 OBJ:4294967295 SCN:0x0000.001918d6 SEQ: 43 OP:5.1
ktudb redo: siz: 192 spc: 4202 flg: 0x0012 seq: 0x02eb rec: 0x2b
xid: 0x0008.011.000001c6
ktubl redo: slt: 17 rci: 0 opc: 10.21 objn: 53093 objd: 53093 tsn: 4
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800cef.02eb.06
prev ctl max cmt scn: 0x0000.0019138d prev tx cmt scn: 0x0000.001913cc
txn start scn: 0xffff.ffffffff logon user: 59 prev brb: 8391895 prev bcl: 0 index general undo (branch) operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0008.00d.000001c6 uba: 0x00800ce5.02eb.01
flg: CB-- lkc: 0 scn: 0x0000.001918d3
Dump kdige : block dba :0x01001be0, seghdr dba: 0x01001bdb
restore block to b-tree
(1): 01
(36):
00 00 80 02 01 00 00 00 00 00 24 00 60 1f 3c 1f 00 00 00 00 dd 1b 00 01 00
00 00 00 00 00 00 00 60 1f 00 00
(20): 01 00 0a 41 30 30 30 30 30 30 30 30 31 06 01 00 1b d4 00 00
This operation occurs when a new branch block is initialized
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t4 ( c1 VARCHAR2(30), c2 NUMBER ); CREATE INDEX i4 ON t4 (c1);
the statement
DECLARE
l_c1 VARCHAR2(30);
l_c2 NUMBER;
BEGIN
FOR i IN 1..50000
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),29,'0');
l_c2 := i;
INSERT INTO t4 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following redo
CHANGE #1 TYP:0 CLS: 1 AFN:4 DBA:0x01001d38 OBJ:53102 SCN:0x0000.00197e86 SEQ:193 OP:10.14 index redo (kdxima): restored block before image, count=2 trans layer b.i. KTB Redo op: 0x05 ver: 0x01 op: R itc: 2 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0007.007.000001a3 0x0080087f.0145.03 ---- 1 fsc 0x0000.00000000 0x02 0x0007.024.000001a1 0x00800884.0145.0d ---- 190 fsc 0x0000.00000000 data block b.i. Dump of memory from 0xB6014264 to 0xB60161C4 B6014260 02850100 00000001 01A000BE [............] B6014270 001001B0 00000000 00000000 01001D37 [............7...] B6014280 1E871E00 1E3A1F60 1F101F38 1EC01EE8 [....`.:.8.......] B6014290 1E701E98 1E201E48 1DD01DF8 1D801DA8 [..p.H. .........] B60142A0 1D301D58 1CE01D08 1C901CB8 1C401C68 [X.0.........h.@.] B60142B0 1BF01C18 1BA01BC8 1B501B78 1B001B28 [........x.P.(...] B60142C0 1AB01AD8 1A601A88 1A101A38 19C019E8 [......`.8.......] ....... B6016120 9900301D 411E0200 30303030 30303030 [.0.....A00000000] B6016130 30303030 30303030 30303030 30303030 [0000000000000000] B6016140 33303730 00010634 9800301D 411E0200 [07034....0.....A] B6016150 30303030 30303030 30303030 30303030 [0000000000000000] B6016160 30303030 30303030 33303730 00010633 [0000000007033...] B6016170 9700301D 411E0200 30303030 30303030 [.0.....A00000000] B6016180 30303030 30303030 30303030 30303030 [0000000000000000] B6016190 33303730 00010632 9600301D 411E0200 [07032....0.....A] B60161A0 30303030 30303030 30303030 30303030 [0000000000000000] B60161B0 30303030 30303030 33303730 00010631 [0000000007031...] B60161C0 9500301D
index redo (kdxima): restored block before image, count=2
kdxbin: operation code 10.15
trans layer b.i.
Transaction level before image (KTB Redo follows)
KTB Redo op: 0x05 ver: 0x01 op: R itc: 2 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0007.007.000001a3 0x0080087f.0145.03 ---- 1 fsc 0x0000.00000000 0x02 0x0007.024.000001a1 0x00800884.0145.0d ---- 190 fsc 0x0000.00000000
See KTBRedo
data block b.i.
Data block before image (block dump follows)
This operation does not generate any undo. However it appears to be followed by a 5.11 operation. For example:
CHANGE #2 TYP:0 CLS:29 AFN:2 DBA:0x00800069 OBJ:4294967295 SCN:0x0000.00197e86 SEQ: 8 OP:5.11
ktubu redo: slt: 7 rci: 0 opc: 10.21 objn: 53102 objd: 53102 tsn: 4
Undo type: Regular undo Undo type: User undo done Last buffer split: No
Tablespace Undo: No
0x0080087f
This operation inserts a new row into a branch block. This operation usually occurs during an index block split.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(10), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
The PL/SQL block
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following index redo after index block split occurs
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001bcc OBJ:53091 SCN:0x0000.0018ec81 SEQ: 1 OP:10.15 index redo (kdxbin) : insert branch block row, count=3 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0002.01e.000001e2 uba: 0x00801118.020b.02 REDO itl: 1 insert into slot 1, child dba 0x1001bce new key : (12): 0a 41 30 30 30 30 30 30 37 32 37 fe
index redo (kdxbin) : insert branch block row,count=3
kdxbin: operation code 10.15
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0002.01e.000001e2 uba: 0x00801118.020b.02
See KTBRedo
REDO itl: 1 insert into slot 1, child dba 0x1001bce
itl ITL Slot number
child dba DBA of new leaf block - in this example 0x1001bce
new key : (12): 0a 41 30 30 30 30 30 30 37 32 37 fe
new key - 12 bytes
In this example the first byte of the new key is the length (0x0a = 10)
The next ten bytes are the key (A000000727)
The final byte terminates the separator key (0xfe = 254)
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:20 AFN:2 DBA:0x00801118 OBJ:4294967295 SCN:0x0000.0018ec81 SEQ: 2 OP:5.1
ktudb redo: siz: 84 spc: 8028 flg: 0x0022 seq: 0x020b rec: 0x02
xid: 0x0002.01e.000001e2
ktubu redo: slt: 30 rci: 1 opc: 10.21 objn: 53091 objd: 53091 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index general undo (branch) operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0002.017.000001e2 uba: 0x0080110d.020b.01
flg: CB-- lkc: 0 scn: 0x0000.0018ec80
Dump kdige : block dba :0x01001bcc, seghdr dba: 0x01001bcb
branch block row purge
(4): 01 00 01 00
This operation deletes an existing row from a branch block. This operation occurs when a leaf block is removed. Note that index leaf blocks are not removed immediately when they become empty as there is a possibility that new rows will be reinserted. Leaf blocks are, however, removed during a COALESCE operation.
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following code:
CREATE TABLE t1
(
c1 VARCHAR2(10),
c2 NUMBER
);
CREATE INDEX i1 ON t1 (c1);
-- Insert some rows
DECLARE
l_c1 VARCHAR2(10);
l_c2 NUMBER;
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
COMMIT;
-- Delete the rows again
DECLARE
l_c1 VARCHAR2(10);
BEGIN
FOR i IN 1..1024
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),9,'0');
DELETE FROM t1 WHERE c1 = l_c1;
END LOOP;
END;
COMMIT;
/
The DDL statement
ALTER INDEX i1 COALESCE;
generates the following index redo when an index leaf block is deleted:
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001bdc OBJ:53093 SCN:0x0000.001919a8 SEQ: 2 OP:10.16 index redo (kdxbpu) : purge branch block row, count=2 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.021.000001c6 uba: 0x00800cf6.02eb.30 REDO itl: 1 slot -1
index redo (kdxbpu) : purge branch block row,count=2
kdxbin: operation code 10.16
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0008.021.000001c6 uba: 0x00800cf6.02eb.30
See KTBRedo
REDO itl: 1 slot -1
slot ITL Slot number - appears to always be -1 - may be a bug in the redo log dump
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:32 AFN:2 DBA:0x00800cf6 OBJ:4294967295 SCN:0x0000.001919a8 SEQ: 2 OP:5.1
ktudb redo: siz: 100 spc: 3532 flg: 0x0022 seq: 0x02eb rec: 0x30
xid: 0x0008.021.000001c6
ktubu redo: slt: 33 rci: 47 opc: 10.21 objn: 53093 objd: 53093 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index general undo (branch) operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0008.011.000001c6 uba: 0x00800cf6.02eb.2d
flg: C--- lkc: 0 scn: 0x0000.001919a8
Dump kdige : block dba :0x01001bdc, seghdr dba: 0x01001bdb
branch block row insert
(8): 01 00 ff ff dd 1b 00 01
(12): 0a 41 30 30 30 30 30 30 37 32 37 fe
This operation occurs when a new branch block is initialized
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit)
Consider the following objects:
CREATE TABLE t1 ( c1 VARCHAR2(30), c2 NUMBER ); CREATE INDEX i1 ON t1 (c1);
the statement
DECLARE
l_c1 VARCHAR2(30);
l_c2 NUMBER;
BEGIN
FOR i IN 1..50000
LOOP
l_c1 := 'A'||LPAD (TO_CHAR (i),29,'0');
l_c2 := i;
INSERT INTO t1 VALUES (l_c1,l_c2);
END LOOP;
END;
/
generates the following redo
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01001ee7 OBJ:53102 SCN:0x0000.00197f3a SEQ: 2 OP:10.17 index redo (kdxbne): initialize branch block,count=4 KTB Redo op: 0x05 ver: 0x01 op: R itc: 1 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0007.022.000001a7 0x00800e3a.014f.03 -B-- 0 fsc 0x0000.00000000 NEW itl: 1 nco: 2 lev: 1 lmc: 0x1001ce5 new block has 211 rows dumping row index Dump of memory from 0xB6014258 to 0xB6014400 B6014250 00260000 0072004C [..&.L.r.] B6014260 00BE0098 010A00E4 01560130 01A2017C [........0.V.|...] B6014270 01EE01C8 023A0214 02860260 02D202AC [......:.`.......] B6014280 031E02F8 036A0344 03B60390 040203DC [....D.j.........] B6014290 044E0428 049A0474 04E604C0 0532050C [(.N.t.........2.] ....... 60143C0 1ADE1AB8 1B2A1B04 1B761B50 1BC21B9C [......*.P.v.....] B60143D0 1C0E1BE8 1C5A1C34 1CA61C80 1CF21CCC [....4.Z.........] B60143E0 1D3E1D18 1D8A1D64 1DD61DB0 1E221DFC [..>.d.........".] B60143F0 1E6E1E48 1EBA1E94 1F061EE0 1F521F2C [H.n.........,.R.] dumping rows Dump of memory from 0xB6014400 to 0xB60161AC B6014400 01001CE6 3030411E 30303030 30303030 [.....A0000000000] B6014410 30303030 30303030 30303030 30303030 [0000000000000000] B6014420 FE313931 01001CE8 3030411E 30303030 [191......A000000] B6014430 30303030 30303030 30303030 30303030 [0000000000000000] ........ B6016160 FE313137 01001EDB 3030411E 30303030 [711......A000000] B6016170 30303030 30303030 30303030 30303030 [0000000000000000] B6016180 39333030 FE313039 01001EDF 3030411E [0039901......A00] B6016190 30303030 30303030 30303030 30303030 [0000000000000000] B60161A0 30303030 30343030 FE313930 [00000040091.]
index redo (kdxbne): initialize branch block,count=4
kdxbne: operation code 10.17
KTB Redo op: 0x05 ver: 0x01 op: R itc: 1 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0007.022.000001a7 0x00800e3a.014f.03 -B-- 0 fsc 0x0000.00000000
See KTBRedo
NEW itl: 1 nco: 2 lev: 1 lmc: 0x1001ce5
itl ITL slot number (1)
nco Number of columns (2)
lev Level of new block (in this case 1 - root block is level 0)
lmc DBA of left hand leaf block
new block has 211 rows
Number of branch rows in new block
dumping row index
Followed by a hexadecimal dump of row (slot) index
dumping rows
Followed by a hexadecimal dump of row data (branch rows)
This operation updates the data in a unique key. The key value is unchanged
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit) and shows a 10.18 operation generated by the update of the data in a bitmap index
Consider the following objects:
CREATE TABLE t1 ( c1 NUMBER, c2 NUMBER ); CREATE BITMAP INDEX i1 ON t1 (c2); INSERT INTO t1 VALUES (0,10); COMMIT;
The statement
UPDATE t1 SET c2 = 11 WHERE c1 = 0;
generates the following index redo:
CHANGE #2 TYP:0 CLS: 1 AFN:4 DBA:0x01000efc OBJ:53205 SCN:0x0000.001b03cf SEQ: 1 OP:10.18 index redo (kdxlup): update keydata, count=2 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0005.02a.00000231 uba: 0x00800055.019b.2a REDO: SINGLE / -- / -- itl: 2, sno: 0, row size 28
index redo (kdxlup): update keydata, count=2
kdxlup: operation code 10.18
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0005.02a.00000231 uba: 0x00800055.019b.2a
See KTBRedo
REDO: SINGLE / -- / --
SINGLE row (as opposed to array)
itl: 2, sno: 0, row size 28
itl ITL Slot number (2)
sno Leaf block slot number (0)
row size Row size in bytes (28)
The above statement generated the following undo
CHANGE #1 TYP:0 CLS:26 AFN:2 DBA:0x00800055 OBJ:4294967295 SCN:0x0000.001b03cf SEQ: 1 OP:5.1
ktudb redo: siz: 112 spc: 508 flg: 0x0022 seq: 0x019b rec: 0x2a
xid: 0x0005.02a.00000231
ktubu redo: slt: 42 rci: 41 opc: 10.22 objn: 53205 objd: 53205 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
index undo for leaf key operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0004.018.000001e4 uba: 0x0080047f.0121.1b
flg: C--- lkc: 0 scn: 0x0000.001b03cb
Dump kdilk : itl=2, kdxlkflg=0x1 sdc=0 indexid=0x1000efb block=0x01000efc
(kdxlup): update keydata in row
key :(24):
02 c1 0b 06 00 00 00 00 00 00 06 01 00 0e f4 00 07 06 c0 8c dd 95 e8 05
This operation updates a non-key value in an index leaf
The following example was developed in Oracle 10.2.0.4 (Linux 32-bit) and shows a 10.35 operation generated by an update of a non-key value in an IOT
Consider the following objects:
CREATE TABLE t1 ( c1 NUMBER, c2 NUMBER, CONSTRAINT t1_pk PRIMARY KEY (c1) ) ORGANIZATION INDEX; INSERT INTO t1 VALUES (1,10); COMMIT;
The statement
UPDATE t1 SET c2 = 20 WHERE c1 = 1;
generates the following index redo:
CHANGE #3 TYP:0 CLS: 1 AFN:4 DBA:0x01001df4 OBJ:53111 SCN:0x0000.00198a4e SEQ: 1 OP:10.35 index redo (kdxlcnu): update nonkey, count=4 KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0009.017.000001fd uba: 0x00800067.0199.23 REDO: SINGLE / NONKEY / -- itl: 2, sno: 0, row size 13 ncol: 1 nnew: 1 size: 0 flag: 0x02 nonkey columns updated: col 0: [ 2] c1 15
index redo (kdxlcnu): update nonkey, count=4
kdxlcnu: operation code 10.35
KTB Redo op: 0x01 ver: 0x01 op: F xid: 0x0009.017.000001fd uba: 0x00800067.0199.23
See KTBRedo
REDO: SINGLE / NONKEY / --
SINGLE row (as opposed to array)
NONKEY data (as opposed to key data)
itl: 2, sno: 0, row size 13
itl ITL Slot number (2)
sno Leaf block slot number (0)
row size Row size in bytes (13)
ncol: 1 nnew: 1 size: 0 flag: 0x02
ncol Number of columns updated (1)
nnew Number of new columns (1)
size Unknown 0 - Row size includes all columns and row header
flag Unknown (0x02) - may indicate non-key value
nonkey columns updated:
List of nonkey columns follows
col 0: [ 2] c1 15
Column in slot zero. Two byte value Oracle NUMBER C115 is 20
The above statement generated the following undo
CHANGE #2 TYP:0 CLS:34 AFN:2 DBA:0x00800067 OBJ:4294967295 SCN:0x0000.00198a0b SEQ: 1 OP:5.1
ktudb redo: siz: 192 spc: 3806 flg: 0x0012 seq: 0x0199 rec: 0x23
xid: 0x0009.017.000001fd
ktubl redo: slt: 23 rci: 0 opc: 10.22 objn: 53111 objd: 53111 tsn: 4
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800067.0199.22
prev ctl max cmt scn: 0x0000.00198256 prev tx cmt scn: 0x0000.00198261
txn start scn: 0xffff.ffffffff logon user: 59 prev brb: 8388709 prev bcl: 0 index undo for leaf key operations
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0007.014.000001aa uba: 0x00800f9f.0152.0f
flg: C--- lkc: 0 scn: 0x0000.00198a40
Dump kdilk : itl=2, kdxlkflg=0x91 sdc=0 indexid=0x1001df3 block=0x01001df4
(kdxlcnu): column-vector nonkey update
ncol: 1 nnew: 1 size: 0 flag: 0x02
key :(3): 02 c1 02
nonkey columns updated:
col 0: [ 2] c1 0b
LOGMINER DATA:
opcode: UPDATE
Number of columns supplementally logged: 0 Flag: SE [ ] NSRCI Objv#: 1
segcol# in Undo starting from 1
segcol# in Redo starting from 2