DBAs will always be needed even in such an environment of double-checks by change-control. Who else but a DBA could figure out that such things as you mention actually need to be done? ;-)
Tightening of such control over what the DBA does has appeared for several reasons. Some companies don't actually know how to interview DBAs to find good ones and they sometimes end up hiring a "wanna-be" that doesn't really know what (s)he is doing and they break stuff if left to their own devices. Even good DBAs break stuff because they may not be aware of the proverbial "bigger picture". To wit, it's impossible even for a great DBA to know absolutely everything about the server and the data and how it could impact the business. The "Change Controls" are just a method for forcing good and adequate communication and planning.
Now, chances are the stuff that you mentioned isn't going to have any impact on the data or worsen the performance of the server. However, the company might be ISO certified where everything has a process or maybe they just want to force people to communicate better. If you feel there's a need to do something, then you must be able to justify why it needs to be done to others, right? So take the time to do the justification. It can usually be done by just a simple paragraph that takes just minutes to write. If you need to do it more than once, write an addition to the company policy and cite it! If you're lucky, they will have a ticketing system for all such work. I say "lucky" because of all of the following...
Shifting gears a bit, think of all of this as a way to "CYA". If you get other people to sign off (which is the very nature of a "Change Control"), then you're not the only one holding the bag of steaming poo when something goes wrong. You won't have to justify and protect yourself by having to write lengthy proofs for stupid things like how it's just not possible that the reindexing you did on some low usage table just brought production to its knees (for example). It's also an opportunity to train people to think that you actually know what you're doing because you're able to easily justify everything you want to do and have done so by writting it into company policy!
This isn't a fault. It's a feature! One of the biggest problems that DBAs have is justifying their existence because most people have no clue what a DBA actually does other than schedule backups and chase the occasional slowdown or deadlock. It's an opportunity to document what you do without looking like a brown-noser. Will it take you longer to do these simple things? You bet it will and so what?! They're paying you to do it! Embrace the opportunity to document and tell people what you do every day! It'll demonstrate why it's such a good idea that they keep paying you to stick around!
If you're really smart, you'll open your own tickets and cite the company policy(ies) that YOU wrote thereby meeting both the letter of the law and making yet another entry in an easily queriable system that continues to justify your very existence!
If they don't sign off on it, then the ball is in their court if something goes haywire because it wasn't done!
My advice to you is to revel in this rare opportunity to demonstrate your ability to prioritize, take the right steps to maintain a viable high performance system, communicate effectively, work well with others, and prove your remarkable attention to detail!
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs