Voice of the DBA

Category: Editorial

  • The Cost of Switching

    I read the book Space Prison a few years ago. It’s about a group of humans, attacked and left as prisoners on a harsh planet. There’s a few hundred of them, many dying in the first few weeks. They must fight just to survive against the planet’s weather, as well as it’s plant and animal life. However they persevere and get revenge on the race that left them there. Not the survivors themselves, but their descendents, hundreds of years later. It’s a story about a group of people truly investing for the future. Not one they’ll see, but one their children’s children’s children will experience.

    I thought about that when I saw a post from Ray Terrill asking for AlwaysOn Availability Groups to be a part of Standard Edition in the next version of SQL Server. He makes a few arguments, but one that is interesting is the idea that the other possibilities for databases with good HA/DR cost less. I certainly agree that the cost of switching, and retraining (or rehiring) is high, it’s all about how you approach things.

    If a company really wants to play long ball, to look to the future and start making decisions for not the next year or two, but for ten years in the future, then is the cost of switching high? Imagine I’m a medium sized company with 500 employees. I have some IT staff (10-20) and say 20 SQL Server standard instances for various things. Replacing one SQL Server that provides basic database services now with something like PostgreSQL might slow me down in development for a couple years, but my staff would gain experience, and I’d have options. I might easily be able to replace more of, or all of, my instances in the next five years. Every decision from then on might be whether I get value specific to SQL Server, or can I use another platform that costs less.

    I know that overall SQL Server provides fantastic value and there isn’t anything else that can replace it wholesale, but the base level of database services that many applications need can be provided by other products, and unless Microsoft gives us good value in Standard Edition, I think it’s a matter of time before the people writing the checks start to think about other options. Good security, encryption, and HA/DR are becoming not “nice to haves”, but necessary for many applications. However not so necessary that I think I want to pay Enterprise Edition prices for most of my applications.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Taking Care of Things Today

    I get the weekly SQLskills newsletter, which I always find interesting. There’s usually a video on a topic that teaches me something, and as an avid reader, I enjoy hearing about the books that Paul Randal has read. However the main part is called Paul’s Ponderings and often has some thoughts that really make me think.

    In one of the recent newsletters, Paul talked about carpe diem, seize the day, and how we shouldn’t let things slide to tomorrow if we can do them today. The examples relevant to DBAs are some maintenance or preparation items that can be tedious or onerous (Paul’s words), like practicing restores for DR, checking indexes, and tackling some documentation.

    Many of us procrastinate tasks at times. Some of us procrastinate constantly, and if we don’t have any impetus pushing us to complete an item, we may delay it indefinitely. I’ve certainly been guilty of that, but I also have learned that I need to tackle some of those tasks regularly. I certainly want to be sure that my instances are healthy, and for me that’s often meant the tedious tasks of checking backups, space, and indexes as well as practicing restores, even when things were running smoothly. These can be mind numbing tasks, especially when you have scripts that do much of the work, but they really do ensure things continue to run smoothly for long periods of time.

    There are plenty of methods for motivating yourself, but I’ve found that setting a few monthly reminders and bunching up smaller tasks allows me to get all the busy work over with at one time. Being a DBA requires some creativity and skills, but it can also require a nose to the grindstone on a regular basis, no matter how boring that may be.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • Debugging SQL Server

    One of the tools that I found useful early in my development career was the debugger. Being able to track the values of variables, check the call stack, and pause execution of programs was handy. Early in my career, the tools were very rudimentary, but the latest debuggers in Visual Studio are quite advanced. I remember using a great debugger in Rapid/SQL years ago that helped me with some SQL Server 2000 code.

    There are debugging tools included with SQL Server, but the last time I used them, they seemed to be a bit flaky. However the need to follow your code slowly along it’s execution plan hasn’t changed. I’m curious this week, what many of you do inside of SQL Server to debug your code. I wanted to ask you this week:

    How do you debug your applications that work with SQL Server?

    These could be .NET applications that query the database. You could have ETL processes using SSIS or some other tool that you work on. Perhaps you have a system that runs entirely inside SQL Server and you need to untangle your T-SQL.

    Do you use Visual Studio tools? Have you configured the T-SQL debugger? Are you a PRINT statement or temp-table-for-results developer? Perhaps you have logging or some other mechanism that you use?

    Let us know this week what works well for you, and if you’ve found a particular technique to be handy in a situation, we’d love an article that might teach someone else how to debug their code.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • A Little Empathy

    In the past, there have been times as a DBA when I’ve been annoyed by the clients submitting tickets to IT. I’m not sure if those incidents were more frustrating than the work I’ve done as a developer for customers, but both can be very annoying and stressful for an employee. I’ve probably acted poorly and said things I didn’t mean while I was upset. I hope I’ve learned to do better by now.

    Things were worse earlier in my career, mostly because over time I developed a more perspective and empathy, both of which Tim Mitchell talks about in his post on perspective. I learned that no one was intentionally trying to be difficult. Each customer or client had their own tasks, and often it was technology that was slowing them down. The only reason they asked me to do some work was that they couldn’t get their work done.

    Much like Tim, I learned that technology doesn’t exist for technology’s sake. If you just want cool technology handling a task, buy a Raspberry PI or Arduino, get some sensors, and build something amazing. However, if you want to be successful in Information Technology, and have people value your applications, systems, and services, learn that you need to solve problems. Learn how to make other people’s work easier.

    I’ve had plenty of success in my career by following Tim’s advice. I’ve made myself part of the business and learned how I can address the problems and challenges faced by others after I’ve learned what those issues are. I’ve also learned that just asking a business person to tell me what to do often results in neither of us being successful.

    Steve Jones

    The Voice of the DBA Podcast

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