Hands-On Microsoft SQL Server 2008 Integration Services part 62 doc

Once you configure these properties, you can create a package deployment utility by building a project on the computer where the Integration Services project is stored.. The build proces

5 8 8 H a n d s - O n M i c r o s o f t S Q L S e r v e r 2 0 0 8 I n t e g r a t i o n S e r v i c e s

Under these conditions, you will be using either a package deployment utility, which can deploy multiple-package projects along with package configurations and miscellaneous files or custom-developed scripts that could be simple windows batch files to do the trick A sample of a simple batch file will be discussed later in the chapter

A package deployment utility is used after you’ve created a package and package configurations, and are ready to deploy To create a deployment utility, you need to configure the Deployment Utility section of the project properties before building the project Three properties here can be configured to control deployment of your project Once you configure these properties, you can create a package deployment utility by building a project on the computer where the Integration Services project is stored The build process automatically includes the packages, package configurations, and miscellaneous files in the project and adds a manifestation file that is gracefully called the Deployment Utility

AllowConfigurationChanges

You can assign a True or False value to this property The True value lets you update configurations during deployment of the package; False lets you omit the update option during deployment You can use this feature when you have to distribute a deployment utility to remote administrators for deploying the project, but do not want them to be able to make changes to configurations This is also useful when you are redeploying packages after making a few changes, but do not want configurations to

be changed

CreateDeploymentUtility

This property also has True or False value options A True value lets the build process create a deployment utility for the Integration Services project; a False value prohibits the creation of deployment utility You need to specify a True value if you want to create a deployment utility, as the default value of this property is False

DeploymentOutputPath

When you create a new project using BIDS, a bin subfolder is also created along with other files within the project folder The default path shown in this property—i.e., bin\Deployment—refers to the same bin folder under the project When you build the project, the packages, the package configurations, miscellaneous files, and the deployment utility file are added in this folder You can change this path to create your deployment utility at a central location within the organization

Deploying Integration Services Projects

The last step in the Integration Services project deployment journey is the deployment

of the project After having created packages for the project, package configurations,

and the deployment utility, there isn’t much left other than actually running the

deployment utility to deploy the Integration Services project

As you create the deployment utility, a manifestation file with the extension

SSISDeploymentManifest is created along with packages, configurations, and

miscellaneous files in the folder specified in the DeploymentOutputPath property of

Integration Services project You need to copy this deployment folder to the deployment

computer and execute the SSISDeploymentManifest file to install the Integration Services

project Executing the SSISDeploymentManifest file starts the Package Installation

Wizard, which then guides you through the process of package installation

Next you have to decide where you want to install the package If you choose to

install your package in the file system, the package and other files such as configurations

and miscellaneous files will be saved to the specified folder on the file system However,

if you choose to install the Integration Services package in the SQL Server, the package

will be saved in the sysssispackages table in the MSDB system database and the other

files will still be saved to the file system in the folder specified

During the life cycle of a package, you may need to modify the package either

to add functionality or to accommodate changes happening somewhere else in

the environment In such cases, you may be making changes to your project in the

development environment and then testing in the test environment Once those

changes have been tested successfully, you are again facing the task of deploying your

project This redeployment differs slightly from the first deployment of the project

You may want to change the deployment process during redeployment—e.g., you

may not want to make any change to package configurations during deployment—

and so you will set the AllowConfigurationChanges property to False Second, if

you’ve made changes only to some of the packages and do not want to redeploy all the

packages within a project, you can create a new Integration Services project and add

only the packages to the project that you want to redeploy When you add a package

to an Integration Services project, the configurations associated with the package are

automatically added to the new project and you don’t have to worry about them

The following Hands-On exercise lets you create a deployment utility and then

install the Integration Services package to the deployment computer

Hands-On: Deploying an Integration Services Project

Create a package deployment utility for the Contacting Opportunities with

Configurations project and finally deploy the package

5 9 0 H a n d s - O n M i c r o s o f t S Q L S e r v e r 2 0 0 8 I n t e g r a t i o n S e r v i c e s

Method

Deploying a project involves going through three simple steps:

Configure the Integration Services project properties

c Build an Integration Services project

c Install the Integration Service project

c

Exercise (Configure Project Properties)

Before you can create a deployment utility, you must configure the project properties These properties provide control over the deployment process

2 In the Solution Explorer, right-click the Contacting Opportunities with Configurations project and choose Properties from the context menu

3 In the property pages, click the Deployment Utility under Configuration Properties on the left pane Specify True in the AllowConfigurationChanges and CreateDeploymentUtility properties (see Figure 13-12) Leave the default bin\ Deployment path in the DeploymentOuputPath property Click OK to close the property pages

Figure 13-12 Configuring Project properties

Exercise (Build the Project)

Building an Integration Services project is quite easy using the Solution Explorer in BIDS

4 In the Solution Explorer, right-click the Contacting Opportunities with

Configurations project again and choose Build from the context menu

Alternatively, you can also do this from the Build menu

5 You will see a success message in the bottom-left corner in BIDS as well as in the

Output window in BIDS

in the folder C:\SSIS\Projects\Contacting Opportunities with Configurations\bin\

Deployment These files consist of conoppo.dtsConfig, the package configurations

file; Mailing Opportunities with Configurations.dtsx, the package XML file;

and Contacting Opportunities with Configurations.SSISDeploymentManifest,

the package deployment utility Copy the Deployment folder to the deployment

computer in the C:\Temp folder

Exercise (Install and Run the Package)

After creating the deployment utility, you can install your package using the DTSInstall

.exe command-line tool or by double-clicking the SSISDeploymentManifest file If you

want to use the DTSInstall.exe tool, you have to specify the complete path and filename

for the manifest file while invoking Package Installation Wizard

Windows Explorer and double-click the Contacting Opportunities with

Configurations.SSISDeploymentManifest file This will start the Package

Installation Wizard after a few seconds Click Next on the Welcome screen

Deployment and SQL Server Deployment of the package Select the File System

Deployment radio button Click Next

Folder to create a Contacting Opportunities with Configurations folder Select this folder and click OK to return and see C:\SSISDeploy\Contacting Opportunities

with Configurations listed in the Folder field Click Next to go to the next screen

Click Next again in the Confirm Installation screen

section You can see the two properties, Subject and ToLine, listed there You

can modify the value of any configuration here by clicking in the Value field of

the configuration Click Next when you’re done

5 9 2 H a n d s - O n M i c r o s o f t S Q L S e r v e r 2 0 0 8 I n t e g r a t i o n S e r v i c e s

11. In the Finish the Package Installation Wizard screen, review the summary that tells you about the package to be deployed, the configuration file to be used, the folder where it will be installed, and the log filename Click Finish to deploy the package

folder using Windows Explorer You will see the Mailing Opportunities with Configurations.dtsx file in the folder

with Configurations directory, and type the following at the command prompt:

dtexec /file "Mailing Opportunities With Configurations.dtsx"

finally returning a DTSER_SUCCESS message

Review

To deploy a project, you need to configure its deployment properties and make sure that the CreateDeploymentUtility property is set to True Once the deployment utility

is created, you can install the package by running the deployment manifest file You can also invoke the Package Installation Wizard using the DTSInstall.exe tool You have also seen that if the AllowConfigurationChanges property is set to True during deployment utility creation, you get an opportunity to modify package configurations during deployment of the package Make sure you use this aspect when you are deploying to several computers with different environments, if you are not using indirect package configurations

One of the benefits of using configurations is the ability to pass them on the cmd line when executing a package This is very handy and practical, especially when you are executing a package on the same server that is acting both as a test and development server with different configurations In this way, you can choose which configuration file to pick up, as environment variables will not work in this case, due to their inability

to point to both versions of the configuration file

Custom Deployment

Sometimes the deployment procedures are guided by already-adopted deployment standards that might be different from what SSIS deployment tools can provide Also,

in the bigger picture, you might need to deploy lots of other stuff along with packages and you find that the available tools don’t provide you an ability to deploy all of the changes in one go In such instances, you might prefer to adopt custom-developed scripts to deploy SSIS packages and the other changes together Typically, your deployment stuff will be made up of the following entities:

SSIS package files

c

SSIS configuration files

c

SQL scripts to populate configurations if you are using SQL Server–based

c

configurations

SQL scripts to create or apply changes to SQL Server databases, tables, or other

c

objects

SQL scripts to create SQL Server Agent jobs

c

Rollback scripts

c

One simple example could be batch file scripts that could be used to deploy all of

these entities A sample of various parts of such a batch file is listed here:

REM***************************************************************

REM Set Variables for Control file

REM****************************************************************

SET DB_SERVER = DatabaseServerName

SET SSIS_SERVER = SSISServerName

SET CONTROL_DATABASE = ControlDatabaseName

SET ENVIRONMENT = PRODUCTION

REM****************************************************************

REM Use the following to copy SSIS packages from a Network Share on to the

Production SSIS Server

REM*****************************************************************

XCOPY "\\ServerName\DeploymentShareName\%Environment%\SSISPackages\*.*" "\\%SSIS_

SERVER%\F$\DeploymentFolder\SSISPackages\" /Y

REM****************************************************************

REM Use the following to deploy an SSIS package from a folder to the MSDB database

on the SSIS Server You do not need to use this step if you are using File System

deployment of packages

REM*****************************************************************

dtutil /Q /FILE "\\%SSIS_SERVER%\F$\DeploymentFolder\SSISPackages\Package1.dtsx" /

DESTS %SSIS_SERVER% /COPY SQL;"/SSISPackages/Package1"

REM*****************************************************************

REM Use the following to run a TSQL script on the database Server to populates

configurations to an SQL Server table, Create SQL Server database objects or an

SQL Server Agent job

REM****************************************************************

SET INPUT_FILE= \\%DB_SERVER%\F$\DeploymentFolder\SQLScripts\

SetSSISConfigurations.sql

SET OUTPUT_FILE= \\%DB_SERVER%\F$\DeploymentFolder\SQLScripts\LOG_OutPut.txt

SQLCMD -S %DB_SERVER% -d %CONTROL_DATABASE% -E -i %INPUT_FILE% -o %OUTPUT_FILE%

5 9 4 H a n d s - O n M i c r o s o f t S Q L S e r v e r 2 0 0 8 I n t e g r a t i o n S e r v i c e s

So, using this or probably extending the previous example, you can carve out a reasonably simple solution that deploys the changes both in SSIS and in SQL Server databases all in one go

Summary

You have completed an interesting journey to deploy Integration Services packages You have created package configurations, used direct and indirect methods to specify configurations for a package, created a deployment utility, and deployed a package using the Package Installation Wizard You now understand the difference between copying a package and deploying a package, and you’re now able to create indirect configurations to make the deployment process as easy as a copy operation

Migrating to Integration Services 2008

In This Chapter

c Upgrade Advisor

c Migrating Data

Transformation Services

Packages

c Upgrading Integration Services 2005

c Summary

5 9 6 H a n d s - O n M i c r o s o f t S Q L S e r v e r 2 0 0 8 I n t e g r a t i o n S e r v i c e s

DTS 2000 and perhaps are looking to migrate to Integration Services And if you have completed previous chapters and have worked with various components of Integration Services such as Control Flow tasks, Data Flow transformations, connection managers, variables, property expressions, and package configurations, you can very well appreciate that Integration Services is totally different from Data Transformation Services of SQL Server 2000 In fact, Integration Services is not an upgrade of DTS; rather, it is altogether a new tool This chapter will cover migration

of both DTS 2000 and Integration Services 2005 to Integration Services 2008

For one thing, Data Transformation services have been deprecated in SQL Server

2008, though 32-bit management, run-time, and design-time support for DTS packages have still been provided in SQL Server 2008 With that in mind, you may be wondering what exactly you can do to your existing DTS 2000 packages Integration Services provides options that you can use to migrate DTS packages into SSIS Later,

in the exercises in this chapter, you will use a DTS 2000 package provided in the RawFiles folder Before you start checking out the options, you’ll need to analyze your packages to determine whether they can be migrated; if they can be, you need to be aware of issues that might come up during migration You can analyze your DTS 2000 packages using the Upgrade Advisor Let’s start the chapter with a discussion of the Upgrade Advisor, and then we will look at the migration options

Upgrade Advisor

As a DBA of SQL Server 2000 or SQL Server 2005, very soon you might find yourself face to face with having to upgrade to SQL Server 2008, if you have not upgraded already The reason could be an end of support for legacy software, or you may want

to use the enhanced performance and new features provided in SQL Server 2008 Microsoft provides a starting point for help in the form of an Upgrade Advisor and recommends that you run it to analyze how your upgrade project will go before you get started on any project upgrades

The Upgrade Advisor is used to analyze the configurations of SQL Server 2005 or SQL Server 2000 components and identifies issues that you must address to ensure a successful upgrade The reports generated by this tool let you plan how to deal with issues during an upgrade and the migration process You can install the Upgrade Advisor from the SQL Server 2008 product media, or you can download it from Microsoft’s downloads center Be sure to go through the system requirements for installing the Microsoft SQL Server 2008 Upgrade Advisor

In the following Hands-On exercise, you will install the Upgrade Advisor and then run it to analyze your DTS 2000 packages

Hands-On: Analyzing DTS 2000 Packages

with SQL Server 2008 Upgrade Advisor

You need to analyze your existing DTS 2000 packages before upgrading them to

Integration Services format to learn about any issues that may come up during migration

Method

In this Hands-On exercise, you will be using the Upgrade Advisor to analyze an existing

package, Importing Contacts.dts, provided in C:\SSIS\RawFiles This exercise has two

main parts:

Installing the Upgrade Advisor

c

Running Upgrade Advisor and viewing an analysis report

c

Exercise (Install Upgrade Advisor)

You will use SQL Server 2008 product media to install the required software in the

following steps However, if you don’t have the product media, they can be freely

downloaded from Microsoft Download Center

Advisor link in the Planning page The installation is straightforward and simple

(Figure 14-1)

Exercise (Run the Upgrade Advisor

to Analyze DTS 2000 Packages)

You will run the Upgrade Advisor to analyze the Importing Contacts.dts package and

will see the report

2008 R2 Upgrade Advisor You’ll see the Welcome page, which provides links

to documentation, the latest updates, and two links for Launch Upgrade Advisor

Analysis Wizard and Launch Upgrade Advisor Report Viewer These two

components are the main components of the Upgrade Advisor

Welcome screen of the Analysis Wizard

For this exercise, make sure you select the Data Transformation Services check

box as shown in Figure 14-2 You can also use the Detect button to let Upgrade

Advisor detect and select the services installed on the specified computer Click

Next to move on