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 «««1234»»

Organizations With No DBAs Expand / Collapse
Author
Message
Posted Friday, September 19, 2008 11:43 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, June 23, 2010 7:04 AM
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 :) )...

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
Post #572738
Posted Friday, September 19, 2008 9:57 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:00 PM
Points: 36,789, Visits: 31,247
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. :D

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

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

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #572920
Posted Friday, September 19, 2008 10:11 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:00 PM
Points: 36,789, Visits: 31,247
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. 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 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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #572922
Posted Saturday, September 20, 2008 4:05 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, June 23, 2010 7:04 AM
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. :D

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

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? :) ). "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...
Post #572971
Posted Sunday, September 21, 2008 11:19 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, July 17, 2014 10:36 PM
Points: 5,308, Visits: 1,378
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.

:)



Post #573246
Posted Monday, September 22, 2008 7:35 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 4:39 AM
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.
Post #573492
Posted Monday, September 22, 2008 3:35 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, August 10, 2012 6:08 PM
Points: 1,156, 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.
Post #573887
Posted Monday, October 6, 2008 6:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:18 AM
Points: 7,056, Visits: 6,822
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.


Wonder which side of that fence I am Jeff

Since I am a developer (this day and age it's too de rigeur to call yourself a programmer :P ) I have to design, build, tune, backup and monitor databases since we do not have a DBA ). I am not a DBA but everyone thinks I am

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.



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

Anon.

Post #581052
Posted Monday, October 6, 2008 9:32 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:00 PM
Points: 36,789, Visits: 31,247
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... :)


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

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #581486
Posted Tuesday, October 28, 2008 1:07 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 19, 2013 11:47 AM
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. :)

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...
Post #593191
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse