MySQL Bugs: #6433: Administrator stops analysing backup file without any stated reason

Bug #6433	Administrator stops analysing backup file without any stated reason
Submitted:	4 Nov 2004 14:27	Modified:	6 Oct 2005 14:06
Reporter:	Patrick Questembert	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Administrator	Severity:	S3 (Non-critical)
Version:	1.0.13	OS:	Windows (Windows XP)
Assigned to:	Mike Lischke	CPU Architecture:	Any

Description:
Database size is 960MB - on small databases the problem doesn't occur.
When trying to open a backup file and analyse it (in order to restore selected tables), more often than not, Adminstrator stops scanning the backup file at random points, and says "Analyze completed successfully".

However, the "Restore Contents" tab shows absolutely nothing (or, rarely, some but not all of the tables).

It seems to occur faster and earlier in the backup file when other MySQL apps are running, but not necessarily.

Whatever the underlying problem, I think Administrator should display and explanation of what happened, and not say "completed successfully" when it only processed 1/10th ot 1/2 of the backup file.

How to repeat:
Backup is defined as "Single Transaction" and "Backup Selected Schemate Completely". All tables ar Innodb (28 tables). Total size 960MB.

I don't know what else to add - obviously many will not see any problem, as I would be suprised that Administrator is unable to handle such task - I filed a related bug #6431 on the problem, but regardless Administrator should be well-behaved and display some kind of error message in this situation - it can hardly assume that it completed successfully after looking at only a small (and random) section of the backup.

I was able to verify this (WinXP / SP2) using a db w/230 tables and a total of 3 GB in size.

All tables where InnoDB.

Same problem, 26 tables. InnoDB. 100MB.

Is there a workaround. This is a MAJOR problem...S2 at least...for me.

Same problem - just backed up 4 gig of data from work, transfered it to home and analyze backup file stops at 0 with "analyze completed successfully", nothing shown in the list of tables.  Really big problem as I wanted to setup a dev environment.  Any other options?  Thanks, James

Can just use command line client in batch mode to get around this for now (as we did here with out small database, no data, just structure). I suspect this is a SQL-parsing bug as we have no data (yet) in our mysql server.

Just had the same problem here. 310 mb, 50 tables (all MyISAM). Tried using MySQL Administrator 1.0.19 trhu 1.0.21 - same result. This must for sure be a critical bug, since I can't restore any backup of the database.

I get this problem all the time.
Opening up the backup with a text editor, you see that strange characters are being inserted into the text (CR?), removing these cause the restore to work. However, on a 128mb file, it takes some time!

I am also having this problem.  I did notice the (CR?) characters and took them out, but am still having trouble.  The restore continues to stop stating it has completed, but really has not.

When I load the offending sql backup file into a mega editor and delete all the other table info, then run it through the analyzer it completes and restores the remaining table correctly.  So I don't think it is necessarily attibutable to corrupt SQL table info in the backup file.  It does seem related to gross size of the backup file.

I got the same problem and it seems to be in the analyzing process! When you run it often it stops allways on a different point. I tried it with a 16 mb backup and after 6 tries it completes the analyzing and I could continiue. 

But on a 288 MB file it never reaches the end! So this must be an error in the administration tool! It happens on xp and on w2k3 server! 

So what to do? Please help!!!!!

Thanks,
Michael

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

I *think* that I have fixed the issue, although some of the descriptions here cannot be explained by what was wrong. Actually, two things made up this issue, one is that a backup file stored in anything else but utf-8 and containing blob data is processed as utf-8 where the analyzation stops as soon as the blob data is read. The internal utf-8 check fails in this case the analyzation (as well as restore) stop at this point. The other thing was that no error was reported in that case and the background thread simply disappeared without a sign.

The fix for the first problem is: simply specify the correct encoding of the backup file. This is particularly important for files that have not been created by MA (MA always creates utf-8 encoded files).

The fix for the second problem should now help you to spot the actual cause of the trouble if there is any. 

As a test I analyzed a 500 MB backup sql script, which went fine.

We're still seeing the problem with version 1.1.4 of MA. We have a 1.5gig database with lots of text column types and when we do a backup from MA and then immediately try and do a restore to a different target schema it either stops part way through the analyze step and indicates that it completed successfully or it just quits with no error.