Why Doesn't Database Software Help Us?

  • Aside from the discussion about the effects of automation on employment and activity focus, I think what really concerns me is that such automation appears to me to dangerously remove the human judgement factor and the value of exposure to things that are 'just not quite right' with our systems.  This can in turn reduce the 'caring' factor in our attention to systems and long term reduce awareness and attention to potential problems.

    Just this morning I have been researching why the cooling fan in my personal system has been running at top speed for some unknown reason.  This has been going on for some time and just hasn't made sense to me.  The system itself has not notified me if anything amiss, things have been running reliably, performance has been very good.   Fortunately, as a human being I have been able to research a number of sources of information and used human intuition and judgement to possibly resolve the issue which all the software involved has been attempting to handle by running the fan without understanding the underlying cause.  I was able to obtain a number of possible causes and select a solution which appears to have made an improvement.

    I firmly believe there is danger in the 'cookie-cutter' approach to systems which depend far too much on distant developers instead of hands-on awareness.

    I do, however, heartily agree that ALL software needs to help us more, actually MORE SPECIFICALLY, with the information they create and deliver to us for attention.  After my decades of use of software, my biggest frustration is information that is incomplete and too general to be of much value.  If you determine something is wrong, tell me EXACTLY what you found, not some general thing like "Oops, something happened' that I have been seeing lately, can't remember offhand which software I use that has been doing that.

    If there is a problem with my software or hardware, I need to know EXACTLY what you discovered, in all the detail available.  Tell me what you were attempting to do up to and at the time of the problem.  Until the software is smart enough to do this, we still need the human factor as close to what is happening as it can be.   One feature that has been sometimes available is the 'TRACE' capability that would provide detail, but mostly was just done in development environments but this has mostly devolved into 'logging' which is usually worthless.  We often don't need a massive history as much we need just a current rolling 'snapshot' of current events.

    Is it time to rethink our approach to software helping us?

     

    Rick

    I may not be good, but I'm slow.

    The only thing worse than being an influencer
    is believing one.

  • To be honest, I don't want anymore "help" from MS in managing databases.  For example, their insistence on permanently implementing the equivalent of TF11117 on TempDB with no way to override has absolutely killed some tried and true methods.

    For example, we sometimes have the need to rebuild a table by copying a portion of its data to a new table and then dropping the old one.  Since the table has an IDENTITY column in it, we have to use SET IDENTITY_INSERT ON.  MS didn't tell anyone that forces a loading and sorting of the ALL the data in the rows being moved even when no sort is required.  We found THAT out the hard way after TempDB blew up because of it.  We would have had no problem with this almost trivial-sized 50GB table except that it's really tough to grow 8 TempDB files each to 50GB on the 100GB drive that had previously worked quite well for nearly a decade.

    I which MS would spend less time trying to make SQL Server in general more idiot proof because, as the saying goes, "If you make something idiot proof, only idiots will use it".  And... they'll still find a way to break their junk.

    Dear MS... stop putting limits on things because some bloody group from who knows where thinks some limit is a good idea.  You're getting as bad as Oracle!  And "improvements" like String_Split() aren't really improvements because it's missing the functionality of returning the ordinal position of the split out elements and returns nothing instead of a NULL if you give it a NULL.  And how about the absolutely miserable performance of the FORMAT() function?  How about those "fast inserts" that chew up a whole extent for 1 row?  Yeah... loved that one and the fact that it's a global setting instead of a table setting.

    What on the good Green Earth are you people thinking when you write stuff like that?  Are you thinking at all?

    --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".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

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

  • I don't understand why you people are complaining about the lack of automated DB tuning.

    You've been given Auto Index Tuning - don't you have enough of it?

    Want more?

    _____________
    Code for TallyGenerator

  • skeleton567 wrote:

    I firmly believe there is danger in the 'cookie-cutter' approach to systems which depend far too much on distant developers instead of hands-on awareness.

    Excellent point on there being a balance between automation and human interaction.  The downside?  Here's a recent article;

    https://www.sqlservercentral.com/articles/your-sql-servers-are-misconfigured-1

    Microsoft have made SQL, and most of their software, almost endlessly configurable, giving us choices.  Some of these choices, as per the article, are non brainers, so why no have the default installation configured that way?

    What's happening to SQL in Azure may take us down an automation path.  We, the SQL community, most likely the MVPs (Steve, Brent et al) may be able to influence this. But then again maybe not.

  • Sergiy wrote:

    I don't understand why you people are complaining about the lack of automated DB tuning.

    You've been given Auto Index Tuning - don't you have enough of it?

    Want more?

    Heh... in a word... "NFW"!  They've "helped" quite enough with things, like making the equivalent of TF11117 permanent on non-overrideable because a bunch of people that don't understand particular needs thought it would be a good idea to protect people that also have no clue.

    --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".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

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

  • skeleton567 wrote:

    I firmly believe there is danger in the 'cookie-cutter' approach to systems which depend far too much on distant developers instead of hands-on awareness.

    Heh... preach it, Brother!

    skeleton567 wrote:

    Is it time to rethink our approach to software helping us?

    Yes... it all starts with three things that are seriously missing...

    1. People need to start reading the readily available documentation.  SQL Server isn't a wind-up toy.  If you think so, then it'll do like the Evel Knievel toy... you'll wind it up only to watch it jump into the toilet. 😀
    2. The people writing the documentation need to get a clue, especially when it comes to usable examples and putting things together correctly.  For example, try finding out what REORGANIZE actually does.  You'd think this would be documented under REORGANIZE or even ALTER INDEX but, no... it's buried in the documentation for sys.dm_db_index_physical_stats under an obscurely titled paragraph of "Evaluating Disk Space Use".  And then there's the damned MS documentation article titled "Resolve index fragmentation by reorganizing or rebuilding indexes" with the infamous 5/30% numbers that everyone has mistaken as a "Best Practice" for index maintenance even despite the footnote quite to the contrary simply because of the wording of the original "suggestion".
    3. People need to actually need to learn how to find (as above, MS didn't make it easy nor even logically correct) and then read the bloody documentation.  If you don't think so, hang around these forums and start looking at some of the questions.

    No matter how good the documentation gets, though, most people will never practice #1 and #3 above.  Apparently, they want a wind-up toy to take care of possibly the most important asset a company has... its data.  Heh... don't forget to flush. 😀

    --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".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

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

Viewing 7 posts - 1 through 7 (of 7 total)

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