Forum Replies Created
-
AuthorPosts
-
December 27, 2011 at 10:02 pm in reply to: Error Upon Executing "extract All" On The Zipped Backup File. #32864dbachachaMember
Hi Peter,
WINRAR worked.
Happy Holidays!
'dbachacha' wrote:Hi,
I am using Sqlyog for scheduling daily backup of MySQL database. The backup script executes on server ABC connecting to the database server DEF via dedicated NIC.
I have set up email notifications after the backup is completed.
Also, I have specified the parameter for zipping the dump file.
When I try to unzip the backup file using Windows Extract All, it tries to unzip and terminates with 80004005: Unspecified error.
I have been receiving emails that mentions backup of each table is completed successfully.
log file does not indicate any error encountered by sqlyog in the backup process.
I have been able to unzip smaller database. The zipped file that cannot be unzipped is of a database of about 80GB.
Please advise.
Thank you,
dbachachaMember'peterlaursen' wrote:There is currently no option to use SELECT SQL_NO_CACHE. But why is it a problem? Because of same considerations as here: http://code.google.c…detail?id=1538?
The link http://code.google.com/p/sqlyog/issues/detail?id=1538 gave 404 http error.
I tried chunk size of 1000,000 records and backup got over within 1.5 hours. During the backup users found that the pages were loading slowly when they switched between various options in the web based ASP.Net application that was connected to MySQl database server. The database server is dedicated to mysql.
I found that SELECt does not use *SQL No Cache*, so MySQL will cache the result set. The QUery Cache is 2GB.
Next day I tried reducing the CHUNK SIZE to 10,000 and it took 15 hours for backup to complete. This is understandable because with reduced CHUNK SIZE, the # of times a SELECt is done on a table is more compared to CHUNK SIZE of 1000000.
Isn't it beneficial to have SQL No Cache in the SELECT statement?
Thank you
-
AuthorPosts