November 29, 2011 at 8:12 am
We have an active/passive cluster at a client site. SSIS installed on both nodes, packages are part of cluster resource, run as file level packages, not msdb. When on node one everything works great. However when it fails to node 2, the job fails with the packages unable to connect to the datasource (the same server, sqlexec (service level) account runs sql server and the job). I can login to the active server, open up BIDS and run the packages manually just fine. I can go to the job the and steps point to the correct location. Any one seen this before?
February 26, 2012 at 5:52 pm
I am having the exact issue and have been unable to solve it. Did you find a solution?
Thanks,
Kimberly Killian
Sr. DBA / DB Engineer
www.sitedataview.com
Follow me on Twitter
Follow me on Facebook
February 26, 2012 at 8:28 pm
Where are the packages stored? you mentioned in the file system.. Is it in a shared location? Is it on a drive that is part of the SQL resource group? Or is it a drive on each node? Tell us a bit more about that?
CEWII
February 27, 2012 at 6:17 am
I've tried both the Filesystem and SSIS pkg store. Both throw this message: "NOTE: The step was retried the requested number of times (1) without succeeding. The step failed." No other message.
Thanks,
Kimberly Killian
Sr. DBA / DB Engineer
www.sitedataview.com
Follow me on Twitter
Follow me on Facebook
February 27, 2012 at 6:31 am
Are you sure that there are no other more-detailed error messages?
Do you know which step is failing? What is it trying to do?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
February 27, 2012 at 7:17 am
Odd solution, the issue was the developer had put a code break in a script. It runs in BIDS not as a job, removed the code break and it worked.
February 27, 2012 at 7:45 am
It's failing on the step that calls the ssis. No other message is thrown, which is why it's so weird.
Thanks,
Kimberly Killian
Sr. DBA / DB Engineer
www.sitedataview.com
Follow me on Twitter
Follow me on Facebook
February 27, 2012 at 7:45 am
I don't think this is my issue - no code breaks.
Thanks,
Kimberly Killian
Sr. DBA / DB Engineer
www.sitedataview.com
Follow me on Twitter
Follow me on Facebook
February 27, 2012 at 7:48 am
Any chance the sql agent service account does not have rights to a file share/folder necessary for the package to execute?
February 27, 2012 at 7:54 am
One of the developers reminded me there were 2 issues that fixed this. One was the code break, the other was the shared resource that was used by this process had a variable in their code that referenced a drive folder that was not a shared folder but a hardcoded drive and folder (they had about 30 variable in the package) All the variables used the shared resource, except for this one (which was used to move error files) which is why it only broke some of the time.
February 27, 2012 at 8:16 am
Ahh.. This is why I like to allocate a shared file drive that is placed in the same resource group as my SQL Server. I can then know that drive X: is always available to that SQL instance no matter what node it is on.
CEWII
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply