Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

SQL 2005 vs. SQL 2008 Part 1 - (Backup File Sizes & Times) Expand / Collapse
Author
Message
Posted Saturday, May 3, 2008 1:08 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Saturday, August 23, 2014 6:56 AM
Points: 335, Visits: 3,173
Comments posted to this topic are about the item SQL 2005 vs. SQL 2008 Part 1 - (Backup File Sizes & Times)
Post #494665
Posted Monday, May 5, 2008 2:19 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 16, 2014 4:46 AM
Points: 5,404, Visits: 1,400
The speed of the backup is a good news. But I have couple of questions? Will it take less space in the tape drive due to compression? Will it be a reliable backup?

:)



Post #494817
Posted Monday, May 5, 2008 3:08 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Saturday, August 23, 2014 6:56 AM
Points: 335, Visits: 3,173
Hi

On your 2 questions:

1) Space on Tape: if your tape device does compression on the fly as ours does. Our usual space saving is approx 65% when going onto tape.

This means that the 3.5GB file is stored on tape as 1.2GB - this is about 200MB more than the SQL 2008 Compressed backup.

If the original 3.5GB file is zipped using maximum compression then the ZIP file is approx 820MB (note: this maximum compression takes longer than the SQL 2008 Compression Backup)

So, this means that there is potentially 200MB that could be saved when storing onto tape for this 3.5GB database backup.

2) Reliability: because the SQL engine is doing the compression and not a third-party vendor, I am reasonably confident that this backup should be seen as reliable as the original .BAK without compression.

Thanks
Kevin
Post #494828
Posted Monday, May 5, 2008 4:12 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, April 1, 2014 8:30 AM
Points: 47, Visits: 95
Hi,

and what about to restore? Do you need more additional space on disk to uncompress first?

Thanks in advance,

Prado
Post #494839
Posted Monday, May 5, 2008 4:55 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Saturday, August 23, 2014 6:56 AM
Points: 335, Visits: 3,173
Hi

The "uncompress" actually happens inside the SQL Engine - so no additional space is required for a "temp" file. The only space required is the size of the Database and Transaction Log.

Note: If a backup file is 900MB - the actual size of the database Data file is 3.5GB and the Log 100MB - then this is the amount of space required on disk for the restored Database files (Data and Log)

Thanks
Kevin
Post #494847
Posted Monday, May 5, 2008 5:32 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
Nice work Kevin!

The compress backups feature will come in handy in many environments - certainly will save space.

One question - I didn't see metrics for restoring. I'd be interested in seeing what the differentce in restore time would be for a compressed backup vs. non-compressed.

The reduced backup time was an interesting effect, it shows that the disk is probably the limiting factor in this instance.

Mark
Post #494864
Posted Monday, May 5, 2008 5:45 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 16, 2014 4:46 AM
Points: 5,404, Visits: 1,400
Kevin (5/5/2008)
Hi

On your 2 questions:

1) Space on Tape: if your tape device does compression on the fly as ours does. Our usual space saving is approx 65% when going onto tape.

This means that the 3.5GB file is stored on tape as 1.2GB - this is about 200MB more than the SQL 2008 Compressed backup.

If the original 3.5GB file is zipped using maximum compression then the ZIP file is approx 820MB (note: this maximum compression takes longer than the SQL 2008 Compression Backup)

So, this means that there is potentially 200MB that could be saved when storing onto tape for this 3.5GB database backup.

2) Reliability: because the SQL engine is doing the compression and not a third-party vendor, I am reasonably confident that this backup should be seen as reliable as the original .BAK without compression.

Thanks
Kevin



Thanks Kevin on your prompt reply. This clears my doubt. :)



Post #494872
Posted Monday, May 5, 2008 5:55 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Saturday, August 23, 2014 6:56 AM
Points: 335, Visits: 3,173
Yes, the restore from compressed .BAK file will be an interesting item to investigate.

I will get my environment up and running and either post feedback on this discussion or provide feedback in the form of a more in-depth technical article on the topic of Restore & Backups with SQL 2008.

Thanks
Kevin
Post #494879
Posted Monday, May 5, 2008 6:20 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, April 1, 2014 8:30 AM
Points: 47, Visits: 95
Hi again,

A lot of thanks for your answer. Your explanations are very useful so we'll wait your feedback about the test for restore.

Thanks,

Prado
Post #494898
Posted Monday, May 5, 2008 6:33 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 9, 2014 10:42 AM
Points: 6,731, Visits: 8,480
Thank you for highlighting this valuable feature.
Saving +60% is certainly worth investigating it to the bone, considering the vase amount of backup data we produce.

Nowadays we compress the backup by using disk compression at our safezone. (backups are procuded local and xcopied to safezone)

Won't compression on compression produce an overhead ?


Johan


Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere

- How to post Performance Problems
- How to post data/code to get the best help


- How to prevent a sore throat after hours of presenting ppt ?


"press F1 for solution", "press shift+F1 for urgent solution"


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me
Post #494908
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse