Compression Testing and Results

To test compression in the three products in this review, I used a 539GB real-world database loaned specifically for my testing. (A small database would not have yielded results showing how efficient a compression was.) The native backup file size that the 539GB backup generated was 440.53GB.

The server I used ran Windows Server 2003 Enterprise Edition x64 with 4GB of memory and had an AMD Opteron 144 1.8GHz single core processor. The disk configuration was two drives: one 250GB drive for the OS, and one 1TB Seagate Barracuda ES.2 SATA drive for the backups and the data to simulate many clients where the backups and data live on the same set of disks. I used SQL Server 2005 Enterprise Edition x64 with SQL Server 2005 Service Pack 2.

I generated all results by using default settings for the fastest time according to how each tool defines that time. All compression tools will add some amount of CPU overhead. This number will vary depending on your systems, but it’s an important measurement to consider. You should run any tool you evaluate on your systems against your databases to get an accurate idea of how it will work on your standard server configurations.

Table A shows the test results. The asterisk next to the native SQL Server times denotes that they are estimated. I restored the database for the test from an external USB drive to the 1TB drive. Making a full backup on the 1TB drive wasn’t possible because the actual database files took up about 540GB (formatted, the 1TB drive has 931GB of usable space).

To estimate the backup time, I backed up one of the 200GB files that made up the database, then restored it. The backup took 3:20:21, was 179.75GB, and had a throughput of 16.051MB/sec. The restore took 3:07:19 with a throughput of 17.167 MB/sec. To get the numbers listed in the table for the native timings, I extrapolated the data, knowing how large the entire backup file was. What I did underscores the reason behind most of these compression tools: There comes a point when the database gets so large that you don’t have enough space to make a full backup on your drive, so you get creative (e.g., by making file backups, shrinking data or log files, and so on).

Please or Register to post comments.

IT/Dev Connections

Las Vegas
September 30th - October 4th

Paul ThurottOur Experts will show you:
• Common SQL Server
Problems
• Best Practices for T-SQL
• SQL Server Integration
Services
• Database Development

Come See Mike Otey & Tim Ford in Person!

Early Registration Now Open

From the Blogs
May 9, 2013
blog

My ISO 8601-Compliant Signature 2

My family recently just "officially" announced that we're in the process of adopting a child from South Africa. We're quite excited, of course, but there's a ton of paperwork to do—along with the need for gobs of signatures....More
May 8, 2013
blog

Use SSIS for ETL from Hadoop

In this blog post, Mark Kromer walks you through using SSIS as a way to use ETL techniques using Microsoft's Hadoop on Windows (HDInsight) as a source using Hive connectors...More
Vision road sign
May 6, 2013
blog

Cheaters Never Win, Even in TPC Benchmarks

In this portion of the series on database benchmarking, I want to tell you about one of my favorite aspects of the TPC benchmarks – CHEATING....More
SQL Server Pro Forums

Get answers to questions, share tips, and engage with the SQL Server community in our Forums.