I set up a job to run a SSIS package in the SSIS Catalog, but the SSIS package doesn't start. If I right-click the package and run it, it completes successfully.
When I look in the execution history of the package in the Catalog, there is no sign that it the package was even started by the job.
I created a test package to make sure it isn't the specific package failing, so the package I'm testing with has a SQL Task that does a 'SELECT 1'. Still fails.
The job just stays in the "Executing" state until I stop the job.
I am running SQL Server 2014 Standard Edition, and running the job with a sysadmin account.
Why is the SQL Agent Job not running my package?
Edit: I had a look through this article but it either doesn't apply or I gave it a shot and it didn't work either.
Edit 2: I found an error under the SQL Server Agent Job History: Unable to terminate process 1850 launched by step 1 of job 0x5DAD5416FA09C445B82ABDBB49F75E38 (reason: Access is denied)
Does that mean my service account doesn't have enough permissions on the local machine? However, I AM able to run the job with DTEXEC using the service account without issues...
I have also faced this scenario many times but when I checked running the package manually,its completing successfully because I was using for each loop container and sequence container as well.In both cases for each loop and sequence were completing without validating other ones.So I checked precedence constraint and change it,Now it working and all the component ran successfully. Sometimes we miss to choose appropriate precedence constraint, there are many option like on Success ,failure,completion and then for you can choose values from Constraint ,Expression,Expression AND Constraint and Expression OR Constraint. Initially i was using Expression OR Constraint for success and now changed it to Expression AND Constraint, its working fine for me. You also need to do this,it will definitely work please try and let me know.
When you look at the connections in the SSIS package, did you put in a user id and password? If so, did you add a package password? The reason I ask is that if you don't add a package password, it will strip out things it thinks should be secure (like passwords). You might want to try putting the connection password in a configuration file, and add that file to the job. Either that or password encrypt the SSIS package but you will have to take special care when you run the package for the first time (or when you create the job) because you will need to provide the password that you used to encrypt the package.
Reboot fixes this issue. Reason is because if you look at this message. Unable to terminate process 1850. That is a windows process. I would say reboot. If you really like to enquire before rebooting. You could use sysinternals process explorer. Download it and use that to find process id 1850 which may be hung process in windows.
Thanks
Ali
Related
I'm maintaining a project using Microsoft SQL Server 2016 (SP1) (according to this script) which heavily depends on recurring jobs (mirroring certain external db's and so on).
Especially the mirroring jobs are essentially based on SSIS packages which define a datasource, then execute a hardcoded SQL query and afterwards store the results in the specified destination.
Unfortunately the source databases where moved to a different domain and thus aren't accessible via the previous url.
My issue right now is that I simply have to change the source destination url but I'm not able to do that. There are plenty of ways to 'modify' SSIS packages but none of them seem to work with me.
What I managed (and seems the most promising) to do is to open the 'Integration Services...' part of my db, export the jobs to my desktop, modify them with Notepad and reimport them. And they seem to work if I execute them separately. But as soon as I try to execute the packages via SQL Server Agent it fails screaming:
Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state."
Does somebody know whats going on here and how I'm able to solve this? No password or username changed, only the connection string.
Is it even possible to manage a package like that?
Thank you for your help!
After further investigation I detected that even a newly created job didn't run properly. It was kind of strange that a package would run without any issues while directly executed but not via the SQL Server Agent, so I assumed it may be a rights issue and it was!
Somehow the Server Agent wasn't allowed to decrypt (although I never changed the executing user of a step) the password anymore.
I was able to work around my issue by simply creating each SSIS package again (some click hell but ok) but this time I secured 'sensitive data' with a password instead of the users key.
Afterwards I had to change each job step with a reference to to the damaged ssis packages and obviously type in the new passwords.
Seems to work again.
Thanks anyway
I have taken a look at several articles including this unanswered question: SQL Server Job runs successfully but doesn't execute packages
I have the exact same problem in SQL Server 2012 using the integration services MSDB catalog. I can execute the SSIS packages manually from that catalog, but the agent job doesn't do anything except state that it completed successfully. I have also executed my SSIS packages from within Visual Studio and they worked just fine. Here's the situation and am wondering if it may be permissions:
SSIS packages look for Excel files matching criteria in a network location.
Once found, the SSIS packages writing the data into the database and archive the file to another folder on that same network location.
Emails are sent upon any failure of import of data into the database or migration into the archive folders.
I have the SQL Agent job running the SSIS packages from a package store (MSDB) using the SQL Server Agent Service Account to run under. Currently we are not doing any sort of project deployment to these servers so I am sticking with package deployment. Here are some steps I've taken:
Run packages manually from Visual Studio 2010 (fully successful).
Run packages manually from SQL Server MSDB catalog (fully successful).
Run job manually from SQL Server Agent using parent package as a step that will execute child packages as an external reference (success but nothing happens).
Run job manually from SQL Server Agent using each package as its own step excluding the parent package (success but nothing happens).
Any ideas? Permissions to the network location or need a proxy? Again, I am running Microsoft SQL Server 2012 Enterprise Edition 64-bit. Many thanks for any help you can provide.
Found the problem. My SSIS package has a foreach loop container and, while the tasks inside the loop container couldn't access the destination, the loop container technically completed successfully. We had to give permissions to the account the steps were running under for the job to correct that. These permissions were put on the network location to allow that account access to read and write to that location. Additionally, my Excel connection was 64-bit so we enabled it to 32-bit runtime and this allowed that portion of the process to complete successfully. I re-enabled any disabled tasks and it looks good to go now. Thanks!
I have also faced this scenario many times but when I checked running the package manually,its completing successfully because I was using for each loop container and sequence container as well.In both cases for each loop and sequence were completing without validating other ones.So I checked precedence constraint and change it,Now it working and all the component ran successfully.
Sometimes we miss to choose appropriate precedence constraint, there are many option like on Success ,failure,completion and then for you can choose values from Constraint ,Expression,Expression AND Constraint and Expression OR Constraint.
Initially i was using Expression OR Constraint for success and now changed it to Expression AND Constraint, its working fine for me.
You also need to do this,it will definitely work please try and let me know.
We have a package that we created in VS. The package executes perfectly in VS. We then saved and deployed the package to SSIS. Inside SQL Server Management Studio, the SSIS package executes perfectly when done manually. We have 2 packages that we manually execute. We are trying to schedule these 2 packages to run automatically using the SQL Server Agent. When we set up a job and schedule it, the job fails. The first step in the package fails with the error: Failed Validation and returned validation status "VS_ISBROKEN"
We think it has to do with the security on SQL Server Agent, but we have checked and all the permissions seem to be set correctly.
Any help is greatly appreciated!
You should be getting additional error messages other than the VS_ISBROKEN, which will be more helpful in figuring out what's going on. It has been my experience that VS_ISBROKEN almost always refers to an invalid query. For example, the query could be referencing an object that doesn't exist on the target server.
I came across a similar problem in an earlier version of SSMS and found the problem was that the owner of the package in SQL server Agent was incorrect and should be sa or dbo
I don't know if it helps but the symptoms for this seem very similar to mine
I created an sql server agent job that consists of steps that are calls to ssis packages.
Let's say that the job is being executed and one of the steps (that is a ssis package) has a file system task/sql task etc that fails. Is there any way that can I retry/rerun this particular package step (file system task/sql task etc) and then go on with my execution of the rest of the job steps after I fix my error? I know that you can retry certain sql server agent jobs and steps but I can't find any way to retry this step and resume my execution in case something inside the package fails.
And I also want to know if there is any way to disable certain package steps from the sql server agent "level" - without having to open Data tools.
Thank you.
Go into the job properties, and into the step that contains the SSIS package. Go to the Advanced tab, and you can modify the number of Retry Attempts for that step.
You could always put some error handling into the package in question. If an exception occurs, it will be handled accordingly allowing the other packages to continue. I always handle exceptions within the packages and log exceptions to a table.
In relation to your other question:
"And I also want to know if there is any way to disable certain package steps from the sql server agent "level" - without having to open Data tools. "
You could always go down the PowerShell route, create a script that takes a parameter. The parameter specifying whether or not you want a specific package to run.
If you want to skip certain steps within the package then you would have to create some sort of precedent constraint that acts on a variable you have set.
I've been having a reoccurring problem that escapes me at this point. I have a job set up in SQL Server 2k that has a few command steps which are followed up by 4 steps that just call DTS packages on the same server. When it comes to calling the packages, the job fails with no real reason given. Ok fine...
Well the thing that I can't figure out is that if I run the packages in order separately they work 100% of the time. I've deleted the packages entirely and re-added them as well as modifying the corresponding step. Am I missing something?
Is there something inherit with the DTS package versioning that causes the job to fail when the package runs just fine as a standalone?
Thanks.
We've always had issues with DTS packages on our SQL Server 2000 databases. You could try checking the windows event viewer/system error logs to see if there is anything more detailed in there.
We've had credentialing issues before that jobs would fail because the windows account running the job may have become inactive - so maybe the credentials the first job is running under doesn't have access to run dts packages, but you (as an administrator) do ?