Voice of the DBA

Category: Editorial

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

  • Hadoop and SQL Server

    There has been a lot of media attention to Hadoop in the last few years. In fact, Microsoft has spent a lot of resources to build the HDInsight version of the platform and integrate it into SQL Server. I’ve read quite a bit about how to setup and query with Hadoop, but haven’t used it for a real project. In fact, it seems relatively few people seem to be finding it to be a replacement for, or better solution than, SQL Server. We published a great introduction to Hadoop written by David Poole awhile back, and recently I ran across another nice writeup from someone I think is a very talented SQL Server professional.

    Michelle Ufford (@sqlfool | b) wrote a piece asking if Hadoop is better than SQL Server. Michelle notes that Haddop is a different platform, and it’s a great way to consume lots of data. In fact, she has a graph from EMC talking about the data explosion and how we still at the low end of the exponential growth curve of data production. It’s a sobering thought and I tend to agree with Michelle and EMC on the growth of data.

    I had hoped Microsoft would do more with Filestream and Filetable to help meet the challenges of large volumes of data, but it seems that very little has been done with those features in the last version of SQL Server. I have little hope that additional investment will come in the future. Instead, it seems Microsoft is leaning towards using Hadoop as one way to process and consume large volumes of data.

    I wrote about Hadoop in 2009 when it was a young project, and I suspected it would enhance and work with, rather than supplant, the RDBMS. There are certainly other technologies out there to help with this, but if you are working with large volumes of data that exceed what a single instance of SQL Server can handle (at a reasonable cost), you might think about learning a bit about Hadoop. It might not solve your issues, but if it can, it would be good to know something about it.

    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.