DB2 Version 9.7 for Linux, UNIX, and Windows

Storing LOBs inline in table rows

Large objects (LOBs) are generally stored in a location separate from the table row that references them. However, you can choose to include a LOB to 32 673 bytes long inline in a base table row to simplify access to it.

It can be impractical (and depending on the data, impossible) to include large data objects in base table rows. Figure 1 shows an example of an attempt to include LOBs within a row, and why doing so can be a problem. In this example, the row is defined as having two LOB columns, 500 and 145 kilobytes in length respectively. However, the maximum row size for a DB2 table is 32 kilobytes; so such a row definition could never, in fact, be implemented.

Figure 1. The problem of including LOB data within base table rows
Illustration of attempt to store two LOBs that exceed 32KB within a base row table

To reduce the difficulties associated with working with LOBs, they are treated differently from other data types. Figure 2, shows that only a LOB descriptor is placed in the base table row, rather than the LOB itself. Each of the LOBs themselves are stored in a separate LOBs location controlled by the database manager. In this arrangement, the movement of rows between the buffer pool and disk storage will take less time for rows with LOB descriptors than they would if they included the complete LOBs.

However, manipulation of the LOB data then becomes more difficult because the actual LOB is stored in a location separate from the base table rows.

Figure 2. LOB descriptors within the base table row refer to the LOBs within the separate LOBs location
Illustration of how LOB descriptors are used within the base table rows.

To simplify the manipulation of smaller LOBs, you can choose to have LOB data that falls below a size threshold that you specify included inline within the base table rows. These LOB data types can then be manipulated as part of the base table row, which makes operations such as movement to and from the buffer pool simpler. In addition, the inline LOBs would qualify for row compression if row compression was enabled.

The INLINE LENGTH option of the CREATE and ALTER TABLE statements allows LOB data smaller than a length restriction that you specify to be included in the base table row. By default, even if you don't specify an explicit value for INLINE LENGTH, LOBs smaller than the maximum size LOB descriptor for the column are always included in the base table row.

With inline LOBs then, you can have base table rows as shown in Figure 3.

Figure 3. Small LOBs included within base table rows
Illustration of smaller LOBs included inline in the base table row

When you are considering the threshold to choose for including LOBs inline, take into account the current pagesize for your database, and whether inline LOBs will cause the row size to exceed the current page size. The maximum size for a row in a table is 32 677 bytes. However, each inline LOB has 4 bytes of storage overhead. So each LOB you store inline reduces the available storage in the row by 4 bytes. Thus the maximum size for an inline LOB is 32 673 bytes.

Note: In the same way that LOBs can be stored inline, it's also possible to store XML data inline as well.