ptg 614 CHAPTER 19 Replication . Setting a minimum amount of memory allocated to SQL Server by using the Min Server Memory option to guarantee ample memory across the board. . Using good disk drive physical separation rules, such as keeping the transaction log on a separate disk drive from the data portion. Your transaction log is much more heavily used when you opt for transactional replication. . Putting your snapshot working directory on a separate disk drive to minimize disk drive arm contention. You should use a separate snapshot folder for each publication. . Publishing only what you need. By selectively publishing only the minimum amount of data required, you implement a much more efficient replication configu- ration, which is faster overall. . Trying to run snapshots in nonpeak times so your network and production environ- ments aren’t bogged down. . Minimizing transformation of data involved with replication. Log Shipping If you have a small need to create a read-only (ad hoc query/reporting) database environ- ment that can tolerate a high degree of data latency, you might be a candidate for using log shipping. Log shipping is still a feature for SQL Server 2008, but it will be deprecated by the next release. In other words, it might be easy to use and easy to manage, but it is being phased out as a feature of SQL Server. For this reason, we do not describe it in this book (it is described in detail in SQL Server 2000 Unleashed, though). For those who have current log shipping configurations, it is time to move to database mirroring. This transi- tion will be easy because the two capabilities are so much alike. (Actually, many aspects of database mirroring came from log shipping.) Data Replication and Database Mirroring for Fault Tolerance and High Availability SQL Server 2008 allows you to use combinations of options to achieve higher availability levels. A prime example is combining data replication with database mirroring to provide maximum availability of data, scalability to users, and fault tolerance via failover at poten- tially each node in the replication topology. You can start with the publisher and distribu- tor, making them both database mirror failover configurations. Building up a combination of both options together is the best of both worlds: the super low latency of database mirroring for fault tolerance and the high availability (and scalability) of data through replication. (For more information, see Chapter 20, “Database Mirroring.”) Download from www.wowebook.com ptg 615 Summary 19 Summary Replication is a powerful feature of SQL Server that can be used in many business situa- tions. Companies can use replication for anything from roll-up reporting to relieving the main server from ad hoc queries and reporting. It is critical to let your company’s require- ments drive the type of replication technique to use. Determining the replication option and configuration to use is difficult, but actually setting it up is reasonably easy. Microsoft has come a long way in this regard. Peer-to-peer replication seems to have the most promise of delivering master-master symmetric replication in a production environment. Microsoft’s overall architectural approach and implementation is the model for the indus- try. You should not be afraid to use this facility. It is more than production-worthy, and the flexibility it offers and the overall performance are just short of incredible, incredible, incredible (replication humor for you). In Chapter 20 we delve into the capability to make an image of a database (a mirror) for failover purposes using the database mirroring mechanism available within SQL Server 2008. This is a landmark addition for SQL Server. Download from www.wowebook.com ptg This page intentionally left blank Download from www.wowebook.com ptg CHAPTER 20 Database Mirroring IN THIS CHAPTER . What’s New in Database Mirroring . What Is Database Mirroring? . Roles of the Database Mirroring Configuration . Setting Up and Configuring Database Mirroring . Test ing Fai lover from the Principal to the Mirror . Client Setup and Configuration for Database Mirroring . Migrate to Database Mirroring 2008 as Fast as You Can . Using Replication and Database Mirroring Together . Using Database Snapshots from a Mirror for Reporting Database mirroring is such a huge technology jump in capabilities that even the smallest company can now provide near-real-time database failover without the fancy, expensive hardware required with more complex configura- tions, such as with SQL Server Clustering (that is built on Microsoft Cluster Services [MSCS]). MSCS requires shared resources, separate network connections for internal heart- beat communication, and so on. In addition, multiple layers of software are involved (MSCS plus SQL Server). With database mirroring, you can set up a near-real-time database failover environment using all conventional, low- cost machines, without any complex hardware compatibil- ity requirements, and database mirroring can fail over in as little as 3 seconds! Database mirroring effectively allows anyone to immedi- ately step up to nearly 99.9% (at least three nines) availabil- ity at the database layer at a very low cost, and it is easily configured and managed. What’s New in Database Mirroring Performance, performance, and more performance! This is the key improvement for database mirroring in SQL Server 2008. This performance improvement was brought about by Microsoft’s efforts to isolate and resolve the bottleneck in database mirroring that existed with SQL Server 2005. That bottleneck centered around the bulky transmission of full- size log records from one SQL Server to another. Improvements in SQL Server 2008 are centered around the data compression used on the log records sent from one server to the other. Later in this chapter we show you some Download from www.wowebook.com ptg 618 CHAPTER 20 Database Mirroring results of a benchmark involving SQL Server 2005 and SQL Server 2008 that show the major impact of this enhancement. In addition, as records are being written to the mirror, automatic page repair can occur if SQL Server finds any page that is not intact, adding more reliability and stability to the overall SQL Server platform. A few more interesting performance counters and new dynamic management views that provide visibility into the health of your mirroring implementation round out the new features. Microsoft SQL Server 2008 is shifting very strongly to a goal of providing a Database Engine foundation that can be highly available 7 days a week, 365 days a year. With data- base mirroring, Microsoft is providing the masses with the opportunity to achieve that dream much more quickly. Database mirroring was first introduced in SQL Server 2005. It was earlier known as Real-time Log Shipping (RTLS) and then had another name for a while, and it finally ended up being called database mirroring—which is what it really is. The key breakthrough that allowed Microsoft to offer database mirroring was something called “copy-on-write” technology. We describe it in more detail in a bit. Suffice it to say that with copy-on-write technology, a transaction can be distributed (that is, written) to another completely separate SQL Server database immediately, and that other database can, in turn, be used as a failover (that is, it can be used to fail over to in less than 3 seconds). NOTE The examples in this chapter are based on the SQL Server 2005 version of the AdventureWorks database rather than the newer AdventureWorks2008 or AdventureWorks2008R2 sample databases used for many of the examples in the other chapters in this book. The reason for this is because Database Mirroring cannot be implemented on a database that is also configured for FILESTREAM storage. The 2008 and 2008R2 versions of the AdventureWorks database make use of FILESTREAM storage. Fortunately, the 2005 version of the AdventureWorks database can be installed using the same installer that installs the AdventureWorks2008 or AdventureWorks2008R2 database. If you didn’t install AdventureWorks when you installed either of these sample databases, simply relaunch the installer and choose to install the AdventureWorks OLTP database. For more information on downloading and installing the AdventureWorks sample data- bases, see the Introduction chapter. What Is Database Mirroring? When you mirror a database, you are essentially asking for a complete copy of a database to be created and maintained, with as much up-to-the-second completeness as possible; you are asking for a mirror image. Database mirroring is a database-level feature. This means that there is no support for filtering, subsetting, or any form of partitioning. You Download from www.wowebook.com ptg 619 What Is Database Mirroring? mirror a complete database or nothing at all. This limitation actually keeps database mirroring simple and clean to implement. It also certainly provides some drawbacks, such as burning up twice the amount of disk storage, but what you get in return is well worth the cost in storage. Database mirroring works through the transaction log of the principal database (of the database that is to be mirrored). You can mirror only a database that uses the full database recovery model. Otherwise, it would not be possible to forward transaction log entries to another server. Through the use of copy-on-write technology, a change to data in a primary server’s database (as reflected in active transaction log entries) is first “copied” to the target server, and then it is “written” (that is, applied or restored) to the target database server (that is, to the mirror server) transaction log. That is why it’s called copy-on-write. Database mirroring is very different from data replication. With replication, database changes are at the logical level (insert, update, delete statements; stored procedure execu- tions; and so on), whereas database mirroring uses the actual physical log entries on both the primary database server side and the mirror database server side. Effectively, the physi- cal “active” log records from the transaction log of the principal database are copied and written directly to the transaction log of the mirror database. These physical log record- level transactions can be applied extremely quickly. As these physical log records are being applied to the mirror database, even the data cache reflects the forward application of the log records. This makes the entire database and data cache ready for the principal to take over extremely quickly. And, now with SQL Server 2008, the log records are compressed on the principal side before transmission, which allows more records per transmission to be sent to the mirror server, thus speeding up the whole topology quite a bit. Figure 20.1 shows a typical database mirroring configuration that has three components: . Principal database server—This is the source of the mirroring. You can mirror one or more databases on a single SQL Server instance to another SQL Server instance. You cannot mirror a database on one SQL Server instance to itself (that is, the same SQL Server instance). Remember, you mirror a database, not a subset of the database or a single table. It’s all or nothing. . Mirror database server—The mirror server is the recipient of the mirroring from the principal database server. This mirrored database is kept in hot standby mode and cannot be used directly in any way. In fact, after you configure database mirror- ing, this database shows its status as being in continuous “restore” mode. The reason is that the physical transaction records are continuously applied to this mirror data- base. This database is essentially a hot standby database and is not available for direct database usage of any kind. The reason is that it is used in case the principal fails and must not be tainted in any way (it must be the exact mirror image of the principal. The one exception to this nonusage scenario is creating database snap- shots from the mirror database (creating database snapshots with a database mirror is described in more detail later in this chapter and in Chapter 32 “Database Snapshots”). 20 Download from www.wowebook.com ptg 620 CHAPTER 20 Database Mirroring SQL Server 2008 Principal Server Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB D SQL Server 2008 Mirror Server Adventure Works DB translog D A B C Client Client ClientClient Network FIGURE 20.1 A basic database mirroring configuration with principal, mirror, and witness servers. . Witness database server—You use the witness database server, which is optional, when you want to be continually checking to see if any failures have occurred to the primary database server and to help make the decision to fail over to the mirror database server. Using a witness server is a sound way to configure database mirror- ing. If you do not identify a witness server, the principal and mirror are left on their own to decide whether to fail over. With the witness server, a quorum is formed (that is, two out of three servers), and it takes the quorum to make a failover deci- sion. A typical scenario is that the principal server fails for some reason, the witness sees this failure, the mirror also sees the failure, and together they agree that the principal is lost and that the mirror must take over the principal role. If the witness still sees that the principal is alive and well, but the communication between the mirror and principal has been broken, the witness does not agree to fail over to the mirror (even though the mirror thinks it must do this because it lost connection to the principal). Witness servers are usually put on separate physical servers. Copy-on-Write Technology The copy-on-write technology is at the core of the database mirroring capability. Look back at Figure 20.1, and notice what happens in a High Safety with Automatic Failover mode (synchronous mode): Download from www.wowebook.com ptg 621 Roles of the Database Mirroring Configuration 1. A transaction from a client connection to the principal server (A) is written to the AdventureWorks database (D). 2. When the transaction is written to the principal server’s transaction log, it is imme- diately copied (B) and written to the mirror server (D). 3. When this physical log record is written to the mirror server, it sends back an acknowledgment (C) to the principal of its write success. This is the copy-on-write technology. The end result is that the mirror server is in exactly the same state as the principal server (if the physical log record has been successfully written on the mirror side). If failure occurs now, the mirror server can pick up all process- ing from the clients extremely quickly and without data loss. NOTE Database mirroring cannot be used for any of SQL Server’s internal databases— tempdb, masterdb, msdb, or modeldb. Database mirroring is fully supported in SQL Server Standard Edition, Developer Edition, and Enterprise Edition, but it is not support- ed in SQL Server Workgroup Edition or Express Edition. However, machines running these server editions could be used as witness servers. When to Use Database Mirroring As mentioned earlier in this chapter, database mirroring elevates the availability level of a SQL Server–based application to a very high level without any special hardware and extra administration staff skills. However, when you should use database mirroring varies depending on your true needs. Basically, if you need to increase the availability of the database layer, have automatic data protection (that is, redundant storage of data), or decrease the downtime that would normally be required to do upgrades, you should use database mirroring. An ever more popular scenario for database mirroring is when you need to offload reporting that is easily satisfied with periodic database snapshots. This usage provides great relief from heavily burdened transactional servers also used for reporting. Finally, if you need data distribution, high availability, and high data resiliency, using data replication with data- base mirroring is also a good idea. We discuss these latter two ideas later in this chapter. Roles of the Database Mirroring Configuration As you have seen, a typical database mirroring configuration has a principal server, mirror server, and witness server. Each of these servers plays a role at some point. The principal and mirror switch roles, so it is important to understand what these roles are and when a server is playing a particular role. 20 Download from www.wowebook.com ptg 622 CHAPTER 20 Database Mirroring Playing Roles and Switching Roles A role corresponds to what a server is doing at a particular point in time. There are three possible roles: . Witness role—If a server is playing a witness role, it is essentially standing along- side both partners of a database mirror configuration and is used to settle all argu- ments. It is getting together with any one of the other servers and forming a quorum to come up with decisions. The decision that it will participate in is whether to fail over. That is it. As mentioned before, the witness server can be any edition of a SQL Server (even SQL Server Express, the free version). . Principal role—If a server is playing a principal role, it is the server that the appli- cation will be connected to and that is generating the transactions. One of the part- ners in the database mirror must start out as the principal. After a failure, the mirror server takes over the principal role, and the roles reverse. . Mirror role—If a server is playing a mirror role, it is the server that is having trans- actions written to it. It is in a constant recovery state (that is, the database state needed to be able to accept physical log records). One of the partners in the database mirroring configuration must start out in the mirror role. Then, if a failure occurs, the mirror server changes to the principal role. Database Mirroring Operating Modes With database mirroring, you have the option of deploying in one of three modes: high safety with automatic failover mode (high availability with a witness server), high safety without automatic failover mode (high protection without a witness server), and high- performance mode. Each mode has different failure and protection characteristics and uses the database mirroring configurations slightly differently. As you might expect, the high- performance mode offers the least amount of protection; you must sacrifice levels of protection for performance. Database mirroring runs with either asynchronous or synchronous operations: . Synchronous operations—With synchronous operations, a committed transaction is committed (that is, written) on both partners of the database mirroring pair. This obviously adds some latency cost to a complete transaction because it is across two servers. High-safety modes use synchronous operations. . Asynchronous operations—With asynchronous operations, transactions commit without waiting for the mirror server to write the log to disk. This can speed up per- formance significantly. High-performance mode uses asynchronous operations. Whether the operations are asynchronous or synchronous depends on the transaction safety setting. You control this setting through the SAFETY option when configuring with Transact-SQL (T-SQL) commands. The default for SAFETY is FULL (which provides Download from www.wowebook.com ptg 623 Setting Up and Configuring Database Mirroring synchronous operations). You set it to OFF for asynchronous operations. If you are using the mirroring wizard, this option is set for you automatically. Of the three modes, only the high safety with automatic failover mode (high-availability mode) requires the witness server. The others can operate fine without this third server in their configuration. Remember that the witness server is looking at both the principal and mirror server and will be utilized (in a quorum) for automatic failover. Role switching is the act of transferring the principal role to the mirror server. It is the mirror server that acts as the failover partner for the principal server. When a failure occurs, the principal role is switched to the mirror server, and its database is brought online as the principal database. Failover variations are . Automatic failover—Automatic failover is enabled with a three-server configura- tion involving a principal, mirror, and witness server. Synchronous operations are required, and the mirror database must already be synchronized (that is, in sync with the transactions as they are being written to the principal). Role switching is done automatically. This is for high-availability mode. . Manual failover—Manual failover is needed when there is no witness server and you are using synchronous operations. The principal and mirror are connected to each other, and the mirror database is synchronized. Role switching is done manu- ally. This is for high safety without automatic failover mode (high-protection mode). You are making the decision to start using the mirror ser ver as the principal (no data loss). . Forced service—In the case of a mirror server being available but possibly not syn- chronized, the mirror server can be forced to take over when the principal server has failed. This possibly means data loss because the transactions were not synchronized. This is for either high safety without automatic failover mode (high-protection mode) or high-performance mode. Setting Up and Configuring Database Mirroring Microsoft uses a few other concepts and technologies in database mirroring. You have already learned about the copy-on-write technology. Microsoft also uses endpoints, which are assigned to each server in a database mirroring configuration. In addition, establishing connections to each server is much more tightly controlled and requires service accounts or integrated (domain-level) authentication. Within SQL Server, grants must also be given to the accounts that will be executing database mirroring. You can completely set up database mirroring by using T-SQL scripts, or you can use the Database Mirroring Wizard within SQL Server Management Studio (SSMS). We always 20 Download from www.wowebook.com . CHAPTER 20 Database Mirroring SQL Server 2008 Principal Server Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB D SQL Server 2008 Mirror Server Adventure Works DB translog D A B C Client. database server This is the source of the mirroring. You can mirror one or more databases on a single SQL Server instance to another SQL Server instance. You cannot mirror a database on one SQL Server. involving SQL Server 2005 and SQL Server 2008 that show the major impact of this enhancement. In addition, as records are being written to the mirror, automatic page repair can occur if SQL Server