June 12, 2012 at 4:14 am
Should you have a separate instance for running all ssis packages required on a SQL Server estate or keep them instance specific
June 12, 2012 at 4:24 am
June 12, 2012 at 8:41 am
I'm pretty sure that both responses are the same for the poll. However, I chose "No." I see no good reason to separate SSIS onto its own instance.
Jared
CE - Microsoft
June 12, 2012 at 9:48 am
I can't see a reason for a separate instance for SSIS, but I could see having a separate system for running SSIS packages (not the same thing in my opinion).
June 12, 2012 at 9:56 am
I'm a big fan of having a standalone system that is dedicated for the housing and execution of SSIS packages. It simplifies deployments and makes management a breeze in enterprise environments.
June 12, 2012 at 1:48 pm
Nailed by the dupe post as well. Dangit, don't do that.
http://www.sqlservercentral.com/Forums/FindPost1314675.aspx
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 12, 2012 at 1:53 pm
My ideal situation is to have a separate server for running Integration Services and other non-database-engine apps, e.g. PowerShell scripts and .NET console apps. The config lets me know the memory is primarily dedicated for running apps like SSIS packages, and not a database engine. The database instance on my app server will host a rather small database containing metadata for my SSIS packages and other apps, as well as the running instance of SQL Agent that runs everything (and associated msdb activity).
When running SSIS on every server hosting a database instance it becomes much more difficult in my opinion to tune memory, and do capacity planning, across the environment as a whole. If one SSIS package goes ballistic, or data volumes grow considerably on a specific instance, then memory in the buffer pool may have to be flushed, or if LPIM is used and max memory is set too high then the SSIS package may be starved forcing the OS to start paging memory. It seems simpler to tune a server's memory with a focus towards running apps -or- towards running a database engine, and not trying to mix both on every server in the environment. Just my two cents.
Note that SQL 2012 makes it easier for us to scale IS separately from the database engine, i.e. to have multiple servers hosting IS, and not database engines. A job scheduler outside of SQL Agent still appears to be a limiting factor however in some scenarios.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 12, 2012 at 1:56 pm
Evil Kraig F (6/12/2012)
Nailed by the dupe post as well. Dangit, don't do that.
Dang it! Caught in the churn again. I started my response before you posted the dupe link. Nice post on the other thread 😉 I agree with many of your points, as you can now see.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply