Understanding the user log cache (ULC) architecture

The Adaptive Server logging architecture features the user log cache, or ULC, by which each task owns its own log cache. No other task can write to this cache, and the task continues writing to the user log cache whenever a transaction generates a log record. When the transaction commits or aborts, or the user log cache is full, the user log cache is flushed to the common log cache, shared by all the current tasks, which is then written to the disk.

Flushing the ULC is the first part of a commit or abort operation. It requires the following steps, each of which can cause delay or increase contention:

  1. Obtain a lock on the last log page.

  2. Allocate new log pages if necessary.

  3. Copy the log records from the ULC to the log cache.

    The processes in steps 2 and 3 require you to hold a lock on the last log page, which prevents any other tasks from writing to the log cache or performing commit or abort operations.

  4. Flush the log cache to disk.

    Step 4 requires repeated scanning of the log cache to issue write commands on dirty buffers.

    Repeated scanning can cause contention on the buffer cache spinlock to which the log is bound. Under a large transaction load, contention on this spinlock can be significant.