Kbase P27424: What happens during the Truncation of the Before-Image Log.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/01/2009 |
|
Status: Verified
GOAL:
What happens during the Truncation of the Before-Image Log.
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
Truncating the before-image log consists of going through crash recovery to ensure the database files are consistent and that there are not active transactions, and then discarding the contests of the before-image log. There are several reasons why one might want to do this. Among them are:
1. To avoid having to include the before-image log when doing a full off-line backup copy of a database. In version 7.3 A and later the full back utility does not copy the before-image log to the backup medium. If needed, the backup utility performs a recovery on the database before making the backup copy. The backup copy is automatically made with a truncated before-image log even though the original is not truncated.
2. To enable after-imaging after a full backup. In this case, Progress automatically truncates the before-image log.
3. To change the before-image cluster size of block-size.
4. To reduce the size of a before-image file that has become unusually large. This rarely occurs during normal operation because the log space is reused. Most of the time, the log reaches some stable size and does not grow further. The size is dependent on the frequency and types of transactions executed by the application.
Single file before-image logs:
When the single file bi log is truncated, the database master block is updated to reflect the fact that it has been truncated, the existing bi file is deleted, freeing the space that was allocated for it. Then a new, empty file (zero bytes long) is created.
The next time the database is updated, four clusters will be allocated and formatted, causing the file to be expanded.
Multi-extent before-image logs.
When a multi-extent bi log is truncated, the database master block is updated to reflect this fact and the headers in all fixed length before-image extents are marked. Any previously written data stored in the extents is not removed or zeroed.
Any variable length extent is deleted and a new empty one is created.
The next time the database is updated, four clusters are allocated and formatted from the available before-image extents, using space from fixed-length extents and expanding any variable-length extent if needed.