Oracle and DB2, Comparison and Compatibility/Process Model/Transaction Management

Overview

Transactions as we saw earlier are a logical unit of work that either all works together, or all fails together in such a way that at the end of execution the database is always left in a known good state. The part of the DBMS that implements this functionality is the transaction manager. If all the steps in a transaction execute successfully (including the writing of the transaction to the log files) the transaction is ‘committed’ with the COMMIT TRANSACTION statement. If there is a problem, the operations and data in the database are rolled back to how they were before the transaction started, and this statement is called (appropriately enough) ROLLBACK TRANSACTION. As described earlier, that data needed to roll back a transaction is stored in the undo segments that are held in memory, on (usually) mirrored disks, and optionally in archives. Database consistency is paramount, that is why such care is taken over recording all changes made to the database. This means that even in the event of a cataclysmic failure (i.e. the database server catching fire), it is still possible to recover the data in a consistent way. This is imperative considering that just about every aspect of modern living is represented in some fashion in a relational database – the bills you pay, the salary you are paid, who you owe money to, and who owes you money for example. It’s important for everybody that given the propensity for computer systems to experience hardware and software failures that these vagaries do not bring the economy to a grinding halt.