Voice of the DBA

Category: Editorial

  • The Hidden Trigger

    I ran across a post recently where someone asked about using a trigger for a particular issue. There were quite a few responses, but one person brought up the fact that triggers have various downsides, all of which I agreed with. However I didn’t see one mentioned, which is a big one with me.

    Triggers are hidden.

    It’s not that triggers are hidden from DBAs by default, after all, there’s a triggers folder under each table in the Object Explorer, but how often do you open that folder? It’s just not obvious when a trigger exists on a table. The use of triggers is too uncommon, and it’s easy to forget they exist, even if you’re the person that added them to a database.

    This is really my one big complaint about triggers. I can’t easily determine when a trigger is firing, which sometimes leads to issues. I’ve troubleshot strange things in SQL Servers, only to realize hours later that a trigger is firing based on some action.

    Perhaps it’s me, but do many of you think about triggers first when something strange happens in SQL Server? I think I’ve gotten better over the years at looking for them, but I still get stymied and waste time trying to debug issues. I really wish that a “triggers” tab would appear in SSMS, maybe after the Execution Plan tab, whenever a trigger fired. It could have a copy of inserted and deleted, or even just the trigger code. That alone might clue me in quicker.

    I think triggers can be valuable in database systems, but because they seem to be so rarely used, I’ve grown to distrust and dislike them over the years.

    Steve Jones

    The Voice of the DBA Podcast

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

  • What’s Your Downtime?

    That’s the question this week: What’s your downtime?

    I thought about this as I read this piece on Azure’s downtime being greater than its rivals in 2014. You do need to provide an email to read the article, but essentially the article builds on tracking from CloudHarmony to show that Azure had more downtime for the year, with about 54 hours. In Europe, that high water mark was 5.97 hours for compute and 1.31 hours for storage, so the European Azure cloud is doing better than the others.

    That’s pretty good. Certainly individual machines went down, and services were unavailable for short periods of time during failover, but keeping a hardware platform up around 5 hours of downtime a year is good. I’m not sure that many of my companies have done this, though to be fair, mostly it’s been patches from Microsoft that caused downtime for Windows machines.

    However, let’s look at your database instances. Do you know what your downtime is? I’d encourag you to track it, and be sure that you report on it. Or at least have the data, in case the boss asks. I don’t know what our SSC total downtime is, but I can tell you that our cluster rebooted in Aug 2015 and Mar 2016, brief outages for some patching. In the past, I’ve typically seen our database instances run the better part of a year, usually only coming down for a Service Pack.

    If you have monitoring in place, and you should, then I hope you have some idea of downtime for your main databases. If you can share, see if you might set the high water mark for the SQLServerCentral community in the last year.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Successful Projects

    What techniques or ideas allow you to build a successful software project? There’s been no shortage of writing and studying on this topic across the last few decades. So many people expend energy and thought trying to solve the problems of building software at a high level of quality, in a reasonable timeframe, and within some scope that matches the desires of their customers.
    I’d like to think most of us succeed, but study after study shows that most parties are disappointed in some way. Developers are under pressure and can’t/don’t built the level of quality they’d like. Management sees software as taking too long and costing too much. End users see too many bugs, though I think that overall quality has risen in the last decade are more proven frameworks are used and developers have gained more experience in newer and better development techniques.
    I ran across a post on a test for successful software projects. It’s the Kevin Test for Successful Projects, and it’s based on a combination of the Joel Test and the Rands Test. The idea is not that you implement all of these test items, or do them perfectly, but that you work towards doing more of them than not. There are explanations of what each item in the test means in the various pieces.
    I think these are good guidelines for projects, and they’re simple ones. They certainly can apply to database development. However most people don’t really want to spend time on these tasks. However, I think the mundane nature of these items slows you slightly, but forces you to think more about what you’re doing. The gains in quality and velocity, in my mind, come from avoiding rework, avoiding losing work, and avoiding regressions.
    Sometimes I think the problems in software development aren’t that we write poor code, but rather that we rush a complex endeavor, being willing to redo work rather than proceeding in a more engineered fashion.
    Steve Jones

    The Voice of the DBA Podcast

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

  • Build a POC

    I have a few friends that work sales engineers for various companies. They often build a proof of concept (POC) project for various customers or potential customers, which is a great job. They get to showcase how a particular product or technology might work in a situation. We see this all time from lots of companies, including a great POC from BMW shown at the recent //build/ conference.

    Sometimes the POC is more mockup than reality, but often this is a way to actually test some software and determine if you should invest more resources in that particular direction. I’ve used this myself, setting up a small project to test items, and I recommend this for others that might want to try something out.

    For example, I like the idea of Continuous Integration (CI) for databases, but implementing CI in one of your production pipelines, on a production database is hard. It’s complex, and it can be distracting, not to mention stressful. Who wants to make a deployment mistake in production?

    What I recommend instead is that you take a small database and practice. I don’t like Adventureworks, but you could grab a few tables from your system and build a new database, download a pre-built one from SQLskills, or even just create a Hello World type database with one table. Download TeamCity, or use the Visual Studio Online build system. Experiment and learn how to take your database code and programatically deploy changes to another system. Redgate has toolsto help, or you can roll your own.

    No matter how you do it, try using a POC the next time you are wondering what the best way to proceed with new technology. You might find the POC makes a new technique more approachable and gives you confidence to tackle deploying the changes in the rapidly changing environments in which we work.

    Steve Jones

    The Voice of the DBA Podcast

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