InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 00:45:16 GMT20http://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxThere's so much that has an impact in answering a query about "dev's as DBA's" that there really is no straight answer. I've found that companies need to grow large enough to warrant a DBA, and that many dev's can do a reasonable job of DBA work in the interim (though unfortunately, the reverse is not always true.)In my career I started off as a developer and made a conscious decision to follow a database-specific path. At one role after I just started I "met the team" of developers and explained my career history. One developer was bewildered that I would turn my back on VB and pursue databases. To them, this was akin to Anakin Skywalker turning to the Dark Side. (As Yoda might say, "Is that set-based logic I sense in you?") But therein lies, for me, a very important distinction in mindset. For a developer a DBMS can be reduced to a fancy flat file. Tables are just a form of TXT file, and SQL Server is just an Excel document with indexed worksheets.As for support, I'm not sure I'd agree with rotating DBA work. The fact that it's rotating suggests to me that no one really wants to do it, and if they don't want to do it then what sort of a job are they doing?S.Wed, 10 Feb 2010 19:11:15 GMTFalhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspx[quote][b]jtfromstl (2/9/2010)[/b][hr]...Most companies don't know they need a solid DBA - until - they need a solid DBA....[/quote]I would take that a step further. Many companies don't know they need a solid DBA - until they get one and see the difference it makes. Trying to have one person wear all of the Database hats is very difficult. A Database team is really what is best in many scenarios.Tue, 09 Feb 2010 17:48:16 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI started off as a DBA almost 15 ago and never wanted to learn Business rules and write a line of development code. I felt at that time to be a DBA was like messenger of the GOD. Times have changed I did a lot of DBA work and some performance tuning and little of DB Architecture over time. I finally found out that these years to grow with your Organization its good to be a good DBA/DBA_Dev/DBE/and Systems Engineering as many employers want a DBA to fit in the shoes of other engineering and development groups. Today, I have a lot more skill set to successfully manage a DBA/Engg group and also adhere to company requirements and regulations. Corner of my heart I still am a DBA(Da Backup Administrator), but I am able to bring a lot more to my management's table need based so I can keep my job.Tue, 09 Feb 2010 17:33:58 GMTViYeshttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxThe TERM DBA is used so loosely these days - no one is even sure what it means anymore.With 15 years of SQL under my belt (both on the admin and dev/design sides) and 25 years of app dev experience, along with a strong sprinkling of network admin duties - I'm here to tell you it's as simple as this.... Most companies don't know they need a solid DBA - until - they need a solid DBA.Most companies that figure this out too late suffer many issues before they hit bottom - and with varying degrees of hole depth - could take a long time to dig out.Most developers are just clueless on good database design, optimization, portability, etc. They can be as good as they want to think they are but nothing replaces experience.Tue, 09 Feb 2010 12:13:45 GMTjtfromstlhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxPlease read K.Brain Kelley's blog. He is a developer/DBA.http://blogs.sqlservercentral.com/brian_kelley/archive/2007/10/29/3075.aspxFri, 08 Feb 2008 08:28:31 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxSAS70 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.Fri, 08 Feb 2008 08:20:53 GMTIndianrockhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxDevelopers 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.Fri, 08 Feb 2008 08:19:41 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspx[quote]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.[/quote]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.Fri, 08 Feb 2008 07:57:02 GMTmatt stockhamhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxMy 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.Fri, 08 Feb 2008 05:55:24 GMTIndianrockhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxIn 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.Thu, 07 Feb 2008 23:01:21 GMTmatt stockhamhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxsearch the SSC forums "developer sysadmin" and you'll find many hits .Thu, 07 Feb 2008 14:40:05 GMTALZDBAhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI 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.Thu, 07 Feb 2008 14:27:59 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxAs "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.Thu, 07 Feb 2008 14:25:46 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxActually 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. KennethThu, 07 Feb 2008 14:12:59 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI 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.:PAnd for sure one thing you learn a lot more about SQL Server.Thu, 07 Feb 2008 11:46:08 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxThe 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.)Thu, 07 Feb 2008 11:31:41 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI 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.Thu, 07 Feb 2008 11:10:26 GMTIndianrockhttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI 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.Thu, 07 Feb 2008 09:45:43 GMTAnimal Magichttp://www.sqlservercentral.com/Forums/Topic452771-146-1.aspxI'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.Thu, 07 Feb 2008 08:18:17 GMTIndianrock