PDF of this tutorialTo understand safeness levels, you have to understand a little bit about how a relational database management system (RDBMS) works.
Changes to data in an RDBMS are collected by the application into "transactions." A transaction is a group of one or more data changes that must either complete entirely, or not take place at all. The classical example of a transaction is a transfer of funds from a checking account to a savings account. For proper operations, one of two cases must be true: either the debit from checking and the credit to savings both take place, or neither takes place.
An RDBMS stores rows of tabular data in pages that have quite a complex structure and may be 2K - 32K bytes in size. A page typically contains a number of data rows, but the whole page must be rewritten to modify any row on it. If the RDBMS were to write every data change back to disk, this would involve writing the entire page, not just the changed row, even if only one byte were changed in one row.
To improve database speed, instead of writing data pages back to disk, the RDBMS records the changes in the form of a compact "log" record that is always written to disk before the transaction commits. The data pages remain in the RDBMS data cache until they are flushed by its cache manager. This means that if the RDBMS terminates unexpectedly, some data pages may not have been flushed to disk, but all of the transaction logs will have been flushed to disk.
By combining the data pages on disk and the log records on disk, the RDBMS can reconstruct the consistent state of the database at the moment of failure, with all committed transactions properly represented in the database, and the effects of any uncommitted, partial transactions completely undone. An RDBMS performs this task automatically every time it starts up.
In the case of a hot-standby pair of database, this means that before a standby RDBMS can become active, it must ensure that all transactions that it knows were committed at the active database are properly represented in the database, and all others are completely undone. This ensures data consistency.
Since the log records provide the DBMS with a compact way of representing transactional data changes, it is natural and efficient to move data changes between the active and standby databases by copying the log records. The standby RDBMS is effectively constantly running recovery, using the copied log records to apply the transactions from the active database to the standby copy.
