Block the DBA?

Question

Block the DBA?

Viewing 7 posts - 16 through 21 (of 21 total)

You must be logged in to reply to this topic. Login to reply

yousef Ekhtiari Ten Centuries Points: 1293 More actions · Answer 1

quote:
You can use the ALTER TABLE command to disable and enable triggers. Also you can use sp_trigger created by Rodrigo G. Acosta. Its in the SQLServerCentral scripts area at: http://www.sqlservercentral.com/scripts/contributions/484.asp

thanks ,but I want to restrict other DBA from performing Dropp triggers against the table.any idea like this article is needed.

DKC Old Hand Points: 325 More actions · Answer 2

I have read this article before, and while it provides useful information, it is in poor taste especially when IT departments all over the world are struggling to keep systems running. Giving ideas to 'rogue' database developers and DBAs only increases the complexities of disaster recovery. When we are all struggling to keep new virii at bay, do we really need to add more sorrow on our desks?

--

rustroot1 Mr or Mrs. 500 Points: 560 More actions · Answer 3

Is there really such a thing as an "unknowledgable DBA"?

The techniques explained while "illegal" could be put to good use for a small IT shop. I don't see this as being practical for large IT shops.

Also, these techniques are also unnecessary if the "real" DBA's have control of a system and know how to grant proper access to the database. In the IT shop I work for, developers and "departmental" DBA's have to justify their security requirements to the database. We don't hand out sysadmin privs unless there is no way around it. Of course this is only possible, if the DBA's are given the authority to make these decisions.

Rusty

jmcgarvey Default port Points: 1489 More actions · Answer 4

Echoing some of the previous post, very interesting, very dangerous. Thanks for including the disclaimer at the end however, I pity the poor well meaning DBA who tries some of your hints as he is reading the article.

I seems to me that as professional DBAs it is our job to protect the database and not give any inexperienced person a weapon of mass destruction. But then that's how some learn.

Again, some interesting thinking. It's always fun to think outside the box but remember the following: It's not that we shoot our selves in the foot so often that's amazing, it's amazing how fast we can reload.

Dave-345922 SSC Rookie Points: 40 More actions · Answer 5

First of all, thank you for getting me out of a serious bind!

Supported or not, when the choice is between losing your job because you can't track harmful changes to sysusers or losing it because you enabled C2 auditing or tried using the profiler and tripled the server count, I'll choose changing something MS fouled up or just plain forgot, any day.

If it breaks something - guess what: I'll remove it. I might even have to go get a backup tape.

The holy system stored procs and MSFT's undocumented practices do a good enough job of tearing up the system tables anyway, why shouldn't we get in on the fun? We might even prevent them from breaking stuff.

It's not like there aren't a couple of dozen third party application categories dedicated to following them around and cleaning up their messes.

And I have a slight problem with their defining objects in MY databases as THEIRS. Master, MSDB, Distribution, and the like are THEIR databases. The ones I create are MINE.

Again, many thanks, and if something breaks, I've never even heard of you. I was never here, nobody saw me, I've got an alibi; that's my story and I'm sticking to it! 😉

Michael Valentine Jones SSC Guru Points: 64818 More actions · Answer 6

The name of the article should be, “Get The DBA So Pissed Off At You That He Takes Away Your Access To Everything”, not “Let’s Play Block The DBA”, since it doesn’t actually stop the DBA from making changes.

Rodrigo Acosta SSC-Insane Points: 21261 More actions · Answer 7

great to see my scripts have been used! at least a looong time ago.