Data Pro, What's Your Groundhog Day Flashback? - SentryOne Team Blog

Data Pro, What's Your Groundhog Day Flashback?

Groundhog Day: The Holiday

I am willing to argue that Groundhog Day is THE WEIRDEST HOLIDAY of them all, at least in the USA and Canada. For international readers, this is a holiday based on a superstition from early German-speaking settlers that if a groundhog emerges from its den on this day, February 2nd, and sees its shadow due to clear weather, we will have six extra weeks of winter. If it cannot see its shadow due to cloudiness, spring will arrive early. Makes perfect sense, right?

The US capital of Groundhog Day is Punxsutawney, Pennsylvania where news camera crews flock to see the local groundhog prognosticator, Punxsutawney Phil, make his prediction. And he's terrible. I mean really bad. Punxsutawney Phil is wrong more often than not. According to a USA Today, ye olde groundhog has been wrong 15 times and right 13 times since 1998, about what you could expect from flipping a coin.

Groundhog Day: The Movie

But the majority of people over 30, when asked about Groundhog Day, wouldn't mention the holiday and instead would dive into their favorite part of the famous 1993 movie Groundhog Day starring the inimitable Bill Murray as the weatherman Phil Connors, a man who is basically a jerk. And for some magical reason, Phil is stuck in a time loop in which he must relive Groundhog Day again and again. Each day, he awakens to Sonny & Cher's "I Got You Babe" and each day he attempts to live the day differently to break the loop. There are many funny scenes in which he tries zany methods to break the loop, but each day he reawakens to "I Got You Babe". It is only after Phil is able to change himself, in effect becoming a good and unselfish person, that he is able to break the loop and move forward in life.

The movie was only a modest success at its release. But over time, its popularity and critical acclaim grew until now, where it is considered one of the Top 10 Comedy Movies of all time. The expression "groundhog day" has entered the popular lexicon for any scenario in which a person is hopelessly stuck doing the same thing day after day. And is now frequently imitated in many other forms of entertainment, having its own entry on the website TVTropes, and appearing in other movie genres, such as Edge of Tomorrow (Sci-Fi) and Happy Death Day (Horror).

Groundhog Day: The Theme and the Challenge

One of the major themes of the movie is as an allegory of self-improvement, since our hero is trapped in a time loop where escape is only possible by accumulating knowledge through multiple passes. It is such a popular opening for conversations about self-improvement that you can find lots of online discussions featuring the movie as well as plenty of articles in the popular press like this one – http://people.com/movies/groundhog-day-movie-10-life-lessons/. I've touched on the theme of looping endlessly through the same technical mistakes over and over even in my own writing, like in this article about SQL Injection at Database Trends & Applications Magazine and this one entitled The Basics are Still Difficult.

So here's your challenge… what are the technical mistakes that you keep seeing repeated over and over again? I'll put a handful of my favorites here since I lecture on this topic all the time, but I want to see your response in the Comments here. What are the things in your career as a data professional that keep popping up over and over again, like a bad dream?

Some candidates:

  • backups that were not checked for corruption
  • backups that were not subjected to a recovery test to ensure they can be used once recovered
  • leaving all server and database configuration settings at the defaults
  • leaving important Windows Server settings at the default, such as Power Setting, Instant File Initialization, Large Pages in Memory, and Lock Pages in Memory (where appropriate)
  • not monitoring SQL Server applications
  • not checking logs
  • not setting up Error Log alerting
  • selecting the wrong data types for a given table
  • poor indexing
  • knee-jerk troubleshooting
  • lack of standardization across SQL Servers
  • no patching process
  • … and the list goes on. What are you Groundhog Day issues?

Looking forward to your insight! Cheers,

-Kev

P.S. Connect with me online! Facebook | Twitter | LinkedIn | Google Author

Comments ( 4 )

      • David Alcock says:

        It's a bit of an "umbrella problem" (for want of a better term) but I routinely come across legacy SQL Server instances that have been left alone, normally for years, without any administration or maintenance. It's usually because at one time the database worked perfectly fine on a default install of SQL so hey, let's just leave it! Then the database grows up, the user base expands and most of the problems you mentioned are experienced.

        It then gets even better because at some point in the future the database/instance desperately needs upgrading or migrating to a new SQL Server, but there's no documentation whatsoever and the guy who used to "look after" it retired ten years ago!!! Oh and naturally this type of database tend to be mission critical too!

      • Kevin Kline says:

        Outstanding, David! Yes, this is indeed a common problem that keeps happening over and over. There was a period of time in the 00's in which Microsoft encouraged this thinking of "Buy it. Set it up. Forget about." In the long run, those installations eventually hit a wall. And then shatter. :-(

      • Elizabeth Hunt says:

        Excellent article. Thank you.

        One of the things I see over and over are queries with hard coded values that eventually need to be rewritten to pull in all valid values from a table.

        There are two main issues here. If a new value is added, it won’t be picked up in the query, and if the hardcoded value changes (e.g. the name of a category or department), then it will stop pulling into the query.

        If we write our queries to use a lookup table of some sort, to ensure all valid values are always available in the results, we can avoid the first scenario.

        If we use codes instead of the actual text values that describe them in our queries, then the label for the category or department can change, and the query will still pull the data accurately using the code value.

        This may not always be possible in every environment, but if it is, then it will save time in the long run to set the query up with these 2 things in mind from the beginning.

      • Kevin Kline says:

        Good one, Elizabeth! Yes, we see that kind of problem again and again.

      Leave A Comment

      Your email address will not be published.