> We've had some cases where an OPTIMIZE TABLE failed because we ran out
> of disk-space (error message "28 when fixing table"). All subsequent
> operations gave us an error 144 ("Table is crashed and last repair
> failed"), resulting in partial backups and partially updated databases.
> What I'd like to do is check on the table's condition *before* doing
> something that might give us that error message. I'm assuming there's a
> status bit somewhere that says that the table is crashed, and basically
> I'd like to be able to read that bit.
> CHECK TABLE or myisamchk is not really an option, because with the size
> of tables we're using that can take over an hour, even with the -q flag.
Using myisamchk -r -n -t <tmpdir> table_name significantly speeds up the
repair process.
Copy one of your large tables and give it a shot. Specify a tmpdir that is
on a disk/volume that gets little use and has plenty of space, if possible.
Best of luck!
-Bruce Bristol
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]