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)
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.
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 🙂