Oracle 5.0 Reference Manual page 1283

• (SRV_FORCE_IGNORE_CORRUPT)
1
Let the server run even if it detects a corrupt page. Try to make
over corrupt index records and pages, which helps in dumping tables.
• (SRV_FORCE_NO_BACKGROUND)
2
Prevent the main thread from running. If a crash would occur during the purge operation, this
recovery value prevents it.
• (SRV_FORCE_NO_TRX_UNDO)
3
Do not run transaction rollbacks after recovery.
• (SRV_FORCE_NO_IBUF_MERGE)
4
Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate
table statistics.
• (SRV_FORCE_NO_UNDO_LOG_SCAN)
5
Do not look at undo logs when starting the database:
committed.
• (SRV_FORCE_NO_LOG_REDO)
6
Do not do the log roll-forward in connection with recovery.
The database must not otherwise be used with any nonzero value of
innodb_force_recovery
INSERT, UPDATE, or
You can
SELECT
If you know that a given table is causing a crash on rollback, you can drop it. You can also use this to
stop a runaway rollback caused by a failing mass import or
process and set
then the table that is causing the runaway rollback.
DROP
14.2.5.3. Checkpoints
InnoDB
implements a checkpoint mechanism known as "fuzzy" checkpointing.
InnoDB
modified database pages from the buffer pool in small batches. There is no need to flush the buffer
pool in one single batch, which would in practice stop processing of user SQL statements during the
checkpointing process.
During crash recovery,
modifications to the database before the label are present in the disk image of the database. Then
scans the log files forward from the checkpoint, applying the logged modifications to the
InnoDB
database.
writes to its log files on a rotating basis. It also writes checkpoint information to the first
InnoDB
log file at each checkpoint. All committed modifications that make the database pages in the buffer
pool different from the images on disk must be available in the log files in case
recovery. This means that when
page images on disk contain the modifications logged in the log file that
other words,
pages to disk.
The preceding description explains why making your log files very large may reduce disk I/O in
checkpointing. It often makes sense to set the total size of the log files as large as the buffer pool or
even larger. The disadvantage of using large log files is that crash recovery can take longer because
there is more logged information to apply to the database.
Backing Up and Recovering an
[1243]. As a safety measure,
operations when
DELETE
from tables to dump them, or
innodb_force_recovery
looks for a checkpoint label written to the log files. It knows that all
InnoDB
InnoDB
must create a checkpoint and this often involves flushing of modified database
InnoDB
Database
InnoDB
InnoDB
InnoDB
innodb_force_recovery
or
DROP CREATE
ALTER
[1243] to to bring the database up without the rollback,
3
starts to reuse a log file, it has to make sure that the database
1263
SELECT * FROM tbl_name
treats even incomplete transactions as
prevents users from performing
[1243] is greater than 0.
tables even if forced recovery is used.
TABLE. You can kill the
InnoDB
InnoDB
is going to reuse. In
InnoDB
jump
mysqld
flushes
has to do a