Kbase P85905: Consequences of skipping crash recovery using the Force option (-F)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/9/2005 |
|
Status: Verified
GOAL:
Consequences of skipping crash recovery
GOAL:
Here is an explanation of what can happen if you use -F or you lose the bi log
GOAL:
What happens when you use the Force Option -F
GOAL:
What happens if you force the Database
GOAL:
The danger of using the -F Force Option at Startup
GOAL:
Consequences of using (-F) Force Option
GOAL:
What happens when you Force a Data Base
GOAL:
The Force (-F) parameter
FIX:
Let's assume you have a very small buffer pool, with only 4 database buffers, and you are going to update 1 record and then read on their one.
Lefting out a few details to keep this from becoming too involved, but nothing important.
First, we read in the root block of an index into one of the 4 buffers.
Assume the index has two levels, so we will have to read a second index block as well.
Next, we read a record block to fetch the record that is going to be updated. Assume it has two fragments so we will have to read another record block.
At this point each of the 4 blocks in the buffer pool contains one of the blocks we just read - two index blocks and two record blocks.
Now, when we update the record, each of the two fragments may be updated, causing the two record blocks to become dirty.
After the update is finished, we have the following situation:
- we generated 4 bi notes to the bi log - a transaction begin note, two block update notes, and a transaction end note.
- on disk, we have exactly what we started with. No updated blocks have been written back.
- in the buffer pool, there are two dirty blocks which need to be, but have not yet been written to disk.
Now we read the second record, again reading in two index blocks. Because the previous index blocks were oldest, they will be discarded and the new ones replace them and move to the front of the lru chain.
Then we read in a single record block, replacing one of the previously modified record blocks, which is written to disk.
At this point, we have:
- the 4 bi notes from the update
- on disk, one of the two modified record blocks has been written
- in memory we have two index blocks, one unmodified record block, and one modified record block.
Now the system crashes because someone unplugs the server so they can plug in the vacuum cleaner. Stuff like this actually happens!
After we plug in the server and reboot, we have:
- the 4 bi notes from the update
- on disk, one of the two modified record blocks which was written and the rest of the stuff that was in the database to begin with
- whatever was in memory has disappeared, including one of our updated record blocks.
If we start the database the normal way, it will go through crash recovery, read the bi notes, discover that one of the block updates was lost, and make that update again. So now we again have both updated record blocks. Everything is fine.
If instead we use -F, the bi notes are thrown away and we are left only with whatever was on disk in the database. We have one half of the updated record and have the old version of the other half.
Rebuilding indexes will not repair the damaged record - there is
o/ information that can be used to repair it.
You are hosed.