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

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 12 ■ DATATYPES 543 Conceptually, the LOB is stored very much like that—in creating those two tables, we would have a primary key on the LOB table on the ID,CHUNK_NUMBER (analogous to the lobindex created by Oracle), and we would have a table LOB storing the chunks of data (analogous to the lobsegment). The LOB column implements this master/detail structure for us transparently. Figure 12-3 might make this idea clearer. Figure 12-3. Table to lobindex to lobsegment The LOB in the table really just points to the lobindex, and the lobindex in turn points to all of the pieces of the LOB itself. To get bytes N through M of the LOB, you would dereference the pointer in the table (the LOB locator), walk the lobindex structure to find the needed chunks, and then access them in order. This makes random access to any piece of the LOB equally fast—you can get the front, the middle, or the end of a LOB equally fast, as you don’t always just start at the beginning and walk the LOB. Now that you understand conceptually how a LOB is stored, I’d like to walk through each of the optional settings listed previously, and explain what they are used for and what exactly they imply. LOB Tablespace The CREATE TABLE statement returned from DBMS_METADATA included the following: LOB ("TXT") STORE AS ( TABLESPACE "USERS" ... The TABLESPACE specified here is the tablespace where the lobsegment and lobindex will be stored, and this may be different from the tablespace where the table itself resides. That is, the tablespace that holds the LOB data may be separate and distinct from the tablespace that holds the actual table data.

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.

CHAPTER 12 ■ DATATYPES 543<br />

Conceptually, the LOB is stored very much like that—in creating those two tables, we<br />

would have a primary key on the LOB table on the ID,CHUNK_NUMBER (analogous to the lobindex<br />

created by <strong>Oracle</strong>), <strong>and</strong> we would have a table LOB storing the chunks of data (analogous to the<br />

lobsegment). The LOB column implements this master/detail structure for us transparently.<br />

Figure 12-3 might make this idea clearer.<br />

Figure 12-3. Table to lobindex to lobsegment<br />

The LOB in the table really just points to the lobindex, <strong>and</strong> the lobindex in turn points to<br />

all of the pieces of the LOB itself. To get bytes N through M of the LOB, you would dereference<br />

the pointer in the table (the LOB locator), walk the lobindex structure to find the needed<br />

chunks, <strong>and</strong> then access them in order. This makes r<strong>and</strong>om access to any piece of the LOB<br />

equally fast—you can get the front, the middle, or the end of a LOB equally fast, as you don’t<br />

always just start at the beginning <strong>and</strong> walk the LOB.<br />

Now that you underst<strong>and</strong> conceptually how a LOB is stored, I’d like to walk through each<br />

of the optional settings listed previously, <strong>and</strong> explain what they are used for <strong>and</strong> what exactly<br />

they imply.<br />

LOB Tablespace<br />

The CREATE TABLE statement returned from DBMS_METADATA included the following:<br />

LOB ("TXT") STORE AS ( TABLESPACE "USERS" ...<br />

The TABLESPACE specified here is the tablespace where the lobsegment <strong>and</strong> lobindex will be<br />

stored, <strong>and</strong> this may be different from the tablespace where the table itself resides. That is, the<br />

tablespace that holds the LOB data may be separate <strong>and</strong> distinct from the tablespace that<br />

holds the actual table data.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!