Voice of the DBA

Author: way0utwest

  • Less Blogs

    I’m going to blog a bit less here this year. As I evaluate my goals and life,  I feel a bit overloaded right now. I have lots of ideas, and lots of things to write about, but I need to focus a bit on some other tasks, and I don’t need to publish here 4-5 times a week, which is what I’ve done.

    As I’ve told others, if you’re changing your blog, make a note. If you stop blogging, write a post. This is that post.

    I will try to publish 2-3 times a week, some Redgate content, some SQLNewBlogger, some interesting things I see, but I’ll spread the content out more.

    I’ll re-evaluate in a few months. At that time I’ll stop coaching for the season, and perhaps life will be a bit different.

  • Your Recovery Time

    Disaster Recovery is both an exciting challenge for many DBAs and also a dreaded event that many hope they never experience. When a true disaster befalls your system, there is a tremendous amount of stress as we work to get things running again so clients can access data. Even the best laid plans will often have a glitch, and while it’s a great technical challenge, most of us would rather keep practicing and gaming possibilities than actually experience a disaster.

    The majority of our system disasters are localized to the actual machine handling our workloads. We often don’t have outside disasters, like hurricanes, with disruption and damage to other parts of our infrastructure and ever our lives. When that happens on top of a down system, it’s a level of stress that can affect our health. I’ve been lucky in that I’ve experienced both kinds of disasters, but never at the same time. I hope you can say the same thing.

    Let’s assume some local disaster defalls your system. Hardware, software, it doesn’t matter, but you end up with a corrupted database of some sort. This week I’m wondering if you have an idea of what the recovery time would be? How long before clients are up and running? Maybe more important, how long before you have system rebuilt?

    If you have some sort of High Availability (HA) plan, then you might be back up for clients quickly, in minutes or even seconds. The disaster really isn’t over, however, since you are now running on less hardware than you planned. Until you can rebuild the downed node, you’re still in disaster mode. If you’re like most of the organizations that have employed me, you’ll also be stressed as your formerly well-designed HA setup is now a single point of failure and you’re scrambling to get the main node rebuilt.

    We often think of a disaster as the time we’re down because of some event. Once clients are being served again, we tend to relax and think the disaster is over. It’s not, because until you replace the affected systems and bring them back online, you’re even more vulnerable than you were previously to another Murphy’s Law incident.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Careful with Session_Context()–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    A quick note, which is more of a reminder to myself. I find writing things down helps me remember, and I need to remember this.

    I was working with session context, specifically the SESSION_CONTEXT() function. When using this function, you give it a key that contains a value, like this:

    2019-01-15 13_45_34-RLS_Testing.sql - Plato_SQL2016.WideWorldImporters (PLATO_Steve (61))_ - Microso

    I get a value back that I can use. Everything is great.  I was using this to allow one process to set a value and another to get it, and I was happy.

    Until things stopped working. While trying to debug this, I ran this code:

    2019-01-15 13_46_46-RLS_Testing.sql - Plato_SQL2016.WideWorldImporters (PLATO_Steve (61))_ - Microso

    Notice a difference? In the first query, I have SupplierID, but the second is SupplierId, with a lower case “d”. These keys are determined when you use sp_set_session_context, which takes a sysname value for the key. These are going to be case sensitive, as each one is a different identifier.

    It’s not likely that this will cause lots of problems, but when you are setting keys, be careful and ensure you use the same value for writing and reading.

    SQLNewBlogger

    This was a quick mistake I made and it took me 5 minutes to write up. It’s helpful to get me to remember to avoid this, but this also shows I can fix my mistakes.

    What’s a simple thing you learned that makes you write better code? Write your own SQLNewBlogger post today.

  • The Heart of DevOps Webinar

    One of the things that I think about DevOps is that it’s really hard to focus on the hard things that create friction in your process. Most of us want to move faster, and tackle the easy things to automate, the easy things to fix. We want to trust developers to move quickly and pick those items that get in their way.

    They do, but they often stop before the database. Or they start to try and find ways to use a different database (ugh). Or they just start putting strange data into existing columns to get things done.

    The database matters, and I’ll be talking about why.

    Webinar social_Heart of DevOps

    I’m doing a webinar on Feb 6 for 30 minutes to talk about the database in DevOps. You can register here: https://attendee.gotowebinar.com/register/3005019550714731265?source=KB