Voice of the DBA

Category: Editorial

  • Valentines Day for Data Professionals

    It’s Valentine’s Day today, and if you’ve forgotten, you still have time to do a little shopping or show your partner that you value them. While this isn’t a public holiday in any country that I know of, many people do want to celebrate with someone special to them. In fact, if you forget about this day, chances are the next few might not be so pleasant.

    For many of us, we’ll spend nearly as much time at work each week as we might spend with our families. Between a few extra hours here and there at work, commuting, and sleep, it may often feel like we spend more time at work. Hopefully that’s not the case, and if it is, you should re-evaluate your current position.

    Most of us do have a relationship with our career. We’ve chosen it for some reason and are often locked into doing certain work in the short term. With today being a relationship holiday, I wanted to ask you to think about if you really love your career?

    I’m not speaking about your current job and employer. You might enjoy being a developer, DBA, or other data professional while not being enamored with the position and place you work now. I’m asking for the long term, are you happy with your career choice and looking to continue moving on this path.

    If you are, good for you, and I hope you find a great position that suits your life. If not, it doesn’t matter what you’ve done in the past. You can start moving forward in another direction today.

    I love my job, and I’ve enjoyed the last 25 years of working with SQL Server. I don’t know if I want to do another 25, but I certainly am still in love with my choice today.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Cloud Safe

    I saw a question recently from an individual that was trying to decide if it made sense to move their databases to the cloud. In this case, management wanted to move, but the technical staff had concerns about Disaster Recovery in the cloud. These are very valid concerns for any system, as technical staff is often responsible for data, regardless of who decides on the architecture of a system.

    The concerns got me thinking a bit. Is the cloud safer for DR? It’s certainly an “it depends” question, especially as the “cloud” isn’t necessarily the same thing for each of us. Some of us would use IaaS, with VMs in the cloud. Others might choose PaaS, with RDS or Azure SQL Database as a platform. Still others might want something like Managed SQL Instances, which is like IaaS+, or maybe PaaS#. I’m not completely sure how to classify this.

    In any case, your choice of cloud architecture can mean better or worse DR. The closer you are to IaaS, the more that you still have the same responsibilities that you might have inside your own data center. The difference is that hardware replacements or options are often quicker to procure, though perhaps with limited choice.

    If you choose PaaS, then you have different DR capabilities and responsibilities. Your vendor might handle some aspects of DR and remove the need for you to worry about hardware, or regular backups, but you might need to worry about other items. Your vendor might give you PIT recovery, but you might not want a database replacement in a busy system, especially if you’ve processed a few thousand transactions since someone ran that UPDATE without a WHERE batch. In that case, perhaps you want to ensure you can restore your database elsewhere, or you have other options.

    Many of us know that managing systems is complex work. Not every environment can be handled in the same way, and we often implement exceptions in both technology and staff knowledge. Ensuring your application and environment can recovery from a DR situation often requires detailed knowledge of both requirements and capabilities of the environment. While I’m not afraid of migrating to the cloud, I’d want to be sure I was prepared to answer questions from management if there are issues. After all, they’re going to look to me, not some vendor, for answers.

    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.

     

  • Production Scripts

    One of the most useful parts of SQL Server is the SQL Agent scheduler. Over the years I’ve used this subsystem to automate work and ease the administrative burden of running a SQL Server instance. At times I’ve even used my SQL Agent to fire off business reports and alerts to nontechnical people that might need to take some action based on the data in our system.

    One common task that I see SQL Agent used for is to backup a database using some method (Ola’s scripts, SQL Backup, etc.) and then delete the oldest backup. This is a common way of ensuring that you keep xx amount of backups around for your business. Often if the first step (the backup) fails, then the second step (delete backup files) doesn’t run. There are times where the execution choices between the steps aren’t configured or get changed, and you run into the situation that Paul Randall describes in issue #170 of the SQLskills newsletter. The backup step starts to fail, but the deletes keep running until you don’t have any more backups stored.

    How does this happen? It’s surprisingly easy because most people don’t really treat their SQL Agent scripts and code like other code. This often isn’t tested well, and rarely tested across time and with unusual conditions. After all, who wants to muck with the time on a production server to be sure that your Agent job works across days? Who wants to force a backup to fail to see how the job handles an issue? Who wants to double check their code when BACKUP is fairly simple syntax and a few quick tests of the delete code works with text files renamed with .bak extensions?

    Do you treat your SQL Agent jobs like the production code that they contain? You should. In fact, moving to a more reliable, repeatable, DevOps style environment means that any code in an Agent job needs to be version controlled, it needs to be tested, and it should be a part of some (hopefully, automated) deployment process that ensures that changes to the code are recorded and you are confident of which version of code is on your system.

    SQL Agent is a powerful tool, but it’s also one that should be treated like a production system. Downtime and simple errors from careless scripting shouldn’t be tolerated. We should, and can, do better.

    Steve Jones

    The Voice of the DBA Podcast

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

  • What to Read in 2018

    Last week I was looking for Database Weekly links and ran across Gail Shaw’s list of books from 2017. It’s an interesting list of fiction, and I might pick up a few this year if I run out of ideas. This reminds me of Paul Randal’s review (done annually) of his reading. I usually find a book or two in there that I’d like to read to enjoy a break from life or expand my horizons.

    I was thinking about this as I’ve seen a few other posts from software and database users with books that they recommend. This was an interesting list from Xiaohan Zeng and I like this general list from John Sansom for SQL Server. I’ve run across a few others, especially from all the learning plans that people built for T-SQL Tuesday #97.

    I have no shortage of fiction that I enjoy reading on a regular basis. This is a way for me to get a break from life, and I’m usually working my way through some book. This month I read the Will Robie series from David Balducci (1-4) and then started re-reading the Jesse Stone series by Robert Parker and others. Those are my downtimes and breaks from life. In the professional area, I’ve been working my way through R in a Nutshell as well as Thoughtful Machine Learning in Python. The latter has been ongoing for some time, and moving rather slow. It’s a tough one to go through.

    There are classic texts in our industry, as well as some really interesting ones that many of us might enjoy. Perhaps there is something you’ve read in the last year you recommend, or there are some you want to tackle. Today I’m asking for your reading recommendations.

    In our careers, I know many of us like shorter, focused posts, some like videos, and others prefer learning in person from others. Those are all great ways to learn, but I still like working through a book to either focus my learning or escape from life. Let us know today what you plan to read this year or what you’d recommend for others, either to help them become better database developers or just enjoy a good story.

    Steve Jones

    The Voice of the DBA Podcast

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