Kbase P24378: Integrity of a standby database updated from AI files
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/12/2005 |
|
Status: Verified
GOAL:
How is the integrity of a standby database assured when updated by AI files
GOAL:
Will After Imaging reliably replicate the live database?
GOAL:
What checking is done on the After-Image (AI) notes before they are rolled forward onto a standby database
GOAL:
After imaging reliability and the integrity of the hotspare database updated through after-imaging
GOAL:
What checks does that AI roll forward mechanism do?
GOAL:
What are the internal AI mechanisms?
FIX:
After imaging (AI) works 100% with a normal healthy Progress database. If for example, there are unseen corruption (code) in a database, it is possible that unseen corruption may be propagated to the remote system. With a healthy database however, there are no known issues with After Imaging alone causing corruption on the standby database, that is not already in the live/ production database.
The following lists the methods Progress uses to check the validity of after image (ai) files during a roll forward operation:
1. When an ai file is first opened, we verify that it is a Progress ai file and that the version number recorded in the ai file is correct;
2. We then verify that it is a complete ai file, not a partial file. A warning message is returned if this is not true:
"Incomplete ai file detected, expected <blocks>, got <blocks>.
Subsequent roll forwards will fail unless this situation is resolved.(9333);
3. Make sure that the file is not an empty ai file. A warning message is returned if this is not true:
Can't roll forward an empty after-image extent file. (3780);
4. Make sure the ai time stamp matches the timestamp recorded in the master block. A warning message is returned if this is not true:
** Those dates don't match, so you have the wrong copy of one of them. (833);
5. Make sure the ai sequence number is the correct. A warning message is returned if this is not true:
Expected ai file number X but file specified is Y in sequence. (8019);
6. During the roll forward phase, we use the block update counter to check the data during this operation, the update counter in the database block should always be one less than that recorded in the ai note. When applying each particular note, we may do more checks inside DO/UNDO routines by suspending the opperation to find out what the next notes are;
7. For some special AI notes we also do additional sanity checks on the data integrity by recursive checking.
For example:
INMEM note is a construct that takes a snapshot of active transactions in shared memory at the switch of a new AI cluster. We then undertake a sanity check on roll forward by rebuilding the image in shared memory to compare the steps taken against the INMEM notes.
AIEXT note is recorded at the switch of ai extent where the current ai extent note number is recorded and compared against the previous one;
8. If we are rolling forward the last ai extent, we will finish all the phases of crash recovery, and during those phases, we also do some sanity checks.
The ai updates are at byte-level modification in the block. Each physical ai note contains information of which dbkey(block) and area the modification is for. When we roll forward that note, first we locate the particular block from this information, then apply the change to it at a byte level within the block;
An ai extent starts with a special block called ai first block, then followed by ai notes. The ai first is the place where the information about that extent is stored, such as open time, sequence number, ai version. When we open an ai extent file, we first perform checks on the ai first block to make sure we are dealing with a correct ai file. These checks include point 1-5. Points 6,7 happen when we roll forward a particular ai note, as mentioned above, the database blocks are involved and the block update counter is used for the sanity check.