INFORMIX
DataBlade API Programmer's Manual
Chapter 3: Handling Smart Large Objects
Home Contents Index Master Index New Book

What Is a Smart Large Object?

 A smart large object is a large object with the following features:

    Currently, a single smart large object can hold up to 4 terabytes of data. This data is stored in a separate disk space called an sbspace.

    The database server can log changes to smart large objects and therefore can recover smart-large-object data in the event of a system or hardware failure. Logging of smart large objects is not the default behavior.

    Access to a simple large object (BYTE or TEXT) is on an "all or nothing" basis; that is, the database server returns all of the simple- large-object data that you request at one time. With smart large objects, you can seek to a desired location and read or write the desired number of bytes.

    When you create a smart large object, you can specify storage characteristics for the smart large object such as:

Subsequent sections provide the following information about a smart large object:

Parts of a Smart Large Object

 Each smart large object has two parts:

Suppose you store the picture of an employee as a smart large object. Figure 3-1 shows how the LO handle contains information about the location of the actual employee picture in the sbspace1_100 sbspace.

Figure 3-1
Parts of a Smart Large Object

The following sections describe the sbspace and the LO handle in more detail.

The sbspace

An sbspace is a logical storage area that contains one or more chunks and stores only smart large objects. The sbspace can contain the following parts:

    This information includes:

    The database server writes this information to the metadata area of an sbspace.

    User applications write smart-large-object data to the user data area of an sbspace.

In Figure 3-1, the sbspace1_100 sbspace holds the actual employee image that the LO handle identifies. For more information about the structure of an sbspace, see the chapter on disk structures and storage in the INFORMIX-Universal Server Administrator's Guide.

The onspaces database utility creates and drops sbspaces for the database server. For more information about the onspaces utility, see the chapter on utilities in the INFORMIX-Universal Server Administrator's Guide.

Important: You can only store smart large objects in sbspaces. You cannot store them in dbspaces. You must create an sbspace before you attempt to insert smart large objects into the database.

The LO Handle

An LO handle is an opaque data structure that identifies the location of the smart-large-object data in its sbspace. Because a smart large object is potentially very large, the database server stores only its LO handle in a database table; it can then use this LO handle to locate the actual data of the smart large object in the sbspace. This arrangement minimizes the table size.

Applications obtain the LO handle from the database and use it to locate the smart-large-object data and to open the smart large object for read and write operations. In Figure 3-1, the LO handle identifies the location of the actual employee image in the sbspace1_100 sbspace. You can store this LO handle in a database column to save this reference for future use. For more information, see "Access to a Smart Large Object".

Information About a Smart Large Object

The database server keeps the following information about a smart large object:

The database server stores this information in a metadata area of the sbspace for the smart large object.

Storage Characteristics

The storage characteristics tell the database server how to manage a smart large object in an sbspace. The following two groups of information make up the storage characteristics for a smart large object:

You can specify storage characteristics at three points.
When Specified Method of Specification

When sbspace is created

Options of onspaces utility

When database table is created

Keywords in PUT clause of CREATE TABLE statement

When smart large object is created

DataBlade API functions

For more information, see "Choosing Storage Characteristics". The following sections describe the two groups of storage characteristics.

Disk-Storage Information
Disk-storage information helps the smart-large-object optimizer of Universal Server determine how to manage the smart large object most efficiently on disk. It is the smart-large-object optimizer that manages the allocation of and access to smart large objects in an sbspace.

Disk-storage information includes the following types of information:

      An allocation extent is a collection of contiguous bytes within an sbspace that the smart-large-object optimizer allocates to a smart large object at one time. The smart-large-object optimizer performs storage allocations for smart large objects in increments of the extent size.

      The smart-large-object optimizer tries to allocate an extent as a single, contiguous region in a chunk. However, if no single extent is large enough, the smart-large-object optimizer must use multiple extents as necessary to satisfy the current write request. After the initial extent fills, the smart-large-object optimizer attempts to allocate another extent of contiguous disk space. This process is called next-extent allocation.

    The name of the sbspace identifies the location at which to store the smart large object.

The smart-large-object optimizer uses the disk-storage information to determine how best to size, allocate, and manage the extents of the sbspace. It can calculate all disk-storage information for a smart large object except the sbspace name.

Important: For most applications, Informix recommends that you use the values that the smart-large-object optimizer calculates for the disk-storage information. For more information, see "Obtaining Storage Characteristics".

For more information on how to specify disk-storage information, see "Using the Storage-Characteristics Hierarchy".

Attribute Information
Attribute information tells Universal Server what options, or attributes, to assign to the smart large object. Attributes provide the following information:

For information on how to specify attribute information, see "Using the Storage-Characteristics Hierarchy". The following sections provide more information about the different smart-large-object attributes.

Logging

When a database performs logging, smart large objects might result in long transactions for the following reasons:

    The amount of log storage needed to log user data can easily overflow the log.

    For example, if a smart large object holds low-quality audio recording, the amount of data collection might be modest but the recording session might be quite long.

A simple workaround is to divide a long transaction into multiple smaller transactions. However, if this solution is not acceptable, you can control when the database server performs logging of smart large objects. (Figure 3-10 shows how you can control the logging behavior for a smart large object.)

When logging is enabled, the database server logs changes to the user data of a smart large object. It performs this logging in accordance with the current database log mode. For a database that is not ANSI compliant, the database server does not guarantee that log records that pertain to smart large objects are flushed at transaction commit. However, the metadata is always restorable to an action-consistent state; that is, to a state that ensures no structural inconsistencies exist in the metadata (control information of the smart large object, such as reference counts).

ANSI
An ANSI-compliant database uses unbuffered logging. When smart-large-object logging is enabled, all log records (metadata and user data) that pertain to smart large objects are flushed to the log at transaction commit. However, user data is not guaranteed to be flushed to its stable storage location at commit time.

When logging is disabled, the database server does not log changes to user data even if the database server logs other database changes. However, the database server always logs changes to the metadata. Therefore, the database server can still restore the metadata to an action-consistent state.

Important: Consider carefully whether to enable logging for a smart large object. The database server incurs considerable overhead to log smart large objects. You must also ensure that the system log file is large enough to hold the value of the smart large object. The logical log size must exceed the total amount of data that the database server logs while the update transaction is active.

Write your DataBlade routines so that any transactions with smart large objects that have potentially long updates do not cause other transactions to wait. Multiple transactions can access the same smart-large-object instance if the following conditions are satisfied:

    Multiple references can exist on the same smart large object if more than one column holds an LO handle for the same smart large object.

The best update performance and fewest logical log problems result when you disable the logging feature when you load a smart large object and re-enable it after the load operation completes. If logging is turned on, you might want to turn logging off before a bulk load and then perform a level-0 backup.

Last-Access Time

The last-access time of a smart large object is the system time at which the database server last read or wrote the smart large object. The last-access time records access to the user data and metadata of a smart large object. This system time is stored as number of seconds since January 1, 1970. The database server stores this last-access time in the metadata area of the sbspace.

Tip: The database server automatically tracks the last-change and last-modification time for a smart large object in the status information. For more information, see "Status Information".

By default, the database server does not save the last access time. Figure 3-10 shows how you can control the last-access time for a smart large object.

Important: Consider carefully whether to use track last-access time for a smart large object. The database server incurs considerable overhead in logging and concurrency to maintain last-access times for smart large objects.

Status Information

Figure 3-2 shows the status information that the database server maintains for a smart large object.

Figure 3-2
Status Information for a Smart Large Object

(1 of 2)

Status Information Description

Last-access time

The time, in seconds, that the smart large object was last accessed

This value is available only if the last-access time attribute is enabled for the smart large object.

Storage characteristics

The storage characteristics for the smart large object

Last-change time

The time, in seconds, of the last change in status for the smart large object

A change in status includes changes to metadata and user data (data updates and changes to the number of references). This system time is stored as number of seconds since January 1, 1970.

Last-modification time

The time, in seconds, that the smart large object was last modified

A modification includes only changes to user data (data updates). This system time is stored as number of seconds since January 1, 1970.

Reference count

The number of references (LO handles) to the smart large object

Size

The size, in bytes, of the smart large object

The database server stores the status information in the metadata area of the sbspace.

Tip: The time values (such as last-access time and last-change time) might differ slightly from the system time. This difference is due to the algorithm that the database server uses to obtain the time from the operating system.

For more information on how to obtain status information in a DataBlade routine, see "Obtaining the Status of a Smart Large Object".



DataBlade API Programmer's Manual, version 9.1
Copyright © 1998, Informix Software, Inc. All rights reserved.