Proactive vs Reactive

  • Comments posted to this topic are about the item Proactive vs Reactive

  • First off many people believe that SQL Server is self-administering. Whilst that is true to a certain degree it is only to a certain degree and is most efficient at doing that when setup properly.

    It is clichéd to say that developers think that "SQL Server is working so leave it alone" as the editorial points out itself. As a developer, I have had my suggestions to get a DBA in ignored, to have SQL Server setup properly ignored and loads of developer centric good practices refused. Mostly due to time/budgetry restrictions. Regardless of any warnings given.

    In general, many companies do not see the value of spending money doing things right when making do is cheaper and works well enough. That is, of course, until it doesn't and that is when they blame the people who did the work (even/especially if they highlighted the risk of missing certain tasks) and sometimes they have to close.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • First off many people believe that SQL Server is self-administering

    No, my complaint is with the companies. Many treat SQL server as a secondary consideration

    I think the installation of the server is far to easy. With some clicks the installation is finshed and the database is running. So why should I hire a DBA if I can do it on my own? 

  • I agree with the thrust of the article. The problem isn't just SQL Server though... One way of looking at this is to call the problem "the drains"! 😉 People like to forget "the drains" exist. So long as they are working, nobody cares. They don't get maintenance, and in many cases they don't even get periodic inspections. Life goes on. People would prefer to spend money and time on re-painting the front door.

    "The drains" aren't interesting, they are not exciting and they are not visible. In some cases the problem is made worse because the data professionals do too good a job with limited resources! I really don't know how you fix that one! Of course, "the drains" become an issue when they block, things get smelly and people start getting cholera.

    I guess the solution is to communicate to _value_ of what is inside the database and especially its value when it becomes unavailable or damaged. I expect most people here understand that value, but communicating it is hard. Once the value is accepted then sensible proactive solutions like having a designated _real_ dba (as opposed to the accidental kind, like me) or regular inspections by such a person become a sensible economic choice rather than simply an expense.

    Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]

  • Whether it's SQL Server, Oracle, MySQL or some other flavor, databases are an afterthought. My company has no data policies except what I've created, and has little interest in doing things to help themselves stay safe until a disaster occurs. Rather than spend 20% extra and get a database that can proactively alert them to potential problems, they want to minimize all costs and leave it to the developers to determine what is needed. Some developers are knowledgeable, but most just want a database to store what is put in with no thought about indexing, partitioning, replication, disaster recovery, or auditing that can help their software be efficient and scalable to get new business or just good enough to fulfill the contract. I fight tooth and nail to educate developers and executives about the need to build data systems with reliability and scalability first, and then let developers build on those systems. The battle continues, and is a balance act to make sure that development speed doesn't overtake database design.

  • Skimping on database admin is a business mistake. Why do people make business mistakes? I don't know.
    Good DBAs and developers are different cats. Yes good DBAs are hard to find and expensive. Get a consultant's advice and then do what he or she says. This should not be so hard to comprehend.

  • As with all things the answer is probably "it depends."  Honestly I think Alex-489474 and Tom Gillies are both dead on.  I was just discussing with some coworkers how a blessing of SQL Server is also a curse.  It's very easy to install and use for the most part.  Unfortunately people get comfortable with its ease of use and don't realize there are a lot of complex operations going on under the hood until they have 4000 operations running against a server or a 200GB database on a full drive and they can't figure out why things are slow.

    Then there's the money aspect.  A 20 employee company would have a hard time justifying paying a top notch DBA 150k/year to manage a couple of SQL Servers but at what point is it worthwhile to have someone dedicated to that role in order to ensure reliability?  As companies grow there's rarely a line-in-the-sand moment when it becomes clear they need someone with that skill level.

    I've worked with many companies (including in the IT services market) with managers who don't understand the difference between someone who can use a SQL Server and someone who can legitimately administer one.  It's almost like they assume that if someone knows how to open Management Studio, they have all the skills necessary to fix a SQL Server.

  • The DBA is hardly the only place where companies scrimp. Take the desktop for example. Buy the cheapest home models that you can find, no need to worry if there aren't even two identical computers in the office. Rely on Windows Update working all the time, no matter what the employees (all of whom have local admin authority) do. And use only the free virus scan editions. No need for a file server, SharePoint, etc., everybody uses their personal Drop Box or Google Drives. As long as there is no medical data and credit cards are run manually thru a cube on someone's phone, look at all that support cost we are saving 🙂

  • Lol, I will never understand that kind of thinking. Compare hardware and software costs to salaries, the business decision is obvious to anyone with a brain.

  • Alex-489474 - Tuesday, April 25, 2017 2:14 AM

    First off many people believe that SQL Server is self-administering

    No, my complaint is with the companies. Many treat SQL server as a secondary consideration

    I think the installation of the server is far to easy. With some clicks the installation is finshed and the database is running. So why should I hire a DBA if I can do it on my own? 

    If you're serious, then go back and reread the article and then read the thousands of posts on this very forum about performance problems, not being able to write the code they need, or recovering from a crash, accidental deletion, or accidental overwrite.  Installing SQL Server correctly is just the tip of the iceberg and I can guarantee you that, although it may install well enough to work (which people mistakenly call "correctly), it doesn't install correctly with just a couple of clicks.  From personal observation, most people that think SQL Server is easy fall into one of two categories... they either know their stuff about SQL Server and don't need anyone else or they don't know their stuff and think they don't need anyone else.  That latter notion even applies to many DBAs that I've interviewed over the last 10 years.

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • GeorgeCopeland - Tuesday, April 25, 2017 12:54 PM

    Skimping on database admin is a business mistake. Why do people make business mistakes? I don't know.

    Heh... I can't speak for anyone else but I've found that the reason is that THEY don't know.  Ironically, they have to hire the right person to actually know that they even need to hire someone.  It's a bit of a "Catch 22".  Or, like you said, run across a consultant that tells them that.

    I also think that a whole lot of people think that all a DBA can actually do is backups, keep the fans dust free, do the occasional upgrade, and bitch at people for wanting too much memory.  While I've certainly run into my fair share of such people, the really good ones can not only do some serious magic in the form of server administration, but they can also design databases, write some awesome T-SQL, and use the peer reviews they conduct to mentor other in a most unselfish manner.

    Of course, you already knew that because you recognize the importance of not skimping on all that goes into databases to begin with.  I just had to say it out loud for any hesitant managers that might be reading this. 😉

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Tuesday, April 25, 2017 8:12 PM

    Alex-489474 - Tuesday, April 25, 2017 2:14 AM

    First off many people believe that SQL Server is self-administering

    No, my complaint is with the companies. Many treat SQL server as a secondary consideration

    I think the installation of the server is far to easy. With some clicks the installation is finshed and the database is running. So why should I hire a DBA if I can do it on my own? 

    If you're serious, then go back and reread the article and then read the thousands of posts on this very forum about performance problems, not being able to write the code they need, or recovering from a crash, accidental deletion, or accidental overwrite.  Installing SQL Server correctly is just the tip of the iceberg and I can guarantee you that, although it may install well enough to work (which people mistakenly call "correctly), it doesn't install correctly with just a couple of clicks.  From personal observation, most people that think SQL Server is easy fall into one of two categories... they either know their stuff about SQL Server and don't need anyone else or they don't know their stuff and think they don't need anyone else.  That latter notion even applies to many DBAs that I've interviewed over the last 10 years.

    Maybe I shoule have made the <sarcasm> tag visible. What I mean is, that you can give the setup to anyone with some experience about installing software. Start the setup, make some clicks and the instance is running. As you wrote a correct installation is something different.

    Honestly I think Alex-489474 and Tom Gillies are both dead on.

    As I am not a native english speaker, can someone explain me what "are both dead on" mean? The german translation does not make very much sense to me.

  • Alex-489474 - Wednesday, April 26, 2017 12:08 AM

    Honestly I think Alex-489474 and Tom Gillies are both dead on.

    As I am not a native english speaker, can someone explain me what "are both dead on" mean? The german translation does not make very much sense to me.

    The poster meant that Alex489474 and Tom Gillies were correct. I suspect it's a shortened form of the idiom 'dead on target' (https://www.vocabulary.com/dictionary/dead%20on%20target).

    I have fun understanding German idioms too 🙂

  • To an extent, SQL Server does a decent job of taking care of itself, but I don't think managers understand that extent.  They're managers, so it isn't in their wheelhouse.  I think they look at it and say "Well, it's worked fine for the past year with the one app that required we get it and is used by 3 people.  Since it takes care of itself over time in a multi-user environment, let's use it for all our data."  Then, the pain starts and performance problems are everywhere.  It takes something like data loss where nobody knows how to recover to cause a re-examination of their original assumption.  Whether they end up in the "SQL doesn't do backups" or "we need a DBA" camp depends on the manager.  Unfortunately, if management never gets past the top-level understanding, nothing causes them to examine their original opinion.

    Sadly, even some people with the  DBA title are reactive instead of proactive.

  • Good questions, Jim. I've seen this too where I've worked in the past. Not my current employer, kudos to them, they've got DBA's on staff, doing regular maintenance, etc.

    But my previous employer was a small group that was a part of our local university. The primarily focus of that group was doing assessments of people addicted to illegal substances, not the applications we wrote to collect that data for grants, nor the data we stored to comply with the grants. When our DBA left I was thrust into the accidental DBA position. I did have some training in being a DBA, because I had taken a course on SQL Server 2005 management, but still I wasn't completely prepared. And the university we were a part of is an Oracle stronghold. They just didn't have anyone on staff who could help us, nor do I think they were even interested in helping us. We were just that little outfit off campus who played around with that silly, inconsequential thing called SQL Server. I did a reasonably good job, but I couldn't have done as well as I did if it were not for this website and especially the people in these forums. If they gave out awards for someone who asked the most questions, I'm sure I would have won more than once.

    This reminds me again just how important this website and the people here are. Thank you so much for helping me as much as you did back then!!!

    Thank you!
    Thank you!
    Thank you!
    Thank you!

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply