SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Developers as sysadmins / no DBA / a trend?


Developers as sysadmins / no DBA / a trend?

Author
Message
Indianrock
Indianrock
SSCommitted
SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)

Group: General Forum Members
Points: 1994 Visits: 2371
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.



Animal Magic
Animal Magic
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1618 Visits: 13731
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.
Indianrock
Indianrock
SSCommitted
SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)

Group: General Forum Members
Points: 1994 Visits: 2371
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.



GSquared
GSquared
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23767 Visits: 9730
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
Loner
Loner
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3592 Visits: 3351
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.Tongue
And for sure one thing you learn a lot more about SQL Server.
Kenneth.Fisher
Kenneth.Fisher
SSCarpal Tunnel
SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

Group: General Forum Members
Points: 4326 Visits: 2033
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 Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
Matt Miller (4)
Matt Miller (4)
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12409 Visits: 18576
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?
Loner
Loner
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3592 Visits: 3351
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.
ALZDBA
ALZDBA
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12326 Visits: 8928
search the SSC forums "developer sysadmin" and you'll find many hits .

Johan


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


- How to prevent a sore throat after hours of presenting ppt ?


press F1 for solution, press shift+F1 for urgent solution :-D


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me Alien but most of the time this is me Hehe
matt stockham
matt stockham
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1162 Visits: 3178
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search