Voice of the DBA

Author: way0utwest

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

  • Data Clarity

    There was an Associated Press (AP) report recently that noted Google applications track your location, even if you’re turned off Location History on your Android phone. The article has details about what the AP noted, as well as the report from some researchers that were testing the functionality. You can read the details, but the issue doesn’t seem to be as simple as the headline of the report.

    Google has responded to the claims, saying that they document and explain the various settings that need to be changed in the applications themselves to prevent any tracking. That might be the case in the eyes of the engineers that built the functionality, but I would tend to argue that the expectations, the descriptions, and explanations we use as technology professionals might not be clear enough for most users. We ought to be documenting, explaining, and even coding systems for users that aren’t as familiar as we are with the technology.

    This is an interesting issue. Not the location tracking, since I assume Apple, Google, government, and more can track my phone if they really want. To me, the issue is that we have data practices that are not clear to the end user. What Google documents, what they do with new services and features, and what the clients expect are not necessarily the same. That’s an issue, and I suspect it’s a similar issue for many companies.

    Most of us collect some level of detail from our software on how the user interacts with it. This might be a local log, or it might be some sort of telemetry, similar to what Microsoft collects from SQL Server. In either case, I think it’s important to spell out what data is being collected and to what extent this data is related to a specific individual or company. The changes to data handling as a result of the GDPR and other legislation might require that we do a better job of disclosing any data we collect, and in which specific circumstances.

    I know that data matters, but I also think that lots of the information that is collected doesn’t need to be related to a specific individual. Aggregates or tokenized data is often enough, though if you need to track a particular individual over time, such as the features they use in their install, be sure that you are very careful with any sensitive data, such as names, locations, etc. Most of us don’t have Google’s resources to combat legal action if customers find we are infringing on their privacy.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.