September 19, 2013 at 6:33 am
How to provide only rights to execute sp_who2 & killing the blocking SPID if any without giving sysadmin rights, is this possible???
************************************
Every Dog has a Tail !!!!! :-D
September 19, 2013 at 6:47 am
Using the KILL command requires ALTER ANY CONNECTION. http://technet.microsoft.com/en-us/library/ms173730%28v=sql.100%29.aspx
Executing a procedure requires access to the database containing the procedure, EXECUTE on the procedure and whatever permissions the procedure code itself requires.
A long-term solution is to find the source of the blocking and fix it.
September 19, 2013 at 6:52 am
You can run SP_who2 with "View Server State" permissions.
grant ALTER ANY CONNECTION to USER, will allow you to kill user sessions.
September 19, 2013 at 7:57 am
SQLJim88 (9/19/2013)
You can run SP_who2 with "View Server State" permissions.grant ALTER ANY CONNECTION to USER, will allow you to kill user sessions.
I have created a Group Named - "Dev_Team"
What will be the SQL command which will grant them to execute SP_who2 & Kill process???
************************************
Every Dog has a Tail !!!!! :-D
September 19, 2013 at 10:19 am
use [master]
GO
GRANT ALTER ANY CONNECTION TO [**USER**]
GO
use [master]
GO
GRANT VIEW SERVER STATE TO [**USER**]
GO
November 11, 2013 at 3:17 am
How to provide access to a user on SQL profiler??
************************************
Every Dog has a Tail !!!!! :-D
November 11, 2013 at 4:13 pm
OnlyOneRJ (11/11/2013)
How to provide access to a user on SQL profiler??
You don't actually want a "user" to run SQL Profiler. Not even on the server side. You're just asking for a world of hurt if you do.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2013 at 4:17 pm
Ed Wagner (9/19/2013)
Using the KILL command requires ALTER ANY CONNECTION. http://technet.microsoft.com/en-us/library/ms173730%28v=sql.100%29.aspxExecuting a procedure requires access to the database containing the procedure, EXECUTE on the procedure and whatever permissions the procedure code itself requires.
A long-term solution is to find the source of the blocking and fix it.
I also have to state that using KILL should be a last resort nearly as severe as bouncing the server because using KILL doesn't always work as expected (and it's a documented CONNECT item). It will frequently leave the connection in a permanent 0% rollback state and some of those will consume the better part of an entire CPU. The only way to fix such 0% rollbacks is to bounce the server or the service.
Consider the use of KILL as a super last resort and, for the love of the server, don't give anyone but trusted DBAs the ability to KILL any connection.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2013 at 4:19 pm
I agree with Jeff. You want to be careful with KILL. I've had it work 99% of the time, but that 1% can be really, really annoying and a killer.
Instead, you ought to track down why the devs need to kill connections. Work to fix the process and remove the need to kill things.
November 11, 2013 at 11:33 pm
We are only providing it on Development servers... where they want to test & check..
Its their server...... we just have to give them rights to run profiler.. but no sysadmin role
************************************
Every Dog has a Tail !!!!! :-D
November 12, 2013 at 12:22 pm
If it's just dev, look at this article: http://technet.microsoft.com/en-us/library/ms187611%28v=sql.100%29.aspx
I'd script the permissions to set this up to a group, then add the devs to the group.
November 15, 2013 at 4:12 am
OnlyOneRJ (11/11/2013)
We are only providing it on Development servers... where they want to test & check..Its their server...... we just have to give them rights to run profiler.. but no sysadmin role
Although you say its their server, you are the DBA supporting that server.
Personally, if a DEV team has a hung connection, or needed to end a connection for any reason, I would ask them to come to me to find out why.
I had a situation previously where the dev team had this access, and were frequently ending my maintenance scripts.. not ideal.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy