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

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.. FI

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 possible owners for the SQL Network Name resource and then upgrades the binaries on NODE2 Here are the detailed steps:

■ On NODE2, launch the SQL Server Installation Center by double-clickingsetup.exeon 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

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

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

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

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

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.

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

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.

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 runselect @@versionagainst 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, downdown-time will be

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-linecluster.exetool

■ 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’);