Skip to content
≡

Administrator

Developer

Tools

External Tools

The Undo Tablespace

The Undo Tablespace#

The undo tablespace is for storing information that is used to cancel update operations. Because Altibase uses Multi-Version Concurrency Control (MVCC), which requires free space to store images of data before update operations.

Only one undo tablespace exists in the database and is shared by all disk tablespaces in the database.

This section describes the features of the undo tablespace and how to manage it, including how to determine its size.

  • Undo Record

  • Features of the Undo Tablespace

  • Transaction Segment Management

  • Reusing Segment Space

  • Modifying the Undo Tablespace

Undo Records#

The database must maintain related information to rollback or undo the results of updated transactions. This information is usually stored as undo records before the transactions are committed.

Undo records are used for the following purposes:

  • Rolling back transactions
  • Recovering the database
  • Guaranteeing read consistency.

When a ROLLBACk statement is executed, undo records are used to undo database changes caused by uncommitted transactions.

Undo records are also used during database recovery. After the database has been restored by re-executing transactions ("REDO") on the basis of log files, undo records are used to cancel changes that were not committed.

Additionally, when a record that is in the process of being changed by a transaction is read by another transaction, even though the transactions access the record simultaneously, read consistency is guaranteed because an image of the record before the change is stored in the undo record.

Features of the Undo Tablespace#

The features of the undo tablespace are as follows:

  • The undo tablespace is automatically managed by the system.
  • The default undo tablespace file is undo001.dbf, which is in auto extension mode. Data files can be added to the undo tablespace, and their sizes can be changed.
  • The undo tablespace can be backed up online.
  • Database objects other than TSS segments and undo segments cannot be created in the undo tablespace.
  • Because the undo tablespace is a system tablespace, it cannot be taken offline or discarded.
  • The undo tablespace is reset whenever the server is restarted.

In Altibase, information about the undo tablespace and the space in the undo tablespace are managed by the system. In other words, the server automatically manages the space and segments in the undo tablespace.

The undo tablespace is created when the database is created. Because it is a system tablespace, only one undo tablespace can exist. If the undo tablespace does not exist, the server will fail to start up, and an error message will be written to the boot log.

In the undo tablespace, transaction segments (TSS segments and undo segments) are managed. The user can change the number of transaction segments using the TRANSACTION_SEGMENT_COUNT property. The numbers of TSS segments and undo segments that are created, respectively, equal the number specified by the user in this property. If the TRANSACTION_SEGMENT_COUNT property is set to 255, 255 TSS segments and 255 undo segments are created every time the server is started up.

If this property is changed to other values to specify a different number of transaction segments, that number of segments will be created the next time the server is restarted.

Transaction Segment Management#

A transaction segment consists of one TSS segment and one undo segment, that is essential for update transactions in disk tablespaces. A transaction segment can't be simultaneously shared by multiple transactions, because one transaction segment is bound to one update transaction, and is not unbound until the disk update transaction has been completed.

The transaction segments that are currently bound can be checked by querying the V$TXSEGS performance view. When a transaction segment is bound to an update transaction that takes place in a disk tablespace, a record indicating the segment ID and the transaction ID is created in V$TXSEGS. When the segment is unbound, the record is deleted.

In addition, space allocated for TSS segments and undo segments can be reused by other transactions after the segments expire. Therefore, when space is required for undo transactions, the undo tablespace does not necessarily need to be expanded by creating segments; instead, segments that have expired can be reused.

TSS segments are allocated for reuse in units of one megabyte (1MB), and undo segments in units of two megabytes (2MB).

The following user properties pertain to undo tablespace:

  • SYS_UNDO_FILE_INIT_SIZE
    The initial size of the undo tablespace data files at the time of creation
  • SYS_UNDO_FILE_MAX_SIZE
    The maximum size of the undo tablespace data files
  • SYS_UNDO_TBS_NEXT_SIZE
    The amount by which the size of the undo tablespace data files is automatically extended
  • SYS_UNDO_TBS_EXTENT_SIZE
    The number of pages in one extent in undo tablespace
  • TRANSACTION_SEGMENT_COUNT
    The number of transaction segments

Reusing Segment Space#

After a transaction has been committed, undo data are needed for rollback or recovery transaction. However, so-called "long-term transactions", meaning transactions that take a long time to commit, require previous versions of records that rely on undo data for read consistency. However, after sufficient time has passed, undo data are not required for the purpose of ensuring read consistency either.

Therefore, Altibase maintains undo records pertaining to committed transactions only as long as necessary, allows other transactions to resue the space occupied by the undo data after that period.

If there are no active transactions accessing the space containing the undo data for transactions that have been committed, the so-called "undo space" is said to have expired. Conversely, if active transactions that might need to access the undo space still exist, space is considered valid, or unexpired. Expired undo space can be reused by other transactions, whereas unexpired space cannot.


[Figure 6-12] Reusing Undo Spaces in an Undo Segment

In the above figure, it shows how the cyclical structure of undo segments allows undo space to be reused

Undo spaces are used sequentially starting with undo space #0, until undo space #5 that is currently being used. Then, if undo space #0, which is the next undo space to be used, is confirmed to have expired, then when all of undo space #5 has been used up, undo space #0 is reused without requiring expansion of the undo segment.


[Figure 6-13] Undo Segment Expansion

However, if undo space #0 has not expired, extents are added to the undo segment, thus creating undo space #6, as can be seen in [Figure 6-13].

This reuse of segment space applies equally to TSS segments.

Modifying the Undo Tablespace#

The undo tablespace can be modified using the ALTER TABLESPACE statement. However, because the undo tablespace is usually managed by the system, only the following operations can be conducted by the user:

  • Adding or dropping data files

  • Increasing or reducing the size of data files

  • Starting or completing the online backup of data files

If the undo tablespace has insufficient space, or in order to prevent errors related to insufficient space, either add data files to the undo tablespace or increase the size of the existing data files.

The following example is an exampole of adding a data file to an undo tablespace:

ALTER TABLESPACE SYS_TBS_DISK_UNDO 
ADD DATAFILE 'undo002.dbf' AUTOEXTEND ON NEXT 1M MAXSIZE 2G;

A data file can be dropped using the ALTER TABLESPACE … DROP DATAFILE statement, and can be increased or decreased in size using the ALTER TABLESPACE ... ALTER DATAFILE… statement.

Additionally, data file backup can be commenced using the ALTER TABLESPACE … BEGIN BACKUP statement, and can be completed using the ALTER TABLESPACE … END BACKUP statement.