I recently posted a question looking to find an alternative to granting devs sysadmin privileges just to use the sql server debugger. I am finding that there really isn't a feasible solution to this.

My question here is, WHY does the sql server debugger require sysadmin privileges? I want to understand the reasons behind designing it this way.

In a dev environment, developers should be able to do dev activities such as using the built-in debugger tools without granting sysadmin, instead of being told to basically build his own debugging mechanism using print statements, etc.

SQL server has privileges for so many specific roles/tasks, etc, it's odd not to see a separate one for this e.g. which could be granted only in a dev environment, etc.

I don't think this question is a duplicate of the others, since this question is not about how to use the debugger if you aren't a sysadmin, but rather, it is so I can understand why it is designed this way.

  • 1
    Why don’t you grant sysadmin to developers in dev environments anyway? – Martin Smith Oct 16 '17 at 20:12
  • 1
    I haven't seen definitive evidence for this, but I presume it is because performing debugging steps on a database can cause serious issues with contention and blocking to the point where it shouldn't be a feature that is easy to doll out access to. It seems MS doesn't plan on changing this, either. – LowlyDBA - John McCall Oct 16 '17 at 20:19
  • 2
    If you have developers use local copies instead of a shared instance, @MartinSmith 's suggestion is even less for you to worry about. – LowlyDBA - John McCall Oct 16 '17 at 20:21
  • @MartinSmith - in this case, I am the developer, not the DBA. Just want to be sure I understand the whole thing before I have discussions. Company policy where i am working is to not ever grant sysadmin to users in any environment. – GWR Oct 17 '17 at 12:00
  • @LowlyDBA - Local copies isn't really feasible either. Huge multiple-db system which many distributed systems also interact with, hence the need for centrally managed environments for end-to-end dev/test/uat, etc. But again, I am not looking for a solution in this question - just for some background info on why it is set up this way. I think you have provided that. – GWR Oct 17 '17 at 12:04