Scheduled a SSIS package on my Sql Server Agent, when i go to the Job History it says the Job succeded for the time it was scheduled to run, but im noticing the Job does nothing, i mean the Package is running but it's not doing what it is supossed to do.
I know the Package works because when i go to the BI Studio and rightclick>Execute Package it works.
Could be a security issue. Agent jobs run as the Agent Service Account, so you want to make sure that account has correct permissions in the database or else you will need to create an SSIS proxy to run the job.
Related
If I have an Azure Managed Instance, what is the difference between scheduling jobs that contain T-SQL and/or packages within the MI on SSMS using SQL Agent and Azure Data Factory? Does the scheduled job run on the VM/Managed Instance instead of the IR in Data Factory? If so how does this handle SSIS Packages? I assume it will just fail?
I thought you could only schedule the jobs with SSIS packages inside Data Factory but I guess I was wrong as it has let me create a schedule (albeit it has not run yet).
Some of these jobs have been created from an offline sql server DB and recreated using a T-SQL script.
EDIT: I am aware of the differences between Data Factory and SQL Agent. I suppose the questions I am asking are:
Can the SQL Agent Job Scheduler run Jobs that have both a T-SQL step and a SSIS package step just like a normal sql server or do the packages strictly have to be scheduled to run in Data Factory with SSIS IR? The official Microsoft Documentation is confusing
If so, what is the best way to run a job that uses both T-SQL scripts and SSIS Packages in a Managed Instance?
For your first question "Can the SQL Agent Job Scheduler run Jobs that have an SSIS package in a step or do the packages strictly have to be scheduled to run strictly in Data Factory with SSIS IR?
Yes, there many tutorials talked about this, you could ref this official document:
Microsoft: SQL Server Agent Jobs for Packages: You can automate and schedule the execution of SQL Server Integration Services packages by using SQL Server Agent. You can schedule packages that are deployed to the Integration Services server, and are stored in SQL Server, the SSIS Package Store, and the file system.
Azure SQL managed instance support SQL Agent job and can schedule run the SSIS packages, Data Factory also could achieve that with SSIS-IR.
Second question, what is the best way to run a job that uses both T-SQL scripts and SSIS Packages in a Managed Instance?
Azure SQL managed instance has almost the same feature with on-premise SQL Server. So you could create the SQL Agent job to execute the T-SQL scripts or SSIS Packages like on-premise.
HTH.
What is the alternative for running jobs when the hosting company that provides shared SQL Server services blocks access to SQL Server Agent?
All windows machines have a built in tool, "Windows Task Scheduler" which can run jobs on a schedule determined by you. Its an easy tool to learn and you probably will have to run your jobs using SQLCMD.
If you don't have access to agent, then you wont get access to Window Scheduler for sure. Request access to the agent or at least have them create a job for you that runs at a specific time. If not the alternative is pretty ugly.
1.What is purpose of the job to be run by the Agent job?
How often did you want it to run (Schedule) ?
If you can answer those two then maybe, we can have an alternative..
In dire need of help. I have a simple SSIS package created but here is the thing. It is NOT stored nor ran from the SQL Server Agent. It's stored locally. We don't have access to utilize SQL Server Agent. So we are using a batch file that is scheduled in Windows to execute the SSIS package. This works, however, someone has to press the stop button when finished. I've googled how to stop it through vb.net but everything I've read is based on hitting the SQL server, looking for the package name and then stopping it this way. Since this isn't stored in SQL Server, that method doesn't work. Any ideas?
I am running SQL Server 2008 R2 and after trial and error I created a package the server agent executes on a schedule, on test server. When I move over to the production server - Using SSMS logged in as SA - I create the package from right clicking the database and going to tasks just like I did in test.
When I log into the Integration Services I see all the folders including the MSDB folder, but my saved package isn't there. When I go to Server agent and navigate to the package I created it's there! But it fails when the Server Agent runs it.
I am trying to eliminate the running of the package itself as the thing causing the error. This is the first time anyone has used the Integration service on the production server so maybe there's a setup step that was missed? How do I get my packages to show up in SSMS under the MSDB folder just like on my test database?
I deployed my working package on server which is enterprise edition, SSIS installed on it. When I tries to run package by connecting to integration services engine from my desktop SQL client (which doesn't have SSIS installed) I get error "The task "Send Mail Task" cannot run on this edition of Integration Services. It requires a higher level edition."
Does it mean that I need to login to the server (RDP) and then run the package?
Also, when I schedule the package thru SQL agent it fails saying login time out but my windos auth login works for everything from connecting, deployment. Any clue?
For your first problem - yes, you need to RDP into the server in order to use SSMS to start the package. When you start it using SSMS on your client, it's attempting to launch the DTExec process on your client machine. It's not running DTExec on the server.
Your second problem is likely a permissions issue. Possibility #1: The connections you have set up on your package require your authentication information, and they don't have it because they're running as the Agent account. You can fix that by creating a Proxy for your account and using that to run your job step. Possibility #2: The connections you have set up on your package are having their sensitive information stripped out due to the default encryption on the packages that prevents anyone but "you" from seeing it - including a SQL Agent job that isn't running "as you". The same resolution as above can help that (as well as others).