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

CHAPTER 12 ■ DATATYPES 549
Note the increased I/O usage, both on the read and writes. All in all, this shows that if you
use a CLOB, and many of the strings are expected to fit “in the row” (i.e., will be less than 4,000
bytes), then using the default of ENABLE STORAGE IN ROW is a good idea.
CHUNK Clause
The CREATE TABLE statement returned from DBMS_METADATA previously included the following:
LOB ("TXT") STORE AS ( ... CHUNK 8192 ... )
LOBs are stored in chunks; the index that points to the LOB data points to individual chunks
of data. Chunks are logically contiguous sets of blocks and are the smallest unit of allocation
for LOBs, whereas normally a block is the smallest unit of allocation. The CHUNK size must be
an integer multiple of your Oracle blocksize—this is the only valid value.
You must take care to choose a CHUNK size from two perspectives. First, each LOB instance
(each LOB value stored out of line) will consume at least one CHUNK. A single CHUNK is used by a
single LOB value. If a table has 100 rows and each row has a LOB with 7KB of data in it, you
can be sure that there will be 100 chunks allocated. If you set the CHUNK size to 32KB, you will
have 100 32KB chunks allocated. If you set the CHUNK size to 8KB, you will have (probably) 100
8KB chunks allocated. The point is, a chunk is used by only one LOB entry (two LOBs will not
use the same CHUNK). If you pick a CHUNK size that does not meet your expected LOB sizes, you
could end up wasting an excessive amount of space. For example, if you have that table with
7KB LOBs on average, and you use a CHUNK size of 32k, you will be “wasting” approximately 25k
of space per LOB instance. On the other hand, if you use an 8KB CHUNK, you will minimize any
sort of waste.
You also need to be careful when you want to minimize the number of CHUNKs you have
per LOB instance. As you have seen, there is a lobindex used to point to the individual chunks,
and the more chunks you have, the larger this index is. If you have a 4MB LOB and use an 8KB
CHUNK, you will need at least 512 CHUNKs to store that information. That means you need at least
as many lobindex entries to point to these chunks. That might not sound like a lot, but you
have to remember that this is per LOB instance, so if you have thousands of 4MB LOBs, you
now have many thousands of entries. This will also affect your retrieval performance, as it
takes longer to read and manage many small chunks than it does to read fewer, but larger,
chunks. The ultimate goal is to use a CHUNK size that minimizes your “waste,” but also efficiently
stores your data.
PCTVERSION Clause
The CREATE TABLE statement returned from DBMS_METADATA previously included the following:
LOB ("TXT") STORE AS ( ... PCTVERSION 10 ... )
This is used to control the read consistency of the LOB. In previous chapters, we’ve discussed
read consistency, multi-versioning, and the role that undo plays in them. Well, when it comes
to LOBs, the way read consistency is implemented changes. The lobsegment does not use
undo to record its changes; rather, it versions the information directly in the lobsegment itself.
The lobindex generates undo just as any other segment would, but the lobsegment does not.
Instead, when you modify a LOB, Oracle allocates a new CHUNK and leaves the old CHUNK in
place. If you roll back your transaction, the changes to the LOB index are rolled back and the