May 25, 2011 at 9:05 am
I work with an unruly developer that always runs DTA against our production databases during prod hours. I have asked him several times not to do this and spoke to our manager about it as well. This has been going on long before I came on board.
Is there ANY way that I could block this from being ran against prod through security?
May 25, 2011 at 9:26 am
Found this over on StackOverflow.com that might work and lead you to a solution.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
May 25, 2011 at 9:34 am
In the very slight chance you guys had considered that option. Have you tried uninstalling the files (or even hard delete)?
Suspension with no pay agreeed by HR might also help here.
May 25, 2011 at 9:55 am
Ninja's_RGR'us (5/25/2011)
In the very slight chance you guys had considered that option. Have you tried uninstalling the files (or even hard delete)?Suspension with no pay agreeed by HR might also help here.
If I can't deny access based on the app name, then I may have to try your option 1 and/or 2.
May 25, 2011 at 9:58 am
SkyBox (5/25/2011)
Ninja's_RGR'us (5/25/2011)
In the very slight chance you guys had considered that option. Have you tried uninstalling the files (or even hard delete)?Suspension with no pay agreeed by HR might also help here.
If I can't deny access based on the app name, then I may have to try your option 1 and/or 2.
My issue with it is that if you kill periodically then possibly DTA will auto-reconnect.
And I'm not 100% sure you can have a logon trigger that blocks this, tho I'd investigate.
May 25, 2011 at 11:47 am
SkyBox (5/25/2011)
I work with an unruly developer that always runs DTA against our production databases during prod hours. I have asked him several times not to do this and spoke to our manager about it as well. This has been going on long before I came on board.Is there ANY way that I could block this from being ran against prod through security?
Don't try to fix management/personnel problems with technical solutions. What he's doing is hindering the business, slowing the applications, in some places that could be considered sabotage. Speak to management, speak to HR.
I used to have a couple developers who thought they were above the rules (connecting to a production server at a bank using an application's account and making data modifications without authorisation). They changed their tune when they were issued a written warning from HR and notified that what they are doing was clearly defined in the IT policy as a dismissable offence and that next time they were caught they would be dismissed on the spot.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 25, 2011 at 12:56 pm
SkyBox (5/25/2011)
I work with an unruly developer that always runs DTA against our production databases during prod hours. I have asked him several times not to do this and spoke to our manager about it as well. This has been going on long before I came on board.Is there ANY way that I could block this from being ran against prod through security?
Sure, remove developer access from production.
Without going into too much detail, I've had issues like this in the past. No one seemed to think anything was an issue, until I showed management a report of all the database objects that were now out of sync with source control because of people with elevated privlidges "helping" out and making changes directly in production. Once management put there heads back together (due to to head explosion), they authorized me to cut everyones permissions.
Heck I don't even want production premissions, but such is life.
To echo what Gail said, if you cannot simple remove their access, then you need to get managment involved.
May 25, 2011 at 1:09 pm
NM. Quoted instead of edit
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 25, 2011 at 2:38 pm
Ninja's_RGR'us (5/25/2011)
My issue with it is that if you kill periodically then possibly DTA will auto-reconnect.
Another issue is that this could leave hypothetical indexes in the database. I'm not aware of any bugs around this currently but there was one in 2005 where it would cause the optimizer to think some stats needed to get updated and issue an update then because stats don't get updated on hypothetical indexes it would enter a loop of just continuing to update the stats.
May 25, 2011 at 2:58 pm
cfradenburg (5/25/2011)
Ninja's_RGR'us (5/25/2011)
My issue with it is that if you kill periodically then possibly DTA will auto-reconnect.Another issue is that this could leave hypothetical indexes in the database. I'm not aware of any bugs around this currently but there was one in 2005 where it would cause the optimizer to think some stats needed to get updated and issue an update then because stats don't get updated on hypothetical indexes it would enter a loop of just continuing to update the stats.
Yup, my whole point there is you don't know the side effects so use as absolute last resort... I preffer whacking the .exe file than going down that road, but HR is definitely the way to go here.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply