Logging

When a database performs logging, smart large objects might result in long transactions for the following reasons:
  • Smart large objects can be very large, even several gigabytes in size.

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

  • Smart large objects might be used in situations where the data collection process can be quite long.

    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. Specifying attribute information 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.
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® 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:
  • The transaction can access the database row that contains an LO handle for the smart large object.

    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.

  • Another transaction does not hold a conflicting lock on the 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.

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.