Storage Characteristics of Sbspaces

As the database server administrator, you can use the system default values for these storage characteristics, or you can specify them in the -Df tags when you create the sbspace with onspaces -c. Later on, you can change these sbspace characteristics with the onspaces -ch option. The administrator or programmer can override these default values for storage characteristics and attributes for individual tables.

Extent Sizes for Sbspaces

Similar to extents in a table, an extent in an sbspace consists of a collection of contiguous pages that store smart large object data.

The unit of allocation in an sbspace is an extent. The database server calculates the extent size for a smart large object from a set of heuristics, such as the number of bytes in a write operation. For example, if an operation asks to write 30 kilobytes, the database server tries to allocate an extent the size of 30 kilobytes.

For most applications, you should use the values that the database server calculates for the extent size.

If you know the size of the smart large object, you can use one of the following functions to set the extent size. The database server allocates the entire smart large object as one extent (if an extent of that size is available in the chunk):

For information about tuning extent sizes, see smart large objects in the chapter on configuration effects on I/O utilization in your IBM Informix Dynamic Server Performance Guide.

Average Smart-Large-Object Size

Smart large objects usually vary in length. You can provide an average size of your smart large objects to calculate space for an sbspace. You specify this average size with the AVG_LO_SIZE tag of the onspaces -c -Df option.

To specify the size and location of the metadata area, specify the -Ms and -Mo flags in the onspaces command. If you do not use the -Ms flag, the database server uses the value of AVG_LO_SIZE to estimate the amount of space to allocate for the metadata area. For more information, refer to Sizing Sbspace Metadata.

Buffering Mode

When you create an sbspace, the default buffering mode is on, which means to use the buffer pool in the resident portion of shared memory.

As the database administrator, you can specify the buffering mode with the BUFFERING tag of the onspaces -c -Df option. The default is "buffering=ON", which means to use the buffer pool. If you turn off buffering, the database server uses private buffers in the virtual portion of shared memory.

In general, if read and write operations to the smart large objects are less than 8 kilobytes, do not specify a buffering mode when you create the sbspace. If you are reading or writing short blocks of data, such as 2 kilobytes or 4 kilobytes, leave the default of "buffering=ON" to obtain better performance.

For information about when to use private buffers, see the section on light-weight I/O operations in the chapter on configuration effects on I/O utilization in your IBM Informix Dynamic Server Performance Guide.

Last-Access Time

When you create an sbspace, you can specify whether or not the database server should keep the last time that the smart large object was read or updated with the ACCESSTIME tag of the onspaces -c -Df option. The default is "ACCESSTIME=OFF". The database server keeps this last-access time in the metadata area.

For more information on how programmers use this last-access time, refer to the IBM Informix DataBlade API Programmer's Guide and IBM Informix ESQL/C Programmer's Manual.

Lock Mode

When you create an sbspace, you can specify whether or not the database server should lock the whole smart large object or a range of bytes within a smart large object with the LOCK_MODE tag of the onspaces -c -Df option. The default is "LOCK_MODE=BLOB", which means to lock the entire smart large object. For more information, refer to the locking chapter in your IBM Informix Dynamic Server Performance Guide.

Logging

When you create an sbspace, you can specify whether or not to turn on logging for the smart large objects. The default is no logging. For more information, refer to Logging Sbspaces and Smart Large Objects.

When you use logging databases, turn logging on for the sbspaces. If a failure occurs that requires log recovery, you can keep the smart large objects consistent with the rest of the database.

You specify the logging status with the LOGGING tag of the onspaces -c -Df option. The default is "LOGGING=off". You can change the logging status with the onspaces -ch -Df option. You can override this logging status with the PUT clause in the SQL statements CREATE TABLE or ALTER TABLE. For more information about these SQL statements, refer to the IBM Informix Guide to SQL: Syntax.

The programmer can override this logging status with functions that the DataBlade API and ESQL/C provide. For more information on the DataBlade API functions for smart large objects, refer to the IBM Informix DataBlade API Function Reference. For more information on the ESQL/C functions for smart large objects, refer to the IBM Informix ESQL/C Programmer's Manual.

When you turn on logging for an sbspace, the smart large objects pass through the resident portion of shared memory. Although applications can retrieve pieces of a smart large object, you still need to consider the larger size of data that might pass through the buffer pool and logical-log buffers. For more information, refer to Accessing Smart Large Objects.