- The Scope of Things
- Available Migration Resources
- Some Migration Considerations
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Available Migration Resources
Knowing that the changes in architecture and features would essentially break a large number of customers, the Integration Services team developed a set of tools and features that you can use to simplify migration. These tools can be used exclusively or in combination with each other, depending on the approach you take, as discussed in the next section.
Upgrade Advisor
The Upgrade Advisor is a tool that interrogates your servers and builds a report that lists any potential problems you might have when migrating to SQL Server 2005. Running the Upgrade Advisor should be the first thing you do when you're considering an upgrade.
Running the Upgrade Advisor
When you first place the SQL Server setup disk into your machine, there should be a splash screen that appears with several links on it. Figure 3.1 shows the splash screen with the link to install the Upgrade Advisor highlighted.
)
Figure 3.1 Install the SQL Server Upgrade Advisor from the Setup Splash Screen
After you've stepped through the setup and have the Upgrade Advisor installed, you can launch it from the SQL Server 2005 Start menu. Figure 3.2 shows the Upgrade Advisor start page. Some links are provided for finding out more about upgrading. The bottom two links are the most interesting. The first link, Launch Upgrade Advisor Analysis Wizard, lets you perform the actual upgrade analysis. The second link, Launch Upgrade Advisor Report Viewer, lets you view reports generated from previous runs of the Upgrade Advisor.
)
Figure 3.2 The Upgrade Advisor lets you view reports or run the Upgrade Advisor Analysis Wizard
Click the link to launch the Upgrade Advisor Analysis Wizard. Figure 3.3 shows the first page in the wizard, which tells you the steps you'll take in the wizard.
)
Figure 3.3 The Upgrade Advisor Analysis Wizard start page details the steps you'll follow
Click the Next button to see the page shown in Figure 3.4. Type in the name of the server and click Detect; the wizard autodetects what SQL Server 2000 components are installed on the server.
)
Figure 3.4 The wizard autodetects SQL Server 2000 components
For the purposes of this exercise, you are only interested in getting advice about upgrading your DTS packages, so leave only the Data Transformation Services check box checked. Click the Next button, and input your credentials to attach to the server and the instances you want to scan. You can select multiple instances. Click the Next button again to see the dialog box shown in Figure 3.5.
)
Figure 3.5 The wizard allows you to scan packages on the server or file system
The wizard mentions the Package Migration Wizard, which is covered later. When you select packages on the server, all packages on the server are scanned. There is no way to scan a subset of the packages. Click the Next button and the wizard shows you a summary of the settings. Click the Run button and the wizard starts scanning and analyzing the packages on the server and instances you've selected. Figure 3.6 shows the dialog box shown after the wizard has completed the analysis.
)
Figure 3.6 The wizard generates a report after performing the analysis
After the wizard has completed the analysis, it writes out the report to the SQL Server 2005 Upgrade Advisor Reports folder under your My Documents folder. You can save these reports to another location and review them later if you want. However, if you leave the report in the same location, the wizard may overwrite it.
Figure 3.7 shows a report the wizard generated for the DTS packages on the test server.
)
Figure 3.7 The Upgrade Advisor Report Viewer shows the analysis results
You can do a number of things with the reports. You can open existing reports, filter line items by issues or component, and even export them. Pay close attention to the When to Fix column. If it says Before, you'll need to understand that entry well, and possibly take action on it before upgrading. To get more information about each issue, click on the issue in the report. Figure 3.7 shows the expanded description for Meta Data Services packages after clicking on it. Notice that it is possible to lose access to the packages stored in Meta Data Services. Again, it is very important that you take time to scan and analyze your packages before you start your SQL Server installation so that you know about the preinstallation tasks before it is too late. In this case, the Upgrade Advisor is telling the user to move any packages stored in Meta Data Services to SQL Server or save them to the file system before installing SQL Server because they will no longer be accessible after installing SQL Server 2005. Certainly, this is something you'd want to handle before installing.
The Execute DTS 2000 Package Task
The Execute DTS 2000 Package Task is a thing of beauty for anyone who needs to use their DTS packages in Integration Services. It provides the entire DTS 2000 package editing environment inside the Business Intelligence Development Studio and a way to execute DTS packages from an Integration Services package. This task is provided to help bridge the gap when migrating from Data Transformation Services to Integration Services. Because the architecture of Integration Services is so different from DTS, few legacy DTS packages will successfully migrate and run in Integration Services. This task provides a "half" migration step so that legacy packages can be run side by side with newer Integration Services packages. Even limited interaction between the two is possible using outer variables such that existing investment in DTS packages is not lost when upgrading to Integration Services. For more information about this task, see Chapter 8, "The Stock Tasks."
Migration Wizard
The Migration Wizard is a way to convert your DTS packages to Integration Services packages. It is a "best efforts" migration, meaning it attempts to migrate the biggest parts of packages, such as tasks and variables. However, in the event that it fails to successfully migrate a package, it migrates those parts of the package that it can and wraps the rest in an Execute DTS 2000 Package Task.
When Package Migration Fails
Many DTS packages will successfully migrate, but most will not. What could cause package migration to fail? The list in Table 3.1 is a good place to start. For example, the DTS Data Transformation Task and the Integration Services Data Flow Task are not compatible and their features don't map to one another. Custom tasks won't migrate because they depend on the DTS object model. The Multiphase Pump and Dynamic Properties Task migration will fail because they have no counterpart tasks in IS and you will probably need to fix up ActiveX Script Tasks, especially if they access the DTS object model.
Because the object models are so different, the package and task properties have changed, and there are so many different package configurations, the odds are against a thoroughly clean migration. Even IS tasks that map well to their DTS counterparts will sometimes fail migration because of some setting that isn't related to the task. For example, the IS packages might be stored on a machine in a different domain without access to the same files or servers. The simple fact that you move the package to a different location can break it. The takeaway here is that there is no free ride. You might get lucky and have great success with migrating a few packages. But, as a general rule, most migrations will be a fairly labor-intensive operation. Fortunately, as discussed in the following section, you have options.
Individual Components and Settings
When it comes to migrating packages, the success or failure of the package migration really boils down to what tasks and connections are in the DTS package. Also, a DTS package is more than a set of tasks. It's a combination of tasks, transforms, logging, and other package settings. A number of DTS-compatible components and settings in Integration Services seem to migrate pretty well with little or no user intervention. In addition, some components and settings don't migrate at all or somewhere in between. Following is a list of DTS components and settings with a very rough expectation of how often each will successfully migrate. The success probability is based on estimates on a number of factors, including the author's own tests, the number of differences between DTS and IS components, the complexity of the component, and wizard support. Notice that none of the success probabilities are estimated at 100%. This is because there are simply too many points of failure when migrating to be sure that any component will succeed all the time.
Migrating Tasks
There seem to be three categories of DTS tasks. The first category is tasks that migrate straight across with few complications and if they don't run successfully the first time, a tweak or two usually fixes any lingering issues. Table 3.2 shows the tasks in this category listed with the IS task to which they migrate.
Table 3.2. Tasks with High Probability of Migration Success
|
DTS Task |
IS Task |
Success Probability |
|
File Transfer Protocol |
File Transfer Protocol |
90% |
|
Execute SQL |
Execute SQL |
95% |
|
Execute Process |
Execute Process |
95% |
|
Copy SQL Server Objects |
Transfer SQL Server Objects |
90% |
|
Send Mail |
Send Mail (New SMTP Info) |
95% |
|
Bulk Insert |
Bulk Insert |
70% |
|
Execute Package |
Execute DTS 2000 Package |
90% |
|
Message Queue |
Message Queue |
80% |
|
Transfer Error Messages |
Transfer Error Messages |
95% |
|
Transfer Databases |
Transfer Database (one for each database) |
85% |
|
Transfer Master Stored Procedures |
Transfer Master Stored Procedures |
95% |
|
Transfer Jobs |
Transfer Jobs |
95% |
|
Transfer Logs |
Transfer Logs |
95% |
The second category contains those tasks that might migrate successfully, but often fail because they are either too complex to migrate or they do something that is no longer supported. The ActiveX Script Task often fails to migrate because it contains code that attempts to access the DTS Object Model. The Data Pump Task fails if it is too complex or contains ActiveX Script. The Data Driven Query does not migrate, but the Migration Wizard wraps it in its own DTS package and calls the package from the Execute DTS 2000 Package Task.
Table 3.3. Tasks with Low Probability of Migration Success
|
DTS Task |
IS Task |
Success Probability |
|
ActiveX Script |
ActiveX Script |
40% |
|
Transform Data |
Data Flow |
40% |
|
Data Driven Query |
Execute DTS 2000 Package |
40% |
The third and final category of tasks is those that simply will not migrate because they are designed to work against a different API or there is no compatible Integration Services task. For example, the Dynamic Properties Task is built upon the premise that it can traverse the package hierarchy and modify other task properties directly. This won't work for two reasons:
- The runtime doesn't allow promiscuous package access any longer.
- Even if it did allow such access, the object model has changed.
Table 3.4. Tasks That Will Not Migrate Successfully
|
DTS Task |
IS Task |
Success Probability |
|
Analysis Services |
Analysis Services Processing |
0% |
|
Dynamic Properties |
ActiveX |
0% |
|
Data Mining Prediction |
Data Mining Query |
0% |
Migrating Connections
Connections are important in DTS and if the connection doesn't migrate successfully, you've got a broken package just the same as if the task didn't successfully migrate. The good news is that the OLEDB connections, the most common connections in DTS packages, have a very high migration success rate because the settings for the IS OLEDB Connection Manager are identical to its DTS counterpart.
Table 3.5. Various Connection Managers and Their Probability to Successfully Migrate
|
DTS Connection |
IS Connection Manager |
Success Probability |
|
OLEDB |
OLEDB : OLEDB Provider |
99% |
|
Access |
OLEDB : Jet 4.0 Provider |
95% |
|
Excel |
OLEDB : Jet 4.0 Provider |
95% |
|
Dbase 5 |
OLEDB : Jet 4.0 Provider |
N/A |
|
HTML File |
OLEDB : SQL Native |
0% |
|
Paradox |
OLEDB: Jet 4.0 Provider |
N/A |
|
Text File (Source) |
Flat File |
0% [*] |
|
Text File (Dest) |
Flat File |
0% [1] |
|
ODBC |
OLEDB: MSDASQL Provider |
30% |
Migrating Settings
The package has a number of settings that impact how the package should run. The Migration Wizard generally ignores these settings. For example, it ignores all the package properties, with the exception of Global Variables. So properties like Package Priority Class, Logging Settings, Fail Package on First Error, Write Completion Status to Event Log, Use Transactions, and so on do not get migrated or in any way affect the properties of the destination IS package. The message here is: Even if your package appears to successfully migrate and you get no errors from the Migration Wizard or the new IS package, this is no guarantee that the package will behave exactly as it did when running under the DTS environment. If you want to retain the values for these properties or the behavior they represent, you need to manually review the package settings and make appropriate settings in the IS package. The Migration Wizard does not do it for you.
Where to Launch the Migration Wizard
You can launch the Migration Wizard from the Business Intelligence Development Studio by right-clicking on the SSIS Packages node in an Integration Services project and selecting the Migrate DTS 2000 Package menu option. You can also launch it from SQL Server Management Studio by right-clicking on the Data Transformation Services node of the Legacy branch in the Management node of SQL Server 2000 servers. The Migration Wizard is a standalone executable, so it can also be launched outside of the designer. On most machines, the Migration Wizard is in the \Program Files\Microsoft SQL Server\90\DTS\Binn\ directory and is named DTSMigrationWizard.exe.