Hướng dẫn học Microsoft SQL Server 2008 part 116 pptx

Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1112 Part VI Enterprise Data Management FIGURE 47-15 Monitoring a database mirroring session Monitoring using System Monitor Apart from using the Database Mirroring Monitor, you can also use System Monitor (previously referred to as Performance Monitor) to monitor database mirroring performance. The SQLServer:Database Mirroring object contains the database mirroring performance counters. The following list describes some of the key counters. Key principal server counters: ■ Log Bytes Sent/sec: Indicates the rate at which the principal is transferring transaction log records to the mirror. ■ Log Send Queue KB: Indicates the total number of transaction log kilobytes that have not been sent to the mirror yet. ■ Transaction Delay: Indicates the delay in milliseconds spent waiting for the commit acknowl- edgment from the mirror. This counter is useful for determining whether database mirroring is impacting performance on the principal server. 1112 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1113 Database Mirroring 47 FIGURE 47-16 Database mirroring history FIGURE 47-17 Setting warning thresholds 1113 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1114 Part VI Enterprise Data Management FIGURE 47-18 Database mirroring warnings ■ Log Compressed Bytes Sent/sec: Indicates the number of compressed bytes of transaction log sent in the last second. To find the factor by which the transaction log stream has been compressed, also referred to as log compression ratio, divide the Log Bytes Sent/sec by Log Compressed Bytes Sent/sec. ■ Log Bytes Sent from Cache/sec: Indicates how much of the transaction log bytes b eing sent from the principal to the mirror is being read from the principal’s in-memory transaction log cache. Keymirrorservercounters: ■ Redo Bytes/sec: Indicates the rate at which log b ytes are being rolled forward on the mirror database. ■ Redo Queue KB: Indicates the total number of transaction log kilobytes that have not been rolled forward to the mirror database yet. To estimate the time it will take the mirror to redo the log, divide Redo Queue KB by Redo Bytes/sec. 1114 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1115 Database Mirroring 47 ■ Log Bytes Received/sec: Indicates the rate at which the log bytes are received from the principal. To estimate the time it will take the mirror to catch up with the principal, divide Log Send Queue KB by Log Bytes Received/sec. ■ Log Compressed Bytes Received/sec: Indicates the number of compressed transaction log bytes received in the last second. ■ Log Bytes Redone from Cache/sec: Indicates the number of redone transaction log bytes that were read from the mirror’s in-memory transaction log cache. For more information on all the performance counters available for database mirroring, refer to the SQL Server 2008 Books Online resource ‘‘SQL Server, Database Mirroring Object’’: http://msdn.microsoft.com/en-us/library/ms189931.aspx. Monitoring using SQL Server Profiler To capture the time taken to switch from the principal to the mirror, launch the SQL Server Profiler tool as follows: 1. From the Start menu, select Programs ➪ Microsoft SQL Server 2008 ➪ Performance Tools ➪ SQL Server Profiler. 2. Select New Trace from the File menu. 3. This is will bring up the Connect to Server dialog. Enter the principal server information and click Connect. 4. On the Trace Properties dialog, enter the trace name in the General tab. 5. On the Trace Properties dialog, click the Events Selection tab. Select the Show all events check box. Expand the Database event and select the Database Mirroring State Change check box. Select the columns TextData (gives a description of the database mirroring state change) and StartTime (indicates the time at which the event started). 6. Click Run to start the capture. Pausing or Removing Database Mirroring After configuring database mirroring you can pause, resume, or remove database mirroring. If database mirroring is affecting your application’s performance, you may want to pause a database mirroring ses- sion. Pausing a database mirroring session causes the mirroring state to change to SUSPENDED.During this time, the principal will not send any transactions to the mirror, and its principal database’s transac- tion log will continue to grow even if you have scheduled transaction log backups. The transaction log will not be truncated because it has to send the transactions to the mirror once the database mirroring session is resumed. To pause a database mirroring session using SQL Server Management Studio: 1. In the Object Explorer on the principal server in SQL Server Management Studio, right-click on the principal database and select Properties. 2. On the Mirroring page (refer to Figure 47-13), click the Pause button. 1115 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1116 Part VI Enterprise Data Management 3. You will be prompted for confirmation. Click Yes. This will pause the database mirroring session, changing the Pause button to Resume. 4. Click the Resume button to resume the database mirroring session. To pause the database mirroring session for the AdventureWorks database in code, connect to either the principal or mirror server and execute the following: ALTER DATABASE AdventureWorks SET PARTNER SUSPEND; To resume the database mirroring session for the AdventureWorks database in code, connect to either the principal or mirror server and execute the following: ALTER DATABASE AdventureWorks SET PARTNER RESUME; To remove a database mirroring session using SQL Server Management Studio: 1. In the Object Explorer on the principal server in SQL Server Management Studio, right-click on the principal database and select Properties. 2. On the Mirroring page (refer to Figure 47-13), click the Remove Mirroring button. 3. You will be prompted for confirmation. Click Yes to confirm, which removes the database mirroring session. This means that the relationship between the partners and witness will be removed and each partner will be left with a separate copy of the database. The mirroring database will be left in the RESTORING state, as the database was created using the RESTORE WITH NORECOVERY command. 4. To resume a database mirroring session after removing it, you need to configure a new database mirroring session as explained earlier in this chapter. To remove the database mirroring session for the AdventureWorks database in code, connect to either the principal or mirror server and execute the following: ALTER DATABASE AdventureWorks SET PARTNER OFF; Role Switching Role switching in database mirroring is the process of changing the principal and mirror roles. Three types of role switching exist based on the database mirroring operating mode: automatic failover, manual failover, and forced failover. Automatic failover is available only in synchronous mode with failover. In this mode, if the principal database becomes unavailable due to any failure and the mirror and witness servers are still connected and the mirroring state is SYNCHRONIZED, automatic failover will occur. Here is a high-level sequence of events that occur in an automatic failover scenario: 1. The principal database becomes unavailable due to some failure. 2. If the principal server is still available, the state of the principal database is changed to DISCONNECTED and all the clients are disconnected from the principal database. 3. The mirror and the witness server detect the failure. 1116 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1117 Database Mirroring 47 The default timeout for communication between the principal, mirror, and witness servers is 10 seconds. If the principal does not respond within the timeout period, it is considered to be down. If you are using high-safety mode, you can change the timeout period using the ALTER DATABASE SET PARTNER TIMEOUT command. The default timeout of 10 seconds works well for most environments. If you do want to change the timeout period, then it is recommended not to set it below 10 seconds, as this may cause false failures. 4. The mirror server recovers the mirror database. 5. The mirror server forms a quorum with the witness server. 6. The mirror server becomes the new principal server and it brings the mirror database online as the new principal database. 7. The old principal server, when it is back online, takes the mirror role and the old principal database becomes the new mirror database and starts synchronizing with the new principal database. Manual failover is available only in synchronous mode with and without failover. As the name suggests, you decide whether to switch the roles of the servers and manually failover the database. Manual failover is used for planned downtime (for example, during hardware or software upgrades). Manual failover is allowed only when the partners are connected and the mirroring state is SYNCHRONIZED.Duringa manual failover, the clients are disconnected from the principal database and the roles of the partners are switched. To perform a manual failover using SQL Server Management Studio: 1. In the Object Explorer on the principal server in SQL Server Management Studio, right-click on the principal database and select Properties. 2. On the Mirroring page (refer to Figure 47-13), click the Failover button. 3. When prompted for confirmation, click Yes to perform a manual failover. To perform a manual failover for the AdventureWorks database in code, connect to the principal server and execute the following: ALTER DATABASE AdventureWorks SET PARTNER FAILOVER; Forced failover, also referred to as forcedservice(withpossibledataloss)is available only in synchronous mode without failover and asynchronous mode. If the principal server is lost, the principal database will be unavailable to the clients. You can make the database available b y manually forcing service on the mirror server by executing the following command on the mirror server: ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS; This will bring the database online on the mirror server, which becomes the new principal server. When the old principal server becomes available, it will automatically assume the mirror role but the database mirroring session will be suspended. To resume the database mirroring session, follow the steps discussed earlier in the chapter. After any type of failover, clients must reconnect to the new principal database. If your applications use Microsoft ADO.NET or SQL Native Client to connect to a database, then in case of a database mirror- ing failover, the a pplications can automatically redirect the clients to the current principal database. You 1117 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1118 Part VI Enterprise Data Management must specify the initial principal server and database and failover partner server in the connection string. The failover partner in the connection string is used as an alternate server name if the connection to the initial principal server fails. If your applications do not use Microsoft ADO.NET or SQL Native Client automatic redirection, you need to use other methods such as network load balancing (NLB), a Domain Name System (DNS) alias, or custom code that will enable your application to failover. After the role-switching process is completed, verify that any database objects such as logins, jobs, main- tenance plans, SSIS packages, and linked servers that reside outside the mirror database are created on the mirror server. For example, if the logins are not created on the mirror server, then users will not be able to connect and you will still have a server down situation. Best Practice I highly recommend thoroughly executing the role-switching steps and documenting them prior to needing to failover to the mirror server. Failure to do this can significantly increase downtime and complexity when you actually need to failover to the mirror server. Summary Database mirroring is an inexpensive software-based solution to achieve high database availability. Database mirroring works by transferring transaction log records f rom the production database on one SQL Server to a mirror database on another SQL Server over the network, either synchronously or asynchronously. Asynchronous database mirroring provides the best performance but has the potential for data loss and does not support automatic failover. Synchronous database mirroring provides a higher level of data protection than asynchronous mode and provides automatic and manual failover options at the cost of reduced application performance. At first glance, database mirroring may appear to be better than log shipping but it is not a replacement for log shipping. Each solution has unique features, and depending on your business requirements you may need to select one or both solutions. For example, log shipping supports multiple copies of the production databases, but database mirroring allows only one copy of the production database. If you need multiple copies of the production database and the features of database mirroring, then you can implement database mirroring and log shipping. Database mirroring also complements existing failover clustering implementations. As with any other solution, take a performance baseline of your environment before and after config- uring database mirroring, and use your performance data to help you determine whether you should use database mirroring or whether you should use synchronous mode or asynchronous mode in your production environment. The next chapter discusses failover clustering, which is the only Microsoft SQL Server 2008 high- availability solution that provides both high availability for an entire instance of SQL Server and the automatic failover option. 1118 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1119 Clustering IN THIS CHAPTER Understanding SQL Server 2008 failover clustering Enhancements in SQL Server 2008 failover clustering Installing a SQL Server 2008 failover cluster Performing rolling upgrade and patching Maintaining and troubleshooting a SQL Server 2008 failover cluster R emember the sitcoms in the 1970s with identical twins? They could switch clothes and fool the teacher, or wear the same clothes and switch boyfriends halfway through a date. I’ve wondered what life would have been like if I had a twin. I suspect that we would have gotten in more trouble together than I got into alone. Having twins brings a whole new set of ‘‘opportunities.’’ SQL Server failover clustering is like having identical twin SQL Servers. They share the same clothes, and look exactly alike. When one gets into trouble, the other can step right in and continue the job with barely a hiccup. Similarly, like human twins, SQL Server failover clusters bring their own set of challenges. This chapter introduces the SQL Server twins and walks through all their twin tricks so you won’t be caught by their jokes. SQL Server 2008 Failover Clustering Basics SQL Server 2008 failover clustering is built on top of Windows failover cluster- ing to provide high availability for the entire SQL Server 2008 instance. A high- availability SQL Server solution masks the effects of a hardware or software failure and maintains the availability of SQL Server so that any downtime for users is minimized. Achieving 100 percent uptime is desirable but virtually impossible, if for no other reason than that at certain times, a security patch or service pack must be applied to the production server to make it secure and stable. This is where the concept of ‘‘nines’’ comes into play. The percentage of uptime all companies should strive for is some variation of 99.x percent where x is the specified number of nines. Five nines is 99.999 percent uptime for your server, which is considered to be 1119 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1120 Part VI Enterprise Data Management the ultimate in availability, as it means about five minutes of total downtime in a calendar year. Note that not all downtime is planned. We all know that even with the best storage subsystems, disks fail or network interface cards fail or there is a power failure. Also, memory leaks in the application or bugs in the OS or SQL Server can cause a failure. Three nines, which means about nine hours of downtime in a calendar year, is a more practical number to strive for. What’s New in SQL Server 2008 failover clustering? SQL Server 2008 failover clustering has changed considerably to provide better supportability and reliability and higher availability. The setup architecture has changed completely to enable features that were not possible in earlier versions of SQL Server. There is a completely new setup user interface that supports both SQL Server and Analysis Services failover clustering. Here are some of the key new features in SQL Server 2008 failover clustering. These features are discussed in detail in the section ‘‘Enhancements in SQL Server 2008 failover clustering.’’ ■ Reliable setup experience ■ Reduced downtime with rolling upgrade and patching ■ High availability with Add/Remove node operations ■ Integrated with Windows Server 2008 failover cluster features ■ Positioned to enable Sysprep and slipstream SQL Server 2008 failover clustering, shown in Figure 48-1, consists of the following: ■ Two or more cluster servers, known as nodes ■ Shared disk storage ■ Two or more networks ■ Virtual SQL IP address and SQL Network Name for clients to connect ■ Windows Server 2003/2008 Failover Clustering A SQL Server 2008 failover clustering instance appears on the network as a stand-alone SQL Server 2008 instance, but it has functionality that provides failover from one node to another if the current node becomes unavailable. The failover is handled by the Windows Server failover cluster, which detects that the current node is no longer available and then accordingly handles the failover of the SQL Server to another node. All clients are disconnected during the failover and need to reconnect following it. However, they connect to the same ‘‘virtual SQL network name’’ or ‘‘virtual SQL IP address’’ as before. Before investing in a SQL Server 2008 failover cluster solution it is very important to know how it works, what it can do, and what it cannot do. Many DBAs are familiar with Oracle clustering and may have different expectations from Microsoft failover clustering. Microsoft failover clustering provides the following benefits: ■ High availability: Microsoft Windows failover clustering provides protection from machine- level failures such as hardware and software failures, service failures, and site-level failures such 1120 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1121 Clustering 48 as hurricanes, fires, and so on. When a system or application in the cluster fails, the cluster software detects the failure and automatically restarts the failed application on a surviving server. It also allows software/hardware upgrades with minimum downtime. ■ Improved manageability: It enables managing services within the entire cluster, as if man- aging a single computer. Applications can be moved to different servers within the cluster. You can manually balance the server workload and free servers for planned maintenance. Using the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster Management tool in Windows 2008 Failover Cluster, you can monitor the status of the cluster, all nodes, and resources from anywhere on the network. ■ Increased scalability: The cluster can grow to meet increased demands. For example, when the load for an application exceeds the resources of the cluster node, it supports the addition of processors, memory, and nodes if required. ■ Instance-level redundancy and automatic failover for SQL Server instances: When a node or resource (disk, IP address, or network name) fails, Windows failover clustering detects it and automatically restarts the entire SQL server instance on the other node. SQL Server failover clustering is the only high-availability option offered by Microsoft that pro- vides instance-level redundancy. Database mirroring, log shipping, and replication all provide database redundancy, not instance-level redundancy. FIGURE 48-1 Typical SQL Server 2008 failover cluster Node1 SQLVS1 192.168.100.14 SQLVS2 192.168.100.15 SQLVS3 192.168.100.16 Client PCs Public Network Node2 Node3 Node4 Redundant Fibre Channel Switched Fabric Shared Disk Storage Cluster Nodes Private Network 1121 www.getcoolebook.com . 1119 Clustering IN THIS CHAPTER Understanding SQL Server 2008 failover clustering Enhancements in SQL Server 2008 failover clustering Installing a SQL Server 2008 failover cluster Performing rolling. principal to the mirror, launch the SQL Server Profiler tool as follows: 1. From the Start menu, select Programs ➪ Microsoft SQL Server 2008 ➪ Performance Tools ➪ SQL Server Profiler. 2. Select New Trace. mirroring, refer to the SQL Server 2008 Books Online resource ‘ SQL Server, Database Mirroring Object’’: http://msdn .microsoft. com/en-us/library/ms189931.aspx. Monitoring using SQL Server Profiler To