Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Organizations With No DBAs


Organizations With No DBAs

Author
Message
arbarnhart-780010
arbarnhart-780010
Grasshopper
Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)

Group: General Forum Members
Points: 18 Visits: 60
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 Smile )...

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? BigGrin
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)

Group: General Forum Members
Points: 44962 Visits: 39862
Loner (9/19/2008)
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.


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.


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. BigGrin

So 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. Smile

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.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
     Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)

Group: General Forum Members
Points: 44962 Visits: 39862
Alvin Ramard (9/19/2008)

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?


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. Smile

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. Tongue 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 will 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.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
     Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
arbarnhart-780010
arbarnhart-780010
Grasshopper
Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)

Group: General Forum Members
Points: 18 Visits: 60
Jeff Moden (9/19/2008)

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. BigGrin

So 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. Smile

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.


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? Smile ). "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...
Anipaul
Anipaul
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

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

Smile



dave1982
dave1982
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 Visits: 105
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.
DPhillips-731960
DPhillips-731960
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: 1158 Visits: 801
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 is 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 inadequate, 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 great 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.
David Burrows
David Burrows
SSCertifiable
SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)SSCertifiable (8K reputation)

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


Ermm Wonder which side of that fence I am Jeff Blink

Since I am a developer (this day and age it's too de rigeur to call yourself a programmer Tongue ) 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


Far away is close at hand in the images of elsewhere.

Anon.


Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)

Group: General Forum Members
Points: 44962 Visits: 39862
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 never been "just" a Developer... Smile

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
     Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Caleb-142520
Caleb-142520
SSC Rookie
SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)

Group: General Forum Members
Points: 30 Visits: 196
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. Smile

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