February 7, 2008 at 8:18 am
I'm wondering if others are seeing a trend towards developers retaining control/development of new database projects with no one who could be called a DBA on staff? ( even after developement is complete and it's in production ) In these scenarios I think a DBA would be viewed as an obstacle to what the developers want to do -- perhaps the DBA would resist adding developers to sysadmin, prefer stored procs over dynamic sql generated by an object, etc etc.
Our company has two sides, Legacy and "the new application." Legacy is web front end with combined foxpro/sql backend. The "new" is all .net C# with sql backend. From the beginning developers on the new side built the schema, code, everything. There is an architect but no DBA, very little use of stored procedures. I'm the closest thing there is to a DBA but I'm pretty much restricted to making sure sql jobs, backups and log shipping function. Production support on the new side is handled by one administrative type person and a developer who is given sysadmin privileges on day one. The developers rotate in and out of the support job about ever 6 months. They do run adhoc updates to fix data regularly as well as running freeprocCache regularly ( not sure why that should need to be run regularly ).
I advised giving this support developer "alter server state" instead of sysadmin but was overruled. I also suggested the developer work in prod support for a few months before being given sysadmin -- overruled again. Even the administrative person runs QA'd scripts to do production schema updates as dbo -- this person is not a developer or sql expert in any way. To me the risk on the "new" side is greater since so far all of our clients' data is now mingled in one database. In legacy, each client has their own database. We don't want to consider every employee as a menace, but isn't it good practice to assume the worst? Our SAS70 audits are becoming more aggressive as the company grows -- I wonder at what point they will dig into this sort of practice.
February 7, 2008 at 9:45 am
I guess it completely depends on the need of the business. If the company thinks that the developers can do enough of the DBA side of things (backups\indexing\query plans\performance monitoring\auditing plus loads more) then your probably ok with developers.
When it starts getting to a point when developers are spending most of their day doing admin tasks then its probably time to get a DBA, unless of course management are happy for the developer to not be developing.
In my experiance developers set things up and then leave them, possibly running the odd reindex job etc. I know this is a complete generalisation and many developers will also be awesome admins, but some are just developers.
Like i said at the start, it depends on the business.
February 7, 2008 at 11:10 am
I think the main point is that those who are developing, in a development environment ( where accidents aren't that big a deal ) should not be moved into a production environment and immediately be given God rights on production databases. It's not a matter of trust, it's sensible business practice and if most auditors can live with our practice something is wrong.
It's especially bad when the production support person is rotated in and out of production regularly and this person may have little sql experience. It may take an accident to cure them of this, then I'll be asked to put our log shipping standby server into production, assuming the data accident hasn't already shipped to the standby database.
February 7, 2008 at 11:31 am
The company I currently work for had a similar situation till I got here.
There was actually no admin on the databases other than automatically scheduled backups. No re-indexing, no/very little performance tuning, no index-use monitoring, no automated integrity checks, etc., just a daily full backup and hourly log backups.
The .NET devs wrote all of their own procs, views, etc.
The first database I started working on had lots of problems caused by this. These guys are good C# devs, but they know just enough about SQL to get into trouble, without knowing enough to get back out of it.
For example, there's a hierarchy table. Resolving it was being done by multiple recursive cursors. One day, about a week after I arrived, all the web pages started timing out. They quickly tracked the problem down to the ten or twelve procs that were crawling the hierarchy. The web timeout was set at 30 seconds, and the minimum run-time on the procs was now 35 seconds. This was three weeks after all of this code went live on the production server, and the quantity of data in the hierarchy table was simply too much for the procs to resolve. I changed it to a more efficient function, changed all the procs so they referenced the function (instead of each one crawling the hierarchy in its own unique way), fixed the indexes, and got the maximum run time down to 12 milliseconds, from 35 seconds minimum (one particularly complex hierarchy took 8 minutes to crash and never did finish, till I fixed it).
There were dozens of other implementations of a similar nature. I've got most of them fixed now. And I have automatic index and integrity maintenance going. Maximum and average run-time on queries are all way down.
It wasn't a question of me being in any way smarter or better or whatever. It was just that I know SQL better than they do. The procs they had written were very good at following procedural best-practices, and very bad at following SQL best-practices. Simple as that.
The IS manager is a good DBA and SQL dev, but he's too caught up in managing the team, interminable and innumerable meetings, etc.
(There are two more servers and six more databases for me to tame. Should be interesting.)
- 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
February 7, 2008 at 11:46 am
I am the developer/DBA plus data modelor and data warehouse experience. Most companies I interviewed for the past year had no DBA so one of their requirements were the candidate had to know DBA work liked performance turning, implementing federated database, data mirroring etc.
I was a developer before but I always did some DBA work which drove the DBAs of my old company crazy. They kept saying those were not my job.
Now I can do both.:P
And for sure one thing you learn a lot more about SQL Server.
February 7, 2008 at 2:12 pm
Actually I know a fair number of developers who became DBA's, or developer/DBA's. But a developer shouldn't be all of a sudden assigned the tasks of a DBA or you are going to run into issues. I've had to fix a fair number of DB/design issues over the years that were caused because while a developer may be a great developer .. that doesn't mean he is a great DB designer. They are 2 different skill sets.
I find it very interesting how a lot of members of management feel that its better to save money now by not having anyone with true DBA experience and don't think about the costs of improper development and potential crises in the future.
As an example of GSquared hadn't been at the company (or another DBA) the developers would have had a hard time fixing problem. Certainly fixing it as quickly/completly as GSquared did.
Maybe I'm just biased but I think having developers (not even someone who has experience with both) as a production DBA is just asking for trouble.
Kenneth
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
February 7, 2008 at 2:25 pm
As "both" a developer and a DBA, I find the position that anyone looking to implement solid practices for testing and roll-out as being "in the way of progress" disingenuous, especially when the developers have no issue implementing testing and rollout processes and using them for their OWN code. So test and debug your own app code, but deny the data folks the same opportunity? It just irks me that I hear so many developers with that very attitude.
As has been seen previously - there are new dynamics to look at when you move from the App code into the data code, so setting up a scenario where you have someone "moonlighting" as the DBA will likely end you up in trouble. At least - make it part of someone's job to keep an eye on things, even if he also has some dev work to do. Pretending that anyone can just pick it up and make good decisions is, well, not true.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 7, 2008 at 2:28 pm
I know a lot of production DBAs only know how to do backup and restore and not much else. I also know a lot of developers only know how to do 'SELECT * FROM table'.
The reason why many companies think they don't need a DBA is because they think SQL Server is pretty easy to maintain. Also maybe those companies do not have a lot of database and servers and do not need to do a lot of maintenance.
If a developer wants to learn DBA work or vice versa, there are a lot of books, web sites that provide learning materials. It depends on the person if he/she wants to learn.
February 7, 2008 at 2:40 pm
search the SSC forums "developer sysadmin" and you'll find many hits .
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
February 7, 2008 at 11:01 pm
In my experience, developers will create something that works (for a while) - but they aren't aware of best practises, optimisation techniques, different techniques of accomplishing something and the pros/cons of each etc. Down the line performance and perhaps security will suffer, and the app may not scale well without significant change.
Of course this depends on the developer - and some will take the time to learn the above and maybe become DBAs. But to learn it in 6 months is optimistic for anyone I think.
As far as SAS70 is concerned, we are just starting the process of certification - my understanding is that knowledge of how to perform a task isn't required, just an ability to implement, follow and document processes and changes (and also to have the appropriate security in place). Frankly this is a good idea for anyone, regardless of experience.
February 8, 2008 at 5:55 am
My point about SAS70 is that your customers want to know their data is safe with you and that you aren't adding people to roles like sysadmin without great care. Rotating developers into production support and giving them sysadmin while they are in production support just seems risky to me. The argument is that developers have the business knowledge to know how to work with what in our case is a very complex schema. The solution in my mind is to have more "permanent" production support staff, who are essentially long-term DBAs and include them in development meetings so they understand business rules and the table relationships etc.
In our case there never was a DBA involved so the database was created by Visio and is very highly normalized. It will be interesting to see how it scales.
February 8, 2008 at 7:57 am
My point about SAS70 is that your customers want to know their data is safe with you and that you aren't adding people to roles like sysadmin without great care. Rotating developers into production support and giving them sysadmin while they are in production support just seems risky to me.
Absolutely, however SAS70 isn't exactly a certification of competence to do the job - so it doesn't matter if the developer has the ability to do DBA tasks (perhaps they can just follow documented procedures when issues arise?), just that they have a true need to be given that access (obviously someone needs to provide support). As long as the number of people given the rights is kept to a minimum and other procedures followed such as removing someone that rolls off the support team, then it may not be a big deal. Having said that, separation of duties is going to come into the picture at some point - are there encrypted fields in the app that a dev knows how to decrypt, can they figure out another users id and password, are code reviews in place to ensure they don't add in a back door entry method etc. Issues like this can possibly be addressed through very strict formal processes but I doubt your auditors would be entirely happy with it.
February 8, 2008 at 8:19 am
Developers can make fine admins, they just usually don't. It comes down to human nature and it's because they're likely to make changes or fix things on the fly, with eternal optimism, and not necessarily follow production rules to ensure a stable system.
If you minimize rights, and can enforce your production rules, then this would be ok. The big thing here might be that a better auditing system would need to be in place to ensure that rules were being followed and short-cuts for expediency's sake, weren't being taken.
February 8, 2008 at 8:20 am
SAS70 has different levels of audit. This year ours was ramped up a bit and they did ask me who the sysadmins were ( at the instant anyway ) . Yes, the prod support developer is removed from sysadmin when he/she goes back to full-time programming, but there aren't really controls on who can add who when to sysadmin. To reiterate my concern, I don't like the rotation idea. Prod support ( which here is daily problem fixes, updates, reports -- NOT admin tasks such as monitoring log shipping ) should be handled by folks who plan to do that for a long time and have a PRODUCTION mind set.
It may all evolve from 1) technical management who aren't very technical, so they hire some people and turn over development of a whole new product to new employees and 2) they either don't know enough to get an experienced DBA or just don't want to pay for one.
A group of developers/data architects may not be at all interested in bringing in a DBA who is going to try and control them in any way.
February 8, 2008 at 8:28 am
Please read K.Brain Kelley's blog. He is a developer/DBA.
http://blogs.sqlservercentral.com/brian_kelley/archive/2007/10/29/3075.aspx
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply