Data Block Dump in Oracle – part 1 – how to dump block

July 7, 2009 by lianggang 1 Comment

Dump data block provides a backdoor for understanding Oracle RDBMS implementation.

Dump data block can be accomplished by issuing a command below, given you have known DATA FILE NAME and BLOCK ADDRESS in interest.

ALTER SYSTEM DUMP DATAFILE BLOCK ;

ALTER SYSTEM DUMP DATAFILE BLOCK MIN BLOCK MAX ;

1) If you know the object name, e.g. table/index name, you can query dba_objects/dba_segments to find the head block and start from there.

select HEADER_FILE, HEADER_BLOCK FROM DBA_SEGMENTS WHERE SEGMENT_NAME = AND SEGMENT_TYPE =

then dump the header to get details of the segment

ALTER SYSTEM DUMP DATAFILE BLOCK ;

2) If you are interested in a specific row of a table, e.g. how Oracle implements certain things, you can find the rowid and then translate rowid into physical address.

SELECT ROWID, COL1,… FROM TABLE WHERE …

Using DBMS_ROWID package to get FILE NUMBER and BLOCK ADDRESS,

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID),  DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM DUAL;

Then ALTER SYSTEM DUMP DATAFILE ….

3) If you get a DBA (Data Block Address – here), e.g. from some trace file in udump directory,  you can get FILE NUMBER and BLOCK ADDRESS using

SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(dba_number),

DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(dba_number)

FROM DUAL;

then ALTER SYSTEM DUMP DATAFILE …

Here is an example for dumping a data block.

CREATE TABLE DUMP_EXAMPLE (

COL1 VARCHAR2(2000),

COL2 NUMBER,

COL3 TIMESTAMP);

INSERT INTO DUMP_EXAMPLE VALUES(

‘ABCDEFGHIJK’,1,SYSTIMESTAMP);

INSERT INTO DUMP_EXAMPLE VALUES(

‘ABCDEFGHIJK’,2,SYSTIMESTAMP+1);

COMMIT;

SELECT SEGMENT_TYPE, FILE_ID, BLOCK_ID, BLOCKS, RELATIVE_FNO FROM DBA_EXTENTS WHERE SEGMENT_NAME = ‘DUMP_EXAMPLE’;

–TABLE 4 161 8 4

then dump the header using ALTER SYSTEM DUMP DATAFILE 4 BLOCK 161

Now, dump the real data in interest.

SELECT ROWID, COL1, COL2, COL3 FROM DUMP_EXAMPLE

– AAAtyiAAEAAAACkAAA abcdefghijk 1 06.07.2009 18:03:12.177

– AAAtyiAAEAAAACkAAB ABCDEFGHIJK 2 07.07.2009 18:03:12.000

– dump the data block

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(‘AAAtyiAAEAAAACkAAA’) , DBMS_ROWID.ROWID_BLOCK_NUMBER(‘AAAtyiAAEAAAACkAAA’) FROM DUAL;

– 4, 164

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(‘AAAtyiAAEAAAACkAAB’) ,  DBMS_ROWID.ROWID_BLOCK_NUMBER(‘AAAtyiAAEAAAACkAAB’) FROM DUAL;

– 4, 164

ALTER SYSTEM DUMP DATAFILE 4 BLOCK 164;

You can find an example of dumping data blocks after knowing a Data Block Address from the post “Index Block Dump in Oracle”

Data Block Dump in Oracle – part 2 – how to read block dump file

? Original article Author: Liang's Blog

Sometime you look into dump/trace files in USER DUMP DESTINATION, aka udump, generated by Oracle to dig into issues, or you dig into problem by dumping some Oracle blocks, you may see something like

Start dump data blocks tsn: 4 file#: 4 minblk 172 maxblk 173

buffer tsn: 4 rdba: 0×010000ac (4/172)

scn: 0×0000.16b676dc seq: 0×01 flg: 0×04 tail: 0×76dc0601

frmt: 0×02 chkval: 0×78c7 type: 0×06=trans data

Object id on Block? Y

seg/obj: 0×2dca4  csc: 0×00.16b676dc  itc: 3  flg: E  typ: 1 – DATA

It is essential to understand who is who. Here I will explain a few attributes in the dump file, highlighted in BOLD.

rdba is the Data Block Address, which can be translated into FILE NUMBER and BLOCK ADDRESS using DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE to get the file number part of a data block address and

DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK to get the block number part of a data block address.

SCN is the block’s SCN, together with flg: etc for transaction control and block cleaning.

seg/obj is the DATA_OBJECT_ID, which pointing to the seg$ location of the block.

type means the type of data block, where “trans data” means table data block or index block – coded as 0×06. There are more than 40 types, like 0×20 “FIRST LEVEL BITMAP BLOCK”. For more, you can visit “block types” by Julian

Data Block Dump in Oracle – part 3 – object_id, data_object_id, block clean up

? Original article Author: Liang's Blog

Data_object_id in the block dump files is different from object_id which can be found in dba_objects. But sometime, they are the same in value. Why?

Block header dump:  0×0041966a

Object id on Block? Y

seg/obj: 0×2dca9  csc: 0×00.16b6bab1  itc: 3  flg: -  typ: 1 – DATA

fsl: 0  fnx: 0×0 ver: 0×01

Every object in Oracle database has an unqiue object_id. If the object is a data object, table/index/lob/their partition/cluster, it will have a data_object_id that is not zero.

When you create a new object, Oracle will assign object_id with the maximum value of two queries.  If it is a data_object, like a table, Oracle will assign the same maximum value.

select max(object_id)+1 from dba_objects

select max(hwmincr)+1 from seg$

Therefore, you can will find object_id having the same value as data_object_id. But data_object_id can be different later, for example, after move or truncate table.

In the example below, moving a table to a different tablespace causes a new data_object_id assigned to the table. Usually, this new value is the max(hwmincr)+1 from seg$ at that point of time.

CREATE TABLE DUMP_EXAMPLE (

COL1 VARCHAR2(2000),

COL2 NUMBER,

COL3 TIMESTAMP);

SELECT OBJECT_ID, DATA_OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = ‘DUMP_EXAMPLE’;

– 70962 70962

ALTER TABLE DUMP_EXAMPLE MOVE TABLESPACE USERS;

SELECT OBJECT_ID, DATA_OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = ‘DUMP_EXAMPLE’;

– 70962 70963

Here is a question regarding block clean up. Would Oracle erases the data in the old location after moves it to a new tablespace? The answer is Not immediately. Here is an example.

I create a table, dump its data block; then I move the table to another tablespace, and then dump data block at the new location as well as the data block at the old location.

CREATE TABLE DUMP_EXAMPLE2 (

COL1 VARCHAR2(2000),

COL2 NUMBER,

COL3 TIMESTAMP);

SELECT OBJECT_ID, DATA_OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = ‘DUMP_EXAMPLE2′;

–70969 70969

INSERT INTO DUMP_EXAMPLE2 VALUES(’ABCDEFGHIJK’,1,SYSTIMESTAMP);

INSERT INTO DUMP_EXAMPLE2 VALUES(’ABCDEFGHIJK’,2,SYSTIMESTAMP+1);

INSERT INTO DUMP_EXAMPLE2 VALUES(’ABCDEFGHIJK’,3,SYSTIMESTAMP+2);

COMMIT;

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID), DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM DUMP_EXAMPLE2;

1 86610

1 86610

1 86610

ALTER SYSTEM DUMP DATAFILE 1 BLOCK 86610;

See dump trace file here.

——————————————————————————–

buffer tsn: 0 rdba: 0×00415252 (1/86610)

scn: 0×0000.000ef52f seq: 0×07 flg: 0×02 tail: 0xf52f0607

frmt: 0×02 chkval: 0×0000 type: 0×06=trans data

Hex dump of block: st=0, typ_found=1

Dump of memory from 0×1C4E6000 to 0×1C4E8000

1C4E6000 0000A206 00415252 000EF52F 02070000  [....RRA./.......]

1C4E6010 00000000 00000001 00011539 000EF528  [........9...(...]

1C4E6020 00000000 00030002 00000000 00050007  [................]

1C4E6030 00000284 00C0058A 00200175 00002003  [........u. .. ..]

1C4E6040 000EF52F 00000000 00000000 00000000  [/...............]

1C4E6050 00000000 00000000 00000000 00030100  [................]

1C4E6060 0018FFFF 1F361F4E 00001F36 1F820003  [....N.6.6.......]

1C4E6070 1F4E1F68 00000000 00000000 00000000  [h.N.............]

1C4E6080 00000000 00000000 00000000 00000000  [................]

Repeat 250 times

1C4E7030 00000000 00010000 00010001 00000001  [................]

1C4E7040 00000000 00000001 00415252 00415252  [........RRA.RRA.]

1C4E7050 00000000 00000000 00000000 00000000  [................]

Repeat 244 times

1C4E7FA0 00000000 00000000 012C0000 42410B03  [..........,...AB]

1C4E7FB0 46454443 4A494847 04C1024B 076D7807  [CDEFGHIJK....xm.]

1C4E7FC0 0B13100B 0B03012C 44434241 48474645  [....,...ABCDEFGH]

1C4E7FD0 024B4A49 780703C1 100A076D 012C0B13  [IJK....xm.....,.]

1C4E7FE0 42410B03 46454443 4A494847 02C1024B  [..ABCDEFGHIJK...]

1C4E7FF0 076D780B 0B131009 C0DB6C29 F52F0607  [.xm.....)l..../.]

Block header dump:  0×00415252

Object id on Block? Y

seg/obj: 0×11539 csc: 0×00.ef528  itc: 2  flg: O  typ: 1 – DATA

fsl: 0  fnx: 0×0 ver: 0×01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0×01   0×0007.005.00000284  0×00c0058a.0175.20  –U-    3  fsc 0×0000.000ef52f

0×02   0×0000.000.00000000  0×00000000.0000.00  —-    0  fsc 0×0000.00000000

——————————————————————————–

ALTER TABLE DUMP_EXAMPLE2 MOVE TABLESPACE USERS;

You can see that a new data_object_id is assigned, while object_id stays the same. The new data_object_id matches to the new location recorded as sys.seg$

SELECT OBJECT_ID, DATA_OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = ‘DUMP_EXAMPLE2′;

– 70969 70970

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) ,  DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)

FROM DUMP_EXAMPLE2;

4 420

4 420

4 420

ALTER SYSTEM DUMP DATAFILE 1 BLOCK 86610;

Dump the block at the old location.

——————————————————————————–

buffer tsn: 0 rdba: 0×00415252 (1/86610)

scn: 0×0000.000ef52f seq: 0×07 flg: 0×06 tail: 0xf52f0607

frmt: 0×02 chkval: 0xbad1 type: 0×06=trans data

Hex dump of block: st=0, typ_found=1

Dump of memory from 0×0C558200 to 0×0C55A200

C558200 0000A206 00415252 000EF52F 06070000  [....RRA./.......]

C558210 0000BAD1 00000001 00011539 000EF528  [........9...(...]

C558220 00000000 00030002 00000000 00050007  [................]

C558230 00000284 00C0058A 00200175 00002003  [........u. .. ..]

C558240 000EF52F 00000000 00000000 00000000  [/...............]

C558250 00000000 00000000 00000000 00030100  [................]

C558260 0018FFFF 1F361F4E 00001F36 1F820003  [....N.6.6.......]

C558270 1F4E1F68 00000000 00000000 00000000  [h.N.............]

C558280 00000000 00000000 00000000 00000000  [................]

Repeat 250 times

C559230 00000000 00010000 00010001 00000001  [................]

C559240 00000000 00000001 00415252 00415252  [........RRA.RRA.]

C559250 00000000 00000000 00000000 00000000  [................]

Repeat 244 times

C55A1A0 00000000 00000000 012C0000 42410B03  [..........,...AB]

C55A1B0 46454443 4A494847 04C1024B 076D7807  [CDEFGHIJK....xm.]

C55A1C0 0B13100B 0B03012C 44434241 48474645  [....,...ABCDEFGH]

C55A1D0 024B4A49 780703C1 100A076D 012C0B13  [IJK....xm.....,.]

C55A1E0 42410B03 46454443 4A494847 02C1024B  [..ABCDEFGHIJK...]

C55A1F0 076D780B 0B131009 C0DB6C29 F52F0607  [.xm.....)l..../.]

Block header dump:  0×00415252

Object id on Block? Y

seg/obj: 0×11539 csc: 0×00.ef528  itc: 2  flg: O  typ: 1 – DATA

fsl: 0  fnx: 0×0 ver: 0×01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0×01   0×0007.005.00000284  0×00c0058a.0175.20  –U-    3  fsc 0×0000.000ef52f

0×02   0×0000.000.00000000  0×00000000.0000.00  —-    0  fsc 0×0000.00000000

——————————————————————————–

ALTER SYSTEM DUMP DATAFILE 4 BLOCK 420;

——————————————————————————–

buffer tsn: 4 rdba: 0×010001a4 (4/420)

scn: 0×0000.000ef540 seq: 0×02 flg: 0×04 tail: 0xf5400602

frmt: 0×02 chkval: 0×3a1f type: 0×06=trans data

Hex dump of block: st=0, typ_found=1

Dump of memory from 0×0C558200 to 0×0C55A200

C558200 0000A206 010001A4 000EF540 04020000  [........@.......]

C558210 00003A1F 00000001 0001153A 000EF53F  [.:......:...?...]

C558220 00000000 00320003 010001A1 00130001  [......2.........]

C558230 00000294 00000000 00000000 00000000  [................]

C558240 00000000 00000000 00000000 00000000  [................]

Repeat 2 times

C558270 00000000 00000000 00000000 00030100  [................]

C558280 0018FFFF 1F161F2E 00001F16 1F620003  [..............b.]

C558290 1F2E1F48 00000000 00000000 00000000  [H...............]

C5582A0 00000000 00000000 00000000 00000000  [................]

Repeat 495 times

C55A1A0 00000000 00000000 002C0000 42410B03  [..........,...AB]

C55A1B0 46454443 4A494847 04C1024B 076D7807  [CDEFGHIJK....xm.]

C55A1C0 0B13100B 0B03002C 44434241 48474645  [....,...ABCDEFGH]

C55A1D0 024B4A49 780703C1 100A076D 002C0B13  [IJK....xm.....,.]

C55A1E0 42410B03 46454443 4A494847 02C1024B  [..ABCDEFGHIJK...]

C55A1F0 076D780B 0B131009 C0DB6C29 F5400602  [.xm.....)l....@.]

Block header dump:  0×010001a4

Object id on Block? Y

seg/obj: 0×1153a csc: 0×00.ef53f  itc: 3  flg: E  typ: 1 – DATA

brn: 0  bdba: 0×10001a1 ver: 0×01 opc: 0

inc: 0  exflg: 0

——————————————————————————–

As you can see, when you move a table, the content of blocks in the table is copied to the new location, with a new data_object_id flag. Oracle updates the data directionary seg$ so that the object is associated to the new location. The content at the old location is NOT erased immediately. This mechanism is known as “delayed block clean up“.

Delayed block clean up also applies to “truncate”. When you truncate a table, Oracle just allocates new extents and points this new location. The old data is left intact at the old location. That is one of reasons that truncate is fast. It also indicates a way to peek into history data even the tables is already truncated.

Data Block Dump in Oracle – part 4 – vs. Transparent Data Encyption

? Original article Author: Liang's Blog

Now, let us look into Transparent Data Encryption in 11g implemention using data block dumps.

Transparent Data Encryption (TDE) can be used to encrypt table columns, or tablespaces (only in 11g) without requiring database users change their access code. In short, data in tables/indexes are stored in an encrypted format; when queried, Oracle will automatically decrypt these encrypted data and present to the users. Once setup, encrypt and decrypt happen on the fly, transparently.

Here, we study a few cases to answer these questions.

1) If I have a table on a not-encrypted tablespace and I encrypt its column, will all data in the column be safe now?

2) If I have a table and I move it to a encrypted tablespace, will all data in the column be safe now?

3) When I generate redo logs or archive logs, are they encrypted?

In the case 1, we see the answer is a NO to question1.

CREATE TABLE DUMP_EXAMPLE (

COL1 VARCHAR2(2000),

COL2 NUMBER,

COL3 TIMESTAMP) TABLESPACE USERS;

INSERT INTO DUMP_EXAMPLE VALUES(’CREDIT CARD NUMBER 1′,12345,SYSTIMESTAMP);

INSERT INTO DUMP_EXAMPLE VALUES(’CREDIT CARD NUMBER 2′,22345,SYSTIMESTAMP+1);

INSERT INTO DUMP_EXAMPLE VALUES(’CREDIT CARD NUMBER 3′,32345,SYSTIMESTAMP+2);

COMMIT;

ALTER TABLE DUMP_EXAMPLE MODIFY (COL1 ENCRYPT);

SELECT TABLE_NAME, COLUMN_NAME, ENCRYPTION_ALG FROM DBA_ENCRYPTED_COLUMNS;  — verify that the col1 is encrypted now.

DUMP_EXAMPLE  COL1 AES 192 bits key

Now, dump the data block.

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID), DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM DUMP_EXAMPLE;

ALTER SYSTEM DUMP DATAFILE 4 BLOCK 478;

27039F80 2C01D801 36012F02 03012C02 45524314  [...,./.6.,...CRE]

27039F90 20544944 44524143 4D554E20 20524542  [DIT CARD NUMBER ]

27039FA0 04C30433 78072E18 0110076D 012C3309  [3......xm....3,.]

27039FB0 52431403 54494445 52414320 554E2044  [..CREDIT CARD NU]

27039FC0 5245424D C3043220 072E1803 0F076D78  [MBER 2......xm..]

27039FD0 2C330901 43140301 49444552 41432054  [..3,...CREDIT CA]

27039FE0 4E204452 45424D55 04312052 2E1802C3  [RD NUMBER 1.....]

27039FF0 076D780B 3309010E 40B9561E C78E0605  [.xm....3.V.@....]

block_row_dump:

tab 0, row 0, @0×1f6f

tl: 41 fb: –H-FL– lb: 0×1  cc: 3

col  0: [20]  43 52 45 44 49 54 20 43 41 52 44 20 4e 55 4d 42 45 52 20 31

col  1: [ 4]  c3 02 18 2e

col  2: [11]  78 6d 07 0e 01 09 33 1e 56 b9 40

tab 0, row 1, @0×1f4a

tl: 37 fb: –H-FL– lb: 0×1  cc: 3

col  0: [20]  43 52 45 44 49 54 20 43 41 52 44 20 4e 55 4d 42 45 52 20 32

col  1: [ 4]  c3 03 18 2e

col  2: [ 7]  78 6d 07 0f 01 09 33

tab 0, row 2, @0×1f25

tl: 37 fb: –H-FL– lb: 0×1  cc: 3

col  0: [20]  43 52 45 44 49 54 20 43 41 52 44 20 4e 55 4d 42 45 52 20 33

col  1: [ 4]  c3 04 18 2e

col  2: [ 7]  78 6d 07 10 01 09 33

end_of_block_dump

As you can see, the column is marked as encrypted, but the existing data are not encrypted.  That would become an issue if you are not aware of this implementation.

What will happen to the new records inserted?

INSERT INTO DUMP_EXAMPLE VALUES(’CREDIT CARD NUMBER 4′,42345,SYSTIMESTAMP+3);

COMMIT;

DBE2130 4403022C 4114097B 486A82F2 98C4247C  [,..D{..A..jH|$..]

DBE2140 21F6778B 511B1456 B544614C AEA2515F  [.w.!V..QLaD._Q..]

DBE2150 10CB765B 96D17F19 58D77344 B0ECD329  [[v......Ds.X)...]

DBE2160 0DBF64F3 D2124302 680A6666 487D69E2  [.d...C..ff.h.i}H]

DBE2170 8030E715 567A3D96 1802C304 6D780B2E  [..0..=zV......xm]

DBE2180 09010E07 B9561E33 03002C40 45524314  [....3.V.@,...CRE]

DBE2190 20544944 44524143 4D554E20 20524542  [DIT CARD NUMBER ]

DBE21A0 04C30433 78072E18 0110076D 002C3309  [3......xm....3,.]

DBE21B0 52431403 54494445 52414320 554E2044  [..CREDIT CARD NU]

DBE21C0 5245424D C3043220 072E1803 0F076D78  [MBER 2......xm..]

DBE21D0 2C330901 43140300 49444552 41432054  [..3,...CREDIT CA]

DBE21E0 4E204452 45424D55 04312052 2E1802C3  [RD NUMBER 1.....]

DBE21F0 076D780B 3309010E 40B9561E C7960601  [.xm....3.V.@....]

Yes, new records are encrypted.

As you can see, further actions are needed to protect/encrypt old records of a column. To encrypt old records, you can move the table using “alter table”.

(Case 2) If a table is moved to encrypted tablespace, the content will be encrypted. Data block dump shows that they are not directly readable.

CREATE SMALLFILE TABLESPACE “ENCRYPTBS” DATAFILE ‘\Path to directory\ENCRYPTBS’ SIZE 2M AUTOEXTEND ON NEXT 1K MAXSIZE 10M  ENCRYPTION USING ‘AES192′ DEFAULT STORAGE(ENCRYPT);

ALTER TABLE DUMP_EXAMPLE MOVE TABLESPACE ENCRYPTBS;

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID), DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM DUMP_EXAMPLE;

ALTER SYSTEM DUMP DATAFILE 7 BLOCK 12;

Block dump from disk:

Encrypted block <10, 29360140> content will not be dumped. Dumping header only.

buffer tsn: 10 rdba: 0×01c0000c (7/12)

scn: 0×0000.0011cde3 seq: 0×02 flg: 0×14 tail: 0xcde30602

frmt: 0×02 chkval: 0×4def type: 0×06=trans data

End dump data blocks tsn: 10 file#: 7 minblk 12 maxblk 12

As you can see the encypted block can not be dumped.

(Case 3) Find out records in redo/archive logs for DMLs on encrypted tables. Here is an example.

Insert a row, redo is generated. Now, find current redo log and dump the redo log.

INSERT INTO DUMP_TDE_EXAMPLE VALUES(’CREDIT CARD NUMBER 4′,42345,SYSTIMESTAMP+4);

COMMIT;

SELECT L.STATUS, LF.MEMBER FROM V$LOG L JOIN V$LOGFILE LF ON L.GROUP#=LF.GROUP#

WHERE L.STATUS = ‘CURRENT’;

alter system dump logfile ‘logfile_number_location’;

Now, ready to look into the redo dump and find out whether data are encrypted. I first calculate DBA (Data Block Address) of the insert value using data file number and block#.

SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID), DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) FROM DUMP_EXAMPLE;

5 472

SELECT  DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(5,472) FROM DUAL; — in decimal

SELECT TO_CHAR(DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(5,472), ‘XXXXXXXXX’) FROM DUAL;  — in hex

Search dump files for the block address. What I see is data in encrypted format. Like,

INSERT INTO DUMP_EXAMPLE VALUES(’CREDIT CARD NUMBER 5′,52345,SYSTIMESTAMP+5);

COMMIT;

If unencrypted, the text can be read

CHANGE #1 TYP:0 CLS: 1 AFN:4 DBA:0×010001d7 OBJ:71094 SCN:0×0000.0011a82d SEQ:  1 OP:11.2

KTB Redo

op: 0×01  ver: 0×01

compat bit: 4 (post-11) padding: 0

op: F  xid:  0×0004.017.000002fe    uba: 0×00c006ca.0187.1a

KDO Op code: IRP row dependencies Disabled

xtype: XA flags: 0×00000000  bdba: 0×010001d7  hdba: 0×010001d3

itli: 1  ispac: 0  maxfr: 4858

tabn: 0 slot: 0(0×0) size/delt: 37

fb: –H-FL– lb: 0×1  cc: 3

null: —

col  0: [20]  43 52 45 44 49 54 20 43 41 52 44 20 4e 55 4d 42 45 52 20 35

col  1: [ 4]  c3 06 18 2e

col  2: [ 7]  78 6d 07 13 01 37 06

If TDE is enabled, the redo data is encrypted. See the different the col0 values above and below for the same inserted record.

KDO Op code: IRP row dependencies Disabled

xtype: XA flags: 0×00000000  bdba: 0×01c00010  hdba: 0×01c0000b

itli: 1  ispac: 0  maxfr: 4858

tabn: 0 slot: 0(0×0) size/delt: 85

fb: –H-FL– lb: 0×1  cc: 3

null: —

col  0: [68]

a4 5d 94 29 07 b6 76 31 d2 10 a8 79 a4 04 4c d3 8f f5 df c7 b0 7d bc 52 95

c6 f7 1b f5 8a da d4 60 3a 7f 3b 7e dc 6a 3d f6 23 e6 6a b2 77 b3 9e 17 8a

58 a9 43 97 45 b4 c2 2c bc bb 1b 63 9c 75 db ea b6 f6

col  1: [ 4]  c3 06 18 2e

col  2: [ 7]  78 6d 07 13 01 3a 08

? Original article Author: Liang's Blog