Tracking Execution Times for SSIS Packages

By:   |   Comments (2)   |   Related: > Integration Services Performance


We use SQL Server Data Tools (SSDT) for importing and transforming some of our data sets and have different needs for timing some of the events within the SQL Server Integration Services (SSIS) packages. With some packages we want to determine the total time a package ran, while with other packages we want to determine the amount of time a specific import or part of the package ran. What are some examples to assist us with tracking this information as close as possible, as we realize we may be limited in some of our packages, but a close estimate will help.


Our solution will depend on what we need to know in the ETL flow. When we consider tracking the time of a process during a package execution, it could be one of the following that we're tracking:

  • Do we need to know the length of time for a specific execution within the SSIS package - such as the length of time for a data flow process?
  • Do we need to know the length of time for the overall package execution - from start to finish?
  • Do we need to know the length of time for specific block of executions - such as the length of time for a data flow process and data transformations within an execute SQL task?

For instance, suppose that we make a call to an API which returns a block of data with each call generally consuming a few minutes to return the data. In this example, we're trying to track the time for a specific call when we get data, which will affect how and where we add our data information.

Option 1 - SQL Server Agent Job

If we need to know the total time that an SSIS package ran and we execute the package through SSIS, we add a T-SQL timestamp before the package executes and another one after the package finishes. In the below code, we use the day as an identifier to update the row when the package finishes - this might change depending on what the identifier is. For an example, if our loader is monthly and it takes more than one day to load, we may use a month and year identifier for updating the row of data. As an alternative to get the duration only, we could also derive this information from the SQL Server Job Agent information by looking at how long the job step executed. Both examples are shown below this.

CREATE TABLE tbDataLoaders(
 DateLog VARCHAR(12),
 DataLoader VARCHAR(100),
 StartDateTime DATETIME,

---- Step 1
INSERT INTO tbDataLoaders (DateLog,DataLoader,StartDateTime)
VALUES (@date,'EnergyDataLoaderOne Package',GETDATE())

---- Step 2
UPDATE tbDataLoaders
SET EndDateTime = GETDATE()
WHERE DateLog = @date

---- SQL agent information from msdb
USE msdb

 last_run_duration RunDuration
 , last_run_outcome RunOutcome
FROM sysjobsteps t
 INNER JOIN sysjobs tt ON t.job_id = tt.job_id
WHERE = 'OurDataLoader'
SQL Server Agent Job Steps
SQL Server Agent Job Output
SQL Server Agent Job Run Duration

The duration of the job being executed in sysjobsteps reports the data in the hhmmss format. Since some environments may not allow developers to access to the system databases, the alternative of stamping the time in the agent may be an option that developers can use.

Option 2 - Use T-SQL or Stored Procedures in the SSIS package

SSIS comes with an execute SQL task, which allows us to call any T-SQL statement. At the beginning of the SSIS package we can add a timestamp value to a table and at the end close the package with a timestamp value. This is similar to the above technique, except the step is added to the SSIS package. We'll borrow the T-SQL from above and add it to our example SSIS package.

Start timestamp in SSIS
Finish timestamp in SSIS
SSIS Data Flow Process

Since DBAs may restrict permissions, sometimes we're limited to updating timestamps within the SSIS package. In this case, our table would be within our loading database, since we'd have permissions there. If the permissions were restricted further, such as object level permissions, we may use stored procedures with the same T-SQL where the user would only have execute permission on the stored procedures and write permissions on the loading table.

Option 3 - Add a time column to the SSIS data flow

We may want to obtain more granular time information when a specific part of our SSIS package runs, such as tracking the time of a file's data flow. For a simple example of this, what if we're importing 100 files and want to track the time range between several files? For an example: file 1 is imported at 11:01AM, file 2 is imported at 11:03AM, file 3 is imported at 11:16AM, and file 4 is imported at 1:18AM. We know that file 2 ran longer than files 1 and 3. In the below example within SSIS, we add a new column using the derived column option and adding a time function as a part of the data flow, which tracks the current time using a function. When the example file below this imports the data, the time is tracked.

SSIS Derived Column Date and Time
SSIS Derived Column Data Flow
SSIS Derived Column Output

Make sure that the table has an appropriate time column for these data to be added to the table, as this will stamp the column with the time (in this example, the ImportTime column on the table will receive the time of the data flow). With this technique, we can be more granular in measuring the time of our tasks, if we want to look at the time for a specific import.

Option 4 - Add data and time information with an SSIS Script task

I've seen some SSIS packages which use script tasks for additional functionality where a timestamp may be required. Because script tasks use the .NET library, we can use the DateTime library in .NET for tracking time. First, let's look at a simple output in the console application within Visual Studio. We'll execute the below code to validate our output - make sure to hit enter after a pause (your dates and time will differ).

using System;

namespace ConsoleExample
    class Program
        static void Main(string[] args)
            DateTime start = DateTime.Now;

            /// Wait a period before hitting enter
            DateTime end = DateTime.Now;

            Console.WriteLine(start.ToString() + "   " + end.ToString());
Console output for Duration

In a script task within SSIS, we will add a start and end variable with the same DateTime class and separate them with 10 seconds using the Threading library. After the ten seconds pass, the script task will write both the start and end time to a log file in our import directory.

public void Main()
 // TODO: Add your code here
 DateTime start = DateTime.Now;
 DateTime end = DateTime.Now;

 using (System.IO.StreamWriter writeFile = new System.IO.StreamWriter(@"C:\import\log.txt"))
  writeFile.WriteLine("Start: " + start.ToString() + "; end: " + end.ToString());

 Dts.TaskResult = (int)ScriptResults.Success;
Write file with date and time output
Next Steps
  • We want to consider what permissions we'll have and what level of access, as we may be limited where we can add timestamps or where we can track information.
  • We want to consider how granular of tracking we want - entire package, a set of actions within the package, etc.
  • Finally, we want to consider where we want to keep this information - the import table itself, a separate tracking table, a logging table, etc.

sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Tim Smith Tim Smith works as a DBA and developer and also teaches Automating ETL on Udemy.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

Friday, February 18, 2022 - 9:20:48 AM - Don S Thompson Back To Top (89809)
Or, MS could simply put a time stamp on the Output debug statements.

Why do we have to continually invent ways to make up for deficiencies in MS products?

Tuesday, April 9, 2019 - 9:00:53 PM - Sean Back To Top (79512)

Just curious. Why not just use SSISDB? 

internal.Executable_Statistics will tell you package and component execution times.

get free sql tips
agree to terms