Oracle block format

Information Reference: http://www.ixora.com.au/
I am particularly grateful to my eldest brother overtime for his selfless help and encouragement to my netizens.
These materials are not supported by oracle, so we cannot guarantee the correctness of the information. Please use them with caution.
Unlimited reprinting of technologies

Oracle 8.1.7 8 k block windows xp
Create table t (n number );
Insert into t values (1); --- From dbms_rowid, we can see that table t data is stored in the 3rd blocks of datafile 4.

Select dbms_rowid.ROWID_RELATIVE_FNO (rowid) as file #, dbms_rowid.ROWID_BLOCK_NUMBER (rowid) as block # from t;

Alter system dump datafile 4 block 3;
Below is the dump file information
You can also use the following statement and then use the above dump statement to view the binary storage format of the block in the memory.
However, the binary format in the memory is slightly different from the block data representation sequence in datafile, probably because of memory addressing.
Alter session set events '10289 trace name context forever, level 1 ';
Alter session set events '10289 trace name context off ';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
Below is the dump file information under the udump directory

----------------------- Part 1

Buffer tsn: 7 rdba: 0x01000003 (4/3)
Scn: 0x0000. 000802a5 seq: 0x01 flg: 0x02 tail: 0x02a50601
Frmt: 0x02 chkval: 0x0000 type: 0x06 = trans data

--- Buffer tsn: the number of tablespace corresponding to the data file. This is only the data recorded in the dump file.
--- The number of the tablespace is not recorded in the block.
--- Rdba: The number of blocks marked by the block address in 4 bytes datafile
--- Scn: 6 bytes system change number
--- Seq: 1 byte A sequence number incremented for each change to a block at the same SCN
--- A new SCN is allocated if the sequence number wraps.
--- If the number of rows in the block is greater than 254, A New SCN will be allocated to the transaction.
--- The following operations may cause more than 254 rows in the same SCN but affected block.
--- "Delete from table_name"
--- The number of affected rows (up to 254) is represented by 0x01 to 0xfe.
--- When the byte data is 0xff, it indicates that the block is broken ---> ora-01578
--- Flg: 1 byte 1 = virgin block
--- 2 = last change to the block was for a cleanout operation
--- 4 = checksum value is set
--- 8 = temporary data
--- This is a value that can be combined. That is to say, if there is 6, it is a combination of 2 and 4.
--- Tail: 4 bytes this is the 4 bytes data recorded at the end of the block
--- The dump file only writes it in front of it.
--- Frmt: 1 byte oracle 8 all seen after 0x02
--- Chkval: 2 bytes the value of db_block_checksum = true is set in the init file.
--- Type: the block type of 1 byte mainly depends on 0x06. This is used to store user data.
--- Other types can refer to http://www.ixora.com.au/notes/cache_block_types.htm

----------------------- Part 2
Block header dump: 0x01000003
Object id on Block? Y
Seg/obj: 0x614a csc: 0x00. 802a3 itc: 1 flg: O typ: 1-DATA
Fsl: 0 fnx: 0x0 ver: 0x01

--- Seg/obj: 4 bytes here is the hexadecimal data corresponding to sys. obj $. obj # Data Dictionary
--- Csc: 6 bytes The SCN at which the last full cleanout was timed med on the block
--- Itc: 1 byte the number of Itl transaction entries 8.1.7 The document above says that when creating a table using INITRANS
--- Limit the size of this value (if max 255 is exceeded, A ORA-02207 will be reported) but consider whether the block space is sufficient.
--- In 8i, INITRANS default is 1, and in 9.2.0, INITRANS default is 2.
--- Yong Huang says sometimes the ORA-00060 can set the INITRANS of the table to a big point
--- Ixora says that when the block space is not enough to create an ITL, it may cause ORA-00054.
--- Flg: 2 bytes 0 indicates that the block is on a freelist. Otherwise the flag is-
--- In the case of 9i ASSM, this value is E
--- Ixora says that he occupies 2 bytes, but my experiment below is somewhat different from his results.
--- What I have observed is:
--- Object id on Block? Y
--- Flg: O
--- Ver: 0x01
--- The preceding three items are represented by the same byte.
--- Typ: 1 byte 1 is table; 2 is index. oracle. The query is based on the conditions in the obj $ table.
--- Determine the object type, not based on the typ. That is to say, if there is a table but the block in the table is changed
--- This flag of can also be used to query data, but an error occurs when dumping the block, as shown in the following ora
--- ORA-00600: Internal error code, independent variable: [4555], [0], [], [], [], [], [], []
--- [0] in the error is the data corresponding to typ.
--- Fsl: 1 byte Index to the first slot on the ITL freelist. itl tx freelist slot
--- Fnx: 4 bytes free list address Null if this block is not on a freelist
--- Data such as fnx: 0x1000029
--- Ver: 1 byte format (version) This data does not see the relevant documentation introduction from ixora said it occupies 1 byte
--- But what I see in the following binary file is different.
--- Unused: 4 bytes there is still 4 bytes free space here, but it is not displayed in the dump file above.
--- The 4 bytes of this unused is the above description in ixora
--- 9i's ASSM's "fsl: 0 fnx: 0x0 ver: 0x01" data has changed

----------------------- Part 3
Itl Xid Uba Flag Lck Scn/Fsc
0x01 xid: 0x0003. 045.000000b4 uba: 0x0080170a. 00c7. 36 -- U-1 fsc 0x0000. 000802a5

--- This is the part of oracle used to record transaction information. Here, only one ITL entry can be dynamically added.
--- As long as the space in the block is sufficient, you can define the number of initialized ITL entries. Use the storage parameter INITRANS.
--- How many ITL can be viewed from the "itc:" section 2 "above?
--- This part involves rollback segment or undo tablespace
--- Itl itl serial number
--- Xid: 8 bytes values can be found using select XIDUSN, XIDSLOT, XIDSQN from v $ transaction;
--- This is comprised of the rollback segment number (2 bytes), the slot number
--- In the transaction table of that rollback segment (2 bytes), and the number
--- Of times use of that transaction table has wrapped (4 bytes ).
--- Uba: 8 bytes The location of the undo for the most recent change to this block by this
--- Transaction. This is comprised of the DBA of the rollback segment block (4
--- Bytes), the sequence number (2 bytes), and the record number for the change
--- In that undo block (1 byte), plus 1 unused byte.
--- Flag 1 nibble ---- = transaction is active, or committed pending cleanout
--- C --- = transaction has been committed and locks cleaned out
----B -- = this undo record contains the undo for this ITL entry
--- -- U-= transaction committed (maybe long ago); SCN is an upper bound
--- T = transaction was still active at block cleanout SCN
--- Lck 3 nibbles The number of row-level locks held in the block by this transaction.
--- Scn/Fsc 6 bytes If the transaction has been cleaned out, this is the commit SCN or an upper
--- Bound thereof. Otherwise the leading two bytes contain the free space credit
--- For the transaction-that is, the number of bytes freed in the block by
--- Transaction
--- Reference http://www.ixora.com.au/q+a/datablock.htm#end
---

----------------------- Part 4
Data_block_dump
====================
Tsiz: 0x1fb8
Hsiz: 0x14
Pbl: 0x02476c44
Bdba: 0x01000003
Flag = -----------
Ntab = 1
Nrow = 1
Frre =-1
Fsbo = 0x14
Fseo = 0x1fb2
Avsp = 0x1f9b
Tosp = 0x1f9b
0xe: pti [0] nrow = 1 offs = 0
0x12: pri [0] offs = 0x1fb2

--- Tsiz: hsiz: pbl: bdba: No data files are stored.
--- Tsiz: aside from the three parts above and the four bytes at the end of the block, the remaining space 0x1fb8 is the block with 8120 bytes and 8 KB:
--- 8192-20 (block head)-24 (Transaction Header)-24 (one Transaction)-4 (block tail) = 8120
--- Hsiz: 20 bytes in the data block header + 4 bytes at the end of the data block = 24 bytes (0x14)
--- Pbl: ptr to buffer holding the block. I used the dedicated mode to dump the block in datafile.
--- All blocks dumped in the dump file of the same session are of the same value.
--- Bdba: Same as rdba in the first part
--- Flag 1 byte N = pctfree hit (clusters), F = don't put on free list
--- K = flushable cluster keys. Of course there are other tags:...
--- Ntab 1 byte the block contains several table data clusters, which may be greater than 1
--- How many rows of data are in the nrow 2 bytes block?
--- Frre 2 bytes First free row index entry.-1 = you have to add one.
--- Fsbo 2 bytes Free Space Begin offset
--- Fseo 2 bytes Free Space End offset
--- Avsp 2 bytes Available space in the block <pctfree and pctused?>
--- Tosp 2 bytes Total available space when all TXs commit
--- 0xe: number of rows of data in the table in nrow 2 bytes block
--- 0xe: offs 2 bytes offset can be seen when cluster is used

----------------------- Part 5
Block_row_dump:
Tab 0, row 0, @ 0x1fb2
Tl: 6 fb: -- H-FL -- lb: 0x1 cc: 1
Col 0: [2] c1 02
End_of_block_dump

--- Tl: the length of this record includes 3 bytes of the general condition of the row head, 1 byte of the data length, and the length of the data itself.
--- Fb: 1 byte K = Cluster Key (Flags may change meaning if this is set to show HASH cluster)
--- C = Cluster table member
--- H = Head piece of row
--- D = Deleted row
--- F = First data piece
--- L = Last data piece
--- P = First column continues from previous piece
--- N = Last column continues in next piece
--- Lb: 1 byte corresponds to the lck of ITL in the third part above, indicating whether the row is locked.
--- Cc: 1 byte indicates the number of data columns in the row.
--- Col 0: [2]: 1 byte indicates the length of this column in this row
--- C1 02: this is the data "1" in the table. You can use the following statement to see if oracle actually uses
--- Select dump (col_name, 16) from table_name;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~

The following data is the binary file corresponding to the above dump file. I explain the content in the order of binary data.

------------------------ The first part of the above dump file
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00006000 06 02 00 00 03 00 01 A5 02 08 00 00 00 01 02
00006010 00 00 00 00

--- 06: type: 0x06 = trans data (corresponding to the content in the above dump file)
--- 02: frmt: 0x02
--- 00 00: filler should be the dump file on the unused. This part of content is not displayed.
--- 03 00 00 01: rdba: 0x01000003 is unique in the same tablespace. It may not be unique in datafile.
--- Let's take a look at his rule: Four datafiles are created consecutively. Their first block is
--- 0x01 00 04 01
--- 0x01 00 08 01
--- 0x01 00 0c 01
--- 0x01 00 00 02
--- The corresponding data is 0x01040001, 0x01080001, 0x010c0001, 0x02000001
--- This shows that the maximum capacity of a datafile is 0x01040001 ~ 0x00000ffff total Yes
--- 4 M (because there is also a datafile head) block. If the block is 8 k, a datafile is 32 GB.
--- This is the reason why oracle documents face oracle's datafile (8 K) up to 32 GB
--- We can also see that the datafile of a tablespace can be 0100 from 0x1023 to 0 xfffe.
--- Datafile. This is also the oracle document. As mentioned above, a tablesapce can have 1022 datafiles.
--- Cause (in fact, a tablespace can have 1023 datafiles I have created)
--- The data section of the big datafile block in oracle10G is 0x00000001 ~ 0 xffffffff
--- This is why the tablesapce of a big datafile only has one datafile and the maximum value is
--- 32 T (8 k: 4G * 8 k = 32 T; 128 T for 32 k data blocks)
--- A5 02 08 00 00 00: scn: 0x0000. 000802a5 oracle is written in C language. These six digits are not exactly an unsigned long
--- Combination of unsigned int
--- 01: seq: 0x01
--- 02: flg: 0x02
--- 00 00: chkval: 0x0000 db_block_checksum = true is set in init.
--- 00 00: the dump file on unused does not display this part.
--- The above 20 bytes of data any change to the value of which must occur ORA-XXXXX (not necessarily ora-01578 I also saw the ora-600)

------------------------ The following corresponds to the second part of the above dump file

01 00 00 00 4A 61 00 00 A3 02 08 00
00006020 00 00 00 01 00 03 00 00 00 00 00

--- 01: typ: 1-DATA
--- 00: I have seen 0x00, but I have never seen other don't know values.
--- 00: other values have been seen, but this value cannot be changed in the dump file by using the editor.
--- 00: I have never changed other values of don't know.
--- 4A 61 00 00: seg/obj: 0x614a
--- A3 02 08 00 00 00: csc: 0x00. 802a3
--- 00 00: other values have been seen, but this value is not changed in the dump file in the editor.
--- 01: itc: 1 Number of ITL entries
--- 00: other values have been seen, but this value cannot be changed in the dump file by using the editor.
--- 03: flg: O ver: 0x01 Object id on Block? Y
--- Flg ver Object id on Block in the files dumped from my observations
--- The rules of the byte they share can be seen from the following situation:
--- Binary data flg ver Object id on Block?
--- 0x00-0x00 N
--- 0x01 0 0x00 N
--- 0x02-0x01 Y
--- 0x03 0 0x01 Y
--- 0x04-0x02 Y
--- 0x05 0 0x02 Y
--- 0x06-0x03 Y
--- 0x07 0 0x03 Y
--- 0x08-0x04 N
--- 0x09 0 0x04 N
--- 0x0a-0x05 Y
--- 0x0b 0 0x05 Y
--- 0x0c-0x06 Y
--- 0x0d 0 0x06 Y
--- 0x0e-0x07 Y
--- 0x0f 0 0x07 Y
--- 0x10... similar to the above loop, this situation has changed on 9i because of the emergence of ASSM.
--- 00: fsl: 0
--- 00 00 00: fnx: 0x0

------------------------ The third part of the above dump file

03 00 45 00
00006030 B4 00 00 00 0A 17 80 00 C7 00 36 00 01 20 00 00
00006040 A5 02 08 00

--- 03 00 45 00 B4 00 00 00: xid: 0x0003. 045.000000b4
--- 0A 17 80 00 C7 00 36 00: uba: 0x0080170a. 00c7. 36
--- 01 0: number of rows locked by Lck. The data of the next byte is also used here.
--- 2: the binary representation of Flag 2 is 0010, which is exactly the same as -- U-in the dump file.
--- 00 00 A5 02 08 00: Scn/Fsc

------------------------ The following corresponds to the fourth part of the above dump file

00 01 01 00 FF 14 00 B2 1F 9B 1F
00006050 9B 1F 00 00 01 00 B2 1F

--- 00: flag
--- 01: ntab
--- 01 00: nrow
--- FF: frre
--- 14 00: fsbo
--- B2 1F: fseo
--- 9B 1F: avsp
--- 9B 1F: tosp
--- 00 00: 0xe: offs
--- 01 00: 0xe: nrow
--- B2 1F: 0x12: pri [0] offs = 0x1fb2

------------------------ The following corresponds to the fifth part of the above dump file

--- This part is omitted much in the middle of the above data because these parts do not store data.

20177ff0 00 00 00 00 00 2C 01 01 02 C1 02

--- This is where the user data is stored in the block.
--- 2C: fb:
--- 01: lb: whether the row is locked
--- 01: How many columns of data in this record can be seen here because only one byte is used to record the number of columns in this row
--- Therefore, a maximum of 255 columns can be set to a maximum of 1000 columns in a table. If the number of columns in a table is greater than 255
--- The link is a link in the block or a direct link between the block and the block based on the length of a row of records.
--- This is why the table design should be as few as 255 columns.
--- 02: What is the length of the data in the 1st column?
--- C1 02: data stored in the block "1"

------------------------ The following corresponds to the first part of the dump file above "tail: 0x02a50601"
01 06 A5 02
--- This is used to verify whether the block is complete mark to change this block's last 4 bytes data in any affirmative ora-1578

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
The preceding section only describes the simplest block format of oracle. There are many other cases, such as cluster and index.
Long, lob, and long raw are represented in blocks, which may vary depending on the Data Length.

Sometimes changing any data in the block may not necessarily lead to a ORA-01578 because the following two parameters are not set to true
Db_block_checking db_block_checksum
These two parameters are true by default for system tablespace.
Data will certainly have a ORA-01578
With the continuous upgrade of oracle version, oracle is constantly improving the correctness of the stored data in the block.
It may be more and more difficult to understand the format of oracle block.