So, we have around 20 SQL Agent jobs that run SSIS packages. They run on a regular schedule 24/7. Said schedule is either every 5 minutes, every 10 minutes, or every 15 minutes. We actually created an individual schedule for each of these jobs in order to help stagger them, but inevitably sometimes a few of them will run at the same time - when this happens, sometimes they fail. We don't believ that the SSIS package is failing, because we have very extensive logging within these packages, and there is no indication that the package failed. In fact, the appear to not even start executing. What it looks like, is that the actual SQL jobs are failing. Here is an example of an error message from last night when two jobs ran at the same time and failed: JOB RUN: '[JobNameRemoved]' was run on 9/13/2011 at 6:05:00 PM DURATION: 0 hours, 0 minutes, 23 seconds STATUS: Failed MESSAGES: The job failed. The Job was invoked by Schedule 192 ([JobScheduleNameRemoved]). The last step to run was step 1 (Execute SSIS). Does anyone have any suggestions on where to look for internal errors, or how to fix this? Also, we will be continually adding these jobs, and staggering the schedules gets more difficult - any thoughts on that? Thanks!Clint

I appreciate everyone's response, but Like I said in my initial post, we have very extensive logging in the SSIS package, and it does not indicate any error...It never even starts logging. It's like the job fails before the package even begins to do anything. How would looking at the SSIS log help me, if there is nothing in it? Are there system tables/view that contain data regarding SQL agent job execution history? Unfortunately, I can't just run the job manually to reproduce the error, because many of them run at the same time, and never have problems. and, it's not using the transfer object task. Also, Debu, I clicked on step one in the history, and that was where I found the error I posted before, there was nothing more detailed. Thanks all.Clint

That error is the "generic" error message from SQL Agent. You would need to look at the SSIS package log to figure out why this is happening. However, I have seen this kind of thing happen if you are using the "Transfer Object" task in your package. This task creates a temp SSIS package with the same name every time. If 2 packages try to use this type of task at the same time, the 2nd fails.

Right click the job and then select history. Then just expand the job and select step 1. It should provide more detail about the failure of step 1.

Unfortunately, that error message is just the "step failed" message without more information it is impossible to guess what the real issue is. I can tell you I run 100+ SSIS packages, using SQL Agent, most on a reoccuring 5,10,15,30 min schedule without issue.

Like Tom mentioned, you can manually run the SSIS package of a SQL job at the time when you know it'll run into some other job and has failed in the past while doing so. If the SSIS package generates an error, you'll know exactly which task caused the failure and what the error message is. Most probably, it will turn out to be a common resource being locked by the other job/process. We do have such processes in our envirnment as well which have a potential of running into each other (not at specific times thoug). For the job steps that we know run into each other, we set the step to attempt retries a certain number of times (a setting in the job step properties) before giving up and failing eventually. Some of the jobs also do a "check" as first step to see if any of the other dependent jobs is still running and go into a loop waiting for that job to finish before starting execution themselves. There can be multiple ways of addressing this conflicting situation. It depends on which one you feel comfortable with. Hope this helps. Cheers! Muqadder.