Voice of the DBA

Category: Editorial

  • Muddle Through

    I used to work in the restaurant business. I got started after my first year at college, landing a job waiting tables in a new hotel. It was eye opening for me to see just how stressful and difficult that job can be. However, I wanted to earn money and jumped at opportunities. When we needed room service waiters to pick up shifts and elevators didn’t work, I carried trays up staircases, taking advantage of the opportunity. When a bartender didn’t show up, I volunteered to take the lunch shift. I had no idea where things were in the bar, I was 19 and didn’t know how to make drinks, and I’d make less money, but it was an opportunity that I knew would pay off at college.

    It did, and at the next three jobs, I wound up me getting hired, starting work, and having either no one to train me that day or a very busy shift where I was mostly on my own to survive. I had to muddle through and learn on the fly. The ability to do that, without panicking  being overwhelmed, or giving up has served me in quite a few positions since then.

    When I started working for various companies as a developer or DBA, I found myself in similar situations. Problems would arise, often the day or week I started, and I’d have to solve them. Usually with DBA positions,  I was the only one there, so I couldn’t depend on anyone else. It was  a good thing as I often found that sysadmins or developers were not managing or configuring databases in an efficient way. As I gained experience, I could make more and more of a difference earlier on at each organization.

    Kevin Feasel wrote a bit about his experiences with Lucerne (near the bottom), muddling through the need to write queries. I’ve seen similar stories from other friends working with SSIS, SSRS, Redis, Azure, and more. They don’t know a lot, but they dig in and learn, making mistakes, but getting tasks done for their employer.

    The ability to work through adversity, have some confidence, learn quickly, and be effective are valuable skills. Those data professionals that can do so often find more opportunities, challenges, they grow their skills, and get more compensation. Those that find reasons to avoid learning, that lack confidence in their ability to find a way to solve a problem, or are unwilling to tackle challenges often stagnate a bit. I’d like to think there are more of the former than latter in this business, but I constantly seem to find people that just look to repeat the same work they’ve done over and over for a long time.

    It can be mentally difficult to start a project using technology with which you have little familiarity. It can be disconcerting to have someone ask you a question that you can’t answer because you’ve barely begun to learn. That ability to muddle through, to keep learning, accepting that you don’t have answers but can find them, knowing that some of your answers will be wrong and you’ll need to backtrack. That ability to muddle through will serve you well.

    I’d urge you to develop it.

    Steve Jones

    The Voice of the DBA Podcast

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

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