[ NOTE: irrespective of the type data that the block contains , the structure of the block is always the

same. Hence, index,data or clustered data are contained in the same structured block.]

Block overhead = block header (general information of the block --> i. block address ii. Type of segment
Index/Data etc..)
+ table directory (contains information about the table having rows in this block)
+ row directory (actual row info [includes each row piece address in the row data
area])
[NOTE: 1.Space once allocated in the row directory for a row is a DATA BLOCK’s OVERHEAD, this space is
not reclaimed when the row is deleted.
2. A block that is currently empty but had 50 rows at a time continues to have 100 bytes
allocated in the header for the row directory.
3. Oracle reuses this space only when rows are inserted in the block.]

Block overhead = variable component + fixed component = 84 bytes to 107 bytes.

Row Data -- ---> contains the actual data pertaining to table or index.
Free Space ---->(i) allocated for insertion of new rows and for updates to rows that require additional
space [ for example, when a trailing null is updated to a non null values ].
(ii) also holds transaction entries. A transaction entry is required in a block for each
INSERT,DELETE,UPDATE and SELECT …. FOR UPDATE statement accessing one or more rows in the block.
Space [ for transaction entry ] --- OS dependent --- approximately 23 bytes.

Free Space Management ---> automatically or manually.

The in-segment free/used space is tracked using bitmaps, as opposed to free lists.
The free space management that is done with the aid of bitmaps is AUTOMATIC free space management.

Advantages:(i) ease of use.

(ii) better space utilization, especially for objects with highly varying row sizes.
(iii) better run-time adjustment to variations in concurrent access.
(iv) better multi-instance behavior in terms of performance/space utilization.
Free Space Coalesce [ in a block ] -----> The fragmented free space in a block is coalesced only under the
following two situations occurring concurrently:

1. When an insert or update statement attempts to use a block that contains enough space to
accommodate the new row piece or data.

2. The free space is fragmented so the new row piece cannot be accommodated in a contiguous
section of the block.
Row Format and Size
Limits on the number of columns in a table --- 256.
Each row piece, chained or unchained, contains ---
(i) row header
(ii) data for all or some of the columns of rows
3.
The image show a row piece in a data block.
The row piece consists of the
(i) row header – consists of (1) row overhead,
(2) number of columns,
(3) cluster key ID (if clustered),
(4) ROWID of chained row piece (if any).

It precedes the data and contains information about: (i) row pieces
(ii) chaining (for chained row pieces only)
(iii) columns in the row piece
(iv) cluster keys (for clustered data only)

(ii) column data – this section contains the column length and column value

Sizes of the row pieces

Row Header -> a row fully contained in one block has at least 3 bytes of row header.
->column length-- 1 byte for columns – stores 250 bytes or less.
-> column length-- 3 bytes for columns – store more than 250 bytes.
[note: column length are specified before its corresponding column data.]
-> column data – depends on the data type , if the data type is variable length, then
the space required to hold a value can grow and shrink with updates to the data.
-> note: column data -- null in a column only stores the column length ( zero ).
-- Oracle does not store data for the null column, only the
column length [ which is 0 ] is recorded.
-- For trailing null columns, Oracle does not even store the
column length.

NOTE: Each row consumes 2 BYTES of the ROW DIRECTORY in the block header.

ROWIDS of Row pieces

===================

The rowid identifies each row piece by its location or address.

- rowid of a given row piece changes when (a) the row is deleted
[NOTE: if the row is deleted and the corresponding transaction is committed and a new row is inserted ,

the new row can take the rowid of the deleted row.]
(b) the row is exported and imported using Oracle Utilities
(c) if the clustered key values of a row change, then the row keeps
the same rowid but also gets an additional pointer rowid for the new values.

Physical Rowids – provide the fastest possible access to a row in a given table.
- contain the physical address of a row (down to the specific block) and allow one to
retrieve the row in a single block access.
- as long as a row is not deleted , its rowid remains unchanged.
- in CLUSTERED tables , rows in different tables that are in the same data block can have
the same rowid.

- a deleted row’s rowid can be reused by a transaction which is other than the
transaction that deleted the row.

FORMATs OF PYSICAL ROWID

=========================
EXTENDED ROWID -> - format supports tablespace relative data block addresses
- efficiently identifies rows in partitioned tables and indexes as well as non-
partitioned tables and index.
- tables and indexes created by an Oracle 8i (or higher) server always have
extended row-ids.
- extended rowids use a base 64 encoding of the physical address for each row
selected. The encoding characters are : A-Z , a-z , 0-9 ,+ and /.
For example, the following query:

SELECT ROWID, LAST_NAME FROM EMPLOYEES WHERE DEPARTMENT_ID=20; --- can return:
ROWID              LAST_NAME
­­­­­­­­­­­­­­­­­­ ­­­­­­­­­­
AAAAaoAATAAABrXAAA BORTINS
AAAAaoAATAAABrXAAE RUGGLES
AAAAaoAATAAABrXAAG CHEN
AAAAaoAATAAABrXAAN BLUMBERG

An extended row id has a four-piece format,

OOOOOO -> the “data object number” that identifies the database segment (AAAAao in this example).
schema objects in the same segment, such as the cluster of tables, have the same data
object number.
FFF -> the tablespace-relative “datafile number” of the datafile that contains the row (file AAT in
the example).

BBBBBB -> the “data block” that contains the row (block AAABrX in the example).
Block numbers are relative to their datafile, not tablespace. Therefore, two rows with
identical block numbers could reside in two different datafiles of the same tablespace.

RRR -> the “row” in the block

“DBMS_ROWID” can be used to obtain the object_id for a corresponding extended rowid or to convert a
rowid from extended format to restricted format (vice versa).
RESTRICTED ROWID -> use a binary representation of the physical address for each row selected.
When queried using SQL* Plus, the binary representation is converted to a VARCHAR2/hexadecimal
representation.

Example:
SELECT ROWID, last_name FROM employees
WHERE department_id = 30;
can return the following row information:
ROWID ENAME
­­­­­­­­­­­­­­­­­­ ­­­­­­­­­­
00000DD5.0000.0001 KRISHNAN
00000DD5.0001.0001 ARBUCKLE
00000DD5.0002.0001 NGUYEN

As shown, a restricted rowid’s VARCHAR2/hexadecimal representation is in a three-piece format,

block.row.file:
DATA BLOCK: DD5 – block numbers are relative to their datafile, not tablespace. Two rows with identical
block numbers could reside in two different datafiles of the same tablespace.
ROW :0,1,2 - row numbers of a given block always start with 0.
DATAFILE :
RESTRICTED ROWID -> is available for backward compatibility with applications developed with Oracle
DB version 7 or earlier releases.

Jonathan Lewis

2. Daily Digest 2:

There are two ID's for a datafile and those are FILE_ID and RELATIVE_FILE_ID.
File_id is unqiue within the database for a file.
Relative_file_id is unique within a tablespace.

However , exception to the rule was highlighted by Tanel Poder where he said:
With the advent of "Transportable Tablespace" the file_id being unique in the database --- no more
holds.
That is the reason for the introduction of the 10 byte EXTENDED ROWID.
Till Oracle 7 , there was this 6 byte RESTRICTED ROWID only.
RESTRICTED ROWID - contains the Block,File and the Row information only.
Whereas EXTENDED ROWID - contains the objectid in addition to the block,file and row information.
So, in an extended rowid , the rowid will hold the objectid of which it is a row.

So, in a database with transportable tablespace , there might be two entries with the same file_id,
however, the EXTENDED ROWID's containing the file_id will be different.
This is because , the object_id is never the same.

- The reason for keeping the file_id same in transportable table is to keep the reference of the ROWID's
in the index same.
- In case of a Global Index on a partitioned table, each rowid in the leaf block should contain in addition
to BRF(block-row-file) , the objectid as well.
 This is because , the 6 bytes Restricted Rowid will contain the file_id,row_id and block_id in the leaf
block.
Now, since the each partition of a table might reside in different tablespace , the file_id might be same
(if the relative file_id) is used. - [ RELATIVE FILE_ID IS USED CONFIRMED from Tanel's blog