Database Mirroring Log Compression in SQL Server 2008 Improves Throughput
Author: Sanjay Mishra
Reviewers: Peter Byrne, Don Vilen, Kaloian Manassiev, Burzin Patel, Eric Jacobsen
Overview
Database mirroring works by transferring and applying a stream of database log records from the principal database to the mirror database. The log records are transferred over a network. For an application that generates lots of transaction log (as measured by the perfmon counter Log Bytes Flushed / sec), the bandwidth of the network can be a limiting factor. The efficiency of log transfer plays a significant role in achieving the best application throughput and performance in a database mirroring environment.
SQL Server 2008 introduces a new feature called "Database Mirroring Log Compression". With SQL Server 2008, the outgoing log stream from the principal to the mirror is compressed, thereby minimizing the network bandwidth used by database mirroring. In a network constrained for bandwidth, compressing the log stream helps improve the application performance and throughput.
In this study, we took a customer workload (an application at a stock exchange that captures stock quotes and orders), with a high log generation rate (12 MB/sec) and ran performance tests with a pre-release build of SQL Server 2008. The results indicate a significant performance benefit of log compression, especially on lower bandwidth networks.
What is Log Compression
Transferring transaction log records from the principal server to the mirror server over a network is central to database mirroring implementation. The more transaction log an application generates, the more log records need to be transferred from the principal to the mirror. Higher log generation rate puts a higher demand on the network bandwidth.
Synchronous database mirroring requires that the log records for each transaction be received and hardened by the mirror database and a confirmation message sent to the principal, before the transaction is committed. Therefore, the network plays a very important role in influencing the performance and throughput. As you can guess, the throughput of an application can reduce under a lower bandwidth network. Refer to the white paper Database Mirroring Best Practices and Performance Considerations for a discussion and performance results of applications under database mirroring in networks with varying bandwidth with SQL Server 2005.
Compressing the log stream means that a significantly less amount of network packets are sent from the principal to the mirror. Therefore more log records can be sent in a given time. This translates into improved throughput for the application.
Test Workload and Test Environment
The workload used for the tests described in this paper consists of a 20 GB database, and 20 concurrent active user connections.
The test hardware consisted of 2 Unisys x64 servers with 16 processors and 64 GB RAM each. The storage was EMC Clariion SAN. The network between two servers 1 Gbps.
The SQL Server 2008 prerelease build 10.00.1049.00 was used.
Synchronous database mirroring was used for these tests.
Improved Throughput
With SQL Server 2008, the log stream is compressed by default. To measure the impact of log compression, we used the trace flag 1462, which disables log compression. Disabling log compression is equivalent of SQL Server 2005 behavior.
Figure 1: With log compression, database mirroring throughput is improved
As shown in Figure 1, the log compression results in higher throughput compared to disabling log compression.
Log Compression Helps Significantly on Lower Bandwidth Networks
The impact of log compression on throughput is much more pronounced on lower bandwidth networks. We used a network emulator software to simulate different network bandwidths between the principal and the mirror servers, and measured the application throughput with and without log compression. Figure 2 indicates a very significant improvement in throughput by having log compression.
Figure 2: The improvement is more pronounced on lower bandwidth networks
As can be observed in Figure 2 (the line chart), the percent of throughput improvement obtained by log compression is usually higher for lower bandwidths. The throughput improvement experienced by an application is dependent upon the data processed by the application.
Log Compression Ratio
Log compression ratio indicates the factor by which the log stream has been compressed. You can divide the perfmon counter Log Bytes Sent/sec by the counter Log Compressed Bytes Sent/sec to get the compression ratio. Figure 3 illustrates the log compression ratio obtained in our test workload. The compression ratio depends upon the application and the data it processes. The compression ratio is not an externally configurable parameter; it is an inherent property of the data.
Figure 3: Log compression ratio
Cost of Log Compression
The outstanding benefits of log compression come with some processing cost. The log records are compressed on the principal before being sent to the mirror, where they are uncompressed before being applied to the mirror database. The extra tasks of compressing and uncompressing the log adds some processing overhead on the principal and mirror respectively, resulting in higher CPU usage. Figure 4 illustrates the CPU usage of the principal and mirror servers at various network bandwidths, with and without log compression.
Figure 4: CPU Usage with log compression
As illustrated in Figure 4, the CPU usage on the principal and mirror servers goes up significantly with log compression, sometimes by as much as twice the CPU usage without log compression. One reason for increased CPU usage is the processing overhead introduced by compressing and uncompressing the log records. The other reason is that the servers are now processing a much larger number of transactions.
It is important to note the tradeoff between the increased CPU usage and the improved throughput of the application. If your application generates a significant amount of transaction log, you may notice reduced throughput and reduced CPU usage when you configure synchronous database mirroring in SQL Server 2005 (Refer to the white paper Database Mirroring Best Practices and Performance Considerations for some data points). The log compression feature introduced in SQL Server 2008 will get you back some of that throughput, and some of that CPU load.
Summary
SQL Server 2008 introduces a new feature that compresses the log stream sent from the principal to the mirror in a database mirroring configuration. Compressing the log stream results in improved application throughput, at the cost of increased CPU load. The improvement in application throughput as well the increase in CPU load are both dependent upon the workload. Some workloads may find that the throughput is constrained by CPU capacity. It is recommended that you test with appropriate workload to estimate the expected improvement in application throughput and increase in CPU load in your environment.
Published Sep 17 2007, 02:18 AM by SanjayMishra Filed under: Database, Availability, Performance
原文：http://sqlcat.com/technicalnotes/archive/2007/09/17/database-mirroring-log-compression-in-sql-server-2008-improves-throughput.aspx