Differential files are good when the transactions are all of a similar run length, but with long-term transactions the management implications of using this approach makes other options much more attractive. As each change to the disk could mean a new disk block is copied, long-term transactions could result in a huge amount of the disk being taken up by disk block copies. This is not a memory efficient approach to such transactions. The changes made in a running transaction have to be stored in memory until the transaction either aborts or commits. For a long-running transaction, this could mean you run out of main memory before it completes, and it certainly stops transactions from being able to run over multiple login sessions (where you could be switching off your computer between sessions). Making immediate updates to the database before the COMMIT means that changes are stored efficiently on the disk while the transaction is still running. This has the benefit of making all the changes persistent over reboots, and keeping the transaction's RAM memory usage to a minimum. R1 Which one of the following algorithms is best suited for long-lived transactions with relatively few roll-backs?
|
|