Microsoft SQL Server 2008 R2 Unleashed- P71 pot

ptg 644 CHAPTER 20 Database Mirroring The ALTER DATABASE and DROP ENDPOINT SQL commands break mirroring on the principal and remove the endpoint: ALTER DATABASE AdventureWorks set partner off go DROP ENDPOINT EndPoint4DBMirroring1430 go From the mirror server instance (not the principal!), you run the DROP DATABASE and DROP ENDPOINT SQL commands, as follows: DROP DATABASE AdventureWorks go DROP ENDPOINT EndPoint4DBMirroring1440 go From the witness server instance, you remove the endpoint as follows: DROP ENDPOINT EndPoint4DBMirroring1450 go To verify that you have removed these endpoints from each server instance, you simply run the following SELECT statements: select name,type_desc,port,ip_address from sys.tcp_endpoints select name,role_desc,state_desc from sys.database_mirroring_endpoints All references to the endpoints and roles are removed. You can also take a peek at the SQL Server log entries being made as you remove data - base mirroring: 02/05/2009 13:06:42,spid55,Unknown,The Database Mirroring protocol transport is disabled or not configured. 02/05/2009 13:06:40,spid55,Unknown,The Database Mirroring protocol transport has stopped listening for connections. 02/05/2009 12:52:55,spid19s,Unknown,Database mirroring connection error 4 ‘An error occurred while receiving data: ‘64(The specified network name is no longer available.)’.’ for ‘TCP:// REM1233 :1440’. 02/05/2009 12:52:55,spid19s,Unknown,Error: 1474 <c/> Severity: 16<c/> State: 1. 02/05/2009 12:52:55,spid19s,Unknown,Database mirroring connection error 4 ‘An error occurred while receiving data: ‘64(The specified network name is no longer available.)’.’ for ‘TCP://REM1233 :1450’. 02/05/2009 12:52:55,spid19s,Unknown,Error: 1474 Download from www.wowebook.com ptg 645 Testing Failover from the P rincipal to the Mirror 20 FIGURE 20.23 Testing failover of a mirrored database . FIGURE 20.24 The failover message for database mirroring. <c/> Severity: 16<c/> State: 1. 02/05/2009 12:51:14,spid21s,Unknown,Database mirroring has been terminated for database ‘AdventureWorks’. These are all informational messages only. No user action is required. As you can see from these messages, you are now in a state of no database mirroring. You have to completely build up database mirroring again if you want to mirror the database again. Testing Failover from the Principal to the Mirror From the SSMS, you can easily fail over from the principal to the mirror server instance (and back again) by using the Failover button on the Database Properties Mirroring page, as shown in Figure 20.23. You must test this failover at some point to guarantee that it works. When you click the Failover button for this database mirroring configuration, you are prompted to continue with the failover by clicking Yes or No, as in the dialog shown in Figure 20.24. Download from www.wowebook.com ptg 646 CHAPTER 20 Database Mirroring FIGURE 20.25 Server instances switch roles following a failover. Remember that clicking Yes closes all connections to the principal server instance that are currently connected to this database. Later, we show you how to make your clients aware of both the principal and mirror server instances so that they can just pick up and run against either server instance, by design. Now, if you look at the Database Properties Mirroring page (see Figure 20.25), you see that the principal and mirror listener port values have switched: the principal instance is now port value 1440, and the mirror instance is port value 1430. The server instances have completely switched their roles. You must now go to the server instance playing the princi- pal role to fail over back to the original operating mode. If you try to open the current mirror server instance database, you get an error stating that you cannot access this database because it is in restore mode. You can also manually run an ALTER DATABASE command to force failover to the mirrored server as follows: ALTER DATABASE AdventureWorks set partner FAILOVER; This command has the same effect as using SSMS or even shutting down the principal SQL Server instance service. One last note with mirroring a database is that you cannot bring the principal offline as you would be able to do in an unmirrored configuration. Download from www.wowebook.com ptg 647 Client Setup and Configuration for Database Mirroring 20 FIGURE 20.26 A client connection string configuration identifying the failover partner. Client Setup and Configuration for Database Mirroring Microsoft has enhanced the client connection capabilities to become mirroring aware. In other words, a client application is now able to connect to either partner in a mirrored configuration. The client would, of course, be connecting only to the server instance that is the current principal. With the help of an extension to the client connection configura- tion file, all .NET applications can easily add both partners to their connection string information, and when a principal fails, they can automatically establish a connection to the new principal (in a mirrored configuration). Figure 20.26 shows the added connection string information that you provide in the configuration file ( app.config) for your appli- cation. This enhancement uses the Failover Partner= addition that identifies the proper failover server instance for this mirrored configuration. As a bonus, we have provided a small .NET C# client application that you can easily use to test client connections in a database mirroring configuration. This C# solution file, SQL Client DB Mirroring Test.zip, is included in the Chapter 20 code samples on the CD supplied with this book. When you expand this file, it builds a complete .NET solution directory with all code needed for this test application. With Visual Studio, you just open the WindowsApplication4.sln file (solution file), and the entire application comes up in Visual Studio. Figure 20.27 shows this simple application in Visual Studio. This simple test program displays data from the Product table in the AdventureWorks data- base (which you are mirroring), along with the exact date and time of the data retrieval, the name of the server instance the data came from, and the SQL process ID (SPID) of the current server instance. This way, you can easily see which physical server the data is coming from. If you are trying to use this program, all you have to do is update the app.config file connection string entry with your two partner server instance names (REM12374333\SQL08DE01 and REM12374333\SQL08DE02, in this example): ConnectionString= “Server= REM12374333\SQL08DE01; Failover Partner= REM12374333\SQL08DE02; Database=AdventureWorks; ” Then you execute the test application. This application automatically connects to the current principal database (AdventureWorks on the REM12374333\SQL08DE01 server instance, in this example), as you can see in Figure 20.28. Download from www.wowebook.com ptg 648 CHAPTER 20 Database Mirroring FIGURE 20.28 A SQL client test against the current principal server instance. FIGURE 20.27 A SQL client test program for database mirroring in Visual Studio. Next, you can fail over the principal to the mirror server, using the Database Properties Mirroring page’s Failover button (refer to Figure 20.22). After you have failed this server over to its mirror (that is, switched roles), you simply click the Retrieve button at the bottom of the client test program to access the data in the AdventureWorks database again. Figure 20.29 shows this subsequent data retrieval. The test application shows the same data rows, along with the date and time of this data retrieval and the name of the server instance from which it got its data. In this case, the data came from the other partner server instance ( AdventureWorks on the REM12374333\SQL08DE02 server instance, in this example). The test application simply uses the added connection information to reestablish its connection to the failed-over server instance (that is, the mirror server), completely transparently to the application. Download from www.wowebook.com ptg 649 Migrate to Database Mirroring 2008 as Fast as You Can 20 FIGURE 20.29 A SQL client test against the current principal server instance (formerly the mirror server) after failover. Migrate to Database Mirroring 2008 as Fast as You Can During our ramp-up on SQL Server 2008, we decided to conduct a benchmark that pitted SQL Server 2005 database mirroring against the exact same configuration with SQL Server 2008 database mirroring. Microsoft had described some performance improvements and other added features that sounded like viable reasons to upgrade to SQL Server 2008. At the heart of our benchmark we would be seeing how much performance improvement was possible with the changes that Microsoft has made to compression of the transaction log records on the principal side, their transmission to the mirror, and the restore to the mirror. Using identical servers, we conducted a fully loaded test with heavy transaction rates—first on SQL Server 2005 and then the exact same database mirroring configuration and transaction load on SQL Server 2008 database mirroring. The results may astound you! First, we ran a transaction sequence of 100,000 iterations of complex update and insert processing against the SQL Server 2005 database mirroring configuration that we built up in this chapter. Figure 20.30 shows the overall load and elapsed time that execu- tion took on SQL Server 2005. As you can see from Figure 20.30, the load was heavy, and it took 6 hours and 5 minutes to complete the 100,000 transactions on the SQL Server 2005 database mirroring configu- ration. We then upgraded the exact same machines to SQL Server 2008 and ran the same transaction load. No other changes of any kind were made. Figure 20.31 shows the overall load and elapsed time of that identical transaction load (100,000 transactions) on SQL Server 2008. As you can see, the exact same transaction load took 3 hours and 34 minutes to complete. This result is nearly 50% faster and is completely transparent from the database and trans- action point of view. Truly remarkable. This translates into being roughly 50% faster in high availability and failover. We think this example provides more than enough justifica- tion to upgrade to SQL Server 2008 as fast as you can. Download from www.wowebook.com ptg 650 CHAPTER 20 Database Mirroring FIGURE 20.31 Transact ion benchmar k against SQL Ser ver 2008 dat abase mirroring . FIGURE 20.30 Transact ion benchmar k against SQL Ser ver 2005 dat abase mirroring . Summarizing, the benchmark results are as follows: . Overall send rate 41% faster (2008 versus 2005) . Overall restore rate 52% faster (2008 versus 2005) . Overall availability topology inherits the restore rate yielding ~50% more availability. We would like to thank the Peace Health database team of John Martin and Jason Riedberger for flawless benchmarking on both of these topologies. Download from www.wowebook.com ptg 651 Using Replication and Database Mirroring Together 20 SQL Server 2008 Publisher Principal Server SQL Server 2008 Mirror Server SQL Server 2008 Distributor Principal Server SQL Server 2008 Witness Server SQL Server 2008 Subscriber SQL Server 2008 Subscriber SQL Server 2008 Mirror Server FIGURE 20.32 Rolling out database mirroring failover within data replication for scalability, availability, and fault tolerance. Using Replication and Database Mirroring Together SQL Server 2008 allows you to use combinations of options to achieve higher availability levels. A prime example would be to combine data replication with database mirroring to provide maximum availability of data, scalability to users, and fault tolerance via failover, potentially at each node in a replication topology. By starting with the publisher and perhaps the distributor, you make them both database mirror failover configurations. Figure 20.32 shows a possible data replication and database mirroring configuration (data- base mirroring of the publisher and database mirroring of the distributor). For further explanation of a transactional replication topology, see Chapter 19, “Replication.” Using database mirroring and replication together is essentially the best of both worlds: you get the super-low latency of database mirroring for fault tolerance, and you get high Download from www.wowebook.com ptg 652 CHAPTER 20 Database Mirroring SQL Server 2008 SQL Server Copy of original pages for snapshot only when a page is changed System Catalog of changed pages Data Pages Adventure Works DB Snapshot AdventureWorks DB FIGURE 20.33 Database snapshots and the original database share pages and are managed within the system catalog of SQL Server 2008. availability (and scalability) of data through replication. The downside of this type of combined capability is that it requires additional servers (for mirroring of the databases). The upside is the increased scalability and resilience of your applications. Using Database Snapshots from a Mirror for Reporting A powerful configuration to help offload reporting workload is to use database snapshots with database mirroring. A database snapshot is a highly efficient feature of SQL Server 2008 that allows for the generation and use of a read-only, stable view of a database at a moment in time (hence, it’s called a snapshot). The database snapshot is also created without the overhead of creating a complete copy of the database or having completely redundant storage. A database snapshot is simply a reference point of the pages used in the database (that is defined in the system catalog). When pages are updated, a new page chain is started that contains the data pages changed since the database snapshot was taken, as illustrated in Figure 20.33. Download from www.wowebook.com ptg 653 Using Database Snapshots from a Mirror for Reporting 20 SQL Server 2008 Principal Server Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB SQL Server 2008 Mirror Server Adventure Works DB translog Network Reporting Users Reporting Users Reporting Users Database Snapshot FIGURE 20.34 A database snapshot defined from a mirror server for reporting use. As the original database diverges from a snapshot, the snapshot gets its own copy of origi- nal pages when they are modified. The copy-on-write technology used for database mirroring also enables a database snapshot. When a database snapshot is created on a database (a mirror database, in this case), all writes check the system catalog of changed pages first; if the snapshot is not there, the original page is copied (using copy-on-write) and is put in a place for reference by the database snapshot (because the snapshot must be kept intact). In this way, a database snapshot and the original database share the data pages that have not changed. Unlike a mirror database, a database snapshot can be accessed by a reporting client in read-only mode, as shown in Figure 20.34. As long as the mirror server is communicating to the principal, reporting clients can access the snapshot database. If the principal fails over to the mirror server, the connections to the snapshot database are disconnected during the database restart process (which makes the mirror server the new principal server). It is possible to reconnect the reporting clients to the database snap- shot after a failover is completed, but you must remember that now both the transactional clients and reporting clients are connected to a single SQL Server instance. This may not be acceptable from a performance point of view. Also, it is always a good idea to keep the number of snapshots to a minimum when creating them against a database mirror. Chapter 32, “Database Snapshots,” covers how to create database snapshots. Download from www.wowebook.com . Together 20 SQL Server 2008 Publisher Principal Server SQL Server 2008 Mirror Server SQL Server 2008 Distributor Principal Server SQL Server 2008 Witness Server SQL Server 2008 Subscriber SQL Server 2008 Subscriber SQL. from a Mirror for Reporting 20 SQL Server 2008 Principal Server Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB SQL Server 2008 Mirror Server Adventure Works DB translog Network Reporting. on SQL Server 2008, we decided to conduct a benchmark that pitted SQL Server 2005 database mirroring against the exact same configuration with SQL Server 2008 database mirroring. Microsoft had