Microsoft SQL Server Best Practices with Data Domain Deduplication Storage

Transcription

1 White Paper White Paper Microsoft SQL Server Best Practices with Data Domain Deduplication Storage Abstract Users are faced with many options and tradeoffs when choosing a backup strategy for Microsoft SQL Server databases. This paper maps out those tradeoffs and examines how Data Domain deduplication storage preserves data integrity, meets stringent RTO/RPO objectives, and integrates easily into a multitude of active SQL or third-party backup environments. DEDUPLICATION STORAGE

2 Microsoft SQL Server Best Practices with Data Domain Table of Contents 1. Introduction Basic concepts Additional concepts Executive summary SQL background Recovery models Recovery techniques Terminology Types of backups Selected SQL backup definitions Data Domain product background Advantages of Data Domain in an SQL environment Data transfer rates Integration Planning Important Options Third-Party Backup Applications Microsoft recommendations Summary Appendix A Backup compression Bottlenecks addressed by compression Compression challenges Pick one form of compression, but not both Appendix B Index Fragmentation Addressing the challenge MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

3 1. Introduction Many database administrators prefer native SQL Server backups compared to using third-party backup applications. 4 There is no reliance on the backup administrative team to perform backups or play a role in database recovery. 4 There is no need for a database administrator to become proficient in deploying, configuring, administering, or maintaining a thirdparty backup application. Historically, native SQL backups have been the target of some criticism for a number reasons: 4 Native SQL backup facilities provide little to no automated media management capabilities. While backups performed to disk media eliminated the challenge of manually managing tape cartridges, it also introduced the need for additional disk. The cost of disk versus removable tape media was significant. 4 In addition, many users require retaining an off-site copy of database backups as part of a disaster recovery strategy. Native backup facilities fell short of providing a viable solution for this requirement. Deployed as database backup media, Data Domain deduplication storage addresses the historical pitfalls of performing native database backups: 4 Backups to disk are no longer cost prohibitive due to Data Domain cost-effective backup deduplication ratios. 4 Data Domain replication software enables users to create off-site backup copies that are easily retained for disaster recovery purposes. 4 In addition users may eliminate any need for third-party backup application SQL Server agents and their associated maintenance fees. This paper provides information about the use of Data Domain deduplication storage as backup media for Microsoft SQL Server backups. The target audience includes data protection architects, SQL server database administrative staff, and backup administrators seeking information about integrating Data Domain deduplication storage as a component in a comprehensive data protection strategy. 1.1 Basic Concepts Microsoft SQL backup methodology falls into one of two generic categories. The first consists of native SQL Server database backups. This backup technique creates SQL database backups using tools and utilities native to Microsoft SQL Server and does not rely on third-party backup application software (Figure 1). Benefits include the use of backup and recovery interfaces familiar to the database administrative staff. This ability is included with Microsoft SQL server, and there are no additional third-party software license fees. Figure 1: Native database backup tool. The native database backup tool is easy to use and provides a feature set that addresses many business requirements. Figure 1 depicts the native database backup tool being used to perform a full database backup to disk. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 3

4 The second backup methodology uses third-party backup application software that interfaces with Microsoft SQL Server to perform SQL database backups based on the Virtual Backup Device Interface (VDI). This solution is typically packaged as a database agent specifically for Microsoft SQL server and a particular backup application. When VDI is used, the backup application allows setting customized backup and recovery parameters similar to those that can be employed when using native Microsoft SQL tools and utilities. Third-party backup software may also use available snapshot technologies designed to enhance functionality or otherwise add value to backup and recovery processes (Figure 2). When the snapshot type is based on Microsoft Volume Shadow Copy Service (VSS), the backup application is the VSS requestor, the SQL Server is the VSS writer, and backup is coordinated with a VSS provider. Advanced backup and recovery features such as disk staging and instant recovery may be available with these implementations depending on the backup application and agent being used. Drawbacks to this strategy may include a user interface foreign to the database administrative staff and substantial third-party backup application license fees. Figure 3: Augmented backup solution. This methodology uses two backup solutions in conjunction to satisfy business objectives. SQL native database backups are performed to a Data Domain system and are subsequently backed up by a third-party backup application and written to the same Data Domain system. 2. Executive Summary For those already well briefed on both Microsoft SQL Server and Data Domain, Table 1 presents a summary of the suggested best practices. Explanations and reasoning for these suggestions are discussed later in this paper. Parameters Affecting Deduplication Performance SQL Server 2008 native compression Third-party backup application SQL Server local compression Third-party backup application multiplexing Setting NO_COMPRESSION Disabled None Parameters Affecting Backup and Recovery Performance Setting Figure 2: NetBackup MS SQL Client backup GUI. The NetBackup MS SQL Client graphical user interface is an example third-party backup application that uses VDI to interface with Microsoft SQL server. 1.2 Additional concepts Many customers utilizing the native Microsoft SQL Server database backup methodology augment the solution with third-party backup client agents that effectively protect the native backup data as a flat file. This two-phased methodology is effectively backing up a backup. Among the perceived benefits of the augmented solution is that it allows segregation of the SQL database administrative staff from the data protection staff while providing means to retain database backups in conformance with sound business practices. (Figure 3) BLOCKSIZE BUFFERCOUNT MAXTRANSFERSIZE Stripes Server Disk Subsystem Default 512 bytes or higher based on performance improvements Minimum 2 buffers per stripe (requires available memory based on MAXTRANSFERSIZE value) (requires available memory based on BUFFERCOUNT value) Consider the use of multiple stripes to improve backup and restore data transfer rates Database and log files should be placed on disk storage with performance attributes facilitating required transaction and backup performance metrics 4 MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

5 Parameters Affecting Backup and Recovery Performance IP Network Data Domain System Setting Dedicated backup network that meets or exceeds bandwidth requirements for the desired data transfer rates Sized to meet or exceed ingest rate and backup retention requirements Mount Options Setting When performing native database backups When using a third-party backup server UNC path Dependent on backup application and server OS type Miscellaneous Options Co-mingling native and third-party backup application database backups Replication Setting Yes (this should have a negligible impact on deduplication ratios) Yes, use the Data Domain system to replicate database backups to remote DR site Table 1: Summary of recommendations 3. SQL Background A Microsoft SQL server instance includes system and user databases. System databases are created at installation and include: 4 The master database, which records all of the system-level information for a Microsoft SQL Server. It contains records for all login accounts and all system configuration settings. The master database records the existence and location of all other databases. 4 The model database, which is used as a template that contains the default settings for all databases created within the Microsoft SQL server instance. 4 The msdb database, which is used for scheduling, alerts and jobs. 4 The tempdb database which serves as a global resource that contains all temporary tables and temporary stored procedures. It is re-created every time the Microsoft SQL Server instance is started. Figure 4: System and user databases. Master, model, msdb, and tempdb system databases as provided by the Microsoft SQL Server Management Studio interface. Data protection strategies for the system databases are dependent on the database being protected. For instance, transaction log backups are not supported for the master database. The master database cannot be recovered if a functional version of it does not already exist. Recovery procedures for the master database may include re-installing Microsoft SQL Server such that a backup of the pre-disaster master database can then be restored. The model and msdb databases can contain customized data such as user-specific templates, scheduling information, as well as backup and restore history information. Without a data protection strategy, these items will need to be manually reconstructed in the event of a disaster. The tempdb database is empty when the SQL instance is shut down, and does not require protection as it is re-created at startup. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 5

6 3.1 Recovery models Microsoft SQL Server includes three recovery models: simple, bulk logged, and full. The desired recovery model can be deployed based on requirements. Functionally, each recovery model differs with regard to how backup and recovery strategies are executed. 4 The full recovery model includes log backups. This model typically has no exposure to data loss. Point in time recovery is possible, up to including the last committed transaction. 4 The bulk logged recovery model requires log backups. This model permits high performance bulk copy operations. Recovery to the end of any backup is possible, point in time recovery is not supported. 4 The simple recovery model consists of performing full backups only. Logs are not backed up. In the event database recovery is required, the most recent full backup can be restored. Any changes that occurred subsequent to the last full backup must be redone. From a transactional perspective, the database can only be recovered to the point of the prior full backup. Figure 6: Restore database dialog window. General database restore attributes. Note that by default the full backup and subsequent transaction log backups are all checked. Clicking the OK button would initiate recovery to the most recent possible point in time. Alternatively, recovery to a specific point in time is also possible. Figure 5: Recovery model selection. Selection of the desired recovery model via the Database Properties dialog window. 3.2 Recovery techniques The technique used to restore a database will vary based on the recovery model being used as well as the backup types being performed. Figures 6-9 provide a brief look at restoring a database that was protected using the full recovery model with full and transaction log backups. A single full backup was performed, followed by 5 transaction log backups. Figure 7: Restore database options. Available database recovery options. Note that by default an existing database will not be overwritten. Also note that by default the recovery state is RESOTRE WITH RECOVERY, which leaves the recovered database in an online and usable state after the restore process completes. Figure 8: Recovery query. An example of a recovery transaction that restores the initial full backup followed by the first transaction log backup. The remaining transaction logs were not included in this query for brevity. 6 MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

7 Third-party backup applications will each have a unique recovery interface for databases. Many automate and coordinate the recovery of full and transaction log backups similar to the way native Microsoft SQL Server tools and utilities do. File backups: 4 File Backup This consists of a full backup of all the data in one or more files or filegroups. 4 Differential File Backup This is a backup of one or more files containing data extents changed since the prior full backup of each file. Transaction log backups: 4 Regular transaction log backups are required when using the full or bulk-logged recovery models. This backup contains all log records that have not been backed up previously. Copy-Only backups: 4 Database backups usually change the database in some way, such as truncating a transaction log in the case of a full database backup. Copy-Only backups can be used in cases where a backup of a database is required without changing the database. Figure 9: NetBackup MS SQL client restore GUI. In this example a single full database backup and 5 transaction log backups are available for recovery. 4. Terminology Entire databases, specific database files, file groups, and transaction log backups are among the supported backup types with Microsoft SQL Server. This section defines the terminology associated with a given backup type. 4.1 Types of backups Database backups: 4 Database Backup This is a full backup of an entire database and represents the state of the database at the point when the backup is completed. 4 Differential Database Backup This is a backup of all the files within a database, and contains only the extents modified since the most recent full backup of each file. Restoring a database protected with full and differential backups to the most recent point in time includes recovering the most recent full and differential backup. 4.2 Selected SQL backup definitions A subset of Microsoft SQL backup definitions as they relate to the use of Data Domain deduplication storage are detailed in this section. Examples shown here use the Microsoft SQL Server Management Studio query interface. The use of these keywords and associated parameters can impact backup performance in terms of both data deduplication and data transfer rates. COMPRESSION Specific to SQL Server 2008 Enterprise and later versions, backup compression can be enabled or disabled. The default product installation does not compress backups. A server-level compression setting can be applied that alters default behavior. The use of the COMPRESSION keyword within a backup SQL transaction explicitly enables backup compression. The use of the NO_COMPRESSION keyword within a backup SQL transaction explicitly disables backup compression. Partial backups: Partial backups provide flexibility for backing up databases that contain some number of read-only file groups. 4 Partial Backup This is a partial backup of all data in the primary filegroup, each read/write filegroup, and any optionally specified read-only files or filegroups. 4 Differential Partial Backup This backup contains only the extents modified since the prior partial backup of the same set of filegroups. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 7

8 Figure 11: Full database backup with BUFFERCOUNT = 1. A full backup of the Test_One database using the optional BUFFERCOUNT keyword with a parameter value equal to 1. This query executed in seconds with a data transfer rate equal to MB/s. Figure 10: SQL Server 2008 native compression. The Compress backup server-level property. This property is used for backup jobs that do not explicitly enable or disable compression. The use of native SQL server compression is not recommended as a best practice when using Data Domain deduplication storage. BLOCKSIZE The BLOCKSIZE keyword can be used to alter physical block size used when writing to backup media. By default the backup process will automatically select a block size appropriate for the backup device. Supported sizes are 512, 1K, 2K, 4K, 8K, 16K, 32K and 64K bytes. The default value used for disk backup is 512 bytes. The default 512-byte size yields excellent performance with Data Domain systems. Third-party backup applications may substitute their own default value. The fact that this parameter can be adjusted is included as reference. The use of larger sizes may improve or degrade performance. Users are encouraged to investigate further to determine what value may provide optimal results in their environment. BUFFERCOUNT The BUFFERCOUNT keyword specifies the total number of I/O buffers used for the backup process. Any positive integer value can be specified. The practice of using a minimum of 2 buffers per stripe is recommended. This practice simultaneously provides one buffer that can be written into from the database (a reader thread) and one buffer that can be read out of for data transfer to a storage device (a writer thread). Buffers consume memory on the Microsoft SQL Server based on the BUFFERCOUNT and MAXTRANSFERSIZE keyword parameters. Figure 12: Full database backup with BUFFERCOUNT = 2. The same full database backup represented in figure 11 using the optional BUFFERCOUNT keyword with a parameter value equal to 2. The use of two buffers increased backup data transfer rate performance by approximately 9% when compared to using a single buffer. MAXTRANSFERSIZE The MAXTRANSFERSIZE keyword specifies the unit of transfer in bytes used between SQL server and the backup media. Values can range from 64 KB to 4 MB. Larger units of transfer are generally preferred to smaller values. Excessive use of buffers combined with larger units of transfer consumes Microsoft SQL Server memory. Care should be taken to avoid memory-related errors as the result of using these parameters. STRIPES While not a keyword within the context of Microsoft SQL Server, the term stripes correlates to the number of simultaneous backup streams to be created for a given backup operation. In the case of disk backups with SQL server, multi-streamed backups are performed by specifying a number of backup disk targets with the BACKUP command. The recommended use of SQL stripes is as a speed matching technology. Multiple backup streams from a given database can be simultaneously written to a target Data Domain system in an effort to achieve an aggregate data transfer rate that aligns with business requirements. 8 MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

9 5.2 Data transfer rates Multiple business objectives are considered when determining required backup and recovery data transfer rates. Decision criteria include backup window duration, log growth, and recovery time. By definition, slow backups are those that fail to meet or exceed business objectives. Understanding factors that can affect performance is critical to removing them from the environment. Figure 13: Multi-striped database backup to disk. A database backup that uses 8 stripes in an effort improve backup data transfer rate performance. Multiple stripes can be used to better match data transfer rate capabilities between source and destination media. 5. Data Domain product background Data Domain deduplication storage systems minimize backup and recovery times, storage and network bandwidth, and risk of data loss. Data Domain offers a comprehensive range of products to meet the backup and archive storage needs of companies of all sizes as they seek to reduce costs and simplify data management. Data Domain systems also offer replication that is extremely easy to deploy. The primary advantage of Data Domain system replication is that the data is all deduplicated and compressed prior to being sent over the network. 5.1 Advantages of Data Domain in an SQL environment Data Domain systems can be directly integrated into Microsoft SQL Server environments as disk backup media. In addition, Data Domain systems support all leading enterprise backup and archive applications for seamless integration into existing IT infrastructures. The use of different backup methodologies with Microsoft SQL Server and Data Domain systems typically has a negligible effect on overall data deduplication ratios. This enables performing native database backups in conjunction with database backups controlled by a third-party backup application without affecting deduplication efficiency. This includes third-party backup applications that use an SQL agent, with or without VSS snapshots. Additionally, the use of different numbers of stripes or different BLOCKSIZE values also has a negligible impact on deduplication ratios. Data Domain replication can be used to create offsite copies of SQL backups faster and more economically than legacy tape-based strategies. Data Domain replication makes advanced disaster recovery preparedness for MS SQL Server a reality. A reasonable place to start any backup performance investigation is to understand the theoretical maximum speed at which SQL Server can process a given database backup. Performing a database backup to a null disk device provides an estimate of that maximum achievable speed in a given environment. (Figure 14) Figure 14: Database backup to a null device part 1. The results of the query indicate that the theoretical maximum rate at which the SQL Server backup function can extract data from this database using a single stripe is approximately 80 MB/s. Regardless of the data transfer rate at which backup media can accept data, backing up this database as it currently stands will be speed limited to 80 MB/s when using a single stripe. Factors that can contribute to slow database backups to a null disk device include disk file fragmentation and the underlying disk storing the database. In the example noted in figure 14, the.mdf and.ldf files associated with the Test_One database resided on a single spindle 250 GB 7200 RPM SATA disk drive. Relocating the.mdf and.ldf files to a higher performance striped external RAID array volume increased the rate at which SQL Server was able to process the database backup. Figure 15: Database backup to a null device part 2. Improved results as the single stripe database backup to a null disk device now executes at more than twice the initial data transfer rate. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 9

10 OST-compliant backup application such as Veritas NetBackup from Symantec). Additionally, OpenStorage adds enhanced backup image replication capabilities known as optimized duplication. In this scenario, backup images are replicated from one Data Domain system to another under the direct control of NetBackup. NetBackup monitoring, reporting, and cataloging of duplicates can be used to architect a comprehensive disaster recovery plan. Figure 16: Database backup to multiple null devices. The use of multiple null disk devices. Similar to multi-striped backups, the use of multiple null disk devices increases the number of readers used during the backup process. Consider the use of non-default values for BUFFERCOUNT and MAXTRANSFERSIZE in addition to the use of multiple backup stripes when investigating database backup performance with one or more null disk devices. (Figure 16) Once an acceptable null device backup data transfer rate is achieved, additional steps can be taken to understand and remove other bottlenecks from the remainder of the backup process. 6.1 Planning Capacity and performance planning play a critical role in both successful deployment and ongoing production usage of a Data Domain system. A detailed capacity analysis should be performed by a knowledgeable Data Domain system engineer. The analysis considers database sizes, growth rates, change rates, and retention periods as input criteria. Performance analysis considers data points such as the required aggregate data transfer rate for backups, connection topology requirements to support the data transfer rate, and the Data Domain system required to meet or exceed the required data transfer rate. Beyond capacity and performance planning are additional considerations for Data Domain system replication. 4 What database backups should be replicated? Replicating all database backups is certainly possible. However, many users will want to implement replication at a more granular level. Production database backups are usually excellent replication candidates, whereas development and test database backups are less critical. An analysis of network bandwidth and destination disk space requirements should be performed by a knowledgeable Data Domain system engineer. Figure 17: Nominal database backup performance improvement. This query shows a moderately tuned 8 stripe SQL database backup with an aggregate data transfer rate of approximately 172 MB/s indicating that the network attached backup devices are now limiting throughput. 6. Integration Direct integration with Microsoft SQL Server, where the Data Domain system is used as disk backup media, is accomplished by using the Data Domain system as a CIFS (Common Internet Filesystem) share. As a general rule, the UNC path to the share should be used instead of a mapped drive because: a) scheduled backups may execute when no user is logged on to the server and b) when Sqlservr.exe is executed as a service, it has no relation to a login session. Third-party backup applications used to protect Microsoft SQL Server can also take advantage of Data Domain systems employed as backup media. Data Domain systems are easily configured as supported backup media types including VTL, CIFS share, NFS mount, or OpenStorage disk pool (OpenStorage requires an 4 Will database backups be replicated to a disaster recovery site, or between multiple production sites? Backups are typically replicated to serve as a second backup copy for recovery in the event of a disaster. When backups from a primary site are being replicated to a secondary site, planning is relatively straightforward. Users with multiple primary sites may decide to implement a bidirectional replication solution where database backups from either site are replicated to the alternate site. Proper planning should render an outline detailing which database backups are being replicated to each location. 4 Will tape-based backup copies be required? Some users replicate backup images to a central location for disaster recovery purposes while also using the solution as a vehicle that enables centralized tape creation. The third-party backup application used to create tape-based backup copies will dictate any additional considerations or restrictions that this solution involves. A knowledgeable Data Domain system engineer will be able to assist with this planning task. 10 MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

11 6.2 Important Options Backup types The goal of backups is to satisfy recovery time and point objectives. Outlining a strategy of full, differential, and transaction log backups is beyond the scope of this paper. That stated, there are a few key points worth noting: 4 Performing full backups frequently with Data Domain deduplication storage does not create a storage usage penalty, as redundant database segments do not consume additional disk space. While this may appear to enable the ability to perform full backups more frequently, the load full backups place on the Microsoft SQL Server and connection topology to the Data Domain system should be taken into consideration. 4 When split-mirror or snapshot backups are performed and controlled by a third-party backup application, the Data Domain system is easily integrated as a backup storage device. The features provided by these backup techniques (low-impact backups, instant recovery, etc.) do not preclude the use of Data Domain technology Compression Data Domain recommends NOT using Microsoft SQL Server-based compression in conjunction with backups written to Data Domain systems. This topic is covered in greater detail in appendix A. Whenever possible, the network used for backup and recovery communications should be segregated from other production networks. This best practice recommendation seeks to assure that network bandwidth is available for backup and restore jobs to meet or exceed business objectives. Network bandwidth requirements may dictate the need for a topology that supports data transfers in excess of 125 MB/s. All Data Domain systems support the use of multiple GbE network interfaces, and many support the use of 10 GbE network interfaces. A knowledgeable Data Domain system engineer will be able to assist with planning the deployment based on user requirements and available resources. 6.3 Third-Party Backup Applications When Data Domain systems are integrated with third-party backup applications, it is important to note that Microsoft SQL Server backup parameters are handled the same as when compared to a native SQL Server backup implementation. The COMPRESSION, BLOCKSIZE, BUFFERCOUNT, and MAXTRANSFERSIZE keywords, as well as any striping, are still valid parameters. Some of these settings may be unavailable when using a third-party backup application. (Figures 18, 19) Multiplexing When the Data Domain system is integrated as a backup device with a backup application that supports multiplexed backups, Data Domain recommends disabling multiplexed backups. Multiplexing limits the ability of the Data Domain system to deduplicate incoming data. Historically used as a speed matching solution where multiple slower data streams were multiplexed into a single stream to take advantage of a somewhat faster tape drive, backups to disk derive no advantage from multiplexing. Whether deployed as a CIFS share, NFS mount, VTL, or OpenStorage disk pool, Data Domain systems accommodate writing multiple backup streams in parallel without multiplexing Network When Data Domain systems are deployed as a CIFS backup share, Data Domain recommends interconnecting SQL Servers and Data Domain systems using a dedicated backup area network. Figure 18: SQL backup parameters NetBackup Third-party backup applications may allow the use of keyword parameters similar to native Microsoft SQL Server backup tools. Figure 18 shows the NetBackup MS SQL Client interface. Note as of NetBackup version there is no ability to override the MS SQL 2008 server level compression setting. When deployment is in conjunction with a backup application as a CIFS share, NFS mount, or OpenStorage disk pool, Data Domain similarly recommends interconnecting backup application media servers and Data Domain systems using a dedicated backup area network. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 11

12 8. Summary A Data Domain system makes an excellent target for Microsoft SQL Server backups because it: 4 Integrates easily and seamlessly into existing Microsoft SQL Server environments 4 Allows the database administrative team to retain a greater number of full backup images online, thereby optimizing recovery options while occupying minimal footprint in the data center 4 Greatly reduces dependence on tape Figure 19: SQL backup parameters Backup Exec Details of the ability to set MS SQL Server 2008 compression on a per job basis with Backup Exec version Other parameters such as BUFFERCOUNT and MAXTRANSFERSIZE are absent from the Backup Job Properties dialog window. Users of third-party backup applications seeking to exploit the full compliment of available Microsoft SQL Server backup options should contact their software provider in the event additional information is required. 7. Microsoft Recommendations A comprehensive collection of resources that address Microsoft SQL Server backup and restore are available online. This section includes a brief sampling of technical articles that can be referenced as required. 4 SQL Server 2000 Backup and Restore 4 Backing Up and Restoring Databases in SQL Server from SQL Server 2005 Books Online 4 Backing Up and Restoring Databases in SQL Server - from SQL Server 2008 Books Online 4 Optimizing Backup and Restore Performance in SQL Server 9. Appendix A Backup Compression Performing compression on the Microsoft SQL Server when backups are executed can provide benefit by reducing the overall size of the backup. Smaller backups require fewer I/O operations to write to backup devices, consume less backup media, and may execute faster when compared to uncompressed backups. This appendix examines the tradeoffs associated with server-based compression; the use of Microsoft SQL Server CPU cycles versus implementing a backup infrastructure that reduces impact to transactional processing performance. 9.1 Bottlenecks addressed by compression Examining the backup data transfer path assists in providing an understanding of the backup bottlenecks that compression is able to circumvent: 4 SQL Server to directly connected disk storage 4 SQL Server to directly connected tape storage 4 SQL Server network connected to a backup application media server Bandwidth constraints between the Microsoft SQL Server and destination storage device are mitigated with server-based compression as less data is being transferred between the server and storage device. Likewise, write speed limitations of the storage device are also mitigated by writing less data during a backup. 9.2 Compression challenges While the benefits of compression are understood, there are potential drawbacks that should be noted: 4 Compression consumes SQL Server resources 4 Disk I/O related to reading database content is unchanged CPU resources on the Microsoft SQL Server are used to accomplish compression at backup time. If online transactions are impacted by the backup process, adding compression to the equation may induce a severe performance impact. 12 MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN

13 Figure 20: CPU utilization without server based compression Figure 21: CPU utilization with MS SQL Server 2008 native compression Figure 23: Data Domain system status. Sample output of the sysstat command on a Data Domain system captured during a database backup. When compression and deduplication are performed on the Data Domain system, CPU usage on the SQL Server platform is greatly reduced when compared to the use of server-based compression. Also worth noting is that the Net in data transfer rate is near the theoretical maximum that can be achieved with 2 GbE network connections. The next logical step to eliminate this bottleneck would be to use additional GbE interfaces or to employ the use of a single 10 GbE network connection. Figure 22: CPU utilization with a third party solution using level 5 compression Figures 20 through 22 detail % Processor Time for the same database backup on a dual quad-core 2.66 GHz server platform with Microsoft SQL Server Data transfer rates and CPU usage vary widely in these examples. No SQL transactions or other activity beyond the single backup were executing at the time these metrics were captured. Note that all three backups used the same Data Domain system as a disk backup device. Also note that the sampling rate used for the performance monitor for figure 17 was decreased to accommodate the longer running backup job. 9.3 Pick one form of compression, but not both The recommended best practice is to architect a solution that compresses database backup data once. There are multiple reasons for this. First, compressing data that has already been compressed usually ends with a larger resulting data set when compared to compressing the data once. Second, the result of multiple compression operations has a negative impact on Data Domain deduplication where the efficient use of disk is reduced. In short, the Data Domain system is designed specifically to optimize compression and deduplication. To get the full value from the Data Domain system, letting it perform the compression will always return the best results. With server based compression CPU usage is elevated to a point where non-backup transactions may be elongated. Backing up multiple databases simultaneously may not be practical with server based compression. 4 Compression and deduplication Native Microsoft SQL Server 2008 compression, or compression provided by a third-party backup application, occurs on the Microsoft SQL Server platform. Data Domain deduplication technology is different in that Microsoft SQL backups are compressed and deduplicated on the Data Domain system. MICROSOFT SQL SERVER: BEST PRACTICES WITH DATA DOMAIN 13

14 10. Appendix B Index Fragmentation Index fragmentation affects I/O performance of queries whose data pages do not reside in the Microsoft SQL Server data cache. A variety of techniques are commonly used to reduce index fragmentation, including but not limited to DBCC INDEXDEFRAG, DBCC DBREINDEX, and CREATE INDEX WITH DROP EXISTING. While these techniques are effective in reducing index fragmentation, they can also have a negative impact on deduplication. Database administrative teams that routinely defragment all indexes at some predetermined frequency may notice reduced data deduplication rates on their Data Domain systems. The end result is reduced storage efficiency. Index defragmentation has the effect of reorganizing the pages within a database such that Data Domain deduplication sees the backup data stream as new unique data. In addition to the inefficient use of backup device storage space, this can also impact the ability to replicate database backups using Data Domain replication. A greater quantity of unique data blocks equates to replicating a greater quantity of data over what may be a bandwidth limited WAN. Database administrative teams may find themselves in a situation where index fragmentation impacts query performance, and frequent index defragmentation impacts backup storage device performance in terms of deduplication and replication rates. files at deployment to accommodate potential future growth. While it may be impossible to anticipate the size of a given database three years into the future, doing so helps to reduce the possibility that file fragmentation will impact query performance. If automatically growing database files is a requirement, consider growing in large chunks versus small chunks. It may be impractical to locate each database on a unique logical volume, but consider doing so for databases that are expected to grow considerably over time. Finally, disk file fragmentation can be reduced by Windows file system defragmentation utilities such as the Windows Disk Defragmenter. 4 Do all indexes need to be defragmented or just a subset? Data Domain recommends the use of index defragmentation tools based on thresholds and limits versus automatically defragmenting every index on every table whether it is required or not. The suggestion is to understand what indexes and their corresponding fragmentation levels impact performance. These indexes should be monitored for a specific fragmentation threshold, and action taken to defragment these indexes only when necessary. Selective index defragmentation will have less impact on production and will assist in preserving the ability to efficiently deduplicate database backups Addressing the challenge Data Domain recommends addressing these challenges with a balanced approach. For instance, instead of defragmenting all indexes based on a schedule, consider defragmentation based on thresholds. Additionally Data Domain recommends the use of index keys that are less prone to fragmentation in the first place. 4 Is index fragmentation the only issue impacting transaction performance? I/O subsystem performance, memory usage, and CPU utilization can all have a negative impact on query performance. These issues should be diagnosed and resolved versus the use of frequent automatic index defragmentation to improve performance. File fragmentation can also impact performance. Many small databases sharing the same logical disk volume combined with the use of the autogrowth property can cause logically sequential database files to allocate non-sequential physical storage on disk. Ideally, administrators should set the size of database Figure 24: DBCC showcontig command output. This graphic includes extent scan fragmentation data indicating that index C_Customer_I1 does not require defragmentation at this time. 4 Indexes and keys Structuring indexes and keys so as to minimize fragmentation may or may not be realistic in all cases, but it should be considered as it potentially reduces the need to defragment indexes frequently. Index and key inserts that occur at the end of the table and index are likely to reduce fragmentation. Deletes that occur in contiguous chunks also assist in reducing fragmentation. Data Domain 2421 Mission College Blvd., Santa Clara, CA WE-DDUPE, Copyright 2010 Data Domain LLC. All rights reserved. Data Domain LLC believes information in this publication is accurate as of its publication date. This publication could include technical inaccurancies or typographical errors. The information is subject to change without notice. Changes are periodically added to the information herein; these changes will be incorporated in new additions of the publication. Data Domain LLC may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time. Reproduction of this publication without prior written permission is forbidden. The information in this publication is provided as is. Data Domain LLC makes no representations or warranties of any kind, with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Data Domain and Global Compression are trademarks of Data Domain LLC All other brands, products, service names, trademarks, or registered service marks are used to identify the products or services of their respective owners. WP-MSSQL-0210 DEDUPLICATION STORAGE