July 15, 2010 at 9:11 am
I am somewhat new to SSIS.
On my local workstation I have Integration Services installed. When I connect to it via SSMS, I simply connect to my local workstation name.
I also have a named instance of SQL Server involved. When I connect to it via SSMS, I connect to workstation\instancename
So far, so good.
I have created a handful of packages and saved them to MSDB on my named instance of SQL Server. I then schedule them to run via jobs and the jobs run fine.
Here is where I get confused. What SSIS service is it using to run these packages? It does not appear to be the one on my local workstation. I can disable that service and the jobs still run fine.
Help.
July 15, 2010 at 10:07 am
Jobs normally run in the context of the SQL Server Agent service.
Edit:
Description of the SQL Server Integration Services (SSIS) service and of alternatives to clustering the SSIS service
http://support.microsoft.com/kb/942176
Google is your friend.
July 15, 2010 at 10:09 am
Right, but I am assuming for an SSIS package to run, the Integration Services service needs to be running. How can the job complete if that service is not running? In addition, I watch some SSIS specific performance counters during execution and see nothing.
July 16, 2010 at 2:44 am
I believe that the SSIS service on your local workstation is necessary so that you can run packages in BIDS.
However, if you run the package in SQL Server itself, it will use it's own service.
Disable the SSIS service, and try to run the package locally in BIDS. Normally, it should fail.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 21, 2010 at 12:10 pm
I don't think so, the Integration Services service is little more than a method of accessing the list of known packages and a method to execute them. In the end, IS calls DTExec which does 99.9% of the work.
Also, I don't even HAVE an Integration Services service on my machine and I can exec packages in BIDS.
There is only a single instance of SSIS on a machine AND it is not cluster aware. Now the big thing to remember is that SSIS can be backed by nearly ANY instance of SQL server, this is controlled by the xml config file.
Also depending on how you schedule them depends on what service is running them. If you specify that this is an SSIS step then the SSIS service will be running the package typically under the security account of the SQL Server Agent. If you actually call DTExec directly then the SSIS service is not running it. In the end BOTH call DTExec to run it but the SSIS step is easier to setup and I highly recommend it.
CEWII
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply