Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

94
CHAPTER 3 ■ FILES
Storage Hierarchy Summary
In summary, the hierarchy of storage in Oracle is as follows:
1. A database is made up of one or more tablespaces.
2. A tablespace is made up of one or more data files. These files might be cooked files in
a file system, raw partitions, ASM managed database files, or a file on a clustered file
system. A tablespace contains segments.
3. A segment (TABLE, INDEX, and so on) is made up of one or more extents. A segment
exists in a tablespace, but may have data in many data files within that tablespace.
4. An extent is a logically contiguous set of blocks on disk. An extent is in a single tablespace
and, furthermore, is always in a single file within that tablespace.
5. A block is the smallest unit of allocation in the database. A block is the smallest unit of
I/O used by a database.
Dictionary-Managed and Locally-Managed Tablespaces
Before we move on, we will look at one more topic related to tablespaces: how extents are
managed in a tablespace. Prior to Oracle 8.1.5, there was only one method to manage the allocation
of extents within a tablespace: a dictionary-managed tablespace. That is, the space
within a tablespace was managed in data dictionary tables, in much the same way you would
manage accounting data, perhaps with a DEBIT and CREDIT table. On the debit side, we have all
of the extents allocated to objects. On the credit side, we have all of the free extents available
for use. When an object needed another extent, it would ask the system to get one. Oracle
would then go to its data dictionary tables, run some queries, find the space (or not), and then
update a row in one table (or remove it all together) and insert a row into another. Oracle
managed space in very much the same way you will write your applications: by modifying
data and moving it around.
This SQL, executed on your behalf in the background to get the additional space, is
referred to as recursive SQL. Your SQL INSERT statement caused other recursive SQL to be executed
to get more space. This recursive SQL can be quite expensive if it is done frequently.
Such updates to the data dictionary must be serialized; they cannot be done simultaneously.
They are something to be avoided.
In earlier releases of Oracle, we would see this space management issue—this recursive
SQL overhead—most often occurring in temporary tablespaces (this was before the introduction
of “real” temporary tablespaces created via the CREATE TEMPORARY TABLESPACE command).
Space would frequently be allocated (we would have to delete from one dictionary table and
insert into another) and de-allocated (we would put the rows we just moved back where they
were initially). These operations would tend to serialize, dramatically decreasing concurrency
and increasing wait times. In version 7.3, Oracle introduced the concept of a true temporary
tablespace, a new tablespace type dedicated to just storing temporary data, to help alleviate
this issue. Prior to this special tablespace type, temporary data was managed in the same
tablespaces as persistent data and treated in much the same way as permanent data was.
A temporary tablespace was one in which you could create no permanent objects of your
own. This was fundamentally the only difference; the space was still managed in the data