Hướng dẫn học Microsoft SQL Server 2008 part 114 potx

Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1092 Part VI Enterprise Data Management What’s New in SQL Server Database Mirroring? S QL Server 2008 database mirroring has some exc iting new features, one of which is called log com- pression . As the name suggests, this feature compresses the transaction log records on the production server before sending them to the mirror server. This feature reduces network bandwidth and increases application performance and throughput at the cost of increased CPU usage. Another new feature is the capability to automatically repair a page. This means that if the production or mirror server is unable t o read a data p age due to certain types of errors like 823, 824, or 829, then the server that is unable to read the page requests a copy from the other server participating in database mirroring. Upon successful retrieval of the data page, the server replaces the unreadable page, which resolves the error automatically. This feature is really nice because in order to fix similar errors during a SQL Server 2005 database mirroring session, you may have to manually run the DBCC REPAIR_ALLOW_DATA_LOSS option, which, as the name suggests, may result in some data loss. The log compression feature is available in SQL Server 2008 Enterprise, Developer, and Standard Editions. It is on by default and requires no special configuration or switches. However, if the extra CPU usage due to log compression is not desirable in your environment, then you can turn off log compression by turning on the t race flag 1462. The automatic page repair feature is not available in SQL Server 2008 Standard Edition. It is available only in SQL Server 2008 Enterprise and Developer Editions. ■ By default, it compresses and encrypts the data between the principal and mirror server. ■ It improves the availability of your databases during hardware or software upgrades. ■ It can be used for high database availability and disaster recovery purposes. To achieve high database availability, place the principal and mirror SQL Servers in the same data-center. For disaster recovery, place the principal and mirror SQL Servers in different datacenters so that a disaster in one datacenter does not affect the other datacenter. ■ By default, it does not support reporting. If you want to use the mirror database for reporting purposes, you can create a database snapshot (refer to Chapter 45 for details on database snapshot) on the mirror database and use the snapshot for reporting purposes. If you are using the mirror database for reporting purposes, then you need to fully license the mirror server. Conversely, if the mirror server is just being used as a hot standby or passive server, then (as per the Microsoft SQL Server 2008 Pricing and Licensing Guide ) a license is not required, provided that the number of processors in the passive server is equal to or less than those of the active server. The passive server can take the duties of the active server for 30 days. Afterward, it must be licensed accordingly. ■ It provides options for no data loss for committed transactions. ■ It can provide a n almost instantaneous database failover solution by using an optional server called a witness. 1092 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1093 Database Mirroring 47 ■ There is no real distance limitation between the principal and mirror servers. ■ It can be implemented without exotic hardware and may be significantly cheaper than other high-availability solutions like SQL Server failover clustering. Note that SQL Server failover clustering provides high availability for the entire SQL Server instance, whereas database mir- roring provides high availability only at the database level. ■ It can complement existing log shipping and failover clustering implementations. ■ If your applications use ADO.NET or the SQL Server Native Client to connect to a database, then in case of a failure, the applications can automatically redirect the clients to the mirror database. However, database mirroring has a few drawbacks: ■ Only user databases in full recovery model can be used for database mirroring. Simple or bulk-logged recovery model cannot b e used. This also means that database mirroring will break if the recovery model f or a mirrored database is changed from full to simple or bulk-logged. ■ System databases ( master, model, msdb, tempdb) cannot b e mirrored. ■ Database mirroring does not support FILESTREAM. This means that databases with a FILESTREAM filegroup cannot be mirrored, nor can you create a FILESTREAM filegroup on a principal database. ■ Database mirroring does not support cross-database transactions or distributed transactions. ■ Like log shipping, database mirroring provides redundancy at the database level and not at the entire SQL Server instance level, like SQL Server failover clustering. ■ Like log shipping, database mirroring only applies to changes that are captured in the trans- action log or the initial full backup of the principal database. Any database objects such as logins, jobs, maintenance plans, SSIS packages, and linked servers that reside outside the mirrored database need to be manually created on the mirror server. ■ Unlike log shipping, database mirroring does not support having multiple copies for the same principal database. This means you can only have one mirror database for each principal database. ■ The mirror database name needs to be same as the principal database name. ■ If the mirror database fails, the transaction log space on the principal database cannot be reused even if you are taking transaction log backup. This means you need to either have enough space for the transaction log to grow, and bring the mirror database online before the log fills up the available disk space and brings the principal database to a halt, or break the database mirroring. ■ Depending on the workload, your environment, and the database mirroring configuration, database mirroring may affect application performance. It can also place a large demand on the network while the transaction log records are being sent. If these drawbacks are acceptable, database mirroring can be an excellent choice for high database avail- ability, disaster recovery, and/or reporting. It is highly recommended that you thoroughly test database 1093 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1094 Part VI Enterprise Data Management mirroring with your application and hardware, and validate your SLAs ( service-level agreements), before implementing it in production. Defining Database Mirroring Although database mirroring appears to be similar to log shipping, it is not the same. As explained in Chapter 46, log shipping involves periodically restoring a transaction log backup from the primary server to a warm standby server, making that server ready to recover at a moment’s notice. Database mirroring continuously transfers the transaction log records (not the transaction log backups) from the principal database and applies them to the mirror database. Database mirroring normally involves three SQL Servers: a principal server, a mirror server, and an optional witness server, as shown in Figure 47-1. FIGURE 47-1 Sample database mirroring configuration DB1 DB2 DB1 DB2 Transaction log records Transaction log records Principal Server Mirror Server Witness Server (Optional) ■ The principal server is the main production SQL Server to which clients connect. This server contains the database for which you want to create a duplicate (also called a hot standby or mirror copy). The initial full database backup is taken on this server, which should be a high-quality server with redundant disk drives. 1094 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1095 Database Mirroring 47 ■ The mirror server is the hot standby SQL Server. If the principal server fails, the mirror server becomes the new principal server. Thi s server should be capable of meeting the min- imum performance requirements during a short-term crisis. If your business does not allow any performance degradation, then the mirror server should be comparable to (same CPU and memory configuration) the principal server. The principal server and mirror server are often referred to as partners in a database mirroring session. ■ The witness server is an optional separate SQL Server and is required only when automatic failover is required. The witness server helps create a quorum to ensure that only one SQL Server — either the principal server or the mirror server — owns the database that is accessi- ble by the clients. The witness controls automatic failure to the mirror if the principal becomes unavailable. One witness server can be used for multiple database mirroring sessions, each for different databases and different partners. Transaction log records are transferred from the principal server to the mirror server synchronously or asynchronously based on the transaction safety level that you select for the database mirroring session. Database mirroring has two transaction safety levels, SAFETY FULL and SAFETY OFF,as detailed in Table 47-1. The failover options are described in the section ‘‘Role Switching’’ later in this chapter. TABLE 47-1 Database Mirroring Safety Levels a nd Failover Options Safety Level Operating Mode Failover Mode Witness Server Required FULL Synchronous Database Mirroring Automatic and Manual Yes FULL Synchronous Database Mirroring Manual and Forced No OFF Asynchronous Database Mirroring Forced N/A SAFETY FULL is often referred to as synchronous database mirroring or high-safety mode.Inthismode, the mirror database is in sync with the principal database at all times and provides full data safety. The following steps, shown in Figure 47-2, describe the sequence of events that occurs when you choose SAFETY FULL: 1. The client submits a transaction to the principal database. The principal server writes the transaction log records to the transaction log buffer. 2. The transaction l og buffer is written to disk (also referred to as hardening of the log) and simultaneously transfers the transaction log records from the buffer to the mirror server. The principal server waits for a confirmation from the mirror. Because the principal waits for an acknowledgment from the mirror, application response time increases and transaction through- put is reduced slightly. The actual performance impact depends on various f actors, such as your network latency, the disk subsystem, the application, and more. 1095 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1096 Part VI Enterprise Data Management There are no specific restrictions on the network for database mirroring, but the net- work connection between the servers is critical. The process of determining a failover in synchronous database mirroring is based on the network connection. If there is a problem with the network, mirroring will failover or deny access to the database because of the quorum requirement. Although mirroring is working as designed, this behavior may come as a surprise to new database mir- roring users, because with a regular standalone server, the database is still available. It is recommended that you have a dedicated network of high quality and high bandwidth. As a rule of thumb, network bandwidth should be three times the maximum log-generation rate. 3. The mirror server writes the transaction log records to the transaction log buffer. The transac- tion log buffer is then written to disk. 4. The mirror server acknowledges that the transaction has been written. 5. The commit is reported to the client. FIGURE 47-2 Synchronous database mirroring mode DBLog 2>2 4 2 5 1 SQL Server DBLog 3>3 SQL Server Client Principal Server Mirror Server Witness Server Mirror is always redoing–it remains current If you choose SAFETY FULL and have a witness server in the database mirroring configuration, then you can achieve automatic failover. This means if the principal database has a failure or is unavailable, the witness server and the mirror server will form a quorum and the mirror server will perform an automatic failover. The mirror server will become the new principal server and will recover the database 1096 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1097 Database Mirroring 47 and start servicing the clients. This operating mode is also referred to as high-safety mode with automatic failover. If you choose SAFETY FULL and you do not have a witness server in the database mirroring configura- tion, then you cannot achieve automatic failover because if the principal database fails, the mirror server cannot form a quorum, as there is no witness server. In this configuration, you need to perform a man- ual failover. This operating mode is also referred to as high-safety mode without automatic failover. Synchronous database mirroring (high-safety mode) is supported by SQL Server 2008 Enter- prise, Developer, and Standard Editions. If you implement synchronous database mirror- ing using SQL Server 2008 Standard Edition, then you cannot create a database snapshot on the mirror database for reporting purposes, as database snapshots are not supported by SQL Server 2008 Standard Edition. SAFETY OFF is often referred to as asynchronous database mirroring or high-performance mode. This safety level provides high performance with possible data loss. In this mode, the communication between the principal and mirror databases is asynchronous. The sequence of events when you choose SAFETY OFF is shown in Figure 47-3. FIGURE 47-3 Asynchronous database mirroring mode DBLog 2>2 5 2 3 1 SQL Server DBLog 4>4 SQL Server Client Principal Server Mirror Server Mirror is busy keeping up with the principal 1097 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1098 Part VI Enterprise Data Management The transaction log records are written to the principal database transaction log and sent to the mirrored database transaction log in the same way as in synchronous mirroring mode. The main difference is that the principal does not wait for the mirror to acknowledge that the transaction has been written to disk. The transactions on the principal database commit as soon as they are written on the principal database transaction log. This increases application performance but creates a heavy load on the principal database, or a network delay could cause the principal database transaction log, which is waiting to be sent to the mirror database, to grow; and in the event of a failure of the principal, the unsent transaction log records may be lost. Automatic and manual failover are not enabled in high performance mode due to possible data loss. Only a forced failover is allowed in this mode. Asynchronous database mirroring (high-performance mode) is only supported by SQL Server 2008 Enterprise or Developer Editions. Best Practice D o not configure a witness server in high-performance operating mode because there is no use of a witness server. In fact, if you use a witness server and for some reason the witness server and mirror server both become unavailable, the principal server will not be able to form a quorum and the principal database will not be accessible to the clients even though the principal server is available and does not have any issues. Configuring database mirroring Database mirroring can be configured using one of two methods: either by using SQL Server Manage- ment Studio or by using system-stored procedures. Pre-database mirroring configuration With either method of configuration, the following prerequisites need to be completed before configur- ing database mirroring: ■ The principal, mirror, and witness servers all must have the same version of SQL Server (SQL Server 2005 or 2008). ■ The principal and the mirror server must have the same edition of SQL Server (Enterprise or Standard Edition). ■ The edition of the witness server (if you are configuring high-safety mode with automatic failover) can be SQL Server Express, Workgroup, Standard, or Enterprise Edition. ■ The recovery model of the principal database must be set to full. ■ Ensure that there is enough disk space for the mirror database on the mirror server. ■ Create the mirror database. To do this, take a full database backup of the principal database and subsequent transaction log backups; copy the backups to the mirror server, and restore it on the mirror server WITH NORECOVERY to put it into a state that allows inserting transaction log records. The name of the mirror database should be the same as the principal database. 1098 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1099 Database Mirroring 47 Before you start mirroring, take a transaction log backup on the principal database and restore it on the mirror database WITH NORECOVERY. Do not restore the transaction log backups WITH STANDBY — even though it’s a loading state, database mirroring will not work. Best Practice I t is recommended (but not required) that the principal and mirror databases have the same directory structure. If the directory structure is different, adding and removing file operations on the principal database will not be allowed without suspending database mirroring. For more information about backup and restore, refer to Chapter 41, ‘‘Recovery Planning.’’ ■ Communication between the SQL Servers in a database mirroring configuration is accom- plished over TCP (Transmission Control Protocol) endpoints. Each server participating in database mirroring requires its own dedicated database mirroring endpoint. Each endpoint listens on a unique TCP/IP port. ■ All the SQL Servers in a database mirroring configuration need to trust one another. If they are on the same domain, you need to ensure that each SQL Server login can connect to the mirroring SQL Server and have CONNECT permission on the endpoints. If the SQL Servers do not trust one another, then you need to use certificates for the communication between the servers. Best Practice U se a private high-speed network between the principal and mirror servers to reduce the network bandwidth and impact on other users. SQL Server 2008 helps reduce the network bandwidth with the log compression feature. Configuring database mirroring using Management Studio The following steps configure database mirroring 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 Options page, verify that the recovery model is full. 3. On the Mirroring page, shown in Figure 47-4, click Configure Security button to launch the Configure Database Mirroring Security Wizard. Click Next to begin the wizard. This wizard enables you to configure the security of the principal, mirror, and witness (optional) servers. 1099 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1100 Part VI Enterprise Data Management FIGURE 47-4 Database Properties Mirroring page 4. On the Include Witness Server page, shown in Figure 47-5, click Yes if you want to operate database mirroring in synchronous (high-safety) mode with automatic failover. For other operating modes (high-safety without automatic failover and high-performance mode), click No. 5. On the Choose Servers to Configure page, shown in Figure 47-6, ensure that the Witness server instance check box is checked. Click Next to continue. If you selected No in the previous step, you will not see this page. 6. The next page is the Principal Server Instance page, shown in Figure 47-7. As discussed earlier, communication between the servers participating in database mirroring is accomplished over TCP endpoints. Each server requires its own, dedicated database mirroring endpoint. Each endpoint listens on a unique TCP/IP port. The default port shown i n Figure 47-7 is 5022. For security reasons, it is recommended to use a non-default port. Also, notice that by default the check box for Encrypt data sent through this endpoint is selected. It is recommended that you leave this checkbox selected to ensure that the data transferred across the network is encrypted. If for some reason you do not need encryption, uncheck this box. You can also change the endpoint name on this page. Click Next to continue. 1100 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1101 Database Mirroring 47 FIGURE 47-5 Selecting the witness server FIGURE 47-6 Selecting the witness server to save the security configuration 1101 www.getcoolebook.com . mirror, and witness servers all must have the same version of SQL Server (SQL Server 2005 or 2008) . ■ The principal and the mirror server must have the same edition of SQL Server (Enterprise or Standard. mode DBLog 2>2 4 2 5 1 SQL Server DBLog 3>3 SQL Server Client Principal Server Mirror Server Witness Server Mirror is always redoing–it remains current If you choose SAFETY FULL and have a witness server. to fully license the mirror server. Conversely, if the mirror server is just being used as a hot standby or passive server, then (as per the Microsoft SQL Server 2008 Pricing and Licensing Guide )