> 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]

Reply via email to