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

544
CHAPTER 12 ■ DATATYPES
The main reasons you might consider using a different tablespace for the LOB data versus
the table data relate mainly to administration and performance. From the administrative
angle, a LOB datatype represents a sizable amount of information. If the table had millions
of rows, and each row had a sizeable LOB associated with it, the LOB data would be huge. It
would make sense to segregate the table from the LOB data just to facilitate backup and recovery
and space management. You may well want a different uniform extent size for your LOB
data than you have for your regular table data, for example.
The other reason could be for I/O performance. By default, LOBs are not cached in the
buffer cache (more on that later). Therefore, by default every LOB access, be it read or write, is
a physical I/O—a direct read from disk or a direct write to disk.
■Note LOBs may be inline, or stored in the table. In that case, the LOB data would be cached, but this
applies only to LOBs that are 4,000 bytes or less in size. We’ll discuss this further in the “IN ROW Clause”
section.
Because each access is a physical I/O, it makes sense to segregate to their own disk those
objects you know for a fact will be experiencing more physical I/O than most objects in real
time (as the user accesses them) to their own disks.
It should be noted that the lobindex and the lobsegment will always be in the same tablespace.
You cannot have the lobindex and lobsegment in separate tablespaces. Much earlier
releases of Oracle allowed you to separate them, but versions 8i Release 3 and later do not
allow you to specify separate tablespaces for the lobindex and lobsegment. In fact, all storage
characteristics of the lobindex are inherited from the lobsegment, as we’ll see shortly.
IN ROW Clause
The CREATE TABLE statement returned from DBMS_METADATA earlier included the following:
LOB ("TXT") STORE AS (... ENABLE STORAGE IN ROW ...
This controls whether the LOB data is always stored separately from the table, in the lobsegment,
or if it can sometimes be stored right in the table itself without being placed into the
lobsegment. If ENABLE STORAGE IN ROW is set, as opposed to DISABLE STORAGE IN ROW, small
LOBs of up to 4,000 bytes will be stored in the table itself, much like a VARCHAR2 would be.
Only when LOBs exceed 4,000 bytes will they be moved “out of line” into the lobsegment.
Enabling storage in the row is the default and, in general, should be the way to go if you
know the LOBs will generally fit in the table itself. For example, you might have an application
with a DESCRIPTION field of some sort in it. The DESCRIPTION might store between 0 and 32KB of
data (or maybe even more, but mostly 32KB or less). Many of the descriptions are known to be
very short, consisting of a couple hundred characters. Rather than suffering the overhead of
storing these out of line and accessing them via the index every time you retrieve them, you
can store them inline, in the table itself. Further, if the LOB is using the default of NOCACHE (the
lobsegment data is not cached in the buffer cache), then a LOB stored in the table will avoid
the physical I/O required to retrieve the LOB.