March 29, 2012 at 8:15 am
Around here, our sys admins do most of the application upgrades & installs. All are vendor apps. Sometimes they upgrade an application, sometimes they install new sys admin type software for monitoring or whatever. If the upgrade/install isn't to a new sql server instance, I might not even be aware its happening. Sometimes these upgrades/installs create new dbs on an existing server. And nobody tells me. I stumble on them by accident. So whose job is it to let the DBA know a new db is now in the mix? Should I, the DBA be looking (daily?), or should I be told.
March 29, 2012 at 8:29 am
Yes, obviously they should tell you, but if they're not, bring the situation into your own control and approach it from a security/change control standpoint. There's no reason that Domain Admins should be sysadmins in SQL Server. So, make a proposal to lock down permissions and put a process in place for new DB's that has to involve you.
It's easy to sell this to a business as you can then document databases as they come in along with their owners and expectations about recoverability/uptime/backup strategy.
Seperate to this, every DBA should have monitoring of new DBs. My one is simply a daily backup exception report that highlights any databases that aren't included in a backup plan - new DB's jump to the top of this list, so it's easy to keep track of, even if something did get in the back door.
March 29, 2012 at 8:33 am
Control the environment.. By creating a NEW DB trigger and remove PUBLIC from any new DB created and or default the permissions so that you define when the db is released.. What san its on.. space allocated etc..
best of luck.. Seems like they have been doing this for a while now.
YoungHog
March 29, 2012 at 8:40 am
IMO you as the DBA shouldnt be told or not. You should be in full control creating and designating servers. Only you will know the load or judge where a DB is bestplaced or grouped.
Who's to say this new database isnt a resource hog and will grow to many GB or TB in a few weeks and effectively knock performance on other databases? What about backups and disaster recovery?
Bad, bad, bad idea and you should be responsible for full control. Too many reasons to list really.
March 29, 2012 at 12:59 pm
Yes, obviously they should tell you.
Thanks. I wanted confirmation before sending my sarcastic email to the sys admins. They all good folks and friends, just averse to communication. 🙂
Control the environment.. By creating a NEW DB trigger and remove PUBLIC from any new DB created
A DDL trigger is perfect. I haven't looked at them since being introduced in sql2005. I just wrote and tested one for create and drop database. I know if a db gets dropped because my backup job will fail and notify me. This allows me to be proactive. Can't remove Public permissions on a vendor app. Might stop it dead in its tracks. There's no guarantee the vendor apps are put together as tightly as you or I might do if we developed them.
You should be in full control creating and designating servers. Only you will know the load or judge where a DB is bestplaced or grouped.
In my environment, where all applications are from vendors, I have no control. A product is purchased because of functionality/price/etc... I have no say in that. Vendor says you need a server here this big, a server there that big, software is installed and off you go. Who knows the load until it starts to be used? We didn't write the code and couldn't change it if we wanted to. After you get a feel for it you can make some decisions... bigger/smaller server, consolidate/decentralize the back-end, etc...
Thanks everyone.
March 29, 2012 at 1:51 pm
You shouldn't be told, you're the best person to advise on server allocation, file locations, growth options, security etc etc. If they are just putting databases on servers, are they also setting up the associated maintenance plans to make sure the recovery options are covered?
The trigger is a great idea to find guilty culprits 🙂
'Only he who wanders finds new paths'
March 29, 2012 at 2:01 pm
Randy Doub (3/29/2012)
You should be in full control creating and designating servers. Only you will know the load or judge where a DB is bestplaced or grouped.
In my environment, where all applications are from vendors, I have no control. A product is purchased because of functionality/price/etc... I have no say in that. Vendor says you need a server here this big, a server there that big, software is installed and off you go. Who knows the load until it starts to be used? We didn't write the code and couldn't change it if we wanted to. After you get a feel for it you can make some decisions... bigger/smaller server, consolidate/decentralize the back-end, etc...
Thanks everyone.
I never said that. You are unlikely to purchase a new server per 3rd party product. Therefore you should be in full control regardless of who is responsible for the code. If it were me I'd find out how many concurrent users were to use the product, how much space it was likely to consume what the business decides is a suitable recovery model..... How can you live up to the DBA responsibilities without covering the basics? You can't implement any DR plan or plan for future capacity if you don't know what you've got
March 29, 2012 at 2:10 pm
Either a DDL trigger that sends you an alert, or a "DBA" database that can be used to log things like "have I set up maintenance plans and backups for X database", and alerts based on that.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 29, 2012 at 3:10 pm
How can you live up to the DBA responsibilities without covering the basics? You can't implement any DR plan or plan for future capacity if you don't know what you've got
Huh? I live up just fine. In my attempt to be brief I must given the wrong impression.
March 29, 2012 at 3:51 pm
Just my 2 cents and to reiterate some of what has already been said. Yes, they should tell you... but you shouldn't count on it. It should be in your "morning report" sent to you by the SQL Server(s). Of course, you have to build that pupply.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 29, 2012 at 4:14 pm
it looks to me like the Change Control processes of your organization are not really well designed.
In regards to existing database servers - you as a DBA should have control over them.
In regards to new servers that pop-up like mushroms - I being there - you should publish and get approval on a list of "supported" databases; what is not in your list does not exists. If a mushrom one day becomes important enough to make it to the list of supported databases, the first thing to do is to secure it.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply