Image may be NSFW.
Clik here to view.
I've recently had some trouble with SQL Server Integration Services behaving badly. SSIS manages its own memory use, and ordinarily does a good job. By throttling inputs SSIS can run vast amounts of data through a data flow without using much memory or swapping to disk. Sometimes this goes horribly wrong, though, and you find your SQL Server database is hard faulting out of physical RAM because SSIS has gone and claimed 110% of the total RAM, much of which was already occupied.
You can use SQL Server Management Studio to kill an SSIS job by connecting to integration services and stopping the package. My next step is to try to stop the database session in Activity Monitor. When these fail, which they often do in my SQL 2012 SP1 environment, I do the following:
First I get the SSIS job's session ID from sys.dm_exec_sessions, and use the KILL command on it.
This sometimes works, and sometimes doesn't.
The last resort is to stop the database instance. If you use the various GUI's ( SQL Server Management Studio, SQL Management Configuration Manager, or Services MMC), they issue a SHUTDOWN command, which is useless if you're trying to stop a process which ignored KILL. You need to open a SQL prompt, and run SHUTDOWN WITH NOWAIT.
SHUTDOWN WITH NOWAIT, isn't as dangerous as the options in some other databases (Oracle's SHUTDOWN ABORT, for example) but it isn't something you want to take lightly. It will not damage your database, or violate ACID. It will happy terminate long running jobs, which may remove a lot of work and cause a long startup delay as the transaction log rolls back.
Of course, good desk checking should make this a rare occurrence, but even the best sometimes spectacularly fail unit test. (When I'm in the mood to flatter my team I point out that the first unit test suffers from Turing's Halting Problem.) If your DB server is unusable due to a runaway session, SHUTDOWN WITH NOWAIT is the correct tool.
