For the MSDB database of the remote SQL Server, you’ll modify the ServerName element as shown: RemoteSQLServerName And for the File System folder on a remote server, you’ll modify the St
Trang 1For the MSDB database of the remote SQL Server, you’ll modify the ServerName element as shown:
<ServerName>RemoteSQLServerName</ServerName>
And for the File System folder on a remote server, you’ll modify the StorePath element as shown:
<StorePath>\\RemoteFileServerName\ShareName</StorePath>
You will have to restart the SQL Server Integration Services 10.0 service for changes
to take effect After restart, when you connect to the local instance of Integration Services using SQL Server Management Studio, the MSDB folder in Stored Packages will show the packages saved to the remote SQL Server and the File System folder will show the packages saved to the file share on the remote server
Managing Packages on an Instance of an SQL Server
One important point is to understand that Integration Services is not a multi-instance application like SQL Server However, it is aware of SQL Server instances and can connect to them For example, you might prefer to save your packages in the instance
of SQL Server to which they relate instead of saving them into default instance In that case you can modify the ServerName element as follows and connect to the MSDB database of the specified instance of SQL Server
<ServerName>ServerName\InstanceName</ServerName>
You will have to restart the SQL Server Integration Services 10.0 service for changes
to take effect After restart, when you connect to Integration Services using SQL Server Management Studio, the MSDB folder in Stored Packages will show the packages saved to the specified instance
Connecting to Integration Services on a Remote Server
Sometimes, you may also want to connect to Integration Services on a remote server; for instance, you may be using SQL Server Management Studio on your client machine but connecting to remote Integration Services You can do so when you choose Integration Services in the Server Type field and the remote server name in the Server Name field in the Connect To Server dialog box, which pops up when you start SQL Server Management Studio or when you click the Connect button in the Object Explorer and choose Integration Services from the options list Remember, Integration Services is a Windows service and uses Windows authentication; that is, it is logged on to the user’s
Trang 2account to connect to a remote server If your account has permissions to connect to the
remote Integration Services server, you will connect without any issues However, you
may receive an “Access Is denied” error if you do not have sufficient rights To allow
remote users connections, users need to have permissions on DCOM objects and the
Integration Services service needs to be configured for the DCOM permissions As you
can guess, administrators will have access by default; however, if you’re using restrictive
security on your server (that is, if you want to give users just enough rights to let them
perform their jobs), you need to assign them appropriate permissions First, you will
need to add the required users into the Distributed COM Users group You also need
to assign users Remote Activation rights in the Launch and Activation Permissions
section under the Security tab of MsDtsServer100 application properties You can access
MsDtsServer100 application under the DCOM Config node of Component Services
management tool For more details on how to configure rights for users, search for the
article “Connecting to a Remote Integration Services Server” on MSDN
Managing SSIS Packages
SQL Server Management Studio enables you to connect to Integration Services and
manage your SSIS packages using a graphical interface Integration Services allows
you to save your packages either on the file system or in the MSDB database and can
manage the storage and running of your packages from this single interface You can
import packages from any storage area and export into another You can also run your
packages from here and watch their progress while the packages are executing
Let’s do a quick Hands-On exercise to understand the storage options provided by
the Integration Services service
Hands-On: Working with Integration
Services Storage Folders
In this exercise, you will learn about the storage areas where you can save packages and
how you can change their storage type and location
Method
The following will be completed:
Connect to the Integration Services service and understand the storage areas
C
Save a package to SSIS Package Store
C
Add a root-level folder to Stored Packages
C
Import and export packages
C
Trang 3Exercise (Connect to Integration Services Service and Understand the Storage Areas)
In the first part of this Hands-on, you will use SQL Server Management Studio to connect to Integration Services service and understand the folder structure it provides
1 Run SQL Server Management Studio Choose Integration Services in the Server Type field of the Connect To Server dialog box and type in the name of your server in the Server Name field Then click Connect
2 You should see the two top-level folders—Running Packages and Stored Packages The Running Packages folder lists the currently running packages You will be monitoring running packages from this place Expand the Running Packages folder You will realize that it doesn’t have any subfolder and you will not be able to create
a subfolder under it This is because the Running Packages folder is not extensible
3 Expand the Stored Packages folder Note that it has two subfolders—File System and MSDB The packages saved on to the file system appear under File System folder, and the packages saved inside the SQL Server MSDB database appear under the MSDB folder You can create subfolders under any of these folders, as this area is configurable and extensible You will be working primarily with this area to manage the storage of your folders
4 The File System and MSDB folders are called root-level folders The File System
folder lists the packages stored in the file system The default location of this folder
is %Program Files%\Microsoft SQL Server\100\DTS\Packages Right-click the File
System folder and choose New Folder from the context menu Type Campaigns
in the Create New Folder window and click OK to close the dialog box You will see the Campaigns subfolder under the File System folder, you might have to refresh if this is not visible Now explore to the %Program Files%\ Microsoft SQL Server\100\DTS\Packages folder and you will see Campaigns folder there
You can also create subfolders in the MSDB folder Packages saved to the SQL Server MSDB database appear under the MSDB folder in Integration Services
To sum up, you can create subfolders under the File System folder and the MSDB folder to manage your packages in a hierarchical order You can then delete or rename these subfolders; however, you cannot delete or rename the root folders
Exercise (Save a Package to an SSIS Package Store)
In this part, you will explore three package storage areas the Integration Services service provides, and will save a package into SSIS Package Store area
5 Start BIDS and open the Contacting Opportunities solution When the solution loads, open the Mailing Opportunities.dtsx package under the SSIS Packages node to open the package in the Designer When the package appears on screen, choose File | Save Copy Of Mailing Opportunities.dtsx As This will open the
Trang 4Save Copy Of Package dialog box, which gives you choices of where you want to
save your package Click the down arrow in the Package location field to see the
locations where you can save your packages You have three options:
SQL Server
c
File System
c
SSIS Package Store
c
Choosing SQL Server lets you save your packages to the sysssispackages table of the
MSDB database in SQL Server The packages saved using this option will appear
under the MSDB folder when you connect to Integration Services using SSMS
The File System option allows you to save your package anywhere on the file
system You can specify a path in the Package Path field for saving the package
You will be using this option if you do not want to save your packages in the
Integration Services’ defined storage area, the %Program Files%\Microsoft SQL
Server\100\DTS\Packages folder The packages saved using this option will not be available for management under SQL Server Management Studio There are times
or instances when you would like to choose this option; for instance, you may want
to save your packages on a central file server instead of the local server or you may
not want your packages be made available in Integration Services storage folders
The third option of SSIS Package Store allows you to save your package in the
Integration Services–defined storage area on the file system or in the MSDB
database When you select this option and click the ellipsis button to specify a
Package Path, you are taken to the root-level folders inside the Integration Services
Stored Packages area and the File System and MSDB folders are shown to you
It’s worth noting the difference between the File System option provided to you
in the Package Location field earlier and the current File System folder shown
inside the SSIS Package Store The earlier option of File System allows you to
save your package anywhere on the file system and those packages will not be
visible in SQL Server Management Studio, while selecting the File System folder
in the SSIS Package Store option lets you save your package only under the
Stored Packages root folder defined in Integration Services, which by default is
%Program Files%\Microsoft SQL Server\100\DTS\Packages, and the packages
saved here will be available for management in SQL Server Management Studio
The defined storage area on the file system is configurable and you can change
the location of this folder; however, it is worth noting the difference between
these two options so that you don’t confuse yourself while saving the packages
6 Select SSIS Package Store in the Package location field and type in your server
name or localhost in the Server field Click the ellipsis button opposite to the
Package Path field to open the SSIS Package dialog box Expand the File System
folder, select Campaigns, and then type Mailing Opportunities in the Package
Name field Click OK to return (see Figure 6-1) Note the path specified in the
Package path field Click OK again to save the package
Trang 57 Switch to SQL Server Management Studio, right-click the Campaigns folder, and choose Refresh to see the Mailing Opportunities package
Also, if you explore to the Campaigns folder under the %Program Files%\
Microsoft SQL Server\100\DTS\Packages folder, you will see the Mailing Opportunities.dtsx file saved there as well This is the default location specified in the Integration Services configuration file, which is discussed in the next part
Exercise (Add a Root-Level Folder to Stored Packages)
Now you know that the root-level folders can contain subfolders But what if you want to store your packages at different location than the default location? Integration Services provides you with a configuration file to configure the storage locations
8 Open the MsDtsSrvr.ini.xml file with Notepad to see the XML configuration code This code has been listed earlier, in the section “Managing Packages with Default Settings.” Locate the XML element <StopExecutingPackagesOnShutdown>
and note that you can control how Integration Services treats the running packages when the service is stopped By default, it is set to True, which means that the running packages will be stopped when the SSIS service is stopped By changing
Figure 6-1 Saving your package to the SSIS Package Store
Trang 6True to False in this line, you can configure Integration Services to continue
running packages even if the SSIS service has been stopped
9 We will now add a root file system folder so that we can save our
packages to a different area Move to the XML element <Folder xsi:
type="FileSystemFolder"> in the configuration file Note that the
storage path \Packages actually points to the %Program Files%\Microsoft SQL
Server\100\DTS\Packages folder Copy the <Folder> element—i.e., copy
four lines starting from <Folder xsi:type="FileSystemFolder">
to </Folder> Now add these lines between the </Folder> and
</TopLevelFolders> elements In the new lines, change the values of
the <Name> element to My SSIS Packages and <StorePath> element to
C:\SSIS\Packages Your new lines should look like this:
<Folder xsi:type="FileSystemFolder">
<Name>My SSIS Packages</Name>
<StorePath>C:\SSIS\Packages</StorePath>
</Folder>
Save the configuration file To see the changes, you have to restart the
Integration Services service Start the SQL Server Configuration Manager
and click the SQL Server Services node in the left-hand pane Locate the
SQL Server Integration Services 10.0 service from the list, right-click, and choose
Restart Once the service stops and starts again, switch to SQL Server Management Studio and refresh Stored Packages to see the newly added root level folder, My
SSIS Packages This folder points to C:\SSIS\Packages folder on the file system
Exercise (Import and Export Packages)
You can change the storage location of packages by using the import and export
features of the Integration Services This can also be done from the command prompt
using the dtutil utility In this exercise, you will import the Mailing Opportunities
package to the MSDB folder and then export this package to the My SSIS Packages
store you created previously
10. Switch to SQL Server Management Studio, right-click the MSDB folder, and
choose Import Package An Import Package window will open This window
is similar to the Save Copy Of Package dialog box, except it has an extra field
for specifying the package name to be imported In the Package Location field
drop-down list, choose SSIS Package Store and type localhost in the Server field
Click the ellipsis button opposite to the Package Path field In the SSIS Package
dialog box, expand the File System folder, then the Campaigns folder, and then
select the Mailing Opportunities package (see Figure 6-2) Click OK to return
11. Verify that the Package name field contains the name Mailing Opportunities
Click OK to start importing the package Refresh the MSDB folder to see that
the Mailing Opportunities package has been imported
Trang 7Connect to the local database server using the Connect button in the Object Explorer window Open a new query pane and run the following query against the MSDB database:
SELECT * FROM msdb.dbo.sysssispackages WHERE name like 'Mailing%'
The result set will contain all the information about the Mailing Opportunities package
12. Let’s export our package to an area on the file system, which is not defined in the SSIS Package Store Go to Integration Services in the Object Explorer of SQL Server Management Studio, right-click the package Mailing Opportunities stored under the MSDB folder, and choose Export Package from the list of options
13. An Export Package\MSDB\Mailing Opportunities dialog box opens In the
Package location field, choose SSIS Package Store and type localhost in the
Server field These settings enable Integration Services to read storage locations from the MsDtsSrvr.ini.xml file on the local server
14. Click the ellipsis button next to the Package Path field to open the SSIS Package dialog box Here you can see the My SSIS Packages folder you created earlier in Integration Services Select My SSIS Packages and verify that the Package Name field already has Mailing Opportunities filled in Click OK to close this dialog box You will see the /My SSIS Packages/Mailing Opportunities value specified
in the Package Path field This is a user-friendly option that allows you to create a storage location pointer in Integration Services; all users can save packages without bothering about the actual storage location of the package This is also quite helpful
in case you want to keep your packages on a central server for archiving on your
Figure 6-2 Selecting a package to import
Trang 8network storage You also get an opportunity to define a new name to your package
here, which is helpful in case you are saving with version numbers attached in the
end of the package name Click OK to export the package Explore to the C:\SSIS\
Packages folder to verify that the package has been saved there Leave the SQL
Server Management Studio running (if you’re not ready for a break yet!), as we will
return to it in the next exercise
Review
In this exercise, you worked with root folders of Integration Services and managed to
create a subfolder to the root folder, save a package to it, and view the options available
for saving a copy of the package You also learned about where you can monitor the
running packages and where you can save them After that, you used the configuration
file for Integration Services to create an additional root folder, My SSIS Packages The
path specified for the My SSIS Packages folder was on the local server hard disk in this
exercise, but it is not limited to that You can actually use a UNC network share (such
as \\<computername>\sharename) for the folder path and point your SSIS packages
store to a central network share You also saw how to use import and export features to
change the storage type and location of the packages
While we are discussing the configuration file options, you might find a couple of
other options useful If you want to use an SQL Server named instance on the same
server or on the remote server for storing your Integration Services packages, you can
do so by specifying the instance name in the <ServerName> element of configuration
file You can specify the named instance in the format InstanceName\ServerName Save
the file, restart the Integration Services service, and you are ready to store your packages
in the specified SQL Server named instance
The second option is to use an alternative configuration file Integration Services
does allow you to set up and use an alternative configuration file By default,
Integration Services refers to the MsDtsSrvr.ini.xml configuration file located at
C:\Program Files\ Microsoft SQL Server\100\DTS\Binn\ MsDtsSrvr.ini.xml
This location is mentioned in the Windows registry You can change the location
of the default configuration file by modifying the value of the registry key HKEY_
LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\
SSIS\ServiceConfigFile After making this change, all you need to do is restart the
Integration Services service, which will then read the new file from the location you
specified in the registry
dtutil Utility
You have worked with Integration Services from within SQL Server Management
Studio and have imported and exported your SSIS packages with the help of GUI
tools Having used these tools, you have realized how easy it is to manage your
Trang 9Integration Services packages from the tools’ GUI However, sometimes you need
a command-line tool to write scripts to do the work in batches, you may want to automate tasks, or perhaps you want to schedule jobs In this section you will learn
to use dtutil, a command prompt utility provided for managing Integration Services packages
The dtutil utility can be used for the following:
Verifying the existence of an SSIS package c
Copying SSIS packages c
Moving SSIS packages c
Deleting SSIS packages c
Signing SSIS packages c
You can use dtutil to perform any of these operations on any type of storage—i.e., the MSDB database in SQL Server, anywhere on the file system, and the defined SSIS Package Store
Here is the base syntax:
dtutil /option [value] [/option [value]]
The parameters can be in any order and are not case-sensitive Also, they are defined
in terms of option and value pairs The options must begin with a slash (/) or a minus
sign (–) The dtutil uses different options for passing user credential details of the source and destination servers For the source server, dtutil uses these options:
SourceS
c For the source server
SourceU
c For the user name at the source server
SourceP
c For the password of this user And for the destination server, dtutil uses the following options:
DestS
c For the destination server
DestU
c For the user name at the destination server
DestP
c For the password of this user You may see a pipe (|) at some places in the syntax, which is used as an OR operator
to show the possible values of the arguments Finally, it is easier to learn the dtutil commands by practicing them than by trying to memorize the syntax So let’s get started with the Hands-On exercises
Trang 10Hands-On: Using dtutil
In this Hands-On exercise, we will use dtutil against various scenarios to understand
how it works and learn the syntax along the way
Method
Start SQL Server Management Studio and connect to Integration Services Also, open
Windows Explorer and the command prompt and be ready to switch windows to see
the results
Exercise (Verify the Existence of an SSIS Package)
You can check the existence of a package using the EXISTS option of dtutil:
dtutil /EXISTS [/option [value]]
1 Verify whether the Mailing Opportunities package exists in the MSDB database
of the local server instance:
dtutil /EXISTS /SQL "Mailing Opportunities"
As we know that the package exists in the local instance, you will see the “The
specified package exists” message The SQL option checks for packages stored
in the MSDB database of the SQL Server The other options that can be used
instead of SQL are FILE and DTS The FILE option allows the dtutil to check
the existence of a package on the specified file system folder, whereas DTS checks through the defined SSIS Package Store Note that the SQL option cannot be
specified with the DTS or FILE option, as they are mutually exclusive However,
you can use the User, Password, or Server options to extend the SQL option
usage
2 Verify that the Mailing Opportunities package exists in the C:\SSIS\Packages
folder of the local server:
dtutil /EXISTS /FILE "C:\SSIS\Packages\Mailing Opportunities.dtsx"
The FILE option checks the specified file system folder for the existence of the
package Note that FILE option cannot be specified with the DTS, SQL, User,
Password, or Server options Also, note the way you specify the name of an
SSIS package—with the FILE option you have to specify the dtsx extension with the package name, while this is not to be included for the other two SQL and
DTS options
3 Verify that the Mailing Opportunities package exists in the shared folder called
Data, of the remote server named AIT:
dtutil /EXISTS /FILE "\\AIT\Data\Mailing Opportunities.dtsx"