Hands-On Microsoft SQL Server 2008 Integration Services part 65 docx

618 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (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 Chapter 14: Migrating to Integration Services 2008 619 5. 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 620 Hands-On Microsoft SQL Server 2008 Integration Services 8. 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 Chapter 14: Migrating to Integration Services 2008 621 node 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 622 Hands-On Microsoft SQL Server 2008 Integration Services 14. 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  5 to execute the package and check that it has been migrated successfully. 15. Press -5 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. Chapter 14: Migrating to Integration Services 2008 623 The 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. is 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. at is, Integration Services 2008 needs SQL Server 2008 and Integration 624 Hands-On Microsoft SQL Server 2008 Integration Services Services 2005 needs SQL Server 2005 to store packages. is 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. is 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. e 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. e 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. e SSIS 2005 roles of db_dtsadmin, db_dtsltduser, and db_dtsoperator are added as members to the corresponding new roles. e 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. Chapter 14: Migrating to Integration Services 2008 625 While 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. e sysssispackages table shows values in the packageformat column to indicate the version of the package. e 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. e 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. is 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. at is, the packages are not available on the upgraded 626 Hands-On Microsoft SQL Server 2008 Integration Services instance 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: e 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. e 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. is 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 Chapter 14: Migrating to Integration Services 2008 627 will 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. is tool is installed when you install Integration Services 2008 and is available only in Standard, Enterprise, and Developer Editions of SQL Server. is 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 . locations, Integration Services cannot use different c versions of SQL Server to store packages, as the tables and metadata won’t exist. at is, Integration Services 2008 needs SQL Server 2008 and Integration. 624 Hands-On Microsoft SQL Server 2008 Integration Services Services 2005 needs SQL Server 2005 to store packages. is also means that you cannot connect to an SSIS 2005 instance from SSMS 2008. . 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