Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1152 Part VI Enterprise Data Management 1. Install prerequisites for SQL Server 2008 as discussed earlier on both NODE1 and NODE2. To minimize downtime, install the prerequisites on the passive node (NODE1) first and reboot NODE1. Then, during a scheduled downtime, failover the SQL Server 2005 instance (SQL2005INST1) from NODE2 to NODE1. This incurs a brief downtime of approximately 15 seconds. After the failover, install the prerequisites on NODE2 and reboot NODE2. Now NODE2 is the passive node and NODE1 is the active node. I do not want to paint a rosy picture suggesting that all failovers will take 15 seconds. The actual downtime will depend on your environment. For example, I saw one failover take 10 minutes, as the SQL Server 2005 instance was dependent on 20 drives and it took all the drives approximately 10 minutes to come online and SQL Server can be online only after the drives it is depen- dent on come online. Also, if there is a long-running transaction running when the failover occurs, SQL Server goes through recovery after failover and will roll back the uncompleted long-running transaction, which again can increase your downtime. This is another reason why you need to have an identical test environment in which to test and observe the actual downtime or at least provide a good estimate of the downtime. 2. During this step, upgrade the passive node (NODE2). When NODE2 is being upgraded, setup automatically takes NODE2 out of the possibleownersfortheSQLNetworkNameresource and then upgrades the binaries on NODE2. Here are the detailed steps: ■ On NODE2, launch the SQL Server Installation Center by double-clicking setup.exe on the root of the SQL Server 2008 installation media. ■ On the left-hand side of the SQL Server Installation Center, click Installation. ■ Click Upgrade from SQL Server 2000 or SQL Server 2005 to start the upgrade. ■ On the Setup Support Rules page, verify that there are no errors and click OK. ■ On the Setup Support Files page, click Install. ■ Setup runs another set of setup support rules. On the Setup Support Rules page, verify that there are no errors and click Next. ■ On the Product Key page, enter the product key for your SQL Server 2008 edition. ■ On the License Terms page, read the licensing terms and check the box to accept them. ■ On the Select Instance page, select the instance of SQL Server to upgrade (MSSQLSERVER in this case, as SQL2005INST1 is a default instance), as shown in Figure 48-17. To upgrade only the SQL Server management tools and shared features, select ‘‘Upgrade shared features only.’’ ■ The Select Features page will be grayed out, as no changes are allowed during the upgrade. ■ On the Instance Configuration page, review the Instance ID for the SQL Server instance and change it if you do not like the default. ■ The Disk Space Requirements page is informational. It displays the required and available space for the SQL Server features. ■ On the Server Configuration page, enter a low-privilege account for the SQL Full-text Filter Daemon Launcher service. This account should be different from the SQL Server service account. If you are not using full-text, then do not specify a service account. If you are using full-text, then create a local user account to be used specially for this service. ■ On the Full-Text Upgrade page, choose the full-text upgrade option. 1152 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1153 Clustering 48 FIGURE 48-17 Selecting the instance of SQL Server to upgrade Best Practice If you are upgrading from SQL Server 2005, all three options in the Full-Text Upgrade page are valid; but if you are upgrading from SQL Server 2000 and you select the Import option in the Full-Text Upgrade page, the Rebuild option is used instead. This means that the catalogs are rebuilt from scratch after the upgrade. Depending on the size of the catalogs and hardware, this may require significant time and resources, which temporarily decreases the server’s performance. To avoid this scenario, it is recommended to select the Reset option on the Full-Text Upgrade page. By selecting this option, the catalogs will remain empty until you manually populate the full-text catalogs after the upgrade is complete. ■ On the Error and Usage Reporting page, optionally select the information you want to automatically send to Microsoft to improve the SQL Server features and services. 1153 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1154 Part VI Enterprise Data Management ■ The Upgrade Rules page runs a set of rules to determine if the upgrade process will be blocked. Verify that all the rules pass before proceeding to the next step. ■ The Cluster Upgrade Report page, shown in Figure 48-18, displays the upgrade status of the failover cluster nodes. Notice that the node state for NODE1 is Online, and for NODE2 it is Passive, as SQL2005INST1 is running on NODE1. The upgrade state for all nodes is Upgrade Pending. FIGURE 48-18 Cluster Upgrade Report page showing the upgrade status ■ Verify the SQL Server 2008 features to be upgraded on the Ready to Upgrade page and click Upgrade. An example is shown in Figure 48-19. ■ The Upgrade Progress page (see Figure 48-20) shows the upgrade progress. Click Next. ■ The Cluster Upgrade Report page, shown in Figure 48-21, displays the upgrade status of the failover cluster nodes. Notice that the state of NODE2 is Offline, and the upgrade state is Upgraded. The state of NODE1 is Online, and the upgrade state is Upgrade Pending. Note also the SQL Version change for NODE2. It has been upgraded to SQL Server 2008 (10.0.1600.22). ■ Click Close on the Complete page. 1154 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1155 Clustering 48 FIGURE 48-19 Ready to Upgrade page showing the features to be upgraded At this point, NODE2 is upgraded and NODE1 is the only node in the possible owners for the SQL Network Name resource, as shown in Figure 48-22. Throughout this process, the SQL Server 2005 instance (SQL2005INST1) was online and running as usual on NODE1 while NODE2 was being upgraded. Also, at this point you essentially have a single-node cluster — if something goes wrong on NODE1, no failover is available. 3. Upgrade NODE1. During this step, upgrade NODE1 by repeating the steps that were used to upgrade NODE2. Before the setup starts upgrading NODE1, it gives a warning: ‘‘If you proceed with upgrade, SQL Server Setup will move the SQL Server resource group ‘SQLServer- GroupName’ to a node that has already been upgraded and complete the database upgrade. Applications will not be able to connect to SQL Server services while the database upgrade is in progress,’’ as shown in Figure 48-23. When the upgrade starts on NODE1, setup adds the upgrade node, NODE2, to the possible owners for the SQL Network Name resource and removes NODE1 from the possible owners. This will cause the SQL Server 2005 instance (SQL2005 INST1) to failover to the upgraded node NODE2. This will cause another downtime of approximately 15 seconds. SQL2005INST1 starts on NODE2 and SQL Server 2008 database upgrade scripts are run against it. During my 1155 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1156 Part VI Enterprise Data Management testing, this took approximately 1.5 minutes and then SQL2005INST1 was up and running on NODE2. Therefore, the total downtime was approximately two minutes. In the meantime, the upgrade process will continue on NODE1 and complete the upgrade on NODE1. Once NODE1 is upgraded, setup automatically adds NODE1 in the possible owners list for the SQL Network Name resource. FIGURE 48-20 Upgrade Progress page showing successful setup process The rolling upgrade process for a cluster with three or more nodes is slightly different. You should still install the prerequisites, starting with the passive nodes first. Then the passive nodes are upgraded to SQL Server 2008. As the upgrade is run on each node, setup automatically removes it from the possi- ble owners for the SQL Network Name resource. When more than 50 percent of the cluster nodes are updated, setup automatically causes a failover of the SQL Server failover clustering instance to any one of the upgraded nodes. Then the setup adds all the upgraded nodes to the possible owners list; and all nodes that are not yet upgraded are removed from the possible owners list. Upon failover, SQL Server 1156 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1157 Clustering 48 starts on an upgraded node and the database upgrade scripts are run against it. Continue upgrading the remaining nodes. As they are upgraded, the setup automatically adds them back to the possible owners list for the SQL Network Name. FIGURE 48-21 Cluster Upgrade Report page showing the upgrade status During rolling upgrade there is no option to control the failover using the setup user inter- face. To control the failover, run the setup on the command line by supplying the failover option /FAILOVERCLUSTERROLLOWNERSHIP. Another important point is that the rolling upgrade can be performed against only one SQL Server 2000/2005 instance at a time. For example, consider a four-node Windows Server 2003 failover cluster with three of them SQL Server 2005 failover clustering instances. It is not possible to upgrade all three SQL Server 2005 failover clustering instances together. You need to repeat the procedure outlined earlier for each instance. Of course, you only need to install the prerequisites once, but the rest of the steps need to be executed once for each instance. 1157 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1158 Part VI Enterprise Data Management FIGURE 48-22 NODE2 is removed from the possible owners list for SQL Network Name resource. Best Practice After performing the rolling upgrade, update the statistics on all databases to optimize query performance and run DBCC UPDATEUSAGE on all databases to correct row and page counts. If you upgraded from SQL Server 2000, then run DBCC CHECKDB WITH DATA_PURITY on all databases to enable column-value integrity, as it is not enabled by default on SQL Server 2000. Patching a SQL Server 2008 failover cluster Once you have a SQL Server 2008 failover cluster installed, it is recommended that you install the latest service pack for SQL Server 2008 to patch the server with fixes to known issues, which in turn reduces downtime due to known issues. This makes the cluster highly available, stable, and secure, and often increases the server’s performance. Of course, before applying the service pack directly on the production cluster, you need to test it thoroughly on a test cluster with all your applications to ensure that everything is working as expected. Microsoft does extensive testing on the service packs but every environment is so different that it is virtually impossible to test each and every scenario. 1158 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1159 Clustering 48 FIGURE 48-23 Cluster Upgrade Report showing the upgrade status and warning message At the time of this writing, there is no service pack released for SQL Server 2008, but Microsoft has released two cumulative updates for SQL Server 2008. Approximately every two months, Microsoft releases a cumulative update. It’s not recommended to apply every cumulative update, and frankly it is very difficult if not impossible to thoroughly test every cumulative update every two months against all your applications. Apply a cumulative update only if you need a fix that is included in the cumulative update or if you want to proactively apply the latest cumulative update released by Microsoft. Either way, always test the cumulative update before applying it on your production SQL Server 2008 failover cluster. Starting with SQL Server 2008 SP1, service pack installation is supported. This is great news because now it is not necessary to uninstall/reinstall SQL Server to uninstall a service pack; but this does not mean that you don’t have to test your applications thoroughly against the latest service pack. It is still best practice to proactively test the service pack on a test server and verify that all the applications work as expected. 1159 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1160 Part VI Enterprise Data Management To minimize downtime and maintain high availability while patching a SQL Server 2008 failover cluster with cumulative updates and/or service packs, use the rolling upgrade process as follows: 1. Open the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster Management tool in Windows 2008 Failover Cluster and remove half the passive nodes from the possible owners of the SQL Network Name resource. 2. Apply the update (cumulative update and/or service pack for SQL Server 2008) on the nodes that were removed. Best Practice Usually the steps to apply the update for a SQL Server 2008 failover clustering instance are very similar to applying it on a stand-alone SQL Server 2008. Nevertheless, some updates may have special considerations for failover clustering, and it is best to review the documentation that is supplied with the update package. Before applying the update on a node, verify that no other cluster services are running on the node. For example, you may be applying the cumulative update 2 (CU2) for SQL Server 2008 instance INST1, but another SQL Server 2008 instance INST2 might be currently running on the node on which you are planning to apply CU2. Although the updates do not install the components of other instances, they do update the shared components. To avoid restart that may occur when shared components are updated, move INST2 to another node in the cluster. 3. After applying the updates on the nodes that were removed in step 1, add them back to the possible owners list for the SQL Network Name resource using the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster Management tool in Windows 2008 Failover Cluster. 4. At this point, half the cluster nodes have the update installed, but the SQL Server 2008 instance is still running on a node that does not have the update. Move the instance to a node that has the update and verify that all the SQL Server resources come online on the updated node. 5. Repeat steps 1 to 3 except now remove the nodes that were not patched from the possible owners list for the SQL Network Name resource, patch them, and then add them back to the possible owners list. 6. If you still have time and can afford downtime, move the SQL Server on each node to verify that it comes online on each node. Also, connect to the SQL Server instance using SQL Server Management Studio and run select @@version against the instance. Verify that the version is the same regardless of the node on which SQL Server is running. If you cannot perform this step now, do it during your next maintenance window. This step is very important to ensure that SQL Server will run on all the cluster nodes after the update is applied. These steps are recommended to attain minimum downtime. Some DBAs install the update directly on the node where the SQL Server 2008 failover clustering instance is running. This was how we installed an update on a SQL Server 2000 and 2005 failover cluster. This method works on SQL Server 2008, but it is not recommend because the number of reboots and down- time is much more compared to the steps just outlined. If one follows the steps, downtime will be 1160 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1161 Clustering 48 minimal, and caused only in step 4 when moving the SQL Server 2008 failover clustering instance to an updated node. It is also important to note that when a SQL Server 2008 patch is installed on a cluster node, it does not automatically install on the remote nodes. It needs to be installed separately on each node just as we installed SQL Server 2008 on each node. Maintaining a SQL Server 2008 failover cluster Once a SQL Server 2008 failover clustering instance is installed, you are ready to manage and maintain the instance just as you would on a stand-alone SQL Server 2008 instance. Managing a clustered SQL Server 2008 instance is no different from managing a stand-alone SQL Server 2008 instance. For more information about configuring, recovery planning, and maintaining SQL Server, refer to Chapter 39, ‘‘Configuring SQL Server,’’ Chapter 41, ‘‘Recovery Planning,’’ and Chapter 42, ‘‘Maintaining the Database,’’ respectively. Here are some maintenance operations that are slightly different for a SQL Server 2008 failover cluster: ■ To start and stop a SQL Server 2008 failover clustering instance, use one of the following tools: ■ SQL Server Management Studio (is cluster-aware) ■ SQL Server Configuration Manager (is cluster-aware) ■ Command-line cluster.exe tool ■ Cluster Administrator tool in Windows 2003 Failover Cluster or Failover Cluster Manage- ment tool in Windows 2008 Failover Cluster Do not use the Services control panel applet in Windows to stop or start SQL Server 2008 failover clustering instances, as the Services applet is not cluster aware. If SQL Server is stopped from the Services applet, then the Windows cluster service will detect this and try to restart it based on the restart properties of SQL Server. ■ To connect to a SQL Server 2008 failover clustering instance, do not use the actual cluster node name. In fact, it’s not necessary to even know the cluster node names; but you need to know the SQL Network Name for the default instance and the instance name for the named instance. For example, to connect to a default SQL Server 2008 failover clustering instance with SQL Network Name as SQL2008VS, use SQL2008VS to connect to the instance. To connect to a named SQL Server 2008 failover clustering instance with SQL Network Name as SQL2008VS1 and named instance name as INST1, use SQL2008VS1\INST1 to connect to the named instance. You can also connect using the SQL IP address instead of the SQL Network Name. Once connected to the SQL Server instance, all other operations are similar to the ones in a stand-alone SQL Server 2008. In fact, for most of the operations you do not even need to know that the SQL Server instance is clustered. Common DBA tasks such as backup, restore, and creating maintenance plans remain the same, without any extra steps. ■ Sometimes it may be necessary to determine the actual cluster node name on which the SQL Server 2008 failover clustering instance is currently running. To find the NETBIOS name of the cluster node, execute the following command: SELECT SERVERPROPERTY(’ComputerNamePhysicalNetBios’); 1161 www.getcoolebook.com . connect to a default SQL Server 2008 failover clustering instance with SQL Network Name as SQL2 008VS, use SQL2 008VS to connect to the instance. To connect to a named SQL Server 2008 failover clustering. SQL Server 2008 failover cluster: ■ To start and stop a SQL Server 2008 failover clustering instance, use one of the following tools: ■ SQL Server Management Studio (is cluster-aware) ■ SQL Server. just as you would on a stand-alone SQL Server 2008 instance. Managing a clustered SQL Server 2008 instance is no different from managing a stand-alone SQL Server 2008 instance. For more information