Controlling soft errors and false alarms in SSIS
- by Jim Giercyk
If you are like me, you dread the 3AM wake-up call. I would say that the majority of the pages I get are false alarms. The alerts that require action often require me to open an SSIS package, see where the trouble is and try to identify the offending data. That can be very time-consuming and can take quite a chunk out of my beauty sleep. For those reasons, I have developed a simple error handling scenario for SSIS which allows me to rest a little easier. Let me first say, this is a high level discussion; getting into the nuts and bolts of creating each shape is outside the scope of this document, but if you have an average understanding of SSIS, you should have no problem following along. In the Data Flow above you can see that there is a caution triangle. For the purpose of this discussion I am creating a truncation error to demonstrate the process, so this is to be expected. The first thing we need to do is to redirect the error output. Double-clicking on the Query shape presents us with the properties window for the input. Simply set the columns that you want to redirect to Redirect Row in the dropdown box and hit Apply. Without going into a dissertation on error handling, I will just note that you can decide which errors you want to redirect on Error and on Truncation. Therefore, to override this process for a column or condition, simply do not redirect that column or condition. The next thing we want to do is to add some information about the error; specifically, the name of the package which encountered the error and which step in the package wrote the record to the error table. REMEMBER: If you redirect the error output, your package will not fail, so you will not know where the error record was created without some additional information. I added 3 columns to my error record; Severity, Package Name and Step Name. Severity is just a free-form column that you can use to note whether an error is fatal, whether the package is part of a test job and should be ignored, etc. Package Name and Step Name are system variables. In my package I have created a truncation situation, where the firstname column is 50 characters in the input, but only 4 characters in the output. Some records will pass without truncation, others will be sent to the error output. However, the package will not fail. We can see that of the 14 input rows, 8 were redirected to the error table. This information can be used by another step or another scheduled process or triggered to determine whether an error should be sent. It can also be used as a historical record of the errors that are encountered over time. There are other system variables that might make more sense in your infrastructure, so try different things. Date and time seem like something you would want in your output for example. In summary, we have redirected the error output from an input, added derived columns with information about the errors, and inserted the information and the offending data into an error table. The error table information can be used by another step or process to determine, based on the error information, what level alert must be sent. This will eliminate false alarms, and give you a head start when a genuine error occurs.
