A database transaction is a logical unit of work that comprises one or more SQL statements. A transaction begins with the first execution of an SQL statement by a user, and ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.
To maintain database integrity, a properly executed transaction must exhibit the four ACID properties: Atomicity, Consistency, Isolation, and Durability.
• Atomicity - Either all of the statements that constitute a transaction are completely executed, or none of them are. That is, the transaction cannot be partially successful.
• Consistency - A properly executed transaction does not break the consistency of the database.
• Isolation - When multiple transactions are underway at the same time, none of the transactions have access to the results of the other transactions.
• Durability - Once a transaction has been committed, the resultant changes are not lost regardless of the circumstances, such as system failure.
ALTIBASE HDB guarantees reliable transactional processing by implementing a database server that satisfies all ACID requirements.
Durability means that after a transaction has been committed, the committed transaction must be guaranteed, even if a database failure occurs before the changed data are physically written to a disk.
ALTIBASE HDB provides durability with a combination of checkpointing and transaction logging.
ALTIBASE HDB adheres to WAL (write-ahead logging) protocol. Based on WAL protocol, before overwriting an object with "uncommitted" updates, ALTIBASE HDB writes the log records related to such updates to disk storage for UNDO operations. And similarly , before committing an update to a database object, it writes the log records related to such an update to the log on disk storage for REDO operations.
Durability & Performance
In ALTIBASE HDB transaction durability has a significant influence on the processing performance. Especially on the memory-based side of the database which can potentially exhibit performance up to 20 times faster than the disk-based side of the database, guaranteeing transaction durability has a much bigger impact on performance. This is due the fact that based on the WAL protocol, in order for a ALTIBASE HDB to provide complete transaction durability, it has to write logs for all database updates to a log file on disk therefore introducing additional disk I/O activity which can degrade the performance.
Users need to consider a trade-off between complete transaction durability and transaction processing performance. ALTIBASE HDB provides multiple levels of durability controls, from most relaxed to most strict, to enable users to have a balance between durability and performance. Each of these levels in ALTIBASE HDB guarantees durability to a different extent and realizes different performance characteristics. Relaxed durability yields the best performance; where as strict durability eliminates loss of transactions.
Relaxed durability: On system or database crash, recovery point is the last checkpoint.
Enhanced durability: On database crash no data loss, recovery point is the last point where OS syncs kernel buffer to disk.
Strict durability: No data loss with system or database crash, each transaction committed only when written to disk.
In addition to these durability levels listed above, with ALTIBASE HDB, users have the option to use Volatile tablespaces which omit logging process completely.
Managing Durability Levels
ALTIBASE HDB provides users with two properties to manage durability level settings. Those properties are: COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE.
COMMIT_WRITE_WAIT_MODE specifies whether a transaction waits until an update log has been written to a log file on disk. This property can be specified for the entire system or for individual sessions.
LOG_BUFFER_TYPE specifies the type of log buffer that is used when update logs are written to a log file. This property can't be changed while the system is running.