Let's assume there is a very small buffer pool, with only 4 database buffers, and we are going to update 1 record and then read another one.
(Leaving 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 (for some reason).
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 (proutil dbname -C truncate bi -F to) force into the database, the bi notes are thrown away. We are left only with whatever was on disk in the database. We have one half of the updated record and the old version of the other half of the record.
Rebuilding indexes will not repair the damaged record - there is no information that can be used to repair it. The database now has logical corruption. For further discussion refer to Article
Consequences of using the -F startup option 
