SSIS Package Stuck at “Created Execution” Status

Question

I recently deployed a update to one of my SSIS projects, and ever since the project has failed it\'s scheduled runs.

The SSIS package appears to be stuck at the \"Cr

Answer 1

For someone that had this issue with a development team triggering 1000+ bad SSIS Executions through the stored procedures we had set up on the Database Administrator side causing a memory overload... Can't do much for not following documentation.

To set parameters in your package if they remain unset. see reference

EXEC [SSISDB].[catalog].[set_execution_parameter_value] id, object_type, parameter_name, parameter_value

If you wish to start it and get it to run after setting up the parameters.

EXEC [SSISDB].[catalog].[start_execution] id

If and only if status of the package is left in the status = 1 state. see reference

There is also if the package is already running to stop it

EXEC [catalog].[stop_operation] id

And if you need to do it bulk for what I had (setting parameters up properly) create a cursor and do what you need to do based on the status and issue in the packages if there are valid ones that need to run and invalid ones that need to end their existence.

DECLARE id BIGINT

DECLARE < cursor > CURSOR FAST_FORWARD FOR
  SELECT * FROM [SSISDB].[catalog].[executions] WHERE [status] = 1

OPEN < cursor >
 FETCH NEXT FROM < cursor > INTO id

 WHILE @@fetch_status=0
 BEGIN
  ...
  Code for changes to SSIS packages
  ...
 END

CLOSE < cursor >
DEALLOCATE < cursor >

Answer 2

In the interest of having an actual answer on this question and having just run into this very frustrating issue myself, the problem lies in package/environment parameters. When a package is run on a schedule, if required package parameters are not supplied, SSIS just... sits there. No errors are reported, but the package never actually starts.

Providing values for the required parameters will resolve this issue.

Answer 3

I found that this can also happen if a new version of a package no longer has, previously configured, parameters. The only solution I found is to re-create the job-step after updating the Environment Variables' configuration. Somehow the Job seems to 'remember' the no longer existing parameters, and will not actually start the package because it thinks that some parameter-configurations are missing.