Vous êtes sur la page 1sur 3

SSIS Data Tap

With data taps, you can capture a copy of the data from a specific data path in
your data flow task in a comma-delimited file at run time. Much like data viewers
are used to monitor the data in the data flow at design time, data taps enable
you to analyze data in a production environment for specific execution of the
To be able to use data taps, you must first use T-SQL to execute the provided
stored procedures inside the SSISDB database. You start by creating an execution
instance for the package by executing the catalog.create_execution stored
procedure, then you add the data tap or taps by running
catalog.add_data_tap, and finally you run the package by using the
catalog.start_execution procedure.
Data taps cannot be defined at design time.

SSIS Project and Package Deployment Model

Integration Services supports two deployment models, the project deployment
model and the package deployment model. The project deployment model
enables you to deploy your projects to the Integration Services server.

When Using the Project Deployment Model

When Using the Package Deployment Model

A project is the unit of deployment.

A package is the unit of deployment.

Parameters are used to assign values to

package properties.

Configurations are used to assign values to package


A project, containing packages and parameters,

is built to a project deployment file (.ispac

Packages (.dtsx extension) and configurations

(.dtsConfig extension) are saved individually to the
file system.

A project, containing packages and parameters,

is deployed to the SSISDB catalog on an
instance of SQL Server.

Packages and configurations are copied to the file

system on another computer. Packages can also be
saved to the MSDB database on an instance of SQL

CLR integration is required on the database


CLR integration is not required on the database


Environment-specific parameter values are

stored in environment variables.

Environment-specific configuration values are stored

in configuration files.

Projects and packages in the catalog can be

validated on the server before execution. You
can use SQL Server Management Studio, stored
procedures, or managed code to perform the

Packages are validated just before execution. You

can also validate a package with dtExec or managed

Packages are executed by starting an execution

on the database engine. A project identifier,
explicit parameter values (optional), and
environment references (optional) are assigned
to an execution before it is started.

Packages are executed using

the dtExec and DTExecUI execution utilities.
Applicable configurations are identified by
command-prompt arguments (optional).

You can also execute packages using dtExec.

During execution, events that are produced by

the package are captured automatically and
saved to the catalog. You can query these
events with Transact-SQL views.

During execution, events that are produced by a

package are not captured automatically. A log
provider must be added to the package to capture

Packages are run in a separate Windows


Packages are run in a separate Windows process.

SQL Server Agent is used to schedule package


SQL Server Agent is used to schedule package


Features of Project Deployment Model




A parameter specifies the data that will be used by a package. You can scope
parameters to the package level or project level with package parameters and project
parameters, respectively. Parameters can be used in expressions or tasks. When the
project is deployed to the catalog, you can assign a literal value for each parameter

or use the default value that was assigned at design time. In place of a literal value,
you can also reference an environment variable. Environment variable values are
resolved at the time of package execution.


An environment is a container of variables that can be referenced by Integration

Services projects. Each project can have multiple environment references, but a
single instance of package execution can only reference variables from a single
environment. Environments allow you to organize the values that you assign to a
package. For example, you might have environments named "Dev", "test", and


An environment variable defines a literal value that can be assigned to a parameter

during package execution. To use an environment variable, create an environment
reference (in the project that corresponds to the environment having the parameter),
assign a parameter value to the name of the environment variable, and specify the
corresponding environment reference when you configure an instance of execution.


All Integration Services objects are stored and managed on an instance of SQL Server
in a database referred to as the SSISDB catalog. The catalog allows you to use folders
to organize your projects and environments. Each instance of SQL Server can have
one catalog. Each catalog can have zero or more folders. Each folder can have zero or
more projects and zero or more environments. A folder in the catalog can also be
used as a boundary for permissions to Integration Services objects.

and views

A large number of stored procedures and views can be used to manage Integration
Services objects in the catalog. For example, you can specify values to parameters
and environment variables, create and start executions, and monitor catalog
operations. You can even see exactly which values will be used by a package before
execution starts.