Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Developers as sysadmins / no DBA / a trend? Expand / Collapse
Author
Message
Posted Thursday, February 7, 2008 8:18 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 1:19 PM
Points: 599, Visits: 1,717
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.




Post #452771
Posted Thursday, February 7, 2008 9:45 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 6:32 PM
Points: 1,001, Visits: 13,529
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.
Post #452820
Posted Thursday, February 7, 2008 11:10 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 1:19 PM
Points: 599, Visits: 1,717
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.



Post #452858
Posted Thursday, February 7, 2008 11:31 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Monday, November 17, 2014 12:50 PM
Points: 13,872, Visits: 9,598
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
Post #452868
Posted Thursday, February 7, 2008 11:46 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 7:42 AM
Points: 2,837, Visits: 3,114
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.
Post #452879
Posted Thursday, February 7, 2008 2:12 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 12:28 PM
Points: 3,467, Visits: 1,828
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
Post #452957
Posted Thursday, February 7, 2008 2:25 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 4:32 PM
Points: 7,154, Visits: 15,633
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?
Post #452963
Posted Thursday, February 7, 2008 2:27 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 7:42 AM
Points: 2,837, Visits: 3,114
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.
Post #452966
Posted Thursday, February 7, 2008 2:40 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:42 AM
Points: 6,743, Visits: 8,515
search the SSC forums "developer sysadmin" and you'll find many hits .

Johan


Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere

- 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"


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me
Post #452974
Posted Thursday, February 7, 2008 11:01 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Saturday, October 18, 2014 9:34 AM
Points: 754, Visits: 3,164
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.
Post #453073
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse