SSIS Overrides
Overview
Somebody reran the month end load with the date parameter pointed at last month. It worked, they moved on, and six weeks later the numbers are wrong and nothing records what happened.
The catalog recorded it, in a table with a column named for the purpose. catalog.execution_parameter_values carries a runtime_override bit that means exactly this run was not started the way the environment would have started it.
Nothing reads that column. Not the built in reports, not SSMS, not this product until now.
Where to find it
Expand a server in the tree, expand a database holding an Integration Services catalog, then SSIS → Overrides.
Two kinds, because they have different owners
Changed values
Project and package parameters. A value changed for one run.
This is the reprocess nobody wrote down, and it is the half that explains wrong numbers.
Changed settings
System parameters at object_type 50. LOGGING_LEVEL, SYNCHRONIZED, DUMP_ON_ERROR and the 32-bit runtime all arrive through the same table.
A package raised to Verbose to investigate something and never put back is visible here and nowhere else, and it is the usual reason SSISDB is the biggest database on the instance.
Reading the grid
| Column | What it is |
|---|---|
| When | When the execution started. |
| Package | The package it was given to. |
| Parameter | The parameter or system setting that was overridden. |
| Value it was given | What it was set to for this run. Sensitive values read as set. |
| Kind | Project parameter, package parameter, or system setting. |
| Started by | Who did it. |
| Status | How the run ended. |
| Execution | The execution_id, so the run can be found on the other pages. |
The toolbar
| Control | Options | Default |
|---|---|---|
| Window | 7 days, 30 days, 90 days | 30 days |
| View | Changed values, Changed settings | Changed values |
| Environments | Opens SSIS Environments. | |
| Catalog health | Opens SSIS Catalog Health. |
Where the data comes from
| Source | What it gives |
|---|---|
catalog.execution_parameter_values |
parameter_name, parameter_value, object_type, sensitive, and the runtime_override bit. |
catalog.executions |
The execution, its package, its caller and its status. |
catalog.object_parameters |
The design default the override replaced. |
Related reports
| Report | Why you would go there |
|---|---|
| SSIS Catalog Health | What a logging level left at Verbose has cost in space. |
| SSIS Who Fills It | Which package that logging level belongs to. |
| SSIS Environments | The bindings an override bypassed. |
| SSIS Packages Run | The run itself. |
| SSIS Dumps and Runtime | Where DUMP_ON_ERROR and the 32-bit runtime lead. |
Frequently asked questions
The numbers for last month are wrong and nobody knows why. Set the window to cover the reprocess and read the Changed values view. If somebody reran the load with a different date parameter, it is on this page with their name against it.
Why is SSISDB huge? Read Changed settings and look for LOGGING_LEVEL. A package raised to Verbose for one investigation and never put back is the usual answer, and this is the only place it is recorded.
Is an override a problem? No. Reprocessing with a changed parameter is a normal operation. What is a problem is that until now there was no record anybody could read.
Sensitive parameter values show as “set”. The catalog masks them. The mask is not the value, and showing asterisks would read like a password.