Original PDF Flash format Microsoft-SQL-Server-2008-Data-and-Backup-Compression  


Microsoft SQL Server 2008 Data And Backup Compression

white paper
Microsoft SQL Server 2008
Data and Backup Compression
Jerrold Buggert
Rick Freeman
Elena Shen
Richard Saunders
Cecil Reames
August 19, 2008
Table of Contents
Introduction to Compression in Microsoft SQL Server 2008
3
Data Compression
3
ROW Compression
4
PAGE Compression
4
Backup Compression
4
Database Testing Considerations
4
Database Information
4
Selection of Tables/Indexes to Be Compressed
4
Selection of ROW vs. PAGE Compression
5
Disk Storage & I/O Reduction vs. Performance
5
Test Configuration
5
Database Server
5
I/O Subsystem
5
Microsoft SQL Server 2008
5
Compression Results
6
Data Compression
6
Space Reduction
6
I/O Reduction
7
Performance Impact
7
Index Rebuild Time
7
Backup Compression
8
Storage Space Reduction
8
Elapsed Time Reduction vs. CPU Increase
8
Summary and Recommendations
9
Backup Compression
9
Database Compression
9
References
12
2
Data compression of selected tables Introduction to Compression in Microsoft
SQL Server 2008
and indexes of a database and
Microsoft SQL Server 2008 introduces two new
backup compression of database
compression features (available in Enterprise and
Developer editions) that are of interest to users with
backups are two new features
large databases. Data compression applies to individual
tables and indexes within a database and comes in two
in Microsoft® SQL Server® 2008
options: ROW and PAGE. Backup compression is a new
database software that can be used option when backing up a database to external storage.
Both compression techniques can be used to reduce the
in combination to reduce database
amount of online storage required for databases and their
backups.
and backup storage costs. Tables
Data Compression
and indexes to be compressed
Data compression can be configured for an entire heap
generally should be chosen so
(table with no clustered index), clustered index, non-clustered
index, or indexed view. For partitioned tables and indexes,
as to reduce overall I/O rates
the compression option can be configured separately (and
differently) for each partition.1
and thus have a minimal impact
The data compression option can be specified during CREATE
on performance, unless spare
TABLE or CREATE INDEX by using the new table_option
DATA_COMPRESSION = NONE or ROW or PAGE. The data
CPU cycles are available. Backup
compression option can also be changed later through ALTER
TABLE or ALTER INDEX with a (new for TABLE) REBUILD clause.
compression is effective in general,
Data compression affects the physical storage of columns
even with an already compressed
within a row and rows within a page on disk and in memory.
It does not change the logical attributes of the data or the
database, and reduces both storage way it is presented by the database, so there are no changes
visible to the application.2
and elapsed times for backup and
Data compression requires more processing for select,
restore. The CPU cost for backup
insert, and update than for uncompressed data.
Furthermore, compression is general y more expensive
compression is significant and can
than decompression. For these reasons, in most cases,
Microsoft recommends that compression not be used on
impact concurrent operations unless tables and indexes if the size of the object is much smal er
than the overal database or if the table is heavily used
some means is used to limit backup for DML operations.3 Note that there is no database-wide
compression option.
CPU usage. Both new compression
Compressing large tables and indexes that generate
features should be considered,
significant I/O volume can frequently improve their memory
caching and reduce the I/O volume enough to compensate
given appropriate circumstances
for (much of) the compression/decompression overhead,
thus reducing storage costs without undue change in
where compression could be helpful. performance. In certain I/O-bound (or memory constrained)
situations, data compression can even improve overall
performance.
To estimate how changing the compression state will affect
the amount of storage required for a table or index, use the
sp_estimate_data_compression_savings4 stored procedure or
the Data Compression Wizard.5
3
ROW Compression
Backup Compression
The new storage format for ROW compression works on
Backup compression is off by default. To change the server-
each column in a row separately and has the following main
level default, use the sp_configure stored procedure to set the
changes:2
value of configuration option ‘backup compression default’ to
• It reduces metadata overhead associated with the
1 and then execute the reconfigure statement.9 To use SQL
record format.
Server Management Studio, click the ‘Compress Backup’
checkbox on the ‘Database Settings’ section of the ‘Server
• It uses variable-length storage for numeric types (e.g.,
Properties’ window, and this feature wil be enabled on the
integer, decimal, and float) and types based on numeric
server level. To override the backup compression default, use
(e.g., datetime and money).
either WITH NO_COMPRESSION or WITH COMPRESSION in a
• It stores fixed character strings by using variable-length
BACKUP statement.10
storage (not storing trailing blanks).
Note that backup compression significantly increases CPU
For numeric and decimal types, the storage format is
usage, and the additional CPU consumed by the compression
identical to the vardecimal format of SQL Server 2005. For
process might adversely impact concurrent operations.
integer types, most significant value bytes with zeros are not
stored. For floating-point types, least significant value bytes
On the plus side, backup sizes and backup/restore
with zeros are not stored.
elapsed times can be greatly reduced (depending on the
compressibility of the database). Databases that use ROW
PAGE Compression
and/or PAGE compression for most of their data wil obviously
PAGE compression is a further extension of ROW
be far less compressible for backups, but additional backup
compression. PAGE compressing the leaf level of tables
compression can occur.
and indexes consists of three operations performed in the
Database Testing Considerations
following order:6
The application and database chosen for this testing is
• Row compression
representative of a modern OLTP financial environment. Both
• Prefix compression
read-only and read-write transactions were implemented,
• Dictionary compression
ranging from relatively simple to fairly complex. The database
Prefix compression looks for common leading byte patterns
consisted of smal , medium, and large tables with primary
(regardless of data type) in each column across al rows in
and secondary indexes, foreign keys, data checks, and
that page. Two or more instances of that byte pattern are
referential integrity checks. The columns spanned a wide
stored in the column’s location within an Anchor Record row,
variety of data types. The rows were initial y populated with
just after the page header.7
realistic data values, so compression results should also be
realistic.
Dictionary compression looks for common byte patterns
across al columns of al rows in the page. Multiple instances
Database Information
are stored in a Dictionary just after the Anchor Record, with
The database tables and indexes were broken into related
the col ective structure cal ed Compression Information (CI).
categories and stored in separate filegroups. The number of
The repeated byte patterns are stored just once in the CI,
files in each filegroup was the same as the total number of
and the columns in the multiple rows on the page merely
data volumes, with each data volume containing a separate
reference those values.8
volume partition for each filegroup. The total data size was
As rows are being added to a page, only ROW compression
about 2 TB.
is performed. When the page becomes fil ed, PAGE
Care was taken to pick appropriate FILLFACTOR values
compression is attempted. If there is enough free space
for certain tables and indexes in the database to reduce
left in the page after creating the CI, the PAGE compression
potential page splits and fragmentation during run time.
is retained. Otherwise, the page is left with just ROW
compression.
Selection of Tables/Indexes to Be Compressed
Non-leaf levels of indexes are compressed using only ROW
Fol owing Microsoft recommendations, the fol owing stored
compression.
procedure was executed to determine the best compression
opportunities: 11
sp_estimate_data_compression_savings
4
In addition, data from executing the uncompressed database
disabled. The fol owing table shows a summary of the
was gathered to give an idea of which tables and indexes
database server components.
caused the largest amount of physical reads to disk, used
Table 1: Database server components
the largest number of buffers in the buffer pool, and had the
smal est percentage of database data cached in memory.
System Component Description
Consult SQL Server 2008 Books Online for more information
Intel® Dual-Core Xeon™ 7140M CPU
on using objects like the following: 12
Processors
3.40GHz, 2 Core(s) (2 Logical Processor)
w/16-MB L3 cache
::fn_virtualfilestats
sys.dm_os_buffer_descriptors
Memory
128 GB RAM
sys.master_files
sys.allocation_units
Network interface
8 integrated Ethernet ports (only 4 ports
card
were used)
sys.dm_index_operational_stats
sys.dm_index_physical_stats
Network protocol
TCP/IP
sys.dm_exec_cached_plans
sys.dm_exec_sql_text
Disk HBA
7 Emulex LightPulse LP11000 dual port
Selection of ROW vs. PAGE Compression
13 RTS 4200 RAID Controllers
Having selected the tables and indexes that might benefit
Disk subsystem for 26 LUNs RAID 10, 22 disks per LUN, 73
the most from compression, the next task is to choose
the database
GB per disk, 15k RPM
which type of compression to use: ROW or PAGE. Since PAGE
1 RTS 4200 RAID Controller
compression starts with ROW compression on the individual
Disk subsystem for
the database log
1 LUN RAID 10, 6 disks per LUN, 146
rows, and then further compresses repeated data patterns
GB per disk, 15k RPM
across the entire page, it obviously requires more processing
Microsoft Windows Server ® 2008
for both compression and decompression. Wil the extra
Operating system
Datacenter Edition, Version 6.0.6001
space savings justify the larger overhead? Wil the reduction
Service Pack 1 Build 6001
in I/O be enough to compensate? Or is the reduction in
Microsoft SQL Server 2008 Enterprise
storage most important? 13
Database manager
Edition (64 bit), RC0 build
Disk Storage & I/O Reduction vs. Performance
When either type of compression is used, there is a multi-
way trade-off involved between storage space (disk and
I/O Subsystem
buffer pool), I/O reduction (due to better memory caching),
The storage subsystem consisted of two types of disk
and performance (loss due to compression/decompression
array systems. Database data consisted of 572x73-GB
overhead, but gain due to lower I/O rate). The results below
disks configured as 26x22-disk RAID10 data arrays. Six
show that it is possible in some cases to achieve an overall
146-GB disks were configured as one RAID10 Database
win in al areas, but doing so isn’t easy and certainly isn’t
log array.
possible in all cases.
Fourteen RTS 4200 RAID Control ers were connected to the
Test Configuration
seven dual-port FC disk adapters instal ed in the database
server. Each of thirteen RTS 4200 RAID control ers managed
The system used for compression testing was the Unisys®
two 22-disk RAID-10 data arrays. One RTS 4200 RAID
ES7000™/one Enterprise Server. Configuration details are
controller was used to manage the log array.
explained in the following sections.
Microsoft SQL Server 2008
Database Server
All SQL Server configuration parameters were unchanged
The ES7000/one Enterprise Server was configured with
from their installation default values for these tests. No
one partition containing 16 Intel® Dual-Core Xeon™ 7140M
trace flags were used.
processors (32 processing cores). Hyperthreading was
5
Compression Results
Space Reduction
The results for data compression are given first, followed
The compression ratio is defined as follows:
by those for backup compression.
Compression Ratio = Uncompressed Size /

Compressed Size
Data Compression
Not surprisingly, the compression tests show PAGE
The following data compression tests were performed:
compression on the large tables yields the best
Test
ROW Compression
PAGE Compression
compression ratio and greatest space reduction for the
initial database.
1
none
none
Table 2: Comparing initial data compression ratios and
2
Large tables and indexes
space savings
3
NC indexes of large tables
Large tables
Initial Data
4
Large tables and indexes
Data
Initial Database
Test
Compression
Compression
Space Savings
Ratio
5
All tables and indexes
1
Uncompressed
1.00
0%
2
ROW
1.21
18%
For tests 2-4, only the large tables and indexes, which
3
PAGE&ROW
1.42
30%
made up the overwhelming majority of the database size,
were selected for data compression, while the small and
4
PAGE
1.85
46%
medium tables were not compressed. For test 5, PAGE
5
PAGE-All-Tables
1.86
46%
compression was applied to all the tables and indexes
in the database (including small and medium tables that
are completely cached in the buffer pool even when not
The following table shows the compression ratios
compressed).
and storage space savings differentials after running
After building the uncompressed database, sp_spaceused
approximately the same total number of transactions on
was executed to determine the initial uncompressed
the initial database for each test.
database size. For each compression test, the following
Table 3: Comparing run-time data compression ratios
additional steps were performed:
and space savings
1. Restore the uncompressed database.
Run Time
Data
Run Time Space
2. Rebuild the tables and indexes with PAGE or ROW
Test
Compression
Compression
Savings
Ratio
compression by executing the appropriate ALTER
statement for each table or index:
1
Uncompressed
1.00
0%
ALTER TABLE <table_name> REBUILD
2
ROW
1.06
6%
WITH (DATA_COMPRESSION=PAGE);
3
PAGE&ROW
1.15
13%
ALTER TABLE <table_name> REBUILD
4
PAGE
1.42
30%
WITH (DATA_COMPRESSION=ROW);
5
PAGE-All-Tables
1.41
29%
ALTER INDEX <index_name> REBUILD
WITH (DATA_COMPRESSION=PAGE);
ALTER INDEX <index_name> REBUILD
Note that run-time space is determined by first subtracting
WITH (DATA_COMPRESSION=ROW);
total database space after a run from initial database
space before the run, next dividing by the total number
Then execute sp_spaceused to calculate the database
of new transactions executed, and then computing the
size for the initial compressed database.
normalized ratios by dividing the test 1 result by each of
3. Make a performance run; then execute sp_spaceused
the test results. Run-time results are lower than initial due
again to calculate the run-time database size.
to some page fragmentation, with the main factors being
newly al ocated pages are only partial y fil ed and some
filled pages later get split due to out-of-key-order insertion or
update of a variable-length column with a larger data value.
6
I/O Reduction
database, and the PAGE compressed quarter memory
As expected, the compression tests also show PAGE
performance actually was 3% better than the half memory
compression achieves highest I/O reduction.
uncompressed performance. These results show that at
least some I/O bound situations have the potential for
Table 4: Comparing disk I/O ratios on full, half, and
dramatic gains through use of data compression.
quarter memory configurations
The following table shows that CPU utilization was almost
Full
Half
Quarter
fully busy for all tests and memory configurations, except
Test
Compression
Memory
Memory
Memory
for the first three tests with only quarter memory.
1
Uncompressed
1.00
1.43
2.16
Table 6: Comparing average CPU % on full, half, and
quarter memory configurations
2
ROW
0.92
1.15
2.13
3
PAGE&ROW
0.87
1.12
2.14
Full
Half
Quarter
Test
Compression
Memory
Memory
Memory
4
PAGE
0.78
0.98
1.34
1
Uncompressed
100%
100%
81%
5
PAGE-All-Tables
0.72
0.91
1.22
2
ROW
100%
100%
91%
3
PAGE&ROW
100%
100%
93%
Note that the smaller memory configurations show a
much bigger I/O reduction than does the full memory
4
PAGE
100%
100%
100%
configuration. In other words, compression improves
5
PAGE-All-Tables
100%
100%
100%
caching in a smaller buffer pool more than in a larger
buffer pool. Note that the first three tests for quarter
memory were I/O bound (see Table 6 below), which is why
Note that the system was I/O bound during the first three
they show such large relative I/O rates and such large
tests of quarter memory (i.e., the CPUs were not 100%
improvements with PAGE compression.
busy because they were often stalled waiting for I/Os to
complete). PAGE compressing the database alleviated
Performance Impact
that situation by reducing the I/O volume and thus greatly
Except for test 5, performance improved due to lower I/O
improving the performance.
rates and improvement in memory utilization. Note that
the effect on performance was much more dramatic with
Index Rebuild Time
less memory.
The time required to rebuild the tables/indexes is
Table 5: Comparing performance ratios on full, half, and
significantly higher with PAGE compression than it is
quarter memory configurations
for ROW compression, which is indicative of the extra
compression effort expended for PAGE. The ratio shown
Full
Half
Quarter
below is the elapsed time for rebuilding each test divided
Test
Compression
Memory
Memory
Memory
by the elapsed time for test 1.
1
Uncompressed
1.00
0.89
0.34
Table 7: Comparing tables/indexes rebuild time
2
ROW
1.01
0.96
0.44
Test
Data Compression
Ratio
3
PAGE&ROW
1.01
0.96
0.45
4
PAGE
1.02
0.97
0.92
1
Uncompressed
1.00
5
PAGE-All-Tables
0.93
0.90
0.86
2
ROW compressed
1.41
4
PAGE compressed
2.40
Note that in test 5, compressing all the tables and indexes
in the database had a negative impact on performance for
Note that compression can also be applied at CREATE
all three memory configurations. Also note that with PAGE
TABLE or CREATE INDEX time, but the compression time is
compression, the half memory performance got within
still quite significant.
3% of the full memory performance of the uncompressed
7
Backup Compression
CPU-Seconds is defined as following:
The following test results were performed on the
CPU-Seconds = ‘backup elapsed time’ x
initial database with all three levels of database data

‘avg CPU %’ x ‘number of CPUs’
compression (NONE, ROW, and PAGE) and with both
The reason CPU-Seconds is defined this way is an attempt
combinations of backup compression (NO_COMPRESSION
to provide a metric that will not depend as much on the
and COMPRESSION).
particular database, backup file, disk configuration, and
After a compressed backup, execute the following
number of processors.
statement to get the backup compression ratio:
Table 9: Uncompressed backup: elapsed time, CPU %,
SELECT backup_size/compressed_backup_size
CPU-Seconds, and CPU-Seconds per GB
FROM msdb.dbo.backupset
DB
Elapsed Avg.
CPU-
Data
CPU-
The backup compression results are broken into several
Size in
Time
CPU
Seconds
Compression
Seconds
GB
(sec)
%
per GB
areas: storage space reduction, and elapsed time
reduction versus CPU increase.
Uncompressed 2,080
6,937
1.42
3,155
1.5
Storage Space Reduction
ROW
1,716
4,125
2.44
3,225
1.9
compressed
The backup compression storage space savings for the
PAGE
1,123
2,581
1.97
1,630
1.5
uncompressed initial database is almost twice as much as
compressed
the backup compression savings for the PAGE compressed
initial database, which is to be expected, given that the
latter database is already compressed. The good news is
Table 10: Compressed backup: elapsed time, CPU %,
that backup compression can further reduce the size of an
CPU-Seconds, and CPU-Seconds per GB
already compressed database. That isn’t too surprising,
DB
Elapsed
CPU-
Data
Avg.
CPU-
however, since the goal of data compression in the
Size in
Time
Seconds
Compression
CPU % Seconds
database isn’t maximum compression, but a balance of
GB
(sec)
per GB
compression with minimum overhead for compressing and
Uncompressed 2,080
2,358
77.26
58,285
28.0
decompressing.
ROW
Table 8: Space reduction for compressed versus
1,716
2,188
76.75
53,745
31.3
compressed
uncompressed backups
PAGE
1,123
1,512
86.55
41,886
37.3
compressed
Backup
Data Compression
Space Reduction
Compression Ratio
Microsoft warns that backup compression can significantly
Uncompressed
2.95
66%
increase CPU utilization and that it may have an adverse
ROW compressed
2.42
59%
impact on concurrent operations. They suggest that
PAGE compressed
1.57
36%
Resource Governor15 can be used to limit the CPU usage
of a compressed backup session when CPU contention
occurs.9 However, because backup compression is highly
Note that the compressed backup size is about the same
parallelized, the more CPU resources that are available,
in all three cases (but slightly larger the more highly
the more the backup elapsed time can be reduced.
compressed the database is).
Elapsed Time Reduction vs. CPU Increase
The elapsed time required to make compressed backups
can be significantly less because the size of compressed
backups are smaller and there are fewer writes to the
backup media. However, overall CPU is significantly higher
because of the compression overhead.14
8
Summary and Recommendations
Database Compression
Both data compression and backup compression are
Recommending how to use data compression properly is
highly useful new features added to SQL Server 2008.
a lot more complicated. There is no database-wide data
compression option, and rightly so. Compression must
Backup Compression
be specified for individual tables and indexes. Picking
Of the two, backup compression takes far less effort to
which tables and indexes to compress (and which of
start using: just add WITH COMPRESSION to the BACKUP
two different compression options to use) is a difficult
DATABASE statement (or change the server configuration
decision. Most importantly, there are tradeoffs that must
default). If backups are performed concurrently with
be made depending on the major objective.
other database operations, the system may be impacted
The graph below shows that in situations where the
if something isn’t done first to limit the CPU used by
system memory is insufficient for a large enough buffer
the backup. The backup CPU usage does increase very
pool, resulting in an I/O bound configuration that cannot
significantly due to the cost of compression. Aside from
keep the processors completely busy, being able to
that consideration, however, using backup compression
PAGE compress the database can improve performance
is recommended to reduce both backup storage and
dramatically. Note, of course, that larger memory
elapsed time.
configurations see less of a gain, and that actual results
depend on many other factors.
Performance Ratios
(Full, Half, and Quarter Memory Configurations)
1.2
1
0.8
0.6
0.4
Uncompressed
Relative Performance
ROW
0.2
PAGE&ROW
PAGE
0
PAGE-All-Tables
Full Memory
Half Memory
Quarter Memory
Compression Type
9
In general, compressing tables and indexes that fit
the cost of compressing new data and decompressing all
comfortably within the buffer pool is likely to hurt
data as it is accessed from the buffer pool.
performance and may do little to reduce storage needs,
If memory was insufficient initially, the I/O savings can
if most of the storage is consumed by large tables.
even be large enough to improve performance, as shown
Compressing just the largest tables (and their most
in the following graph. Note that these trade-offs will likely
used indexes) is likely to produce most of the storage
be different for each system and database.
reductions and may reduce the I/O rate enough to mitigate
Disk I/O Ratios
(Full, Half, and Quarter Memory Configurations)
2.5
2
1.5
1
Uncompressed
Relative Disk I/O
ROW
0.5
PAGE&ROW
PAGE
0
PAGE-All-Tables
Full Memory
Half Memory
Quarter Memory
Compression Type
10
For systems with spare CPU cycles for performing
yields less compression. PAGE compression starts out
compression, the objective may be just reducing the
with ROW compression and then looks for repeated values
amount of online storage needed for holding the database.
across the rows of the entire page. The repeated values
The following graph shows how much compression
can then be stored just once in a page dictionary and
can reduce the amount of disk storage needed. (Note
referenced from multiple rows and columns within the
that disks needed to maintain the I/O rate is another
page. The actual PAGE compression is delayed until the
consideration.)
page fills completely, but it is still more expensive. PAGE
If there aren’t many spare CPU cycles, then picking which
decompression is also somewhat more expensive than
compression option to use is harder. ROW compression
for ROW. So again, there are CPU costs versus disk space
provides variable-length storage of values for fixed-length
versus I/O rate tradeoffs to be made.
columns at relatively low compression cost, but it also
Initial Data Compression Ratios
2
1.8
1.6
1.4
1.2
1
0.8
0.6
Relative Compression
0.4
0.2
0
Uncompressed
ROW
PAGE&ROW
PAGE
PAGE-All-Tables
Compression Type
Considering one final situation, if the database is
storage reductions and/or performance improvements
partitioned, and data in older partitions is accessed much
for I/O bound systems can be sizeable, so the potential
less frequently, then deciding to use ROW and then PAGE
payoff can justify the significant initial effort required.
compression just on older partitions, to reduce online
Recommending the use of backup compression is much
storage for older data, might be an easy decision to make.
easier. It requires little effort to get started, although
In summary, consider using SQL Server 2008 data
limiting its significant CPU usage is advised if backup is
compression for appropriate situations, based on
performed along with concurrent database operations.
a thorough examination of all factors, the various
Both compression features can be used together.
tradeoffs, and the particular objective to be met. The
11
References
1. SQL Server 2008 Books Online. Topic: “Creating Compressed Tables and Indexes”
2. SQL Server 2008 Books Online. Topic: “Row Compression Implementation”
3. http://blogs.msdn.com/search/SearchResults.aspx?q=compression+AND+user%3aSunil&o=Relevance

SQL Server Storage Engine blog, Sunil Agarwal, “Compression Strategies”
4. SQL Server 2008 Books Online. Topic: “sp_estimate_data_compression_savings (Transact-SQL)”
5. SQL Server 2008 Books Online. Topic: “Data Compression Wizard F1 Help”
6. SQL Server 2008 Books Online. Topic: “Page Compression Implementation”
7. http://blogs.msdn.com/search/SearchResults.aspx?q=compression+AND+user%3aSunil&o=Relevance

SQL Server Storage Engine blog, Sunil Agarwal, “Details on PAGE compression (column-prefix)”
8. http://blogs.msdn.com/search/SearchResults.aspx?q=compression+AND+user%3aSunil&o=Relevance

SQL Server Storage Engine blog, Sunil Agarwal, “Details on PAGE compression (page-dictionary)”
9. SQL Server 2008 Books Online. Topic: “Backup Compression (SQL Server)”
10. SQL Server 2008 Books Online. Topic: “BACKUP (Transact-SQL)”
11. http://blogs.msdn.com/search/SearchResults.aspx?q=compression+AND+user%3aSunil&o=Relevance

SQL Server Storage Engine blog, Sunil Agarwal, “Estimating the space savings with data compression”
12. http://sqlcat.com/toolbox/archive/2008/02/21/scripts-and-tools-for-performance-tuning-and-troubleshooting-sql-
server-2005.aspx
13. http://blogs.msdn.com/search/SearchResults.aspx?q=compression+AND+user%3aSunil&o=Relevance

SQL Server Storage Engine blog, Sunil Agarwal, “Data compression techniques and trade offs”
14. http://blogs.msdn.com/sqlcat/archive/2008/03/02/backup-more-than-1gb-per-second-using-sql2008-backup-
compression.aspx

SQL Server Development Customer Advisory Team, Lindsey Allen & Thomas Grohser, “Backup More Than 1GB per
Second Using SQL2008 Backup Compression”
15. SQL Server 2008 Books Online. Topic: “How to: Use Resource Governor to Limit CPU Usage by Backup Compression
(Transact-SQL)”
© 2008 Unisys Corporation.
All rights reserved.
Unisys is a registered trademark and ES7000 is a trademark of Unisys Corporation. Intel and Xeon are
registered trademarks of Intel Corporation. Microsoft, SQL Server, and Windows Server are registered
trademarks of Microsoft Corporation. All other brands and products referenced herein are acknowledged to
be trademarks or registered trademarks of their respective holders.
August 2008
12

Document Outline