SQL Server Agent job steps vs SSIS

When doing ETL, you have the choice of using T-SQL or SSIS (see When to use T-SQL or SSIS for ETL).  If you decide T-SQL is the way to go and you just want to execute a bunch of T-SQL statements (individually or within a stored procedure), it’s still a good idea to wrap them in SSIS Execute SQL Tasks because you can use logging, auditing and error handling that SSIS provides that T-SQL does not.  You can also easily run SSIS Execute SQL Tasks in parallel, so if those tasks are calling stored procedures that means you are able to run stored procedures in parallel.  Other benefits for using SSIS instead of a SQL Server Agent job include:

  • The ability to use a project data connection manager, so if the connection info changes you only need to change it in one spot
  • You can create checkpoints for restarting
  • You can add logic to check if packages have run by querying the status log (SSISDB catalog) instead of manually looking at the SQL Server agent job steps
  • You can do reporting off of the auditing info you capture
  • You can use select statements against the SSIS history for analysis (history stored in SSISDB catalog), which you don’t have for job steps in SQL Server agent
  • Ease of maintenance (but depends on knowledge of SSIS vs knowledge of SQL Server)

 

About James Serra

James currently works for Microsoft specializing in big data and data warehousing using the Analytics Platform System (APS), a Massively Parallel Processing (MPP) architecture. Previously he was an independent consultant working as a Data Warehouse/Business Intelligence/MDM architect and developer, specializing in the Microsoft BI stack. He is a SQL Server MVP with over 25 years of IT experience.
This entry was posted in SQLServerPedia Syndication, SSIS. Bookmark the permalink.

2 Responses to SQL Server Agent job steps vs SSIS

  1. Steve Neumersky says:

    That represents a nice compromise for teams that have only a small percentage of SSIS folks….. if the discipline and enforcement of that design pattern is utilized.

  2. Agree 100%. I have a lot of SSIS packages which are basically T-SQL statements, but everything is wrapped up nicely in SSIS because of the auditability and maintainability. And parallellism of course :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>