Sql server 2012 Upgrade Technical Guide Writers

64

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 

shipping. (For more information, see Chapter 3, "Relational Databases," and 

Chapter 4, "High Availability.") For Analysis Services, you can use backup and 

restore (see Chapter 16, "Analysis Services"). 



 

Use new service accounts. Create and use new service accounts and groups, if 

it is necessary, with your SQL Server 2012 implementations. This guarantees 

account separation from the legacy instances of SQL Server 2005/2008/2008 R2. 

An in-place upgrade will not automatically change the legacy instance’s service 

accounts. Create new domain-based service accounts that have the correct user 

rights on each server, and after the upgrade, use SQL Server Configuration 

Manager to update the SQL Server 2012 services to use these new accounts. 



 

Check data consistency. When you upgrade relational databases, run a Full 

DBCC CHECKDB on databases before upgrading while the database is online so 

that you do not affect downtime. (See Chapter 3, "Relational Databases," for 

more information.) 



 

Back up data before and after the upgrade. Check that your backup media 

has no errors and is available for restores if necessary (see "Plan for Backups" 

earlier in this chapter). 

Developing an Upgrade Plan 

Every upgrade of a production database system that contains valuable data should 

occur in the context of a good plan. In addition to performing the upgrade-plan tasks 

we have already covered, you should also follow some other general best practices 

when planning for an upgrade. 

Treat the Upgrade as an IT Project 

If you do not have the luxury of extensive planning or testing and you decide to just 

upgrade, we recommend that you take some basic precautions so that you can recover 

from any issues that might arise: 



 

Schedule a longer maintenance downtime window than you think you must 

have. If everything finishes without issue, you will be able to bring users back 

online faster than they expected. But if unexpected issues arise, you will have 

more time to deal with them without inconveniencing users. 



 

Do a complete backup of all the files and installed software on the server in case 

you have to restore the server to its previous state. Confirm that your backup 

media is complete and available. 

---

65

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 



 

Do a complete backup of all the user databases on the server in case you have 

to selectively restore user databases. Confirm that your backup media is 

complete and available. 

After the upgrade, check before you leave to make sure that everything looks to be 

working. Make sure that applications return to running correctly and that transaction 

workloads are processed correctly. 

It is best not to treat an upgrade informally, as a one-off procedure. Instead, treat it as 

a major database upgrade. This approach implies the following steps: 



 

Applying database change control procedures to the upgrade project 



 

Guaranteeing sufficient integration and quality assurance (QA) testing 



 

Developing verification and acceptance tests 



 

Scripting and automating the deployment process and tests as much as you can 



 

Developing a rollback plan in addition to a priority patch strategy 



 

Guaranteeing sufficient downtime for the upgrade 

The actual steps that you use should comply with the rules and procedures already 

existing in your organization, but most likely, they will include all the above. The 

important point is that an upgrade to SQL Server 2012 is not a minor change to your 

production database system; instead, it should fit into existing procedures for major 

database changes. 

Updating Skills 

Before you try to upgrade to SQL Server 2012, make sure that those administering or 

deploying SQL Server 2012 are ready. Just as you would with any other application, 

never assume that your staff can deploy and then manage the upgraded system 

without being correctly prepared. 

Before deployment, set up a SQL Server 2012 environment so that everyone who has to 

update his or her skill set can become familiar with the new version. If the DBAs are 

comfortable with SQL Server 2012 by the time of production deployment, the transition 

from SQL Server 2005/2008/2008 R2 will go much more smoothly. 

There are many resources that are available to update skills. To start, see the 

SQL Server 

2012 Learning Center

 (http://msdn.microsoft.com/en-us/sqlserver/ff898410). Also you 

can get initial experience with SQL Server 2012 using the training material on the 

SQL 

---

66

 

SQL Server 2012 Upgrade Technical Guide 

 

 

 

Server Virtual Labs

 (http://www.microsoft.com/sqlserver/en/us/learning-center/virtual-

labs.aspx) technical training site. 

Documenting the Upgrade Plan 

Work as part of a team, document the planning process, and communicate the 

upgrade effectively. Team members and stakeholders usually include not only DBA 

staff, but Operations staff, QA staff, the Security officer, and application/business 

owners. Explicitly document requirements and establish agreement from relevant 

stakeholders, just as for any major database server change. Use the documentation as a 

basis to execute the upgrade during the deployment phase. The plan should be as 

detailed as possible, and you should store the resulting document or documents by 

using some form of change control such as a source control system. In the rest of this 

section, we will detail these steps. 

When documenting the plan, include the upgrade requirements in addition to the 

rationale for choosing an upgrade strategy for each instance or class of instances. Use 

the rest of the plan to detail remaining issues. For example, the plan might include the 

following steps: 



 

Identify pre-upgrade tasks. This step includes installing Microsoft Windows 

Installer (MSI) 4.5, .NET Framework 3.5 SP1, and the SQL Server Native Client on 

the target instances. Because these steps do not affect the application, they can 

occur before the actual upgrade deployment begins. Be aware that installing 

MSI 4.5 requires a restart of the server. 



 

Establish performance baselines. If performance is an important feature of the 

current legacy system, collect data that indicates typical performance 

measurements for important and common queries. Refer to these baselines after 

the upgrade if reports show that performance has changed. Users might be 

mistaken, and you might find through the baselines that the new system 

performs equally well or better.  



 

Estimate required downtime. The deployment of an upgrade will involve some 

downtime for the targeted database servers. When you perform the actual 

upgrade, allow for enough downtime so that the processes can be completed 

successfully. Try to give yourself time to roll back in case an unexpected issue 

arises that cannot be resolved in the downtime window. This might mean that 

you reach a go/no-go deadline within your downtime window where you must 

decide whether to finish the upgrade or roll back. 

 

 

---