Earlier versions of Adaptive Server flushed the data pages and single log records (SLRs) because crash recovery was not supported for tempdb or any databases not requiring recovery.
SLRs are log records that force a flush of the user log cache (ULC) to syslogs immediately after the record is logged. SLRs are created for OAM modifications, and Adaptive Server creates log records affecting allocation pages in a mixed log and data database as SLRs.
For regular databases, a ULC containing SLRs is flushed immediately to avoid any undetected deadlocks caused during buffer “pinning”. Avoiding a ULC flush for SLRs reduces log semaphore contention, improving the performance.
A ULC flush avoids the deadlock caused by buffer pinning. Because Adaptive Server does not pin the buffers for databases that do not need recovery, it avoids this deadlock and does not have to flush the ULC for SLRs.
For databases that require recovery, Adaptive Server flushes dirty pages to disk during the checkpoint. This ensures that, if Adaptive Server crashes, all the committed data is saved to disk. However, for databases which do not require recovery, Adaptive Server supports a runtime rollback, but not a crash recovery. This allows it to avoid flushing dirty data pages at a checkpoint and improves performance.
Adaptive Server does not support write ahead logging on databases that do not require recovery. Write-ahead logging guarantees that data for committed transactions can be recovered by “redoing” the log (reperforming the transactions listed in the log), and “undoing” the changes done by aborted or rolled back transactions to maintain database consistency. Write-ahead logging is implemented by the “buffer pinning” mechanism. Since Adaptive Server does not ensure write-ahead logging on databases not needing recovery, it does not pin buffers for these databases, so it can skip flushing the log when it commits a transaction.