Database Reference
In-Depth Information
Most blocks, regardless of their size, have the same general format, which looks something like Figure
3-2
.
Header
Table Directory
Row Directory
Free Space
Data
Tall
Figure 3-2.
The structure of a block
Exceptions to this format include LOB segment blocks and hybrid columnar compressed blocks in Exadata
storage, for example, but the vast majority of blocks in your database will resemble the format in Figure
3-2
. The block
header contains information about the type of block (table block, index block, and so on); transaction information
when relevant (only blocks that are transaction-managed have this information—a temporary sort block would not,
for example) regarding active and past transactions on the block; and the address (location) of the block on the disk.
The next two block components are found on the most common types of database blocks, those of HEAP-
organized tables. We'll cover database table types in much more detail in Chapter 10, but suffice it to say that most
tables are of this type.
The table directory, if present, contains information about the tables that store rows in this block (data from more
than one table may be stored on the same block). The row directory contains information describing the rows that are
to be found on the block. This is an array of pointers to where the rows are to be found in the data portion of the block.
These three pieces of the block are collectively known as the block overhead, which is space used on the block that is
not available for your data, but rather is used by Oracle to manage the block itself.
The remaining two pieces of the block are straightforward: there may be free space on a block, and then there will
generally be used space that is currently storing data.
Now that you have a cursory understanding of segments, which consist of extents, which consist of blocks, let's
take a closer look at tablespaces and then at exactly how files fit into the big picture.
Tablespaces
As noted earlier, a tablespace is a container—it holds segments. Each segment belongs to exactly one tablespace. A
tablespace may have many segments within it. All of the extents for a given segment will be found in the tablespace
associated with that segment. Segments never cross tablespace boundaries. A tablespace itself has one or more data
files associated with it. An extent for any given segment in a tablespace will be contained entirely within one data
file. However, a segment may have extents from many different data files. Graphically, a tablespace might look like
Figure
3-3
.
