Activity overview
Latest activity by mgjernes
Yes, 6.4.0.1015 has done it all so far. I have been able to restore that 30GB database using the Latest_All option from a network backup source with many backup files present. The full restore component completed in just over 44 minutes, just like 6.4.0.56. It has also worked with several smaller databases, too.
Fantastic!!
Thanks for all your efforts, Pete. / comments
Yes, 6.4.0.1015 has done it all so far. I have been able to restore that 30GB database using the Latest_All option from a network backup source with many backup files present. The full restore co...
After the 30GB full restore failure above with 6.4.0.1014, I reverted this test server to 6.4.0.56 and then re-ran the same restore command. It completed successfully in 00:46:37. / comments
After the 30GB full restore failure above with 6.4.0.1014, I reverted this test server to 6.4.0.56 and then re-ran the same restore command. It completed successfully in 00:46:37.
All RedGate SQL Backup file in all my tests are production backups, all with the same settings from 6.4.0.56:
single backup file, 3 threads, compression level 4, 256 bit encryption
Full backup command:
EXECUTE master..sqlbackup '-SQL "BACKUP DATABASES EXCLUDE [Databas list etc..] TO DISK = ''\\[network resource]\<AUTO>.sqb'' WITH ERASEFILES_ATSTART = 21, MAILTO = ''sql_alerts@archipelago.ca'', PASSWORD = ''<ENCRYPTEDPASSWORD>[pwd]=</ENCRYPTEDPASSWORD>'', DISKRETRYINTERVAL = 120, DISKRETRYCOUNT = 5, COMPRESSION = 4, INIT, KEYSIZE = 256, THREADCOUNT = 3, VERIFY"', @exitcode OUT, @sqlerrorcode OUT / comments
All RedGate SQL Backup file in all my tests are production backups, all with the same settings from 6.4.0.56:
single backup file, 3 threads, compression level 4, 256 bit encryption
Full backup comm...
It was my post in this thread dated 2010-08-07 09:20 Pacific Daylight Time.
Post subject: Slow Restore "Fixed Congrats" premature / comments
It was my post in this thread dated 2010-08-07 09:20 Pacific Daylight Time.
Post subject: Slow Restore "Fixed Congrats" premature
The reported "Compressed By" amount was 97% for the full backup and 92% for the differential.
Note: for me, the slower rate for the differential restore with SQL Backup is not really an issue. The faster restore over native backups is great - except in the instances with release 6.4.0.10xx where the larger restore jobs fail to complete. That is the more important issue from my perspective. 6.4.0.56 is working fine for my day to day use - I can get by without the functional LATEST_ALL option until the .10xx "patch" is really ready to go.
Thanks for all your efforts! / comments
The reported "Compressed By" amount was 97% for the full backup and 92% for the differential.
Note: for me, the slower rate for the differential restore with SQL Backup is not really an issue. The...
All of the Red Gate SQL backup files were compressed at level 4 using 3 threads and 256 bit encryption. The temp drive used to hold the backup files for the test restores was on a different local disk set from the SQL data/log files. / comments
All of the Red Gate SQL backup files were compressed at level 4 using 3 threads and 256 bit encryption. The temp drive used to hold the backup files for the test restores was on a different local ...
Well, it appears that my testing was not sufficiently thorough. Release .1014 did resolve the slow restore speed on the smaller databases I used for the testing. However, on a larger database, it hangs up just as did .1001 and .1013.
The database in question is about 30GB for the data file.
Release 6.4.0.56 can restore this database on my test server in about 45 minutes. In the "In Progress" view of the UI, it reaches 27.3GB restored after about 18 minutes and stays there until the restore completes. With release .1013, the progress halted at 9.1GB restored and stayed there until I killed the job after several hours. With .1014, the reported progress reaches 27.3GB in about the same time as release .56, but then it never finishes either - at least not within the limits of my tolerance [image] I saw this same behaviour with .1014 on this same DB when I tried to restore a very large log backup (after a rebuild of all indexes). The log backup size was 61GB compressed to 9GB (full DB backup was ~90GB). Note to self - enable frequent log backups during reindex next time! The log restore attempt with 6.4.0.1014 ran for over 24 hours before I canned it. I did not attempt that log restore with .56 / comments
Well, it appears that my testing was not sufficiently thorough. Release .1014 did resolve the slow restore speed on the smaller databases I used for the testing. However, on a larger database, it...
Thanks for changing the default script naming to the ISO date format in SQL Compare release 8.2.0.16! Much nicer! [image] / comments
Thanks for changing the default script naming to the ISO date format in SQL Compare release 8.2.0.16! Much nicer!
Is there any further work on enabling user-configurable options for the default file name formats for the Data Compare scripts and snapshots? Something like the Auto name formatting options for SQL Backup would be great. [image]
I use SQL compare to sync schemas between multiple dev, test and prod systems and I don't usually script all changes at once, so saved command lines may not be an option. It is a great tool, but changing the default snapshot and script name to a more useful format each time is a little irritating. dmYYYY just does not sort properly when searching by file name. The ISO format as suggested makes far more sense.
Thanks for a great set of products! / comments
Is there any further work on enabling user-configurable options for the default file name formats for the Data Compare scripts and snapshots? Something like the Auto name formatting options for SQ...