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.
The storage characteristics tell the database server how to manage a smart large object in an sbspace. Three 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 an sbspace is created | Options of onspaces utility |
| When a database table is created | Keywords in PUT clause of CREATE TABLE statement |
| When a smart large object is created | DataBlade API functions |
The following sections describe the three groups of storage characteristics. For additional information, see Choosing Storage Characteristics.
Disk-storage information helps the smart-large-object optimizer of the database server determine how to manage the smart large object most efficiently on disk. The smart-large-object optimizer manages the allocation of and access to smart large objects in an sbspace.
Each smart-large-object has the following disk-storage information:
An allocation extent is a collection of contiguous bytes within an sbspace that the smart-large-object optimizer allocates to the smart large object at one time. Information about allocation extents is as follows:
The smart-large-object optimizer allocates storage for the smart large object in the amount of the extent size.
The smart-large-object optimizer attempts to allocate an extent as a single, contiguous region in a chunk. If no single extent is large enough for the smart large object, the optimizer uses 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.
For more information on extents, see the chapter on disk structure and storage in the IBM Informix: Administrator's Reference.
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.
For special situations, you can set disk-storage information for a smart large object as part of its storage characteristics. For more information, see Choosing Storage Characteristics.
Attribute information tells the database server what options, or attributes, to assign to the smart large object:
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. If this solution is not acceptable, you can control when the database server performs logging of smart large objects. Table 32 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).
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.
Write your DataBlade API modules 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.
For more information on smart-large-object locks, see Locking Modes.
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.
By default, the database server does not log the user data of a smart large object. You can control the logging behavior for a smart large object as part of its storage characteristics. For more information, see Choosing Storage Characteristics.
The last-access time of a smart large object is the system time at which the database server last read or wrote to the smart large object. The last-access time records access to the user data and metadata of a smart large object. The database server stores this system time as number of seconds since January 1, 1970, in the metadata area of the sbspace.
By default, the database server does not save the last access time. You can choose to track the last-access time for a smart large object as part of its storage characteristics. For more information, see Choosing Storage Characteristics.
The structure of an sbpage in the sbspace determines how much data integrity the database server can provide. An sbpage is the unit of allocation for smart-large-object data, which is stored in the user-data area of an sbspace. The database server supports the following levels of data integrity:
The database server uses the page header and trailer to detect incomplete writes and data corruption. Moderate integrity provides the following benefits:
Moderate integrity might be useful for smart large objects that contain large amounts of audio or video data that is moved through the database server and that does not require a high data integrity. By default, the database server uses high integrity (page headers and page trailers) for sbspace pages. You can control the data integrity for a smart large object as part of its storage characteristics. For more information, see Choosing Storage Characteristics.
For information on the structure of sbspace pages, see your IBM Informix: Administrator's Guide.
When you open a smart large object, you can specify the open mode for the data. The open mode describes the context in which the I/O operations on the smart large object are performed. It includes the following information:
The database server uses the following system default open mode when it opens a smart large object.
If your smart large object usually requires certain access capabilities when it is opened, you can associate a default open mode with the smart large object. The database server stores this default open mode with other storage characteristics of the smart large object. For more information, see Choosing Storage Characteristics. To override the default open mode, you can specify an open mode for a particular smart large object when you open it. For more information, see Opening a Smart Large Object.
The smart-large-object open mode includes an access mode, which determines which read and write operations are valid on the open smart large object. Table 23 shows the access modes for a smart large object.
| Access Mode | Purpose |
|---|---|
| Read-only mode | Only read operations are valid on the data. |
| Dirty-read mode | You can read uncommitted data pages for the smart large object. No locks are requested on the data. You cannot write to a smart large object after you set the mode to MI_LO_DIRTY_READ. When you set this flag, you reset the current transaction isolation mode to dirty read for this smart large object. |
| Write-only mode | Only write operations are valid on the data. |
| Write/append mode | Any data you write is appended to the end of
the smart large object. By itself, it is equivalent to write-only
mode followed by a seek to the end of the smart large object. Read
operations fail.
When you open a smart large object in write/append mode only, the smart large object is opened in write-only mode. Seek operations move the seek position, but read operations to the smart large object fail, and the LO seek position remains unchanged from its position just before the write. Write operations occur at the LO seek position, and then the seek position is moved. |
| Read/write mode | Both read and write operations are valid on the data. |
| Truncate | Delete any existing data in the smart large object and move the LO seek position to the start of the smart large object (byte 0). If the smart large object does not contain data, this access mode has no effect. |
The smart-large-object open mode includes the access method, which determines whether to access the smart-large-object data sequentially or with random access. Table 24 shows the access methods for a smart large object.
| Method of Access | Purpose | |
|---|---|---|
| Random access | Indicates that I/O is random
When you plan to read in nonsequential locations in the smart large object, the smart-large-object optimizer should not read ahead a few pages. |
|
| Sequential access | Indicates that reads are sequential
in either forward or reverse direction
When you read a smart large object sequentially, the smart-large-object optimizer can read ahead a few pages. |
|
| Forward | Indicates that the direction of sequential access
is forward
If you do not specify a direction, the default is forward. |
|
| Reverse | Indicates that the direction of sequential access is reverse | |
The default access method is random, although the smart-large-object optimizer might change this default based on a particular read pattern.
The smart-large-object open mode includes a buffering mode, which determines how read and write operations on the open smart large object are buffered. Table 25 shows the buffering modes for a smart large object.
Keep the following issues in mind when you use lightweight I/O:
Otherwise, the memory that has been allocated to the private buffers remains allocated. This private-buffer memory is only deallocated when you close the smart large object.
All opens of the same smart large object share the same lightweight I/O buffers. Potentially, an operation can cause the pages in the buffer to be flushed while other operations might still expect these pages to exist.
The smart-large-object optimizer imposes the following restrictions when you switch from lightweight I/O to buffered I/O for a given smart large object:
However, you cannot alter the buffering mode from buffered I/O to one with lightweight I/O.
If an open smart large object specifies buffered I/O, the smart-large-object optimizer ignores any attempt to open it with lightweight I/O. However, if you first change the buffering mode from lightweight I/O to buffered I/O, you can then specify buffered I/O when you open the smart large object.
In this case, the smart-large-object optimizer does not allow write operations on the smart large object. Attempts to do so generate an error. To write to the smart large object, you must close it then reopen it with buffered I/O and an access mode that enables write operations.
These limitations ensure consistency of the smart-large-object buffers without imposing processing overhead for I/O operations.
If you do not specify a buffering mode, the default is buffered I/O. The smart-large-object optimizer determines the default buffering mode for a smart large object.
To prevent simultaneous access to smart-large-object data, the smart-large-object optimizer obtains a lock on this data when you open the smart large object. This smart-large-object lock is distinct from the following kinds of locks:
A lock on a smart large object does not lock the row in which the smart large object resides. However, if you retrieve a smart large object from a row and the row is still current, the database server might hold a row lock as well as a smart-large-object lock. Locks are held on the smart large object instead of on the row because many columns could be accessing the same smart-large-object data.
A lock on one smart large object does not affect other smart large objects in the row.
The smart-large-object open mode includes a lock mode, which determines the kind of the lock requests made on a smart large object. Table 26 shows the lock modes that a smart large object can support.
| Lock Mode | Purpose | Description |
|---|---|---|
| Lock-all | Lock the entire smart large object | Indicates that lock requests apply to all data for the smart large object |
| Byte-range | Lock only specified portions of the smart large object | Indicates that lock requests apply only to the specified number of bytes of smart-large-object data |
When the smart-large-object optimizer opens a smart large object, it uses the following information to determine the lock mode of the smart large object:
The database server obtains a lock as follows:
When a write operation (or some other update) is actually performed on the smart large object, the database server upgrades this lock to an exclusive lock.
If you have selected an isolation mode of repeatable read, the smart-large-object optimizer does not release any locks that it obtains on a smart large object until the end of the transaction.
By default, the smart-large-object optimizer chooses the lock-all lock mode. You can request locks on the data of a smart large object at the byte level with a byte-range lock. For more information, see Accessing the Default Open Flag.
The smart-large-object optimizer retains the lock as follows:
When one of the preceding conditions occurs, the smart-large-object optimizer releases the lock on the smart large object.
The smart-large-object optimizer releases the lock when the current transaction terminates. However, the optimizer obtains the lock again when the next function that needs a lock executes. If this behavior is undesirable, use BEGIN WORK transaction blocks and place a COMMIT WORK or ROLLBACK WORK statement after the last statement that needs to use the lock.
Table 27 shows the status information that the database server maintains for a smart large object.
The database server stores the status information in the metadata area of the sbspace.
For more information on how to obtain status information in a DataBlade API module, see Obtaining Status Information for a Smart Large Object.
Enterprise Edition Home | Express Edition Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]