Adaptive Server does not recover temporary databases when you shut it down or it fails, but Adaptive Server does create the temporary databases when you restart the server. Because temporary databases do not require recovery, Adaptive Server optimizes the logging mechanism for temporary databases to improve performance by:
Single log records – force Adaptive Server to flush syslogs to disk immediately after Adaptive Server logs the record. Adaptive Server creates single log records while modifying OAM pages or allocation pages (in a database that is configured to use mixed log and data on the same device). Adaptive Server must flush syslogs to avoid undetected deadlocks created during buffer pinning. Because Adaptive Server does not pin buffers for temporary databases, it need not flush the syslogs data for the temporary database when it writes an single log records, which reduces log semaphore contention.
Flushing dirty pages to disk – for databases that require recovery, Adaptive Server flushes dirty pages to disk during the checkpoint, ensuring that, if Adaptive Server fails, all committed data is saved to disk. For temporary databases, Adaptive Server supports runtime rollbacks, but not failure recovery, allowing it to avoid flushing dirty data pages at the checkpoint.
Avoiding write-ahead logging – write-ahead logging guarantees that Adaptive Server can recover data for committed transactions by reissuing the transactions listed in the log, and undoing the changes performed by aborted or rolled back transactions. Adaptive Server does not support write-ahead logging on databases that do not require recovery. Because Adaptive Server does not recover temporary database, buffers for temporary databases are not pinned, which allows Adaptive Server to skip flushing the temporary database log when it commits a transaction using a temporary database.
