4. Upgrading SQL Server
Chances are that if your organization has
existing SQL Server implementations, you may eventually need to upgrade
them. Each version of SQL Server (and almost any other software product)
is officially supported for a limited number of years. Once this time
is up (as it was in April 2008 for SQL Server 2000), customers can
purchase extended support agreements. You can find detailed information
on the life cycles of Microsoft products at www.microsoft.com/lifecycle.
Upgrading servers in your organization is
probably not a spur-of-the-moment decision. A lot of planning should be
done beforehand to make sure the upgrade goes smoothly. When thinking
about upgrading a SQL Server database, it is important to first consider
the following questions:
- Is the server hardware capable of running this new version of SQL Server?
If you are planning on using the same hardware you were using to run
SQL Server 2005, this may not be suitable for SQL Server 20012.
- Are you planning on using the right edition of SQL Server?
A lot of the bright and shiny features of SQL Server 2012 are in the
Enterprise edition. If you are currently running the Standard edition
and want to upgrade because you want to leverage the new AlwaysOn
Availability Groups feature, simply upgrading to SQL Server 2012
Standard edition will be disappointing. On the bright side, it’s very
easy to upgrade editions within SQL Server’s Setup application. If this
is your scenario and you wanted to go from SQL Server 2005 or SQL Server
2008 Standard edition to SQL Server 2012 Enterprise, the best practice
is to go through the setup process and upgrade the server to SQL Server
2012 Standard first. Once SQL Server is upgraded, test your applications
against it. When you’re satisfied, rerun Setup, and run the Edition
Upgrade Wizard on the Maintenance tab of the SQL Server Installation
Center.
Note Other than feature availability between editions, the development interfaces are the same for all editions of SQL Server.
- Which upgrade strategy should you implement? When it comes
time to actually perform the upgrade, you have two options to actually
upgrade the bits on the server to SQL Server 2012. You can implement an
in-place upgrade that’s basically running Setup and replacing the old
SQL Server bits on the disk with the new SQL Server 2012 ones.
Alternatively, you could do a side-by-side upgrade where you do not
touch the old installation at all and instead install a new instance of
SQL Server 2012. With this new instance, you will copy databases and
objects from the old database into the new one. There are pros and cons
to either one of these kinds of upgrades. An in-place upgrade is the
fastest and least resource intensive, but it incurs more downtime of the
server, and if something bad happens, it will take a long time to
reinstall the old server version again. The side-by-side upgrade is
resource intensive and more of a manual operation, but the benefit is
you don’t have to move clients over until the new server is ready. If
something bad happens on upgrade, there is no downtime.
- Are you using deprecated features? As new versions of SQL
Server are released, sometimes an existing feature or functionality is
no longer needed. Since users and third-party software developers may
have extensively used the feature, Microsoft cannot simply remove the
feature from the product upon upgrade to the newer version. This action
would break the user’s applications and make the incentive of upgrading
much less desirable. For this reason, Microsoft has a three-release
deprecation policy.
Consider the sp_renamedb stored procedure. This stored procedure’s functionality was replaced by the introduction of a MODIFY NAME parameter in the ALTER DATABASE statement. Since having two ways of renaming a database is not desirable, Microsoft officially deprecated the sp_renamedb
stored procedure starting in SQL Server 2005. This means that SQL
Server 2012 will be the last version that this stored procedure exists
in the product. So, if you don’t upgrade your scripts by this future
version, they will not work anymore.
Before you perform an upgrade, you can launch
the free Upgrade Advisor from the Planning tab of the SQL Server
Installation Center. This tool runs through your existing databases, SQL
Server trace files, and T-SQL scripts and produces a report of issues
that should be addressed before you upgrade. One of the issues the tool
reports on is the use of deprecated features.
If, after you upgrade, you are still concerned
that you may have some deprecated features being used, you can use the
Windows Performance Monitor tool and monitor the SQL Server: Deprecated
Features performance object counter. Figure 18 shows the Add Counters dialog box of the Windows Performance Monitor tool.
Figure 18. Windows Performance Monitor: Add Counters dialog box
In the Add Counters dialog
box, you can collect specific deprecated features, or you can select
“All instances” and collect any occurrence of a deprecated feature.
As you can see, there are a number of questions
to ask and issues to deal with when upgrading. Your organization may
also have additional standard operating procedures for upgrading servers
that may involve the use of test servers and other processes.
