Running Out of Log Space
[Transactions, Locking and Logging]

Collaboration diagram for Running Out of Log Space:

---

Detailed Description

Updates performed by transactions are logged so that the can be rolled back (in the event of a transaction abort) or restored (in the event of a crash). Both the old and new values of an updated location are logged. This allows a steal, no-force buffer management policy, which means the buffer manager is free to write dirty pages to disk at any time and yet does not have to write dirty pages for a a transaction to commit.

The log is stored in a set of Unix files, all in the same directory, whose path is determined by a run-time option. The maximum size of the log is also determined by a run-time option.o The proper value of the log size depends on the expected transaction mix. More specifically, it depends on the age of the oldest (longest running) transaction in the system and the amount of log space used by all active transactions. Here are some general rules to determine the amount of free log space available in the system.

• Log records between the first log record generated by the oldest active transaction and the most recent log record generated by any transaction cannot be thrown away.
• Log records from a transaction are no longer needed once the transaction has committed or completely aborted and all updates have made it to disk. Aborting a transaction causes log space to be used, so space is reserved for aborting each transaction. Enough log space must be available to commit or abort all active transactions at all times.

• Only space starting at the beginning of the log can be reused. This space can be reused if it contains log records only for transactions meeting the previous rule.

• All storage manager calls that update records require log space twice the size of the space updated in the record. All calls that create, append, or truncate records require log space equal to the size created, inserted, or deleted. Log records generated by these calls (generally one per call) have an overhead of approximately 50 bytes.

• The amount of log space reserved for aborting a transaction is equal to the amount of log space generated by the transaction plus a fudge factor. (Where btrees are concerned, a structure modification might be necessary on abort, using more space on abort, or might not be necessary on abort where it was done during forward processing, using less space on abort.)

• The transaction assumes responsiblity for reserving space in the log so that it can abort, should it need to (without leaving an unrecoverable volume). The transaction and the log cooperate to reserve space for the transaction's aborting.

• When insufficient log space is available for a transaction, the transaction is (may be, depending on the server) aborted. The storage manager will return an error indication (out of log space) if it is unable to insert a log record into the log due to insufficient space.

Bug:

GNATS 142 There remain a number of places in the storage manager code that react to a lack of log space with a fatal error; this is a hold-over from the original storage manager, before any attempt to reserve space was in place. This code has to be rewritten to handle more gracefully such errors. In order for this to be done, the multi-threaded transaction support will be deprecated.

Checkpoints are taken periodically by the storage manager in order to free log space and shorten recovery time. Checkpoints are "fuzzy" and can do not require the system to pause while they are completing.

See the storage manager constructor ss_m::ss_m for more information about handling out-of-logspace conditions.

Classes
class	xct_t
	A transaction. Internal to the storage manager. This class may be used in a limited way for the handling of out-of-log-space conditions. See Running Out of Log Space. More...

---