1.

Solve : Batch to stop SQL2005 service MSSQL$CSS ( sqlservr.exe )?

Answer»

Looking for the INSTRUCTION for my batch file to easily stop and start the MSSQL$CSS SQL2005 server service.

Looking to perform this through NET STOP and NET START.... ( whatever the service is called )

I have been able to us ethis to clear print spoolers before such as

NET STOP SPOOLER
NET START SPOOLER

in a batch. So I would like to do this as well without having to go to the system management --> services to STOP and START, but do from command line instruction that I can add to a batch backup program to stop the service and backup the database, then start the service back up after the backup of the data is completed.

Some say that you can back up SQL2005 on the fly, but I'd rather shut the service off to know that data is not being altered during the backup process.

Thanks!

Dave
Well
Code: [Select]@echo off
taskkill -f sqlservr.exe
pause >nulwill end the process.

and then svchost will start it up again...


look into downloading and trying PSSERVICE from SYSINTERNALS- looks like it might be the type of thing your looking for.Quote from: BC_Programmer on October 29, 2008, 04:36:33 PM

and then svchost will start it up again...


look into downloading and trying PSSERVICE from sysinternals- looks like it might be the type of thing your looking for.
Less arrogance in the future please.
I'm trying to help.I wasn't being arrogant, I was merely stating a fact.

Actually, if you keep taskkilling in a loop for a while, svchost will give up starting it. Unfortunately I believe it also disables the service, causing problems with SQL server.


Also- what if SQL server is in the middle of a transaction when you taskkill it? databases could get CORRUPTED, file handles remain open, meaning starting it again later (assuming the fact that svchost hasn't already disabled the service because it kept "crashing"), would CAUSE SQL server to have problems gaining EXCLUSIVE access to it's own databases again.


Killing processes is never a really clean solution, even if it would appear so- even when it works- terminating processes leaves a lot of cruft, from open file handles to open registry keys and even open devices (try killing a burning program when it's in the middle of a burn...)Quote from: BC_Programmer on October 29, 2008, 05:06:32 PM
I wasn't being arrogant, I was merely stating a fact.

Actually, if you keep taskkilling in a loop for a while, svchost will give up starting it. Unfortunately I believe it also disables the service, causing problems with SQL server.


Also- what if SQL server is in the middle of a transaction when you taskkill it? databases could get corrupted, file handles remain open, meaning starting it again later (assuming the fact that svchost hasn't already disabled the service because it kept "crashing"), would cause SQL server to have problems gaining exclusive access to it's own databases again.


Killing processes is never a really clean solution, even if it would appear so- even when it works- terminating processes leaves a lot of cruft, from open file handles to open registry keys and even open devices (try killing a burning program when it's in the middle of a burn...)

I'd rather not, and I have 0 experience with MySQL, He asked how to end a process, I gave him an answer.he asked how to end a service. Although a service is a process, it's always best to get svchost to shut down the service cleanly.

Your solution works fine- but it could have ramifications beyond the solution (I stress the could part since it's highly likely that SQL server is smart enough to notice that it's service is disabled and enable it again anyways).Quote from: BC_Programmer on October 29, 2008, 05:18:18 PM
he asked how to end a service. Although a service is a process, it's always best to get svchost to shut down the service cleanly.

Your solution works fine- but it could have ramifications beyond the solution (I stress the could part since it's highly likely that SQL server is smart enough to notice that it's service is disabled and enable it again anyways).

Agreed, period.Thanks for info both of you!

Dave


Discussion

No Comment Found