Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Tips Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS Access
SQL Scripts & Samples
» Database Forum
» Slideshows
» Sitemap
Free Newsletters:

By submitting your information, you agree that databasejournal.com may send you databasejournal offers via email, phone and text message, as well as email offers about other products and services that databasejournal believes may be of interest to you. databasejournal will process your information in accordance with the Quinstreet Privacy Policy.

News Via RSS Feed

Database Journal |DBA Support |SQLCourse |SQLCourse2

Featured Database Articles


Posted Jan 21, 2004

Repairing Database Corruption in MySQL - Page 2

By Ian Gilfillan

Repairing tables

In most cases, only the index will be corrupted (the index is a separate, smaller, file with records that point to the main data file) - actual data corruption is extremely rare. Fixing most forms of corruption is relatively easy. As with checking, there are three ways to repair tables. These all only work with MyISAM tables - to repair corruption of the other table types, you will need to restore from backup:

  • The REPAIR TABLE SQL statement (obviously the server must be running for this)
  • The mysqlcheck command-line utility (the server can be running)
  • The myisamchk command-line utility (the server must be down, or the tables inactive)

Repairing a table requires twice as much disk space as the original table (a copy of the data is made), so make sure you are not going to run out of disk space before you start.

Repairing a table with REPAIR TABLE

The syntax is, as would be expected, REPAIR TABLE tablename[,tablename1...] [options]. This method only works with MyISAM tables. The following options are available.


The quickest, as the data file is not modified.


Will attempt to recover every possible data row file, which can result in garbage rows. Use as a last resort.


To be used if the .MYI file is missing or has a corrupted header. Uses the .frm file definitions to rebuild the indexes.

In most cases, a simple REPAIR without any options should work fine. An unusual case is when the .MYI is missing. Here is what would happen:

mysql> REPAIR TABLE fixtures;
| Table                   | Op     | Msg_type | Msg_text                                    |
| sports_results.fixtures | repair | error    | Can't find file: 'fixtures.MYI' (errno: 2)  |

The repair has failed because the index file is missing or has a corrupted header. To use the definition file to repair, use the USE_FRM option, as follows:

mysql> REPAIR TABLE fixtures USE_FRM;
| Table                   | Op     | Msg_type | Msg_text                           |
| sports_results.fixtures | repair | warning  | Number of rows changed from 0 to 2 |
| sports_results.fixtures | repair | status   | OK                                 |

Everything has gone smoothly this time, as indicated by the OK Msg_text.

Repairing tables with mysqlcheck

The mysqlcheck command-line utility can be used while the server is running, and, like all the methods of repair, only works with MyISAM tables. The syntax is:

%mysqlcheck -r sports_results fixtures -uuser -ppass
sports_results.fixtures                            OK

You can also repair multiple tables in a database, by listing them after the database name, or all tables in a database by just passing the database name, for example:

%mysqlcheck -r sports_results fixtures events -uuser -ppass
sports_results.fixtures                            OK
sports_results.events                              OK

%mysqlcheck -r sports_results -uuser -ppass
sports_results.fixtures                            OK
sports_results.events                              OK

Repairing tables with myisamchk

The server must be down, or the tables inactive (which is ensured if the --skip-external-locking option is not in use). The syntax is myisamchk [options[ [tablenames]. Remember again that you must be in, or specify, the path to the relevant .MYI files. The following options are available:

--backup, -B

Makes a .BAK backup of the table before repairing it


Corrects the checksum

--data-file-length=#, -D #

Specifies the maximum length of the data file, when recreating

--extend-check, -e

Attempts to recover every possible row from the data file. This option should not be used except as a last resort, as it may produce garbage rows.

--force, -f

Overwrites old temporary .TMD files instead of aborting if it encounters a pre-existing one.

keys-used=#, -k #

Can make the process faster by specifying which keys to use. Each binary bit stands for one key starting at 0 for the first key.

--recover, -r

The most commonly used option, which repairs most corruption. If you have enough memory, increase the sort_buffer_size to make the recover go more quickly. Will not recover from the rare form of corruption where a unique key is not unique.

--safe-recover, -o

More thorough, yet slower repair option than -r, usually only used only if -r fails. Reads through all rows and rebuilds the indexes based on the rows. This also uses slightly less disk space than a -r repair since a sort buffer is not created. You should increase the key_buffer_size value to improve repair speed if there is available memory.

--sort-recover, -n

MySQL uses sorting to resolve the indexes, even if the resulting temporary files are very large.


The directory containing the character sets


Specifies a new character set for the index

--tmpdir=path, -t

Passes a new path for storing temporary files if you dont want to use the contents of the TMPDIR environment variable

--quick, -q

The fastest repair, since the data file is not modified. A second -q will modify the data file if there are duplicate keys. Also uses much less disk space since the data file is not modified.

--unpack, -u

Unpacks a file that has been packed with the myisampack utility.

An example of its usage:

% myisamchk -r fixtures
- recovering (with keycache) MyISAM-table 'fixtures.MYI'
Data records: 0

I hope that you will never have to do any repairing, but I am sure at least some of you reading this article (at least those who got this far) are here precisely because you've got some corruption. I hope that your repairs will be as painless as all mine have been. Good luck!

» See All Articles by Columnist Ian Gilfillan

MySQL Archives

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Latest Forum Threads
MySQL Forum
Topic By Replies Updated
MySQL in high availability and transction secure banking application klamor 1 August 28th, 10:24 AM
MySQL rollback UAL225 1 August 28th, 10:15 AM
Browsing a DB file that uses MySql finleytech 1 July 26th, 10:51 AM
php cookie won't pass variable to next page ITdevGirl 0 June 22nd, 12:13 PM