March 3, 2005 at 12:51 pm
Needed: a tool to allow non-DBAs to do production database updates safely without installing the sql client tools or adding them to the sysadmin group. Ever heard of such a tool?
For now, we have a configuration manager running database update scripts from Query Analzyer, rather than the DBA doing that. Not my preference, so I'm looking for a GUI that would connect with sufficient permissions but only allow the user to run approved scripts, not just anything they want to type into query analyzer.
Randy
March 3, 2005 at 1:51 pm
I guess question 1 is What kind of UPDATES? Data or Structure?
IF Data I would create stored-procedures and then GRANT EXEC to them (and only them) and as long as ownership chain is not broken that should suffice
IF Structure WHY would you want these done without DBA involvement or approval??
Good Hunting!
AJ Ahrens
webmaster@kritter.net
March 3, 2005 at 4:19 pm
Both data and structure updates. There is some DBA oversight ( too long a story to tell here ) Bottom line is the person running these are now in the sysadmin group so I would like to have any/all sql tools removed from their workstation including osql. If they can run a stored procedure, presumably through query analyzer, they can also run "drop database" etc.
I'll google for a ready-made tool. The idea is for a DBA to type in the connection string ( username password ) so the tool can connect to sql with needed permissions, but the tool presents ONLY the option to run an approved script.
Randy
March 7, 2005 at 6:32 am
What if they just Terminal Services onto the SQL server and run the tools anyway? Because they are domain or enterprise admins, they can do whatever they want - it just takes a little longer...
March 7, 2005 at 6:59 am
In our environment, being a member of the sql sysadmin group does not mean you are a domain admin or even a local admin on the sql server box. Terminal services to the production sql boxes is blocked for all but the network/domain admins. Actually I think I read that term svcs to a sql box in a cluster is bad.
In any event, our situation is evolving. What I'd like to see is the "acting DBA for backups and disaster recovery" ( me ) move into the IT department so the network admins feel they can trust me more.
Having a "Configuration Manager" do database updates seems weird, especially when there is no indication the CM is sql trained or likely to become a DBA. I think that person should manage code releases and have the DBA staff do the database updates.
For now the two lead developers on our new .net sql application handle DBA duties related to indexes/performance and schema updates ( which are then implemented by the CM).
I'd love to hear reports on what are industry standards today for such a .net environment. That is, is my environment becoming the norm where a whole application/database environment is developed without even having a DBA? What of this configuration manager role -- never heard of it until a year ago. And what of developing a VERY HIGHLY normalized sql database with Visio??? The queries/procedures that you get have NUMEROUS joins and there are so many constraints that doing anything is difficult.
I'm not trying to advocate denormalization, but how much is too much? I think this extremly complex database schema is the result of non-database people creating the database as if it is just some storage box. Is Microsoft advocating this approach with the whole database "object modeling" approach?
Randy
March 7, 2005 at 8:38 am
Both data and structure updates
It is my opinion that the UI really does not matter. you can even create a script with osql and run it using a pointer to the file that contains the approved script, but if that login has permissions like db_owner they would still be able to run anything they want like "DROP TABLE"
It is my experience that such changes should be performed either by DBAs or App support service people the latest must be with an automated tool msi style
HTH
* Noel
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply