Microsoft SQL Server 2008 R2 Unleashed- P29 pps

ptg CHAPTER 9 Upgrading to SQL Server 2008 FIGURE 9.6 The Upgrade Advisor Progress screen.. You can upgrade your existing SQL Server 2000 SP4 or later and SQL Server 2005 SP2 or later in

ptg CHAPTER 9 Upgrading to SQL Server 2008

FIGURE 9.6 The Upgrade Advisor Progress screen

Note that the DTS Parameters screen advises that you must install the Legacy

Components feature when installing SQL Server 2008; otherwise, SQL Server 2008 will not

be able to run your DTS packages (unless they are upgraded to the new SSIS format) To

upgrade your DTS packages, you need to use the DTS Migration Wizard, which is installed

with SSIS and discussed later in this chapter, in the section “Migrating DTS Packages.”

When you’re all set with your DTS and SSIS selections, click Next to reach the Confirm

Upgrade Advisor Settings screen Make sure that all the SQL Server services you are

analyz-ing are runnanalyz-ing and (if you’re happy with your selections) click the Run button to begin

the analysis

As you can see from the Upgrade Advisor Progress screen that appears (see Figure 9.6), the

wizard performs a task-based study of each component, providing per-step reporting, similar

to the installer and the System Configuration Checker (both discussed in Chapter 8)

When the analysis is complete, the UA Progress screen presents a Launch Report button

The output of the UA Analysis Wizard is an XML report that you can view via the

second major component of the UA, the Report Viewer, described in the next section

NOTE

You can view your last-generated report by using the Report Viewer; you can find the

link to launch it on the main screen If you run the UA more than once against the

same SQL Server instance, however, you must save your previously generated reports

to a directory other than the default output directory; otherwise, the previously

gener-ated report will be overwritten

UA reports are saved by default to the folder My Documents\SQL Server 2008 R2

Upgrade Advisor Reports\Servername, and then they are broken down into

sepa-rate XML files by component (for example, AS.xml for Analysis Services, DE.xml for the

Database Engine)

You can launch the Report Viewer to figure out what to do about the issues the UA may

have uncovered Click the Launch Report button to proceed

The Report Viewer

The Report Viewer is one of the most important tools in the upgrade process because it

provides per-issue messaging, resolution tracking, and (in many cases) hyperlinks to the

compiled help documentation distributed with the UA

Issues are organized in the Report Viewer on a per-server and then per-component basis

They can be filtered by type (that is, all issues, all upgrade issues, pre-upgrade issues, all

migration issues, and resolved issues), and you can track your resolution progress by

checking the This Issue Has Been Resolved check boxes Figure 9.7 shows the main user

interface of the Report Viewer

FIGURE 9.7 SQL Server UA’s Report Viewer

CHAPTER 9 Upgrading to SQL Server 2008

Destination: SQL Server 2008 or SQL Server 2008 R2

Now that you have become familiar with how to use the helpful Upgrade Advisor, you’re

ready to begin your extensive pre-upgrade testing phase After you resolve all the issues

you can, it’s time to take the next step: install SQL Server 2008 (in your test and

develop-ment environdevelop-ments first, of course)

Two different paths lead from SQL Server 2000 or 2005 to SQL Server 2008:

You can upgrade your existing SQL Server 2000 SP4 or later and SQL Server 2005 SP2

or later instances in-place, using the SQL Server Installer

You can install SQL Server 2008 side by side with your current SQL Server instances

and then migrate your data and other content to SQL Server 2008

The same upgrade paths exist for upgrading from SQL Server 2008 to SQL Server 2008 R2

The path you choose depends primarily on two factors: your comfort level with the new

platform and the scope of feature use in your current environment When you have

become familiar with what it takes to travel either path, you’ll find it much easier to make

your decision The first approach we explore in this chapter is the more conservative

side-by-side migration path

NOTE

If the server environment where your current SQL Server installation resides is not a

supported platform for performing an in-place upgrade, a side-by-side migration may

be your only option For example, if you are upgrading from SQL Server 7 or running in

a Windows 2000 server environment, an in-place upgrade is not supported For a list

of supported in-place upgrade paths, see the “Upgrading In-Place” section, later in

this chapter

Side-by-Side Migration

SQL Server 2008 can coexist without a problem on the same servers as any existing SQL

Server 2000 or 2005 instances SQL Server 2008 R2 can coexist on the same servers as any

existing SQL Server 2000, 2005, or 2008 instances This means you can install one or more

instances of SQL Server 2008 or 2008 R2 without performing an in-place upgrade of any

pre-2008 instances You don’t have to worry about whether you’re breaking existing

func-tionality Side-by-side migration is therefore an easy option to investigate

NOTE

If you are doing a side-by-side installation, be sure your server has sufficient resources

(CPU, memory, disk space) to support running multiple instances of SQL Server

Many administrators favor the side-by-side approach to upgrading because it gives

every-one on the development team (including eager software folks) a chance to get comfortable

with the new features in the new SQL Server release before committing to it in production

environments

In addition, it is far easier to roll back to your previous-version SQL Server components

because installing side by side leaves them intact (unlike upgrading in-place, which

replaces them) When you are reasonably comfortable with the new SQL Server release,

you can go forward confidently in migrating all your objects (presuming that, if you’re

leaving previous versions intact, you’re also ready to perform necessary tasks, such as

changing connection strings, server aliases, and so on)

Avoiding an Unintentional In-Place Upgrade During Setup

If you do intend to go ahead with a side-by-side installation, there’s a small gotcha you

need to watch out for when installing a new instance of SQL Server 2008 When you run

the Setup program, the Instance Name screen is somewhat lengthy in its header’s verbiage,

and if you don’t take the time to read it closely, you might unintentionally upgrade all

your components This is the lowdown:

If you choose the Default Instance radio button and you already have a SQL Server

default instance, that default instance is upgraded

If you the choose the Named Instance radio button, you need to make sure to enter

a name that you know is not in use as an instance name; otherwise, the existing

named instance is upgraded

Figure 9.8 shows an example of how to make the right choice and use an instance name,

SQL2008R2, that makes it abundantly clear you are installing a new instance

FIGURE 9.8 Installing a new named SQL Server 2008 R2 instance

CHAPTER 9 Upgrading to SQL Server 2008

Migrating Databases

Now it’s time for the most important task: migrating your databases to SQL Server 2008

One method of migrating to SQL Server 2008 or 2008 R2 is by backing up your SQL Server

2000 and 2005 databases and restoring them to SQL Server 2008 Another method is to

attach or restore a database from a prior version of SQL Server to SQL Server 2008 When

you migrate using either of these methods, the database is upgraded automatically during

the attach/restore process

NOTE

Database backups created by using SQL Server 7.0 or earlier are in an incompatible

format and cannot be restored in SQL Server 2008 or 2008 R2 For information on how

to migrate a database from SQL Server 6.5 or 7.0 to SQL Server 2008, see the

sec-tion “Upgrading from SQL Server 7 or SQL Server 6.5,” later in this chapter

When you use backup and restore to copy a database to another instance of SQL Server,

the source and destination computers can be any platform on which SQL Server runs The

general steps to upgrade using backup and restore are as follows:

1 Back up the source database that resides on an instance of SQL Server 2000, SQL

Server 2005, SQL Server 2008, or SQL Server 2008 R2

2 Restore the backup of the source database on the destination SQL Server Restoring

the database automatically creates all the database files and upgrades the database

When restoring the database, you might need to use the MOVE option to relocate the

data-base files because SQL Server 2008 and SQL Server 2008 R2 use a different default path

than earlier versions For more information on using backup and restore, see Chapter 14,

“Database Backup and Restore.”

In SQL Server 2008 R2, you can also use the detach and attach operations to migrate a

user database from SQL Server 2000 or SQL Server 2005 After you attach a SQL Server

2005 or SQL Server 2000 or SQL Server 2008 database to SQL Server 2008 R2, the database

is upgraded automatically and becomes available immediately For more information on

the syntax and options for detaching and attaching databases, see Chapter 23, “Creating

and Managing Databases.”

Another method of migrating an existing database is by using the SQL Server Copy

Database Wizard to copy databases between multiple instances of SQL Server

TIP

Before you use any of the methods described here, Microsoft recommends you run the

appropriate DBCC consistency checks to make sure there is no data corruption within

the databases to be migrated

Using the Copy Database Wizard Using the Copy Database Wizard is probably the easiest

approach to use to migrate your databases to SQL Server 2008 or 2008 R2 To run the

Copy Database Wizard, using SQL Server Management Studio (SSMS), connect the Object

Explorer to your previous SQL Server version’s instance Expand Databases and then select

and right-click the database you want to copy (or move) into SQL Server 2008 Then select

Tasks, Copy Database

When the wizard’s initial Welcome page is displayed, click Next and then select your

source server (the 2000 or 2005 instance) Click Next again and select your destination

server (your newly installed SQL Server 2008 or SQL Server 2008 R2 instance) Click Next

again to bring up the Select the Transfer Method screen This screen provides two options

for copying or moving your databases to SQL Server 2008:

Detach and Attach—This option is the same as the detach/attach method

described previously It’s fast, but it takes the database offline during the migration

process

Use the SQL Server Management Objects (SMO) to Import the Database—This

option is slower, but it keeps the source database online during the process

NOTE

When you use the detach and attach method, SSIS uses the service account of SQL

Server Agent that is running on the 2008 (destination) instance This account must be

able to access the file systems of both servers; otherwise, the wizard will fail

Select the option that works best for you and then click Next The Select Databases screen

appears, and, as Figure 9.9 shows, you should check the Copy (not Move) check boxes for

the databases you want to migrate

FIGURE 9.9 Selecting the databases to copy to SQL Server 2009

ptg CHAPTER 9 Upgrading to SQL Server 2008

FIGURE 9.10 Copy Database Wizard Configure Destination Database screen

CAUTION

After a pre-2008 database is upgraded (in case you choose the Move Database option

or you perform an attach or restore and delete the original), it cannot be downgraded

back to its former version—not even if you attempt to detach/attach or restore it to

SQL 2000 or 2005 Thus, it is especially important to create full backup copies of all

your databases before you upgrade It’s also a good idea to back up the entire

Program Files/Microsoft SQL Server directory tree

After you make your database selections, click Next, and the Configure Destination

Database screen appears for each database you selected in the previous step This screen

allows you to rename the database on the destination server if you so desire (see Figure

9.10) It also provides options to overwrite any existing databases or MDF (data) and LDF

(log) files on the destination server or to create new ones in the folders of your choice

Make your selections and click Next

The Select Database Objects screen that appears next (see Figure 9.11) provides some real

power because it allows the server-wide objects (those stored in the system databases and

source database) to be imported These objects include stored procedures residing in

master, SQL Server Agent jobs, custom user-defined error messages, SSIS packages, and

SQL Server logins You need to click the ellipsis button to choose the specific ones you

want to import (rather than choosing them all, which is the default)

When you’re finished selecting the objects you want brought over, click Next again The

Configure the Package screen that appears next provides the opportunity to name and

save the SSIS package created for migrating the database, and to specify how you want to

log the messages generated during the transfer Click Next to present the Schedule the

FIGURE 9.11 Importing server-wide objects, using the Copy Database Wizard

Package screen, which allows you to run the transfer immediately or schedule it to run at

a specific time You are also given an opportunity to specify an SSIS proxy account to use

to run the transfer (you should make sure it’s an account that has appropriate permissions

on both the source and destination servers to ensure a successful transfer)

After you make your scheduling choices, click Next to display the Complete the Wizard

screen (see Figure 9.12) Here, you have an opportunity to review the choices you’ve made

on the prior screens If everything looks okay, click Finish to complete the wizard and

start or schedule the Copy Database package

FIGURE 9.12 The Copy Database Complete the Wizard screen

CHAPTER 9 Upgrading to SQL Server 2008

Database Compatibility Level Migrating pre-2008 databases into SQL Server 2008 brings

up the question of compatibility issues and database compatibility levels The

compatibil-ity level is a per-database setting that controls T-SQL execution behavior with regard to

SQL Server’s versioning system

The T-SQL execution engine is flexible insofar as it has the capacity to switch between

varying, version-dependent behaviors according to the current compatibility-level setting

When a database is upgraded to SQL Server 2008 from any earlier version of SQL Server,

the database retains its existing compatibility level if it is at least 80 (SQL Server 2000)

Upgrading a database with a compatibility level below 80 sets the database to

compatibil-ity level 80

Compatibility level affects behaviors only for the specified database, not for the entire

server An important point to understand about database compatibility levels, however, is

that the database compatibility-level setting is intended to provide only partial backward

compatibility with earlier versions of SQL Server It does not prevent the use of new T-SQL

features available in SQL Server 2008 such as new data types and statements

The compatibility-level setting is provided primarily as an interim migration aid to work

around version differences in the behaviors that are controlled by the relevant

compatibil-ity-level setting Essentially, it allows T-SQL code that may be using deprecated features or

expects pre-100 level behaviors for certain commands to continue operating as it did in

the prior version of SQL Server Using the compatibility-level setting should not be viewed

as a permanent solution It should be used only until the T-SQL code affected by

behav-ioral differences in SQL Server 2008 can be converted to work properly in SQL Server

2008 Then you can use ALTER DATABASE to change the compatibility level to 100

You can find a full list of the behavioral differences between the compatibility-level settings

in the Books Online article associated with the “ALTER DATABASE Compatibility Level”

topic This option can be used to set the compatibility level for a particular database

To view the current compatibility level of a database, query the compatibility_level

column in the sys.databases catalog view:

select compatibility_level from sys.databases where name = db_name()

go

compatibility_level

-90

Upgrading In-Place

Now that you’ve seen how to migrate your databases to SQL Server 2008 by following the

by-side migration path, let’s look at the alternative: upgrading in-place Unlike a

side-by-side install, an in-place upgrade permanently modifies the SQL Server components,

data, and metadata objects, and there is no going back You will likely be more

comfort-able taking the by-side migration path than doing an in-place upgrade, unless a

by-side migration is not possible because of disk space limitations, you have very few SQL

Server features in use, or you are fairly confident about the potential success of the

upgrade process because you’ve done extensive issue resolution with the assistance of the

Upgrade Assistant

If you are performing an in-place upgrade of the Database Engine, it is strongly

recom-mended that you first do the following:

Create full, verified backups of your existing SQL Server databases

Run the appropriate DBCC consistency checks (for example, DBCC CHECKDB and DBCC

CHECKFILEGROUP)

Make sure the system databases on your pre-2008 instances (for example, master,

msdb, tempdb, and model) are all set to auto-grow

Disable any startup stored procedures that get kicked off when the SQL Server

service starts

Disable database replication and empty the replication log

After you perform all these actions, you are ready to begin the upgrade process

Upgrading the Database Engine

You perform an in-place upgrade by running the SQL Server Installation Center On the

Installation page, you can invoke the Upgrade Wizard to upgrade from SQL Server 2000,

2005, or 2008 (see Figure 9.13) After first running the Setup Rules check and installing the

Setup Support Files, the Upgrade Wizard essentially runs the installation process (The

installation process and all its screens are described in Chapter 8 under the heading,

“Install Screens, Step by Step.”) The key differences between running a new install versus

an upgrade is that during the upgrade process, you choose an existing default or named

instance on the Select Instance screen (see Figure 9.14)

After selecting the instance to upgrade, you see the Feature Selection page The features to

be upgraded are preselected You cannot change the features to be upgraded, and you

cannot add features during an upgrade operation To add features, you need to run the

Installation Center again after the upgrade operation is complete

After making choices on the Features Selection page, step through the Instance

Configuration, Disk Space Requirements, and Server Configuration screens, making

changes as necessary For example, authentication and login information are carried

forward from the previous instance of SQL Server You can assign the same login account

to all SQL Server services, or you can configure each service account individually You can

also specify whether services start automatically, are started manually, or are disabled

Next, you are presented with options for upgrading your full-text catalogs In SQL Server

2005 and earlier versions, each full-text index resided in a full-text catalog that belonged

to its own filegroup and was treated as a database file In SQL Server 2008, a full-text

catalog is a logical concept that refers to a group of full-text indexes and is no longer

treated as a separate database file with a physical path However, during upgrade of any