As you know, SQL Server 2000 uses the sysdtspackages table to store DTS packages and Integration Services 2005 uses the sysdtspackages90 table to store SSIS packages in the SQL Server 20
Trang 1Exercise (Use the Package Migration Wizard)
In the first part of this Hands-on, you will create a new project and run the Package Migration Wizard by right clicking the SSIS Packages node This will not only migrate the package but will add it in the project as well
1 Start BIDS and create a new Integration Services project with the following details:
Name Migrating Importing Contacts
Location C:\SSIS\Projects
2 When BIDS loads the blank project, go to the Solution Explorer window, right-click the SSIS Packages node, and choose Migrate DTS 2000 Package from the context menu (see Figure 14-13)
3 This will invoke the Package Migration Wizard, and you will see the first screen
of this wizard Click Next to move on
4 The Choose Source Location screen allows you to select the location where your package is stored Click the down arrow in the Source field to see the list of source locations The Package Migration Wizard can read DTS 2000 packages stored in Microsoft SQL Server or in a structured storage file As mentioned, SQL Server 2005 does not support Meta Data services (also called the repository)
If your DTS 2000 package is stored in Meta Data services, you may prefer to save those packages to the locations supported by the Package Migration Wizard In case you cannot do that, the Package Migration Wizard provides a way to read packages from Meta Data services when SQL Server 2000, SQL Server 2000 tools, or the repository redistributable files are installed on the local computer For this exercise, select Structured Storage File in the Source field
Figure 14-13 Starting the Package Migration Wizard
Trang 25 Specify C:\SSIS\RawFiles\Importing Contacts.dts in the File Name field as
shown in Figure 14-14 Alternatively, you can choose this file by clicking Browse
Click Next to move on
6 In the Choose Destination Location screen, specify the folder where you want to
save the migrated package The migrated package is created as a new DTSX file,
and your DTS 2000 package is left as is without any changes In the Folder Name field, specify C:\SSIS\Projects\Migrating Importing Contacts as the folder where
you want to save the migrated package (see Figure 14-15) You can also click
Browse to choose this folder, which also provides you an opportunity to create a
new folder if you need to Click Next
7 As a structured storage file can have multiple packages and package versions, you
can select the packages and their versions you want to migrate in the List Packages
screen You can also modify the name of the migrated package by editing the
Destination Package field for the selected package Select the Importing Contacts
package and change the Destination Package to Importing Contacts (Migrated)
by directly typing it into the field (Figure 14-16) Click Next
Figure 14-14 Specifying the DTS 2000 package location
Trang 38 In the Specify A Log File screen, click Browse and specify Migrating Importing Contacts.Log in the File Name field after selecting the C:\SSIS\RawFiles folder and click Save Select Yes to create this file Then click Next
9 The Complete The Wizard screen shows you summary information for all the options that you have selected in the previous screens Note that this screen also tells you the number of packages that will be migrated and the number of packages that will not be migrated Review the information and click Finish when ready
10. You will see activities occurring while the package is being migrated, component by component in the Migrating The Packages screen You can interrupt this process
by clicking Stop if necessary Once the package is migrated completely, you will see a success status for the package At this stage you can see the report by clicking Report Once you’re happy, click Close to close the Package Migration Wizard
11. As the Package Migration Wizard is closed, you will notice that a package by the name Importing Contacts (Migrated).dtsx has been added in the SSIS Packages
Figure 14-15 Specifying a destination folder for the migrated package
Trang 4node in the Solution Explorer window You can delete the blank package
Package.dtsx, as it is not required in this exercise
12. Explore to the C:\SSIS\RawFiles folder and open the Migrating Importing
Contacts.Log file using Notepad This shows you details of how the migration
progressed
Exercise (Execute the Migrated Package)
In this final part, you will execute the migrated package
13. Double-click the Importing Contacts (Migrated).dtsx package to open it You
will see a Data Flow task named DTSTask_DTSDataPumpTask_1 on the
Control Flow Designer surface Notice that this is the DTS 2000 data pump task
name Also, two connection managers were added: the OLE DB Connection
Manager for connecting to the Campaign database, and a Flat File Connection
Manager for connecting to the Contacts.txt file Double-click the Data Flow task
to open the Data Flow panel
Figure 14-16 Selecting DTS 2000 packages that you want to migrate
Trang 514. As the DTS 2000 package was quite simple, you will see a flat file source and
an OLE DB destination adapters connected by a data flow path with a data conversion task in between in the Data Flow Designer surface Press f5 to execute the package and check that it has been migrated successfully
15. Press shift-f5 to stop debugging the package Go to the Data Flow tab and double-click the OLE DB Destination to open the editor Review the settings in the Connection Manager page Go to the Mappings page and note that though the input column names do not match with the destination columns, they have been mapped correctly When you’re done, click OK to close the editor
Review
You’ve used the Package Migration Wizard to migrate a DTS 2000 package to Integration Services You selected a DTS 2000 package stored on the file system in a structured storage file and saved the destination package in the DTSX format on the file system
In the end, you observed that though the package was migrated successfully and no error was reported, the settings do seem in need of tuning The point to be noted is that the Package Migration Wizard can migrate most of the components successfully, yet it needs to be tested out and the migrated package might need configurations
Upgrading Integration Services 2005
If you are facing the task to upgrade a previous version of Integration Services, you will find this section useful as you will learn about various options available to you when upgrading from Integration Services 2005 Depending upon how the server is currently configured and what you want to achieve, you will choose one of the various options available to you that are explained next
Before we go ahead and look at pros and cons of each approach, let us understand what key changes have been implemented in SQL Server 2008 from the point of view
of Integration Services 2008 If you save your packages to SQL Server, they get stored into the MSDB database However, they are stored in different tables, depending on which version of the SQL Server or Integration Services you use As you know, SQL Server 2000 uses the sysdtspackages table to store DTS packages and Integration Services 2005 uses the sysdtspackages90 table to store SSIS packages in the SQL Server
2005 MSDB database With the SQL Server 2008 release, the word “dts” has been replaced in these tables with the more relevant word “ssis” and the table Integration Services 2008 uses to store packages is named as sysssispackages Not only the storage table but other relevant tables used by Integration Services have undergone this change too—e.g., sysssispackagefolders and sysssislog tables Understanding this difference alone will answer most of your questions on differences in behavior between the two versions of Integration Services
Trang 6The other key difference is made in BIDS, which uses Microsoft Visual Studio
Tools for Applications (VSTA), replacing the Microsoft Visual Studio for Applications (VSA) environment This will mean that all your scripts you have developed in SSIS
2005 need to be upgraded to the VSTA environment You do not need to worry
here, as VSTA converts VSA scripts for you Having understood these changes, let us
explore the options described
Same-Server Installation
In this case both the SQL Server Database Engine and Integration Services are running
on the same server currently and you wish to upgrade them In this case you might choose from one of the following two options:
Running side-by-side
c
Upgrading both SQL Server and Integration Services
c
Running Side-by-Side
First of all, the good news is that Integration Services 2008 can coexist with Integration Services 2005 as it does with Data Transformation Services If you install Integration
Services 2008 side-by-side with its 2005 predecessor, you can run both versions of
packages with their respective development environments Considering the changes in
Integration Services storage tables and the changes in BIDS as explained earlier, the
following issues will come up:
BIDS 2005 can maintain and develop SSIS 2005 packages, while BIDS 2008 can
c
maintain and develop SSIS 2008 packages
BIDS 2008 can open and load SSIS 2005 packages, while BIDS 2005 cannot
c
open SSIS 2008 packages When opening an SSIS 2005 package in BIDS 2008,
the SSIS 2005 package gets converted at loading stage into SSIS 2008 format
BIDS then works on this package format, and once this loaded and converted
package is saved, it can’t be opened using BIDS 2005
Much as described in the preceding point, when you try to run an SSIS 2005
c
package using the SSIS 2008 dtexec utility, the utility temporarily converts the
package into SSIS 2008 version before running it This happens only in memory
and the original version is not changed
Due to differences in storage locations, Integration Services cannot use different
c
versions of SQL Server to store packages, as the tables and metadata won’t exist
That is, Integration Services 2008 needs SQL Server 2008 and Integration
Trang 7Services 2005 needs SQL Server 2005 to store packages This also means that you cannot connect to an SSIS 2005 instance from SSMS 2008 However, you can modify the configuration file so that you can manage SSIS 2005 packages from SSMS 2008 This also enables you to import packages into SQL Server 2008 from
an instance of SSIS 2005, but not the other way around: using SQL Server 2005 Management Studio doesn’t allow you to manage or connect to a higher version
of Integration Services, nor does it allow you to import or export packages to SSIS 2008
Upgrading Both SQL Server and Integration Services
Your next option is to upgrade both SQL Server and Integration Services, especially
if they exist on the same server As discussed earlier in the chapter, you can use the Upgrade Advisor to find out any issues with the upgrade and can fix them before you begin the upgrading process When you run the upgrade process and choose to upgrade both SQL Server 2005 and Integration Services 2005 to their respective 2008 releases, the upgrade process performs a series of tasks that are important to understand
The upgrade process replaces the SSIS 2005 files with SSIS 2008 files and c
configures Integration Services to point to the new instance of SQL Server 2008
It creates new metadata, tables, and stored procedures for Integration Services in c
the MSDB database, removing the old msdb.sysdts*90 system tables and the system stored procedures used by SSIS 2005 The new tables, named as msdb.sysssis*, contain the required metadata for SSIS 2008
It creates three new fixed database-level roles: db_ssisadmin, db_ssisltduser, and c
db_ssisoperator for access control to SSIS packages The SSIS 2005 roles of db_dtsadmin, db_dtsltduser, and db_dtsoperator are added as members to the corresponding new roles
The most important task it does from the user perspective is to move SSIS c
packages from old store locations to new store locations Bear in mind that it can do this only for the locations it is aware of So, it moves packages from the sysdtspackages90 system table to the sysssispackages system table for the packages that are stored in the MSDB database And it moves packages stored in SSIS
2005 default SSIS package store, that is, the …\SQL Server\90 folder, to the new default location under …\SQL Server\100 Along with moving packages, it also moves the folder structure you have created in SSIS 2005 by moving folder metadata from the sysdtsfolders90 system table to the sysssispackagefolders system table All other storage locations used to store SSIS 2005 packages remain as-is and no change happens there, as the upgrade process is not aware of them
Trang 8While it moves packages to new storage locations, it does not migrate them to
c
2008 format You will need to migrate them separately using the SSIS Package
Upgrade Wizard The sysssispackages table shows values in the packageformat
column to indicate the version of the package The packages that are still in the
SSIS 2005 version will have a value of 2, whereas the packages that are in SSIS
2008 will have a value of 3 You can use the packageformat column to identify the
current version of the packages when looking to upgrade existing packages
Last, the SQL Server Agent jobs that use dtexec utility directly will not run due
c
to a change in the path of the dtexec utility in the 2008 release You will need to
modify these jobs yourself
Different Server Installation
In this installation, you have a SQL Server database engine installed on one computer
while the Integration Services package that connects to this database instance is
installed on another computer You might choose one of the following two options in
such a scenario:
Upgrading SQL Server Database Engine only
c
Upgrading Integration Services only
c
Upgrading SQL Server Database Engine Only
In this scenario you upgrade only the SQL Server database engine that is used by
Integration Services to store packages The Integration Services process could be on a
different server and remains on 2005 version This shows your intention to keep using
SSIS 2005 without upgrading packages even after an upgrade of SQL Server Here are
the limitations that apply in this case:
You can still use BIDS 2005 to develop and modify existing Integration Services
c
packages that are stored in the file system
The system tables used by Integration Services in the MSDB database get
c
migrated to 2008 format as has been discussed in the preceding section, and the
SSIS 2005 packages are moved to the new system table This change renders
Integration Services 2005 unable to open the packages stored in SQL Server
Actually, not only Integration Services but the other SQL Server 2005 tools
on other computers, such as BIDS, SQL Server Management Studio and SQL
Server 2005 Agent Jobs, cannot discover the packages on the upgraded instance
of the database engine That is, the packages are not available on the upgraded
Trang 9instance of SQL Server from the perspective of the SSIS 2005 toolset You should keep a copy of packages on the file system before upgrading the database engine
if you intend to keep using SSIS 2005 even after an upgrade of the SQL Server database engine
Upgrading Integration Services Only
In this scenario you upgrade only the Integration Services while the SQL Server database engine that is used to store packages is on another computer and continues
to be the 2005 version You intend to upgrade packages after the upgrade, though the SQL Server is not upgraded Here are the limitations that apply in this case:
The packages stored in the file system are available to Integration Services 2008 c
and can be easily upgraded using the SSIS Package Upgrade Wizard However, the upgraded packages or the new SSIS 2008 packages cannot be saved to SQL Server 2005, as BIDS 2008 looks for the 2008 versions of system tables in the MSDB database
The packages stored in SQL Server 2005 cannot be accessed by BIDS 2008 due c
to different system tables However, these packages can still be executed by SQL Server Agent jobs that run on SQL Server 2005, as no change has happened on the SQL Server
Later, if you want to upgrade the packages that are stored in SQL Server 2005, c
you will have to export them to a file system so as to enable BIDS 2008 to access them
Upgrading SSIS 2005 Packages
By now you understand that the upgrade process moves the existing SSIS 2005 packages
to new system tables or to the new SSIS Package Store, but does not upgrade them to
2008 format You will have to manually upgrade these packages Following are the tools that you can use and the consideration you need to be aware of while upgrading SSIS
2005 packages to SSIS 2008 format
If you open an SSIS 2005 solution or project in BIDS 2008, the Visual Studio c
Conversion Wizard starts automatically (Figure 14-17) and converts the solution
or the project created in the previous version to the current version This is in-place conversion, so you should take a backup or keep a copy in another location before proceeding further If the solution or project is under source control, it
Trang 10will automatically be checked out during the conversion Once the Visual Studio
conversion completes, the SSIS Package Upgrade Wizard starts automatically
You can use the SSIS Package Upgrade Wizard to upgrade one or many SSIS
c
2005 packages (see Figure 14-18) together to SSIS 2008 format This tool is
installed when you install Integration Services 2008 and is available only in
Standard, Enterprise, and Developer Editions of SQL Server This wizard can also
be started manually from one of the following places:
By right-clicking the SSIS Packages node in the Solution Explorer and
c
selecting the Upgrade All Packages option
While connected to Integration Services in SSMS, by expanding the Stored
c
Packages node and then right-clicking the File System or MSDB node and
selecting the Upgrade Packages option
From Installation Center | Tools | Upgrade Integration Services packages
c
By running the SSISUpgrade.exe file from the command prompt after going
c
to the C:\Program Files\Microsoft SQL Server\100\DTS\Binn folder
Figure 14-17 Visual Studio Conversion Wizard