Blog Post

Perform a Rolling Upgrade to SQL Server 2008 R2 SP2 in a Database Mirroring Scenario

,

Yesterday evening (European Time zone) Microsoft has released the SP2 for SQL Server

2008 R2. You can download the Service Pack here: http://www.microsoft.com/en-us/download/details.aspx?id=30437

Because I'm currently working on a Database Mirroring Test Lab that is based on SQL

Server 2008, I thought it would be a good exercise to perform a Rolling Upgrade to

SP2 and document the correct sequence in this blog posting. In my Lab I have 3 Virtual

Machines that are performing the following roles:

  • VM1: Principal
  • VM2: Mirror
  • VM3: Witness

When you are performing a Rolling Upgrade you have to do 2 failovers (Principal =>

Mirror => Principal), which means that you should perform the upgrade at a time where

the user impact of those failovers is very little. The idea of a Rolling Upgrade in

a Database Mirroring scenario is very straightforward:

  • Disable the Witness (when you are using Automatic Failovers)
  • Install the Service Pack on the Mirror
  • Failover to the upgraded Mirror
  • Install the Service Pack on the old Principal
  • Failover to the upgraded Mirror
  • Install the Service Pack on the Witness
  • Add the Witness back to the Mirroring session

Let's have a more detailed look at these steps.

1. Disable the Witness

In my lab I have a dedicated VM which acts as a Witness to provide automatic Failovers.

In that case, you have to remove the Witness from your Database Mirroring session:

ALTER DATABASE TPC_E SET WITNESS OFF

GO

Before you remove the Witness you should also write down its network address, because

you need that address afterwards, when you want to add the Witness again to the Database

Mirroring session. You can use the view sys.database_mirroring to

find out the network address of the Witness:

SELECT

database_id,

mirroring_witness_name

FROM sys.database_mirroring

GO

2. Install the Service Pack on the Mirror

In the next step you can install the Service Pack on the Mirror. The update process

itself just takes a few minutes and during the process your SQL Server Instance on

the Mirror is restarted.

During the restart, your Principal runs in the Exposed state, which means, when you

lose your Principal in that timeframe, your database is down.

As soon as your SQL Server Instance is restarted, the upgraded Mirror is automatically

synchronized with the Principal:

3. Failover to the upgraded Mirror

In the next step you have to failover to the upgraded Mirror, which will become the

new Principal in your Database Mirroring session.

ALTER DATABASE TPC_E SET PARTNER FAILOVER

GO

During the failover your applications have to reconnect to your SQL Server databases,

which means you could have a short outage (it mainly depends on how well-written your

applications are…). During the failover the new Principal (the old Mirror) has also

to redo all transactions from the REDO queue, which also impacts how long the failover

will actually take.

Note: Only the Enterprise Edition SQL Server will provide you

multiple REDO threads. You will get 1 REDO thread for every 4 CPU cores that are assigned

to your SQL Server (per database). In Standard Edition the REDO is always done with

just 1 thread (per database).

As soon as the failover completed, your new Principal will run on the new Service

Pack Level:

Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30

Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1

(Build 7601: Service Pack 1) (Hypervisor)

4. Install the Service Pack on the Mirror (the old Principal)

After you have applied the new Service Pack to the old Mirror, you just do the same

on the old Principal.

5. Failover to the upgraded Mirror

After you have installed the Service Pack on the old Principal, you again fail back

to the upgraded old Principal.

ALTER DATABASE TPC_E SET PARTNER FAILOVER

GO

Now both the Principal and the Mirror are running on the new Service Pack Level, and

you are almost complete with your Rolling Upgrade. The only thing that is left is

the upgrade of the Witness, when you are using it for providing Automatic Failovers.

6. Install the Service Pack on the Witness

Nothing special is to note here.

7. Add the Witness back to the Mirroring session

As soon as your Witness is also upgraded, you can add the Witness back to your Database

Mirroring session:

ALTER DATABASE TPC_E SET WITNESS = 'TCP://sql2008hadr3.sqlpassion.com:5022'

GO

Conclusion

As you have seen in this blog posting, installing a new Service Pack through a Rolling

Upgrade in a Database Mirroring scenario is not a big deal. But you have to plan it

carefully, because you have to do 2 failovers, and those failovers will impact your

applications.

Thanks for reading!

-Klaus

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating