SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Sean Grinslade / Organizations With No DBAs / Latest Posts

RE: Organizations With No DBAs

Jeff Moden — Tue, 28 Oct 2008 20:57:55 GMT

Heh... then I'm about to make you incredibly jealous... we're phasing out the Oracle side of the house in my shop. I've died and gone to heaven! :)

RE: Organizations With No DBAs

Caleb-142520 — Tue, 28 Oct 2008 13:07:52 GMT

I like this article. The struggle you are talking about is very real. I especially agree with the "patience" that is required to bring in process control and stability. Sometimes when I walk in the door, I feel like the only person who wants to see this SQL Server environment run smoothly is me. I look at 30 servers running single disks and ask for another disk for each of the PROD boxes so I can at least split out the logs. "Sorry, we can't split the RAID and these servers have no more slots.." Okay, can we purchase a small mid-grade storage array? Connect me to the SAN? "Please describe your business need again..." Everybody has SA? All the developers login to PROD with dbo? Not a single prod server has a legitimate backup plan least of all a working DR? Yep. That's what you walk into. Your own boss, the manager of "ORACLE" (UPPER CASE) apps has no respect for your pc-dbms (small case) and doesn't want to spend a dime or a moment of time considering your proposals. However, I remember the fact that they plunked down $$$ for me to come in and clean it up, so they must want the pain that I bring deep down. :)Also, there is a delicate area where a Hybrid DBA assists with T-SQL or SSIS code review. I usually try to guide them to their own answers...

RE: Organizations With No DBAs

Jeff Moden — Mon, 06 Oct 2008 21:32:32 GMT

Dang! I'm not sure how it happened, but I missed the whole gambit of 9/22 posts! Very well stated, folks. Well done.And, you, Mr. Burrows, have [i]never [/i]been "just" a Developer... :)

RE: Organizations With No DBAs

David Burrows — Mon, 06 Oct 2008 06:47:20 GMT

[quote]p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.[/quote]:ermm: Wonder which side of that fence I am Jeff :blink:Since I am a developer (this day and age it's too [i]de rigeur[/i] to call yourself a programmer :P ) I have to design, build, tune, backup and monitor databases since we do not have a DBA :crying: ). I am not a DBA but everyone thinks I am :Whistling:We do have people that have been trained in some DBA duties but some duties are born out of necessity as I am somewhat protective (and to some degree affectionate) towards my databases. :hehe:

RE: Organizations With No DBAs

DPhillips-731960 — Mon, 22 Sep 2008 15:35:40 GMT

I find this article and the ensuing discussion highly entertaining.As a contract/consultant, I have quite often been thrust into the midst of small to mid-sized companies that seem to be nearly entirely bereft of DBA experience, or were brand new implementations in a formerly paper-driven company with some sort of a contact application. Most of my paying work has been paid from the need or want of the development side. I first cut my teeth on RDBMS design before I ever learned how to code any of the modern languages. Personally, I feel that every developer should learn this most common and fundamental data model before ever writing a line of code.It is mighty difficult to get an organization of any size to see light of value in a real DBA if they do not already have a sponsor for one. I have won the battle in a few places, but almost always as the sacraficial one. Basically I have had to leave or be going before the change would take affect. I have tried the soft TLC route, the golden sledgehammer route, and the "just live with it" route... but I cannot just live with it. Change is almost always painful, and sometimes, a position would come with too much pain and effort, to continue it. I don't fear leaving, and I don't fear staying... what I do evaluate is the "is it worth it to me to try". The phrase, "Tripping over dollars to pick up a dime" is something that I have seen far too applicable to organizations in many industries.What I would like to see is the compilation of success stories/senarios where "conversion" was made. I do agree with Jeff Moden where he noted that white papers and other peoples stories are not good tools for convincing others. I have experienced this in fact several times... the white papers and such have the MOST effect AFTER the hard test proof is sitting in front of the right nose(s). It [i]is[/i] very hard sometimes to not call a current situation bad names (like trying to explain why 2GB RAM on a WIN 2003 Server with SQL 2005 DB on core operations for a company is categorically [u]inadequate[/u], not to mention that reporting is running from the same box).Solutions may be specific to specific companies, but the mental mindset on the need of a real DBA in such companies is quite common, I think, and I think many would benefit from such a discussion. Things like having a Sponsor, a Champion, and a Technician (the DBA). A DBA cannot easily stand alone... s/he'd have to be perfect, awesomely right in every circumstance, and have a very hard shell, without being viewed as a bulldozer!It seems that in today's world, a [i]great[/i] DBA needs to have experience in Humanities and Psychology too. I dare say most DBA's never dreamed they would have to learn to work the corporate psychology in order to be successful and effective. Most that I know are better known in the back rooms, not mingling in the corporate mindset.

RE: Organizations With No DBAs

dave1982 — Mon, 22 Sep 2008 07:35:02 GMT

As a developer who has been given the role of DBA in the past the first thing I made very clear to my new job is that I am not a DBA I may know a fair bit about SQL server but I am not a DBA and nor do I want to be one.I am very keen on doing things properly and have worked in environments both with and without DBA's I must say the one with the DBA wins every time.I left my last job because I was never allowed to improve anything because that wasn't seen as being profitable they just wantedmud slung at the problem and hope that it stuck. They would spend more upgrading the servers or constantly doing things like splitting databases over different raid controllers to improve disk performance. Why was the disk performance so poor because the code was utter rubbish. Every time I suggested tuning any of the stored procs I was met with a stern no just fix the bug don't tune anything. 90% of the bugs were performance problems!! It was like a brick wall I would have given alot for a DBA to back me up!!Anyway now I am back to the safety of code. I do try and find best practice at all times using design patterns for my OO code and try my best to optimise my SQL. I admit I don't know all the answers always admit this to my management and always show a willingness to learn this is the only way I can get better and I will.

RE: Organizations With No DBAs

Anipaul — Sun, 21 Sep 2008 23:19:55 GMT

There are lot of companies who do not have DBA's. Some of them have tie up with others to maintain their database but some them rely on 'amateurs' in DBA line. They do not understand the 'value' of DBAs unless they loose millions of dollars. Jeff and others already pointed out some important points on these. I just want to know why they look at DBAs blindly despite DBAs saves millions dollars for their company.:)

RE: Organizations With No DBAs

arbarnhart-780010 — Sat, 20 Sep 2008 04:05:15 GMT

[quote][b]Jeff Moden (9/19/2008)[/b][hr]No... hiring a DBA would solve the problem. The hard part, it appears for most managers, is actually finding a DBA and not some cowboy that thinks (s)he is because they know how to install the Developer Edition. :DSo far as getting people to listen and learn, you sometimes have to use a "bat" in the form of before'n'after code. If you cannot prove what you say, what you say is not proof and few will listen without proof especially if your way is on the fringe of innovation or effectiveness. And, "white-papers" and forum posts are not proof. [b]Only code or demonstrably hacking lame security is proof.[/b] :)Everyone has had managers that would rather get it done in a hurry instead of doing it right. You've got three choices there, too. Proof of the ROI of good code, do what they say and smile even if artificially (I never do that if they're wrong), or get out of the company.[/quote]Absolutely correct. I have often given up on resolving something in meetings and just said "I gotta do something even if it's wrong." Challenge my ideas and we can easily get into a stand off. Challenge my code by demonstrating an alternative and the results can be measured objectively. Developers have an inherent distrust for people who talk or write about how the code should be written but don't write any to prove it. You still have to be wary of code loyalty - a sorry waste of emotions IMO. People will come up with some pretty lousy reasons not to change code even in the face of evidence. "It's easy to understand and better for future maintenance." (You mean like changing it now? :) ). "Your code depends on observed behavior" (Duh! The whole point of benchmarking is to observe behavior). That sort of thing is one of the issues that caused me to step down from management. When code isn't right you can correct it and it stays fixed. People are different...

RE: Organizations With No DBAs

Jeff Moden — Fri, 19 Sep 2008 22:11:41 GMT

[quote][b]Alvin Ramard (9/19/2008)[/b][hr]So how do fix this problem?Should we work together to find a bunch of resources/white papers that we can present to management to should them what they're doing wrong?[/quote]No... paper means nothing... Resources mean nothing... Not when someone has dug in on being right. :hehe: The proof is in the performance of the code and the server. If you cannot prove the ROI of doing it right or, even if you can prove it, if managment cannot see the ROI, then it's time to prepare a different white paper... a resume. Find a job where people actually care about the data. :)And, no... I'm not giving any advice that I haven't personally tried. It's pretty spooky, sometimes, but if you have the "hair" for it and time things correctly, you'll do very, very well. Remember... they can't eat ya. :P But too many people think they can and they simply give up.If you like your job and you've been put into the position of DBA by osmosis, then you need to spend some serious time finding out what's right. Don't give me the ol' "I have a life"... you have a job and if you can't do it, they [b]will [/b]find someone else. Spend some time studying especially on forums like this one. Make Books Online your friend. And, practice, practice, practice. Just think of it as "going back to school" and you'll do fine.

RE: Organizations With No DBAs

Jeff Moden — Fri, 19 Sep 2008 21:57:27 GMT

[quote][b]Loner (9/19/2008)[/b][hr][quote]Developers aren't any worse than anyone else... they just don't know what they don't know. You're well ahead of the game... you, at least, are willing to admit that you don't know about some things.[/quote]Yes at least some developers are learning because we have no choice.However on the other hand some DBAs think they know everything and refuse to listen and learn. What is worse? A good developer in house of a bad DBA ?????Just hiring a DBA in house does not solve the problem, it depends on that person's skills and knowledge. If the person who interviews to hire a DBA and does not know anything about database, the chance is the company will hire a doofus as the 'wonderful' DBA.[/quote]No... hiring a DBA would solve the problem. The hard part, it appears for most managers, is actually finding a DBA and not some cowboy that thinks (s)he is because they know how to install the Developer Edition. :DSo far as getting people to listen and learn, you sometimes have to use a "bat" in the form of before'n'after code. If you cannot prove what you say, what you say is not proof and few will listen without proof especially if your way is on the fringe of innovation or effectiveness. And, "white-papers" and forum posts are not proof. Only code or demonstrably hacking lame security is proof. :)Everyone has had managers that would rather get it done in a hurry instead of doing it right. You've got three choices there, too. Proof of the ROI of good code, do what they say and smile even if artificially (I never do that if they're wrong), or get out of the company.

RE: Organizations With No DBAs

arbarnhart-780010 — Fri, 19 Sep 2008 11:43:54 GMT

Don't worry about me; I am cocky enough about what I do well to take a beating on what I can't without wincing (much :) )...I have learned a few things:Cursors are dynamic by default and if you mess with the table(s) in the result set inside a fetch loop, you will alter the records being returned, possibly skipping some or seeing some mutliple times.Once you figure that out and make the cursors static, then you will find out they are dog slow anyway and you have to remove the code you finally got working.When you replace that loop with a SQL statement about a mile long with a bunch of joins in it, don't mess around with it unless you know what you are doing. SQL Server seems to know how to optimize a bunch of related tables joined together on key fields, but when you get clever with subqueries and using foreign keys in the where clause instead of joining to make the SQL look simpler to humans, it won't get optimized as much.Indexes are your friend.Bulk operations rock! No matter how complex it is, you will very rarely encounter a situation where two or more simpler statements execute faster than one beast.If you don't add an exception handler to your stored proc, Visual Studio debugging will not show you when errors occur.If you don't specify the collation sequence when you install on a foreign language machine, you will be punished.Can I be a DBA now? :D

RE: Organizations With No DBAs

BobSaint — Fri, 19 Sep 2008 11:11:53 GMT

arbarnhart - you hit the nail on the head. When you say, "...but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is." You exemplify the nature of the problem. If you have a complex query, there is a very good chance you could write it three to four different ways - and produce the exact same results. ONE of those four ways will be most efficient. I have personally re-written stored proc's that have performed anywhere from 2 to 100 times faster simply by looking at a few execution plans, understanding how the engine goes out to get the data and re-writing the code to be more efficient, make better use of stats and indexes, and before I propose any index restructuring.Don't get me wrong - I applaud your honesty as much as RBAR and I certainly don't knock you for trying. After all, what choice did you really have? :) I just couldn't resist quoting you on this because I think that this approach to TSQL coding is very common and it furthers my point: SQL Server certainly won't raise an error if you construct code that is technically "legal" but terribly inefficient. It will dutifully try to execute it the best it can, churning away for minutes or hours if necessary until it completes or becomes victim of deadlock or connection timeout or gets killed by somebody like me! ;)

RE: Organizations With No DBAs

Shah_hs — Fri, 19 Sep 2008 11:11:47 GMT

I personally experience this one time. I was appointed by a mid size company (50+ employees) where there was never DBA appointed in their history. I did knew this during interview but i accepted the challenge. During my first few days i figured out that there were zero security in terms of database access. Everyone from IT and few Non IT staffs were given sa password. When i did bring this concern to my manager, he did not paid much attention to my words. I also found out that the non DBAs used to work on databases and since they were totally aware of database principles and concepts, they anyhow maintained the database on server without any constraints, rules, security, etc. I was shocked and very disappointed to see this. But every time i did showed my concern no one gave much importance and i was advised that i should manage with the existing environment. After some time, i decided to note down all the points and submitted to my mgr with my concerns and then left the environment as it was before. I did my job anyhow.In today's business there are few companies which do not understand the difference between DBA and Database Developer. Such companies many time hire DBAs for development work and the DBA end up doing something which he do not want to do all the time. Thats IT'Thanks,Hemal Shah : DBA

RE: Organizations With No DBAs

Shah_hs — Fri, 19 Sep 2008 11:11:31 GMT

RE: Organizations With No DBAs

BobSaint — Fri, 19 Sep 2008 10:04:54 GMT

Wow, I could expound for hours on this one. And what excellent fodder for a forum of experienced DBA's who have "been there - done that". There have already been some excellent replies on this article so I won't won't relate the volumes of my own experiences on this subject - the several times when I've been called in to "rescue" the work of some wannabe DBA that has propagated a house of cards and bolted, or the work of a bevvy of programmers that have pounded-in some application with schemas and code that could only be considered server abuse. There are just a couple of points I wanted to chime in on:[i]Anticipate [/i]the misconceptions toward your expertise and the value of the work that you do, and evangelize SQL best practices with kid-gloves and lavish diplomacy. You must never report your findings to any member of your client company with words like, "this code is awful" or "this is just wrong", even if you speak the terrible truth. Strive to teach and bring them over to your side by shining a light not so much why their way is wrong but why your way is better. If you're as good as you say you are the reasoning you provide will become abundantly clear to them, and will smooth the way toward reception of your ideas, even if there is some cost involved (which of course, is almost always the case!). Nobody wants to hear that their work (or even the work of a former employee) was of poor quality, even if that is obviously the case and is directly attributable to the reason you're here. You must take on the role of salesman, teacher and diplomat as much as SQL guru, and with any luck the thought bubble will begin to form above their heads, "Hey, maybe it really [i]does [/i]take a specialist to keep the back-end healthy, protected, available, agile, etc."The other thing I wanted to say is that the reason this scenario is so common is certainly at least partly Microsoft's fault. In short, they've made it very easy to build a bad database. When you look at all the "vigilante" data storage projects out there built with Access, Excel files and build-and-forget SQL databases and the fact that many of the tools are largely GUI-based and very intuitive, this scenario is indeed, almost inevitable. [b]Every [/b]business of every size and description needs to store and retrieve data, and they will of course want to do it in the cheapest, fastest and easiest way possible. This combined with the fact that almost every IT discipline requires at least [i]some [/i]training in SQL Server, which means that every programmer out there will at some point hear the words, "can you build the back-end for us?" and consider him/herself perfectly capable of doing so. This is not to say that a well designed schema cannot be built by a programmer, but at some point during the life span of that solution (if it makes it to production) I can almost guarantee that it will need a good DBA to make sure it is well protected, scales properly with growth, well tuned and highly available down the road. And of course we can only hope that the original author anticipated the need to do all these things in his/her original design! ;)

RE: Organizations With No DBAs

Jeffrey Irish — Fri, 19 Sep 2008 09:56:52 GMT

All bashing aside, we all know that there are exceptional DBA's and Developers, just as there are horrible versions of the same.If I had my choice, I would rather have a good Developer, one that understands the structure of the database, be a dedicated DBA than to have a bad DBA. However, what I have have commonly run into, hence the "inmates running the asylum" crack, is personnel pulling double or triple duty. They are the developer, database architect, DBA, and QC Analyst. All of the changes they are making work just fine from their perspective, all we need to do is throw more hardware at it (Vista anyone?)Yes, I realize that something this is the necessary evil in the world of low-ball budget IT, but it dumps the ability to deal with controlled change. I find it works out a little better when there is a team to build in some checks and balances so that you are not running into the situations that Jeff Moden was talking about.I'm sure that we have our share of horror stories. I cannot share because of confidentiality agreements, but I have had my share. :w00t:

RE: Organizations With No DBAs

Alvin Ramard — Fri, 19 Sep 2008 09:55:26 GMT

So how do fix this problem?Should we work together to find a bunch of resources/white papers that we can present to management to should them what they're doing wrong?

RE: Organizations With No DBAs

Loner — Fri, 19 Sep 2008 09:24:26 GMT

[quote]Developers aren't any worse than anyone else... they just don't know what they don't know. You're well ahead of the game... you, at least, are willing to admit that you don't know about some things.[/quote]Yes at least some developers are learning because we have no choice.However on the other hand some DBAs think they know everything and refuse to listen and learn. What is worse? A good developer in house of a bad DBA ?????Just hiring a DBA in house does not solve the problem, it depends on that person's skills and knowledge. If the person who interviews to hire a DBA and does not know anything about database, the chance is the company will hire a doofus as the 'wonderful' DBA.

RE: Organizations With No DBAs

Jeff Moden — Fri, 19 Sep 2008 08:56:31 GMT

[quote][b]arbarnhart (9/19/2008)[/b][hr][quote][b]Jeff Moden (9/19/2008)[/b][hr]p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.[/quote]A lot of us suck at it (playing DBA) and know it, but really aren't given much choice. Then we get defensive when someone is hired to come in and reveal that we are idiots. I used to be the manager in my group and I stepped down because I'm not good at that. I didn't want to have the project fail and get fired because I wasn't competant in that position when there was lots of work in areas that I excel in. But I can't step down as DBA; as bad as I am at it, no one else cares enough about it to do a better job (plenty of guys wanted to be manager; more power to 'em). I can do complex logic and I have written some pretty scary stored procs, but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is.[/quote]I absolutely love absolute honesty... thank you for that. That's pretty much what I was talking about. Developers aren't any worse than anyone else... they just don't know what they don't know. You're well ahead of the game... you, at least, are willing to admit that you don't know about some things.What's bad is the managers that do the same thing as you've admitted to... the part about "choose which way to do something based on how long it will take to code". Many managers really don't understand that "If you want something really bad, it normally turns out that way." :PThank you very much for the feedback. I value honesty/integrity probably more than anything else... if I were in a position to hire you, I would.

RE: Organizations With No DBAs

arbarnhart-780010 — Fri, 19 Sep 2008 08:47:13 GMT

[quote][b]Jeff Moden (9/19/2008)[/b][hr]p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.[/quote]A lot of us suck at it (playing DBA) and know it, but really aren't given much choice. Then we get defensive when someone is hired to come in and reveal that we are idiots. I used to be the manager in my group and I stepped down because I'm not good at that. I didn't want to have the project fail and get fired because I wasn't competant in that position when there was lots of work in areas that I excel in. But I can't step down as DBA; as bad as I am at it, no one else cares enough about it to do a better job (plenty of guys wanted to be manager; more power to 'em). I can do complex logic and I have written some pretty scary stored procs, but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is.

RE: Organizations With No DBAs

Jeff Moden — Fri, 19 Sep 2008 08:28:31 GMT

p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.And, I forgot a very important point in my "rant" above... on that 24 hour dupe check that I rewrote to run in 15 minutes and do 50% more work? I did a little research on how long it took to develop the "bad" dupe check using "Agile" methods... it took 2 developers a week each and that didn't include acceptance testing. It only took me 20 hours from the time I started until I delivered the final UAT tested product. Not bad for an "old style DBA", huh? :P

RE: Organizations With No DBAs

Jeff Moden — Fri, 19 Sep 2008 08:17:06 GMT

Heh... most of the companies that have hired me to fix things, have rooms full of developers that hate "old style DBA's" or think they know things like what Agile programming really is. The reasons the companies hire me is always the same... the system is not maintainable... the system and the related apps are too slow... they keep loosing data... it takes too long to deploy new apps... it takes too long to even find a problem, never mind actually fix it... when people leave, the learning curve for new hires is too steep... they run out of disk space... backups take way too long... etc, etc, etc. And, they don't even know what a deadlock is never mind fixing and preventing them.Jeffrey Irish probably said it best above... having developers, whose only goal in life is to get the job done no matter what, because the boss said so, IS very much like having the "inmates run the asylum". If you think that having a traditional hybrid DBA interferes with Agile development, you're absolutely incorrect... getting the hybrid DBA's involved in Agile Development is the best thing you could do because they can make things happen more quickly because they know the system 100 times better than most developers and they can do it with great fore thought to prevent problems in the future simply because of their knowledge and experience.Would you let a person who maintains go-carts and has never seen the guts of a Ferrari tune your Ferrari? I wouldn't think so... and you certainly wouldn't use the same fuel in the Ferrari as you do the go-carts.Databases aren't just a place to store data... they are an engine and it doesn't matter how many bell's and whistles you hang on the mirror of a car, if the engine doesn't work right, the car goes no where fast or, worse, may leave you stranded where you can least afford it. It's the same with every business... the data is the only thing that allows a business to stay in business. Protect it. Let (hell, INSIST) the DBA's do their job even if you think it's not "Agile"... they might even save your agile butt in the process. ;)Two of my favorite examples of what I'm speaking of follow...When I arrived at my previous job, they had an average of 640 deadlocks PER DAY with spikes to as many as 4000! Customers were constantly complaining about the "deadlock victim" messages they were getting. Management and the developers had been working on the problem for months. They even called in so-called "experts" that told them to convert all of their cursors to Temp Tables and While Loops, which they spent a huge amount of money and time doing. The deadlocks never waivered... maybe even got a little worse.The System DBA's knew exactly which routine was causing the problem. It turned out to be a very simple "GetNextID" routine that would get the next PK ID for a group of tables from a "sequence" table. We made a very simple change based on database best practices and a little known ability of the Update statement... the day we implemented the change, the deadlocks dropped almost to zero. Keep in mind that this was a problem that management and the developers had been working on for months and had expended close to a half million dollars on. Now, if the DBA knew so much about the problem, why didn't he fix it? Heh... he was told that he wasn't a developer and couldn't touch the code. They wouldn't even entertain his ideas. ;)My other favorite problem of this nature is a "dupe check" written in an Agile fashion by developers. The goal was to check 93 separate databases (1 for each day... another design by developers) to see if there were any dupes in a particular table in each database across all the databases. The table in each database contained anywhere from 3 to 6 million call detail records EACH. The developers designed a "system"... it took 24 hours to usually fail and they could only go back 2 months (62 databases) instead of the required 3 months (93 databases) because it just took too bloody long and there was a month-end SLA with the PUC and some of the financial departments that absolutely had to be met (interpret as huge fines if not met).After I totally rewrote the dupe check system, it would do all 3 months (93 databases) in 15 MINUTES! No, that's not a misprint... the methods I used brought a job down from 24 hours to 15 minutes all while doing 50% more work. And, it's NEVER failed in the two years that it's been in operation.Remember... the original system was built in an Agile fashion by developers... not DBA's.I've got hundreds of other examples... and the current job I've recently landed is no different. I'm working on some POP code (Proof-of-Principle code) to demonstrate a single stored proceedure that replaces an entire ETL subsystem. Their method currently takes 40 minutes for a particular type of file. My POP code currently takes about 90 seconds and that's without me looking for any tuning opportunities.If you think "old style DBA's" are contrary to Agile, you're just dead wrong. :D If you think they slow things down in the development process, you're probably right... it takes just a bit of time to do it right so you don't have to do it over and over and over every time there's a minor change in scalability requirements. While it's certainly an important consideration, the reduced "Time to Market" provided by Agile should NOT be the only consideration. :hehe:

RE: Organizations With No DBAs

blandry — Fri, 19 Sep 2008 08:02:48 GMT

One thing I have seen in my years in the business is that some companies don't really understand what a DBA is and why they need one. They hear the term "Database Administrator" and seem to think this is not any fulltime job - just someone to clean up messes and occasionally do a backup or two. When they find themselves in some crisis, they job out the DBA work and never think that so many hands in the "soup" might be hosing things up worse than they were before.I have also seen a couple situations where the DBA role is played by another employee. I worked at one company where the lead QA guy was the DBA, and another where the hardware support guy had the DBA responsibilities. In both of these situations things were a mess and of course, trying to play multi-roles meant stressed employees, requests going unfulfilled, and SQL Server itself often in abysmal states.But I have seen the flip-side as well - like the time I interviewed a "DBA" for a DBA position who didn't know what an Inner Join was. It's true! This fellow had been doing the SQL backups at his last job and therefore felt he was a DBA because he had been "administering databases".My Father used to say that the worst companies are successful companies because they presume that being financially successful implies that they have all the right staff, doing all the right things. I think this is true and the hard part is making it clear to upper level managers why the DBA role really is a fulltime role with plenty to do. Then there is the problem of ensuring that any DBA you might hire is really a DBA. I still occasionally interview developers who say they are also DBAs. When asked why they think that, the answer is usually that they wrote some stored procs, and did a backup, and therefore must be DBAs. ...to me thats like someone saying that they have once worn rubber gloves and carved a turkey, therefore, they are surgeons.

RE: Organizations With No DBAs

Indianrock — Fri, 19 Sep 2008 07:49:28 GMT

Last night was a classic case. I'm a data analyst ( DBA without the title I guess ) who generally is given the job of making sure backups and/or log shipping run. We use accurev, which I'm just learning as I migrate from our Legacy side of the house. A big build went out which involved a large amount of database work. This is handled by production support developers who are given sysadmin rights on SQL.I woke up this morning to find that the production sql server had been restarted several times ( probably by the on call Systems/Network person ). Since our SAN doesn't have enough space to keep two copies of the 350GB full backup, my sql job must delete the prior one first. The restarts killed the backup job so we went several hours with no full backup.I just emailed them that this must stop or we'll all be either in court or jail for exposing hundreds of clients to total loss.

RE: Organizations With No DBAs

arbarnhart-780010 — Fri, 19 Sep 2008 07:07:09 GMT

[quote][b]Indianrock (9/19/2008)[/b][hr]Some companies don't have a DBA on purpose. It's called Agile Development. Some experienced developers who are trying to follow agile development want to retain all control over the databases. Generally the network admins are clueless about this as is IT management. Agile developers have quite often dealt with "old style" DBAs in the past and don't want anyone or anything to block rapid change/development.In our case the developers are doing a fairly good job of developing a new product using .net with sql 2005 backend and even tune indexes etc. The main problem is the neglect of basic things such as disk space and disaster recovery.Typically developers assume the hardware will handle whatever is thrown at it.[/quote]I am a software developer in a situation we like to pretend is like that, but in our case, it's more like "frAgile Development" - RAD without much structure. We migrated to SQL Server because we outgrew Access and had too many problems with corrupt databases that could not be recovered. Guess what? It turns out that SQL Server isn't just a more capable version of Access. :DI am the closest thing we have to a DBA and I really don't have the experience to do it well - that's why I am here reading an article about companies that try to operate without a DBA. If I didn't have this site (and a few others, but 'Central is usually where I find the best information and scripts) I would be sunk. My post and visit count is misleading; I registered again when I was having trouble logging in and was in a hurry. I probably should lobby to get a "real" DBA in here for at least a short while to evaluate the structure of our database and make suggestions. Quite often I come here looking for a script to do something and find out I was taking a horribly inneficient approach and there is a better way to do it. I am sure there have been other times when I just found the answer and trudged ahead without realizing there was a better way. I am sure that a DBA who interviewed would know what he/she was getting into and wouldn't come aboard unless there was a way to fit into our model of doing things. We manage the database by pushing generated scripts into source management, with each developer using their own instance of SQL Express. A DBA could work on his/her copy and push scripts with optimizations up; I do that, but I miss a lot. Developers aren't DBAs. We aren't better or worse; we're focused on different aspects of the database and generally have a different midset. We need a DBA and it would probably be better to have had one here to get things right to start with, but more likely we will either do without or bring one in to clean up a big mess.

RE: Organizations With No DBAs

kenksoftware — Fri, 19 Sep 2008 06:54:07 GMT

I have worked in more than one situation where the initial database was designed by someone in the company who likes to program as a hobby. They usually start with Access and basically build tables to match what they had been doing in Excel. By the time they hire me the database looks like my worst nightmare. There are tables within tables and no data integrity and in one instance just 3 giant tables with no relationships between them. I've even seen an instance where a new database table was created to match the fields in each report (about 60) and the data was copied from one table to another so it was duplicated 60 times in the database. The main challenge I faced in all of these situations was just getting them to understand what a database is and to convince them that there is a better way. As this article points out they just want me to come in and fix it so they can continue programming the way they have been. This is definitely when you get the feeling of "being in the trenches" The one thing I have learned from these places is knowing when to say when. In some cases you simply cannot convince them there is a better way to do things or that it is worth the effort to redesign and re-write existing code. In one instance, after shooting down my suggestions for weeks we were in a meeting to discuss what our options were and they shot down everything I suggested in that meeting as well. The programmer who developed the database was certain that his design was use-able and we'd just keep working with it - although nobody else could access it or use it except for the guy that built it. When I knew that I was not interested in working there any longer I looked at him and said "here is all that I can recommend for your new reporting system" and slid my legal pad and a pen across the table to him.

RE: Organizations With No DBAs

Loner — Fri, 19 Sep 2008 06:41:07 GMT

I worked in a few companies that did not have DBA, some of them actually had over 100 people in their IT department. None of the company used Agile development. It was a matter of senior management did not think the position of DBA was not needed. In most cases the senior management thought SQL Server had all the tools that a developer would do the work as the DBA.So I am the DBA, database developer, data architect, data warehouse architect, data warehouse developer plus a few other responsibilities.I agree in most cases a DBA should be on site. However I also worked in a big company that had 3 SQL Server DBAs and 3 Oracle DBAs. I had to say the DBA were not very helpful and their knowledge was very limited.So it depended who you hire, a very good SQL Server developer could very well served the position of DBA, on the other hand, a very lousy DBA was totally useless.

RE: Organizations With No DBAs

Jeffrey Irish — Fri, 19 Sep 2008 06:30:26 GMT

I can play a couple of angles on this one as I have worked with both types of businesses mentioned in this post.There are those small organizations that have a skeleton crew of IT folks that handle everything from top to bottom. Sometimes this approach yields a savings, but I find the majority of the time it does not. More often than not these types of companies look to their vendors for support of "3rd party" products such as RDBMS's and in many cases Operating Systems. I have seen companies hire on a inexperienced DBA, mostly to save cost, in many situations and management of various areas use him or her as a mat on which to wipe their dirty shoes on. The project goes to hell and the DBA takes the heat.Large corporations sometimes will just hire someone to fill the position or in some cases just move someone from another area into the position of DBA. The key problem I have experienced with large corps is keeping everyone communicating together. There are so many projects, but so few lines of communication between projects that affect each other. If two systems have to share data via some kind of interface, the teams have to communicate or there will be problems. In these situations I have found DBA's are often getting dumped on and expected to immediately resolve issues without any prior knowledge.With regard to Agile Development and leaving Development retain full control of the database, this in my mind is like haveing the inmates run the asylum! :w00t: While being agile has its advantages, there are also many disadvantages. When you have a large team of developers all making changes to the Database at the same time you get a bloated, inefficient Database that is chock full of useless Indexes. Simply adding a Database Admin as the keeper of data and Architect of objects and change to meet the business plan will go a long way to heading off major performance issues.Does this mean that having someone who is designated as the DBA will prevent all types of problems? No. Early on in my DBA career I made mistakes, as many of us do, but that is how you learn.

RE: Organizations With No DBAs

Indianrock — Fri, 19 Sep 2008 06:04:09 GMT

Some companies don't have a DBA on purpose. It's called Agile Development. Some experienced developers who are trying to follow agile development want to retain all control over the databases. Generally the network admins are clueless about this as is IT management. Agile developers have quite often dealt with "old style" DBAs in the past and don't want anyone or anything to block rapid change/development.In our case the developers are doing a fairly good job of developing a new product using .net with sql 2005 backend and even tune indexes etc. The main problem is the neglect of basic things such as disk space and disaster recovery.Typically developers assume the hardware will handle whatever is thrown at it.

RE: Organizations With No DBAs

william woods-415265 — Fri, 19 Sep 2008 04:27:45 GMT

I agree totally with this advice. I've been in similar position in trying to establish standards and professionalism for companies who had small IT departments but had 'gotten by' with a lot of shortcomings and less than professional approach. Recently we downsized by 66% in our IT department and I decided to engage a third party for one week to upgrade our Backup and Anti-virus, and at the same time do knowledge transfer to my only remaining adminisrtator (who is more a DBA than a system administrator). Formal training wsn't available, and this way my guy got fast-track hands on experience that he didn't get before the other two staff left.

Organizations With No DBAs

ToDBAHereNow — Thu, 18 Sep 2008 22:53:09 GMT

Comments posted to this topic are about the item [B]Organizations With No DBAs[/B]