The Leaves Are Changing, But Why?

  • Comments posted to this topic are about the item The Leaves Are Changing, But Why?

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Heh... this site left me no choice, Grant. I had to give this article only 5 stars because it won't let me give it 1000!

    It's amazing how many "Brown Leaf" problems (perfect analogy there, Grant!) there actually are out there that most of the world is actually perpetuating and promoting to this very day because of the very reason you mention. And, yeah... I was one of them on a lot of these problems because, like a lot of good folks, I simply didn't realize that the problem that was identified wasn't actually the problem at all.

    I know you know and so do some of the folks on this site but one of the problems present can be demonstrated by a few common "interview" questions that require a bit of discussion to answer correctly.  And, to be sure, I used to get these wrong, as well.

    As a hint to everyone looking at these questions, if you provide the typical answers that are frequently posted on various websites, forums, in articles, in presentations, in videos (even official training videos), whatever (even some MS documentation), you're going to be wrong because of some really big issues that have a root cause of exactly what Grant speaks of in his short but incredibly important article.  When it comes to a lot of things that we've been taught about in SQL Server, my best hint to you is "There is no spoon".

    1. What does the REORGANIZE option of ALTER INDEX do?
    2. What does the REBUILD option of ALTER INDEX do?
    3. Why are Random GUIDs the worst choice for Clustered Index first column keys and what you can use instead?
    4. What are the "Best Practices" for Index Maintenance?
    5. You're stuck with the Standard Edition of SQL Server on a server that has a 24/7 requirement and no downtime for maintenance is allowed on any index except for 1 hour once per quarter.  What should you do about fragmentation the rest of the time?  Use REORGANIZE or REBUILD?

    If that interests you, then, to continue the Matrix analogy, do you take the Red Pill or the Blue Pill?

    Red Pill:  https://www.youtube.com/watch?v=qfQtY17bPQ4&list=PLr9ab4Dj3ObuaHAUA9JJz-GUbfbwXEyS5&index=4

     

    Blue Pill: https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15

     

    --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)
    Intro to Tally Tables and Functions

  • Grant, I agree with you that people tend to make conclusions as to how to solve a problem, long before they've reviewed enough of the data to gain a complete understanding of the problem. My guess is that this is a problem most of the time.

    I'd like to add a cautionary note to this discussion. The minority of the time there will be people who get involved in "analysis paralysis". I am guilty of doing this, so much so that I have, a few times, done nothing in favor of continuing data gathering and analysis. Something I have to work at not doing.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod.  Do you have a description that you can share of the particular "Analysis Paralysis" instance that you're talking about?

    I ask because I've seen a huge number of articles that describe what it is and how to avoid it but there aren't many first hand accounts of what people have suffered through and, if you're willing, would love to hear your story.

    --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)
    Intro to Tally Tables and Functions

  • Often times (especially in the realm of politics, finance, and health) the data itself can be rubbish when curated to support a narrative.

     

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Thanks for the feedback everyone.

    Rod, I think the analysis paralysis thing is a problem for really smart people. Me, I'm more likely to come to the brown leaves conclusion far too quickly.

    Jeff, no arguments.

    Eric, yeah. Sadly, GIGO is real.

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Grant Fritchey wrote:

    Thanks for the feedback everyone.

    Rod, I think the analysis paralysis thing is a problem for really smart people. Me, I'm more likely to come to the brown leaves conclusion far too quickly.

    Jeff, no arguments.

    Eric, yeah. Sadly, GIGO is real.

    I wouldn't even call it "garbage data", I'd call it "poison data" when it's been crafted to intentionally deceive (for good or bad).

    https://www.technologyreview.com/2021/03/05/1020376/resist-big-tech-surveillance-data/

    In the realm of IT, focussing on the wrong metrics can skew data-driven business intelligence. Think about auto insurance rating or credit scoring. Also, when it comes to news, we should understand that the media (specific media platforms in particular with an agenda) can act as a filter between ourselves and the primary and authoritative data sources.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff, well you've called me out on producing an example of my "analysis paralysis". Under such circumstances I freeze. I had to think about this for few moments, but I've got one. This is fresh because I'm living it now. Our Project Management Office has started a process of cataloguing all the software we use, whether built in-house or from third-party vendors. I'm meeting with them tomorrow to discuss our use of TFS.

    I know you're familiar with the phrase, "Accidental DBA", from here on SSC. Well, I've become what I call the "Accidental TFS Administrator", or more generally the "Accidental DevOps Guy", although not everyone where I work would agree with that. The guy who used to handle TFS, left a while back, thus I became the TFS administrator since I spent more time than my colleagues in learning how to use TFS. (Generally, I love learning how to make any tool work better for me as I do my job, which is software development.)

    They've been using TFS longer than I've been here, but I get the feeling that they've only used it for storing source code. You can do more with it, such as automating unit tests, and performing CI/CD. Even though we use an out-of-date TFS, it still can do these tasks. And I'm trying hard to get us to adopt Azure DevOps Services as a replacement for our old, out of support TFS.

    I see the adoption of Agile/DevOps and related, as a way of producing applications faster and potentially with better results than we do now. However, I appear to be going up against decades of inertia, where there's no desire to do anything at all new, for several simple excuses such as, "We've never done that before", "We've always done it this way" or the unspoken "I don't want to." Another thing that makes my trying to bring about a cultural change difficult is I work for a large state government department, which means we don't have any competition. But I really struggle hard with the huge level of inefficiency, which is not only tolerated but I'm convinced encouraged to be in place. Last year I complained in these forums of having to wait a week for a high-level committee to pass judgment on whether I could add two records to a lookup table in SQL Server. Also, the tendency here has been to make builds a one-shot thing, where a developer will build the app (Windows or Web app), then push it out to whatever the destination. I'm engaged in what now seems like a futile attempt to get people to use the build system that TFS supports. To that end I've spent a lot of time reviewing all our applications that are in TFS. I look through their build and release sections (TFS 2015 uses those terms. Azure DevOps uses Build and Pipeline.) Over several weeks I've discovered that the team I'm on is the only one which makes builds and releases of the Windows apps we make. Even my team doesn't make build and releases of the Web apps we make. None of the other teams make builds and releases for the apps they produce. I keep digging into this for analysis, discovering what we're doing (or not doing in this case), but I don't really know how much I should continue to pursue this analysis. My tendency is to continue to investigate, but standing back from it I really can see that there's truly little evidence I can find, to prove from our own data, that trying to follow agile practices produces quicker and more consistent results. If anything, the lack of evidence I've found supports the idea I've suspected for a while that what really happens here when management tells us to adopt agile practices, what happens is the resistance to adopt agile is so strong no one does anything about it, then when no evidence of agile efficacy is produced, they declare agile a failure. They can go back to producing applications the way they've produced apps for years, which often aren't compliant with what the user wanted and built inconsistently when different developers build the app on different machines.

    (Sorry for the length of this reply. Much of it was to demonstrate how and why I'm churning at trying to find evidence for the efficacy of following good CI/CD practices.)

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Hey Rod,

    I know I'm not supposed to try humor any more because it just leads to me getting in trouble, but your co-workers could use a clue-by-four up side the head.

     

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Rod at work wrote:

    I'm churning at trying to find evidence for the efficacy of following good CI/CD practices.

    As tedious and disappointing as that all is for you, I don't see that as "Analysis Paralysis" where someone cannot make a decision.  From your story (thank you for taking the time to write that up), they've definitely made the decision to continue to do what has been working for a long time because, and please take no offense, you've not yet been able to identify the ROI of the proposed in a manner sufficient to change their minds.

    As for taking a clue-by-four to them as Grant suggests, you've not yet proven that they need a cylindrical cellulose calibration session nor have you proven they're wrong nor have you proven the ROI of the change nor have you proven that the change would actually work.

    But, whatever... this isn't a case of "Analysis Paralysis" thing.  This is a "Show me and prove the ROI" thing.

    --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)
    Intro to Tally Tables and Functions

  • Grant Fritchey wrote:

    Hey Rod,

    I know I'm not supposed to try humor any more because it just leads to me getting in trouble, but your co-workers could use a clue-by-four up side the head.

    <Imagine a big laughing emoji here>

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I see your point, Jeff. In this case I thought my spending lots of time trying to find something that's hard to find or not even there, a waste of my time and that of my employer's. I could produce other scenarios but feel that I've already spent enough time on this. So, I'll move on. 🙂

    Kindest Regards, Rod Connect with me on LinkedIn.

  • If you actually believe that it's a worthwhile endeavor, don't give up.  Just don't let it be all consuming.  You might be surprised what kind of proof you can come up with or fall upon in a eureka moment during a little low pressure thinking moment on such a thing.

     

    --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)
    Intro to Tally Tables and Functions

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

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