1. SQL Server Integration Services
SQL Server Integration
Services (SSIS) was introduced in SQL Server 2005 and uses a completely
different architecture than its predecessor Data Transformation Services
(DTS). SSIS provides a much more robust environment for moving and
transforming data, but it also provides difficulties when upgrading
packages from SQL Server 2000. You basically have two choices: You can
rewrite each package to run in SSIS or use the old DTS DLLs to continue
running each package. If you have a small number of fairly simple
packages, it may be easy enough to rewrite the packages manually. If
not, there are a few tools available to help you with the conversion
process.
1.1. Running DTS in SQL Server 2008
SQL Server 2008 provides
the ability to run and manage DTS packages by downloading a couple of
add-ons. We would use this approach as a last resort and use the upgrade
as an opportunity to migrate your packages to SSIS. SSIS performs much
more efficiently, and the add-ons may not be available in the next
version of SQL Server. For more information, search for the topic "How
to: Install Support for Data Transformation Services Packages" in SQL
Server Books Online or MSDN (http://msdn.microsoft.com).
1.1.1. Runtime Support
In order to run DTS packages in
SQL Server 2008, you must install the runtime support add-on. To
install runtime support for DTS packages in SQL Server 2008, download
and install the Microsoft SQL Server 2005 backward compatibility
components from the Microsoft SQL Server 2008 Feature Pack web page from
the Download Center located at www.microsoft.com/downloads/details.aspx?FamilyID=228de03f-3b5a-428a-923f-58a033d316e1&DisplayLang=en.
1.1.2. Design-Time Support
In order to design and
manage DTS Packages in SQL Server 2008, you must install the design-time
support add-on. To install design-time support for DTS packages in SQL
Server 2008, download the Microsoft SQL Server 2000 DTS designer
components from the Feature Pack for Microsoft SQL Server 2005 web page
from the Download Center located at www.microsoft.com/downloads/details.aspx?FamilyID=50b97994-8453-4998-8226-fa42ec403d17&displaylang=en.
1.2. DTS Package Migration Wizard
The DTS Package Migration
Wizard is installed when you select Integration Services as a feature
during your SQL Server 2008 install. The Migration Wizard allows you to
upgrade existing DTS packages to an SSIS format, as long as all the
objects are compatible. The Upgrade Advisor can be used to identify some
of the issues that need to be resolved before migrating the packages.
NOTE
DTS xChange is a
third-party tool that can be used to migrate DTS packages to SSIS. DTS
xChange does a better job than the DTS Migration Wizard. It can also
convert packages that the Migration Wizard will be unable to convert.
DTS xChange is not a free tool, but if you have many complex DTS
packages to convert, it may be well worth the investment. The demo
version can be used to migrate up to five packages and can be downloaded
from the Pragmatic Works web site at www.pragmaticworks.com.
Use the following steps to convert DTS packages to SSIS using the DTS Package Migration Wizard:
Start the DTS Package Migration Wizard in one of three ways.
Navigate
to the Legacy folder under Management in SQL Server Management Studio.
Right-click Data Transformation Services and select Migration Wizard.
Open
an Integration Services project in the Business Intelligence
Development Studio (BIDS). Right-click on SSIS Packages in the Solution
Explorer and select Migrate DTS 2000 Package.
Start the DTSMigrationWizard.exe located in the C:\Program Files\Microsoft SQL Server\100\DTS\Binn folder.
Select the source of the packages.
Select the destination for the packages.
Select the available packages from the source that you wish to migrate.
If
any of the packages are password protected, you will be prompted for
their passwords. It is not possible to migrate a package that has been
password protected without knowing the password. If none of the packages
is password protected, the wizard will skip this step.
You can specify a log file to capture any errors that were encountered during the migration.
The
packages are then upgraded one by one, and you can view the progress of
each migration. If a package cannot be migrated, you can opt to end the
migration process for the remaining packages or to skip just the
package that cannot be migrated.
Once
the migration process is complete, open the packages using BIDS and
check for any validation errors. If possible, run each package to make
sure it executes successfully and that the results are as you expect.
2. Post-Upgrade Procedures
In order to take advantage of
everything that SQL Server 2008 has to offer, there are a few steps that
need to be taken after an upgrade has occurred. We will discuss each
change that needs to be made and explain how it benefits you after the
upgrade. Following are the steps that you should perform after any
upgrade:
Change the compatibility level
Check the integrity of the objects in your database
Correct inaccurate row and page counts for tables and indexes
Set your page verification method to CHECKSUM
Update statistics
2.1. Changing Compatibility Level
The first thing you should do
after the upgrade is change the compatibility level of the database,
assuming it is supported by the application. We have had some vendors
allow us to upgrade the database, as long as we left the compatibility
level set to the prior version. When upgrading a database to SQL Server
2008, the database maintains the current compatibility level. In order
to take advantage of the new features offered in SQL Server 2008, you
should change the compatibility level to SQL Server 2008 (100).
NOTE
If the database
compatibility level is below SQL Server 2000 (80), it will be changed
automatically to SQL Server 2000 (80) during the upgrade, which is the
minimum level supported in SQL Server 2008.
To view the current compatibility level, you can query the sys.databases catalog view:
Select name, compatibility_level FROM sys.databases
The ALTER DATABASE command replaces the sp_dbcmptlevel
procedure that was previously used to change the compatibility level.
You can also change the compatibility level in the Options tab of the
Database Properties dialog box that is displayed by right-clicking the
database and selecting Properties.
Run the following statement to change the compatibility level to SQL Server 2008:
ALTER DATABASE [DatabaseName] SET COMPATIBILITY_LEVEL = 100
|
Changing the compatibility
level while the database is currently in use could result in the
generation of an incorrect query plan and unpredictable queries. The
faulty query plan may also be stored in the cache and used for multiple
queries. It is recommended that you change the compatibility level when
the database is in single-user mode.
|
|
2.2. Checking Object Integrity
The next thing you should do is run DBCC commands to test for object integrity. The DBCC CHECKDB
command checks the integrity of the objects in a database and should be
run on a regular basis. One thing that this command does not check in
databases created in versions prior to SQL Server 2005 is the integrity
of the data in the columns. Adding the DATA_PURITY option causes the CHECKDB
command to look for column values that are invalid or out of range. Any
database that was created in SQL Server 2005 or later will include the DATA_PURITY check by default; but if the database is being upgraded from an earlier version, you must run the command with the DATA_PURITY
option at least once and fix any issues. Once the command has executed
successfully and the issues have been resolved, an entry is made in the
database header and the DATA_PURITY option will be included by default as a part of the normal CHECKDB operation.
The following command should be executed to perform a CHECKDB with DATA_PURITY:
DBCC CHECKDB ([DatabaseName]) WITH DATA_PURITY
2.3. Correct Row and Page Counts
The DBCC UPDATEUSAGE
command corrects inaccurate row and page counts for tables and indexes.
Invalid counts are common in previous versions of SQL Server and can
skew the results of certain commands, such as sp_spaceused. You should always run the UPDATEUSAGE
command on databases that have been upgraded from SQL Server 2000. You
do not need to run the command on a regular basis unless frequent Data
Definition Language (DDL) modifications are made in the database.
The following command should be executed to update the usage counts for a given database:
DBCC UPDATEUSAGE ([DatabaseName])
2.4. Setting the Page Verification Method
When upgrading a database, the PAGE_VERIFY option will remain the same as it was in the prior version. You should make sure this option is set to CHECKSUMCHECKSUM option was introduced in SQL Server 2005 and provides the highest level of integrity for the data files. When the CHECKSUM
after the upgrade. The option is enabled, a checksum of the whole page is computed and stored
in the page header when the page is written to disk. When the page is
read from disk, the checksum is recalculated and compared with the value
in the header.
To view the current PAGE_VERIFY option, you can query the sys.databases catalog view:
SELECT name, page_verify_option_desc FROM sys.databases
Use the ALTER DATABASE command to change the PAGE_VERIFY option to CHECKSUM:
ALTER DATABASE [DatabaseName] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT
2.5. Updating Statistics
Updating the statistics
after the upgrade allows the database engine to take advantage of the
enhancements made in SQL Server 2008 to optimize query performance. The
statistics that reside in the database were created with an earlier
version of SQL Server. By recreating them with SQL Server 2008, you are
allowing SQL Server to create more intelligent statistics to work with.
This ultimately results in a better execution plan and faster, more
efficient queries.
To update statistics, run the following script against each of the databases that have been upgraded:
USE [DatabaseName]
GO
sp_msforeachtable 'UPDATE STATISTICS ON ? WITH FULLSCAN; '
