In this lesson, we will look at the syntax and an example of creating a database object or an object table with LOB as its data type. Let us first review the characteristics of the LOB data type:
A LOB data type can be stored in three ways: inline, out of line, and externally. Storing LOB inline means storing it within
the same location as its table. Storing LOB out of line means storing it within a separate tablespace and storing its location within the table. LOB can be stored externally by using the BFILE data type.
More than one column can be defined as a LOB data type within a table.
Each LOB column can be of a different LOB data type.
Partitioning of table data with one or more LOB columns is possible.
The LOB data type supports random access of data.
SQL statements define the LOB columns within a table and the LOB attributes within a user-defined object type. When defining the LOBs
within a table, you can explicitly specify the tablespace and storage characteristics for each LOB.
LOB storage clause
Because LOB data can be separated from the table data by using a locator, you must specify the storage parameters of the LOB column when creating a table. The locator is a pointer to the actual data, which can be stored within a different tablespace with different storage
parameters than the table.
The storage for LOB data can be specified within the CREATE TABLE statement using the LOB
storage clause. This clause can specify the storage parameters, the name of the tablespace, the number of bytes allocated for LOB manipulation, and the maximum percentage of overall LOB storage space used for creating new versions of the LOB.
Let us review the different parameters of the LOB storage clause.
The syntax for this clause is:
LOB (LOB item name) store as {TABLESPACE
<tablespace_name>}
{ENABLE / DISABLE STORAGE IN ROW}
{CHUNK <chunk_size in bytes>}
{PCTVERSION <value>}
{CACHE / NOCACHE LOGGING/NOLOGGING}
{storage parameters}
TABLESPACE
This parameter specifies the tablespace for an internal LOB column. If a tablespace is not specified, the LOB will be stored within the same tablespace as its associated table. Specifying the tablespace avoids troublesome space management issues and can reduce device contention during DML and SQL statements.
CACHE/NOCACHE
This stipulates whether LOB data will be parsed through the database buffer cache. This should be set to NOCACHE, unless the LOB
data will be used frequently and the LOB data size is inconsequential with respect to the database buffer cache. If it is set to
CACHE, any changes to the LOB value will also be passed to the redo log buffer and redo logs.
The default value is NOCACHE.
LOGGING/NOLOGGING
This specifies if changes to the data will be passed to the redo log buffer. For bulk loading of the data, set this value to NOLOGGING. The default value is NOLOGGING.
CHUNK
This is an integer specifying the number of bytes used for manipulation of the LOB. This value should be in multiples of DB block size.
PCTVERSION
When a LOB is modified, a new version of the LOB page is made to support consistent read of the prior versions of the LOB value. PCTVERSION is the percentage of all used LOB data space that can be occupied by old versions of LOB data pages. As soon as the old versions of LOB data pages begin to occupy more than the PCTVERSION amount of used LOB space, Oracle will try to reclaim the old versions and reuse them. In other words, PCTVERSION is the percentage of used LOB data blocks available for versioning the old LOB data.
Storage parameters to be specified are similar to the ones specified for a table, index, cluster, rollback segment, or tablespace, which
include details like INITIAL EXTENT, NEXT EXTENT, MINEXTENTS, MAXEXTENTS, PCTINCREASE, OPTIMAL value, and BUFFER POOL size.
Examples of LOB columns
Let us review some examples of object tables with LOB as a column data type. An object table is based on an object, and that object can have LOB as a data type for one of its attributes. Let us create an object with a LOB data
type:
CREATE OR REPLACE TYPE CUSTOMER_PHOTO_OBJ_TYPE AS OBJECT
(
CUSTOMER_ID NUMBER (10),
CUSTOMER_PHOTO BLOB,
CREATED_DATE DATE
);
In this object type, the CUSTOMER_PHOTO attribute is based on BLOB. Now lets create a table based on this object
type:
CREATE TABLE CUSTOMER_PHOTO_OBJ_TABLE OF
CUSTOMER_PHOTO_OBJ_TYPE
(CONSTRAINT CUSTOMER_PHOTO_OBJ_PK
PRIMARY KEY (CUSTOMER_ID));
Now let us look at creating the CUSTOMER_PHOTO_OBJ_TABLE object table without specifying an object type:
CREATE TABLE CUSTOMER_PHOTO_OBJ_TABLE
(
CUSTOMER_ID NUMBER (10),
CUSTOMER_PHOTO BLOB,
CREATED_DATE DATE
)
LOB (CUSTOMER_PHOTO) STORE AS
(CHUNK 4096
PCTVERSION 5
NOCACHE LOGGING
STORAGE (MAXEXTENTS 5)
);
For this table, we have defined the storage parameters for the column with the LOB data type.
Now let us look at an example of creating a table based on the BFILE LOB data type:
CREATE TABLE CUSTOMER_PHOTO_OBJ_TABLE
(
CUSTOMER_ID NUMBER (10),
CUSTOMER_PHOTO BFILE,
CREATED_DATE DATE
)
Now that we have looked at some examples, lets review the syntax and an example of updating records within object tables in the
MouseOvers below:
Updating Object Tables
The following diagram provides an example of creating an object table with the LOB data type:
In the next lesson, we will describe the components of the DBMS_LOB package.
Oracle PL/SQL