SQL Integration Package Test

Packages are at the core of the data transformation and integration services provided by SSIS. Using packages, you can merge data from heterogeneous data sources into the SQL server. Packages also help populate data warehouses, clean and standardize data, and automate administrative tasks.

This means that if a package runs slowly, it will adversely impact the operations and overall performance of the data integration and workflow applications that are built on the SSIS platform. To avoid such performance setbacks, administrators need to track the execution time of individual packages, rapidly isolate packages that are executing slowly, and quickly diagnose and fix the reason for the delay. This is where the SQL Integration Package test helps!

This test monitors the packages that are deployed to the SQL Integration server and tracks the execution time of each package. Packages that have been executing beyond an acceptable duration (which is configurable) are promptly captured and brought to the attention of administrators as part of detailed diagnostics. This is how the test highlights 'slow packages'. Additionally, the test sheds light on what could have slowed down package execution. Typically, any slowness in package execution can be attributed to delays in the operations of the components (eg., data flow components, control flow components etc.) that are included in that package. This is why, the test not only monitors package execution, but also measures the amount of time the components in each package took to execute. If one/more components have taken longer than a permitted duration (which is configurable) to execute, then the detailed diagnostics reported by the test pinpoints such components. Using these detailed metrics, administrators can quickly and easily determine the root-cause of package slowness.

Target of the test : A Microsoft SQL Server Integration Services server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the server being monitored

Configurable parameters for the test
Parameters Description

Test period

How often should the test be executed

Host

The host for which the test is to be configured.

Port

The port at which the specified Host listens.

Database Name

This test runs queries on the SSIS database and reports metrics. To enable the test to connect to and execute queries on the SSIS database, this test has to be configured with the name of the SSIS database. By default, the ssisdb is the name of the SSIS database. If you have assigned a different name to this database in your environment, then override the default name by changing the value of the Database Name parameter.

Database PortNo

This test runs queries on the SSIS database and reports metrics. To enable the test to connect to and execute queries on the SSIS database, you need to configure this test with the correct port number at which the SSIS database listens. To know how to determine the port number of the SSIS database, refer to Configuring the eG Agent with the Database Port Number.

User and Password

To run queries on the SSIS database and report metrics, this test requires the permissions of a SYSADMIN user. Therefore, specify the credentials of a SYSADMIN user against User and Password.

However, if, owing to security constraints, administrators prefer not to expose the credentials of a SYSADMIN user, then you can create a special user on the Microsoft SQL Server with SSIS_LOGREADER rights to the SSIS database. To know how to create such a user, refer to Configuring the eG Agent with Query Execution Permissions. Once the user is created, pass the credentials of this user to the test using the User and Password parameters.

Confirm Password

Confirm the password by retyping it in the Confirm Password text box.

Instance

The name of a specific SQL Integration Server instance to be monitored. The default value of this parameter is “default”. However, if the Microsoft SQL Server hosting the SSIS database uses named instances, then do the following:

  • Configure the Instance parameter with the name of the SQL Server instance that hosts the SSIS database.
  • Do not change the default value of the Port parameter

Domain

By default, none is displayed in the Domain text box. If the 'SQL server and Windows' authentication has been enabled for the server being monitored, then the Domain can continue to be none. On the other hand, if 'Windows only' authentication has been enabled, then, in the Domain text box, specify the Windows domain in which the SSIS database that this test connects to exists. Also, in such a case, the User name and Password that you provide should be that of a user authorized to access the Microsoft SQL server hosting the SSIS database of interest.

Is NTLM v2

In some Windows networks, NTLM (NT LAN Manager) may be enabled. NTLM is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM version 2 (“NTLMv2”) was concocted to address the security issues present in NTLM. By default, the Is NTLMv2 flag is set to No, indicating that NTLMv2 is not enabled by default on the target Microsoft SQL server hosting the SSIS database. Set this flag to Yes if NTLMv2 is enabled on that Microsoft SQL server.

SSL

By default, this flag is set to No, indicating that the Microsoft SQL server hosting the SSIS database is not SSL-enabled by default. On the other hand, if the SSIS database is hosted by a Microsoft SQL server that is SSL-enabled, then, set this flag to Yes.

Execution Duration Seconds

If a package/component is running for a duration beyond the value (in seconds) configured here, then the test will consider that package/component as 'slow' and report its details in the detailed diagnosis. By default, this parameter is set to 10 seconds. This means that, by default, this test will consider any package/component that runs for more than 10 seconds as 'slow' and provide the details of such packages/components in detailed diagnosis.

DD Row Count

By default, this parameter is set to 10. This implies that by default the detailed diagnosis of the test reports the top-10 packages/components in terms of their execution duration. If you want detailed diagnosis to include more or less number of packages/components, then change the value of this parameter.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Component count

Indicates the number of components running on the server.

Number

 

Maximum duration of component

Indicates the high watermark of execution duration across components.

Seconds

If the value of this measure is abnormally high, it implies that one/more components are running for a duration beyond the Execution Duration configured for this test.

In such a situation, use the detailed diagnosis of this measure to know which components are running slowly, and which package they belong to.

Package count

Indicates the number of packages running on the server.

Number

 

Maximum duration of package

Indicates the high watermark of execution duration across packages.

Seconds

If the value of this measure is abnormally high, it implies that one/more packages are running for a duration beyond the Execution Duration configured for this test.

In such a situation, use the detailed diagnosis of this measure to know which packages are running slowly, and which components in those packages are contributing to the delayed execution.