ISAM corruption: Error 1033: Incorrect information in file
'/path/x.frm'
Brian J.S. Miller 24 September 2004 18:50:46
Hello,
I've read over every archived posting I can find about this problem and havne't found a solution that seems to work for me.
Here is the deal: I had a server crash. Hard. I re-built the server (i686, Debian install, kernel 2.4.18). I restored the data for 1 database from tapes to use for testing purposes.
The database has 76 tables, all of type ISAM.
To restore the data, I did the following: 1) /etc/init.d/mysql stop 2) cp all files from tape restore (ISM, ISD and frm for each of the 76 tables) to /var/lib/mysql/databasename/ 3) chown/chgrp/chmod the new files so they're mysql.root, 0664 4) chown/chgrp/chmod the new directory so it's mysql.root, 0775 5) /etc/init.d/mysql start
The server starts just fine. ~> mysql databasename
I get 66 tables working fine, 9 tables reporting "Didn't find any fields in table 'admin_privs'" (or whatever the table name is..that's just 1 exaple).
Here is what I have tried already: 1) backing down to Mysql 3.23 2) Running 2.6 kernel (read that ISAMs aren't binary compatible across OS/platform) 3) CHECK TABLE admin_privs (says: "Incorrect information in file: './path/admin_privs.frm') 4) isamchk (says: "isamchk: error: 'admin_privs' is not a ISAM-table")
Does anyone have ANY ideas?! I'm at a complete loss here (and, of course, getting bashed for not being able to restore from tape).
I've read over every archived posting I can find about this problem and>havne't found a solution that seems to work for me.>
Here is the deal:>I had a server crash. Hard.>I re-built the server (i686, Debian install, kernel 2.4.18).>I restored the data for 1 database from tapes to use for testing purposes.>
The database has 76 tables, all of type ISAM.>
To restore the data, I did the following:>1) /etc/init.d/mysql stop>2) cp all files from tape restore (ISM, ISD and frm for each of the 76>tables) to /var/lib/mysql/databasename/>3) chown/chgrp/chmod the new files so they're mysql.root, 0664>4) chown/chgrp/chmod the new directory so it's mysql.root, 0775>5) /etc/init.d/mysql start>
The server starts just fine.>~> mysql databasename>
I get 66 tables working fine, 9 tables reporting "Didn't find any fields>in table 'admin_privs'" (or whatever the table name is..that's just 1>exaple).>
Here is what I have tried already:>1) backing down to Mysql 3.23>2) Running 2.6 kernel (read that ISAMs aren't binary compatible across>OS/platform)>3) CHECK TABLE admin_privs (says: "Incorrect information in file:>'./path/admin_privs.frm')>4) isamchk (says: "isamchk: error: 'admin_privs' is not a ISAM-table")>
Does anyone have ANY ideas?! I'm at a complete loss here (and, of course,>getting bashed for not being able to restore from tape).>
Thanks,>Brian>
Brian, Are the tables ISAM or MYISAM ? From the manual - "MyISAM is the default storage engine as of MySQL 3.23"
If they are MYISAM, then you should be running myisamchk. We run this everytime we start/restart our db which checks for tables not closed properly and will automatically repair them. Of course, read the manual for all the myisamchk options.
walt
#!/bin/bash FILES=`ls /var/lib/mysql/NEA/*.MYI` for n in $FILES; do echo "checking $n"; myisamchk -f -m -O key_buffer=100M -O sort_buffer=64M -O read_buffer=50M -O write_buffer=1M $n;
Brian J.S. Miller 24 September 2004 22:20:44 [ permanent link ]
Brian J.S. Miller wrote:>
Hello,>>
I've read over every archived posting I can find about this problem and>>havne't found a solution that seems to work for me.>>
Here is the deal:>>I had a server crash. Hard.>>I re-built the server (i686, Debian install, kernel 2.4.18).>>I restored the data for 1 database from tapes to use for testing>> purposes.>>
The database has 76 tables, all of type ISAM.>>
To restore the data, I did the following:>>1) /etc/init.d/mysql stop>>2) cp all files from tape restore (ISM, ISD and frm for each of the 76>>tables) to /var/lib/mysql/databasename/>>3) chown/chgrp/chmod the new files so they're mysql.root, 0664>>4) chown/chgrp/chmod the new directory so it's mysql.root, 0775>>5) /etc/init.d/mysql start>>
The server starts just fine.>>~> mysql databasename>>
I get 66 tables working fine, 9 tables reporting "Didn't find any fields>>in table 'admin_privs'" (or whatever the table name is..that's just 1>>exaple).>>
Here is what I have tried already:>>1) backing down to Mysql 3.23>>2) Running 2.6 kernel (read that ISAMs aren't binary compatible across>>OS/platform)>>3) CHECK TABLE admin_privs (says: "Incorrect information in file:>>'./path/admin_privs.frm')>>4) isamchk (says: "isamchk: error: 'admin_privs' is not a ISAM-table")>>
Does anyone have ANY ideas?! I'm at a complete loss here (and, of>> course,>>getting bashed for not being able to restore from tape).>>
Thanks,>>Brian>>
Brian,> Are the tables ISAM or MYISAM ?> From the manual -> "MyISAM is the default storage engine as of MySQL 3.23">
If they are MYISAM, then you should be running myisamchk. We run this> everytime we start/restart our db which checks for tables not closed> properly and will automatically repair them. Of course, read the manual> for all the myisamchk options.>
walt
Walt,
The tables are ISAM type. These are some seriously old tables (originally from version 3.21) and were never updated to type MyISAM. Despite frequent updates to mysqld.
There is a program isamchk which is similar to myisamchk, but it returns the error "___ is not a ISAM-table."
I have read and re-read the man pages for this utility and cannot get it to spit out anything more than the error listed above.
Anyone else got an idea? This is killing me. Brian
I've read over every archived posting I can find about this problem and>>>havne't found a solution that seems to work for me.>>>
Here is the deal:>>>I had a server crash. Hard.>>>I re-built the server (i686, Debian install, kernel 2.4.18).>>>I restored the data for 1 database from tapes to use for testing>>>purposes.>>>
The database has 76 tables, all of type ISAM.>>>
To restore the data, I did the following:>>>1) /etc/init.d/mysql stop>>>2) cp all files from tape restore (ISM, ISD and frm for each of the 76>>>tables) to /var/lib/mysql/databasename/>>>3) chown/chgrp/chmod the new files so they're mysql.root, 0664>>>4) chown/chgrp/chmod the new directory so it's mysql.root, 0775>>>5) /etc/init.d/mysql start>>>
The server starts just fine.>>>~> mysql databasename>>>
I get 66 tables working fine, 9 tables reporting "Didn't find any fields>>>in table 'admin_privs'" (or whatever the table name is..that's just 1>>>exaple).>>>
Here is what I have tried already:>>>1) backing down to Mysql 3.23>>>2) Running 2.6 kernel (read that ISAMs aren't binary compatible across>>>OS/platform)>>>3) CHECK TABLE admin_privs (says: "Incorrect information in file:>>>'./path/admin_privs.frm')>>>4) isamchk (says: "isamchk: error: 'admin_privs' is not a ISAM-table")>>>
Does anyone have ANY ideas?! I'm at a complete loss here (and, of>>>course,>>>getting bashed for not being able to restore from tape).>>>
Thanks,>>>Brian>>>
Brian,>>Are the tables ISAM or MYISAM ?>> From the manual ->>"MyISAM is the default storage engine as of MySQL 3.23">>
If they are MYISAM, then you should be running myisamchk. We run this>>everytime we start/restart our db which checks for tables not closed>>properly and will automatically repair them. Of course, read the manual>>for all the myisamchk options.>>
walt>>
Walt,>
The tables are ISAM type. These are some seriously old tables (originally>from version 3.21) and were never updated to type MyISAM. Despite>frequent updates to mysqld.>
There is a program isamchk which is similar to myisamchk, but it returns>the error "___ is not a ISAM-table.">
I have read and re-read the man pages for this utility and cannot get it>to spit out anything more than the error listed above.>
Anyone else got an idea? This is killing me.>Brian>
Brian, The "Didn't find any fields in table 'BLA'" sounds like you're missing the table definition file. If the table name is BLA, the file would be BLA.ISM. MySQL is finding table data, but no table structure.
Gerald_clark 24 September 2004 22:54:21 [ permanent link ]
Brian J.S. Miller wrote:
Walt,>
The tables are ISAM type. These are some seriously old tables (originally>from version 3.21) and were never updated to type MyISAM. Despite>frequent updates to mysqld.>
There is a program isamchk which is similar to myisamchk, but it returns>the error "___ is not a ISAM-table.">
I have read and re-read the man pages for this utility and cannot get it>to spit out anything more than the error listed above.>
Anyone else got an idea? This is killing me.>Brian>
Make sure you are running isamchk on th .ISM files, and that the user running isamchk has read and write privileges for these files and their directory.
If these files did not come from a linux box of the same architecture, you may have to go back to a duplicate of the old machine to convert or dump them.
Brian J.S. Miller 24 September 2004 23:15:05 [ permanent link ]
Brian J.S. Miller wrote:>
Walt,>>
The tables are ISAM type. These are some seriously old tables>> (originally>>from version 3.21) and were never updated to type MyISAM. Despite>>frequent updates to mysqld.>>
There is a program isamchk which is similar to myisamchk, but it returns>>the error "___ is not a ISAM-table.">>
I have read and re-read the man pages for this utility and cannot get it>>to spit out anything more than the error listed above.>>
Anyone else got an idea? This is killing me.>>Brian>>
Make sure you are running isamchk on th .ISM files, and that the user> running isamchk> has read and write privileges for these files and their directory.>
If these files did not come from a linux box of the same architecture,> you may have to go back to a> duplicate of the old machine to convert or dump them.>
When you say "same architecture" ...as long as it's i686 it should work right? The box hasn't changed, but the drive and filesystem have. I was running this on a 36.7G ultra160 drive. I replaced it with an older 18G drive, re-installed the OS onto this drive, and tried to copy the files.
The CPU, memory, etc. have stayed the same.
The old install was reiserfs but the new one is ext3. That shouldn't make a difference either right?
As for your other suggestion, I was definitely running isamchk on the .ISM files. What's weirdest is that 67 of the 76 tables are working. There are just 9 that won't work. They're the 9 biggest tables, however (which is the weird part).
Being a system administrator, I periodically use various data recovery services from other software developers. From my point of view, the mssql repair utility: http://www.recoverytoolbox.com/mssql_server_repair_database.html is very easy to use, it features intelligent data recovery algorithms that work under all supported software and hardware configurations.
If you would like to report an abuse of our service, such as a spam message, please . Если Вы хотите пожаловаться на содержимое этой страницы, пожалуйста .
