Voice of the DBA

Author: way0utwest

  • Republish: I Feel Like a Magician

    I’m off in the UK and buried with other work, so a republish today.

    I Feel Like a Magician

  • T-SQL Tuesday #106 – Trigger Headaches or Happiness

    tsqltuesdaySince I took over the T-SQL Tuesday a few months ago, I decided I ought to host again. Especially since I’ve done it twice, but Wayne Sheffield got his third spot last month. Gotta keep up with Mr. Sheffield.

    Triggers, for fun and frustration

    I’ve been working with SQL Server and T-SQL a long time, and across many jobs, I think I’ve ended up using triggers in 0.01% of my tables or less. They can be a useful and helpful construct, but they can also be problematic and difficult, especially in the age of changing business models and rules.

    Since I’ve found triggers to be both helpful and hurtful, I decided to ask you to write about an experience you’ve had with triggers. Either good or bad, but let me know this month what stands out in your mind.

    The Rules

    As always, the rules for this month are simple.

    • Write and publish a post on September 11, 2018, UTC time.
    • Include the T-SQL Tuesday logo (you can grab this above) and link your post back to this invitation.
    • Leave a comment/pingback on this post for me to use to include you in the roundup
    • Have fun.

  • We Don’t Have Perfect Information

    I was discussing the PASS Summit with someone and they were wondering about building their schedule. Actually, they wanted to pick sessions, but see the choices in a calendar format, but the schedule wasn’t out. My suggestion was to just build the schedule and then sort out conflicts later.
    A few people have mentioned over the years that they want to build a schedule and be ready for the event to maximize their experience and be efficient. I think that’s a common, normal, technical person thing to do. We’re Type-A, we like knowing and having a set schedule.
    The problem is that we don’t have perfect information. Even if the descriptions and abstracts included perfect information about the agendas, what is covered, and to what depth, including demos, we’d still not necessarily assimilate and recognize all that data. We’d think a session on database design covered fourth normal form, even when the text said third normal, or we’d expect that an SSIS data load talk included something on CSVs when the presenter described the talk as being with flag text files.
    We’re human, and that means we have flaws in how we deal with the world. This includes the ways in which we model and analyze data. While we can make mistakes in our analysis, we often may simplify our view of a problem to the point where our analysis is inherently flawed.
    I try to remember this when I write reports from systems that others will use. I won’t have every piece of information that might affect a system, but I try to ensure I have the most important, or significant, data. At least, the data I (and the users) feel is significant. The important thing to remember is that out data is always incomplete, and it’s entirely possible that we have missed a valuable piece of data.
    When that happens, we have to adapt and adjust our systems, just like our conference schedule. We’ll learn more across time and we can use that information to change our system. I know that my view of a conference like the PASS Summit today, or even a week before the event, will be different than what I know, and how I feel, at the event. I should have a plan, but be willing to flex as circumstances change.
    Steve Jones

  • Custom Data Purging in SQL Monitor

    In talking to a customer recently, they were worried about the amount of data kept by SQL Monitor. That’s a fair concern as monitoring a large number of servers can result in lots of data.

    As an aside, data management is one of the reasons that I’d always want to buy a monitoring tool from a vendor. Most people don’t get this right and it’s a pain to deal with. I’d like you to look at SQL Monitor, but if it doesn’t work for you, look at our competitors. More people need monitoring on their systems.

    In any case, this customer wanted to ensure some data was removed, but not other data. Their concern was that things like performance data or storage data might be needed for a long time while alert data or top queries might not. In other words, customized data management is needed.

    I posted the suggestion in the SQL Monitor Slack channel, asking the developers if they were considering it. In about 5-10 minutes, I got this link: https://monitor.red-gate.com/Configuration/Purging

     2018-08-23 12_15_16-Configuration _ Data purging

    Shazam! They’d already done it.

    Actually, they’ve released this to frequent updaters, but in an upcoming release, this will be the default. You’ll be able to customize how long you want to keep each kind of data. Not by machine (yet), but if you need that, let us know.

    SQL Monitor continues to amaze me with their progress. If you want to get an idea of how it works, check out monitor.red-gate.com, our demo site, where we monitor some real servers at Redgate, including the SQLServerCentral database instances.

    And if you want it in your enterprise, download a trial today.