Sql server 2012 Upgrade Technical Guide Writers

61

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 

40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx) and 

Planning, Implementing, and Supporting SQL Server Virtualization 

with Windows Server 2008 R2 Hyper-V and Live Migration

 

(http://download.microsoft.com/download/4/4/D/44DB08F7-144B-

4DF6-860F-

06D30C6CE6E4/SQL%20Server%202008%20R2%20Virtualization%

20Whitepaper.docx) 



 

You cannot use an old Windows NT-style domain for a Windows Server 2008 or 

later server. You must be using Active Directory. If your organization is using 

older-style domains, you cannot deploy Windows Server 2008/2008 R2 until 

your Active Directory infrastructure is upgraded. 



 

By default, Windows Server 2008 and 2008 R2 are more secure than Windows 

Server 2000 and Windows Server 2003. Many of its features are not configured, 

so there will be additional work involved in the upgrade. 



 

Windows Server 2008 and 2008 R2 support only SAS, fiber channel, and iSCSI. If 

you are using older parallel SCSI, you have to upgrade your disk solutions to 

support Windows Server 2008. 

For more Windows-specific information about how to deploy and upgrade to Windows 

Server 2008 and 2008 R2, see 

Upgrading to Windows Server 2008

 

(http://technet.microsoft.com/en-us/library/cc754728(WS.10).aspx) and 

Windows 

Server 2008 R2 Upgrade Paths

 (http://technet.microsoft.com/en-

us/library/dd979563(WS.10).aspx). For information about how to upgrade to Windows 

Server 2008 or 2008 R2 failover clustering with SQL Server 2008 R2, see the "Upgrading 

Failover Clusters" section in Chapter 4, "High Availability." 

Upgrading Multiple Instances 

You might have multiple instances of SQL Server 2005/2008/2008 R2 on a standalone 

or clustered server. Multiple instances can make the upgrade process more difficult, so 

you must consider them before the upgrade. The options are simple: Should all 

instances be upgraded in one maintenance window, or should you upgrade them 

individually? 

Upgrading them all at the same time will minimize overall deployment resources 

because you have to schedule only a single outage. But that also means that if anything 

goes wrong for any reason, you might have more to fix and deal with, which could 

increase downtime. It is a risk versus reward decision. 

---

62

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 

Upgrading Very Large Databases 

Many SQL Server databases are in the hundreds of gigabytes or terabytes range. This 

presents special challenges in any upgrade process because you have to account for 

constraints in time and hard disk space when you deal with large amounts of data in a 

short window of maintenance time. Databases in the terabyte range can potentially 

take days to copy over a network—even the fastest networks. These VLDBs might be 

mission-critical databases powering the largest systems in your business and might 

tolerate very little downtime. When an upgrade has to occur over a weekend, you 

might have to use several techniques and put in many preparation hours to meet the 

required time frames for success. You might have to revise the upgrade window if the 

upgrade will not fit within it. 

When you work with VLDBs, more than any other scenario except perhaps high 

availability, careful planning is required to ensure a successful upgrade experience. The 

cost of a failure if there is an unexpected issue is much larger because of the time 

involved to resolve the issue. For example, if a copy of a database backup file stops half 

way through, or if a stored procedure uses discontinued T-SQL syntax, you will lose 

time. With an in-place upgrade, you gain more time because you do not have to 

physically move the database. However, this upgrade method makes a restore costlier 

if there is a serious failure causing you to roll back to the original database. Advance 

testing in a full-size test or staging environment is very important in these cases. 

For more information about VLDB upgrades involving failover clustering or database 

mirroring, see Chapter 4, "High Availability." 

Upgrading High Availability Servers 

For issues related to high availability features such as clustering, database mirroring, 

log shipping, and replication, see Chapter 4, "High Availability." See Chapter 4 even if 

you do not use these features for high availability. For example, if you have to upgrade 

systems that use replication, even if the upgrade is not for high availability purposes, 

you need to review Chapter 4’s information. 

Minimizing Upgrade Downtime 

For small, simple instances where you can afford maintenance downtime during the 

business day, it might not be important to take additional measures to speed up the 

upgrade and minimize end-user downtime. But many times, you will want to take the 

quickest route to minimize the inconvenience to your business when a business 

---

63

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 

application is offline waiting for the upgrade to be complete. For high availability 

applications, you might have to take additional measures to absolutely minimize the 

downtime. For high availability and VLDB upgrades, see the detailed information in 

Chapter 4, "High Availability," which goes beyond the basic information in this section. 

The following steps can help minimize the downtime involved in an in-place upgrade 

or side-by-side upgrade: 



 

Check the legacy SQL Server versions. Make sure that the legacy instances of 

SQL Server 2005/2008/2008 R2 are at the correct service-pack level for an in-

place upgrade. If they are not at the correct level, plan to update them before an 

in-place upgrade (see "Setup Requirements for an In-Place Upgrade" earlier in 

this chapter). 



 

Make sure that installation requirements are met. SQL Server 2012 Setup 

also has Windows and other component requirements (see "Setup Requirements 

for an In-Place Upgrade" earlier in this chapter). 



 

Preinstall .NET and Windows components. If you can, install .NET Framework 

3.5 SP1 or a later version and Windows Installer (MSI) 4.5 beforehand on the 

target server. Both require a restart. For an in-place upgrade, if a restart in 

production cannot be enabled except for the upgrade, install them during the 

upgrade and not earlier. For a side-by-side upgrade to a separate server, 

installing these components before the upgrade will help reduce downtime. 

When you run the SQL Server 2012 Upgrade Advisor on a legacy server, a restart 

will be required if MSI 4.5 must be installed. 



 

Preinstall Visual Studio 2008 SP1 or a later version. If Visual Studio 2008 is 

installed on the server, make sure that it is at the SP1 level (see "SQL Server 

Prerequisites Installed by Setup" earlier in this chapter). 



 

Preinstall SQL Server 2012 common components. Install the SQL Server 2012 

common components (such as the SQL Server 2012 SQL Native Client) before 

the upgrade. Also consider pre-installing the Management Tools if SQL Server 

2012 Management Studio (SSMS) is not required to manage SQL Server 2000 

instances. (For more information, see Chapter 2, "Management and 

Development Tools.") 



 

Select the optimal side-by-side upgrade strategy. In a side-by-side upgrade, 

SQL Server databases must be transferred during the upgrade, and several 

strategies are available, such as backup and restore, detach and attach, and log 

---