Voice of the DBA

Tag: career

  • Hire the Right People

    I’ve seen this list of why projects fail going around the Internet for awhile (recently from Brent Ozar Unlimited).  There are a number of items in here, and if you substitute some other field for the data scientist part, you might have seen some of these issues as well. One of the items that really struck me was number 5, which is titled: You shouldn’t have hired scientists. The other part of the slide is that ETL needs data engineers (whatever those are) and reporting needs BI analysts.

    I with that we had good ideas and definitions of what different jobs are supposed to do in a company, and what skills are helpful. The more I look at job descriptions and responsibilities, the more I find that DBA, analyst, data xxx-anything are just amorphous concepts that vary dramatically from organization to organization. In fact, since the title that one has often determines pay scales, I think that we start to covet titles and work towards getting a title, regardless of the work we do. This isn’t helpful for anyone, least of all HR departments that try to match salaries to value and pay for particular jobs.

    There isn’t a great solution here. Our industry is young and changing more rapidly than any other in history. New jobs are created out of thin air, to meet the changing face of software development and system administration. Build master, data scientist, blockchain engineer, and a few others didn’t exist when I started working in technology. Whether those jobs are needed in an organization might not relate to whether or not anyone has those titles, or if they perform the tasks we might expect of those positions.

    I think that many of us are expected to be able to perform any task tangentially related to our position. Or we should be able to learn it quickly. DBAs should understand replication as easily as they might Availability Groups and configuring Extended Event sessions. A developer should be able to write C# as well as T-SQL. Both should be able to use SSIS to import and export data. While I’m sure many of us could do those tasks at a rudimentary level, are we really competent and capable at each of those tasks? Maybe enough for our organizations, maybe not.

    When we embark on projects, there may be needs to accomplish tasks outside of the core competency of our staff. That’s fine, and since many people in technology are willing (and excited) to learn new skills, this situation may be perfectly acceptable for our project. When there are core skills critical to the project, such as a deep understanding of large scale ETL processes, we are probably better off hiring people that have those skills or investing heavily in just-in-time training for existing staff. Hoping that the average DBA or C# developer can just “pick up some tips” is a recipe for project failure.

    Steve Jones

  • A New Recovery Tool for Your Toolbelt

    Those of us that administer databases and are responsible for ensuring the integrity and availability of data know that being able to restore systems is a core skill. In the SQL Server world, this should mean more than just being able to run a RESTORE DATABASE Sales FROM DISK = ‘Sales.bak’. Many of us would easily recognize that we should be able to use the WITH MOVE option. We should also understand when to use (and not use) NORECOVERY and STANDBY. Perhaps more importantly, we need to know the default option is RECOVERY.

    If we delve further, perhaps we could debate and discuss when a tail log backup is needed. Many might mention how to programmatically use FILELISTONLY and HEADERONLY to generate scripts.  A few of you would note that restoring databases means restoring logs as well and an understanding of the STOPAT option is important. Perhaps learning the ins and outs of restoring a filegroup is important in your environment. There are many nuances and options with restoring a database that a system administrator could learn.

    Apart from performing a restore, a careful DBA might think that we should try to avoid restoring databases if possible. Perhaps a DR system using Log Shipping can be used to recover data quicker than a database restore. Maybe periodic snapshots are valuable in recovering from those “whoops” mistakes. As our data sizes grow larger, we may need to develop more creative ways of recovering from user mistakes.

    Recently I saw the SQLCAT team had written a post on using Temporal Tables to recover from an “oops” mistake. If you haven’t looked at these structures, they are new in SQL Server 2016. Temporal tables, or system versioned tables, allow a user to view a row as of a certain timestamp, which can be especially useful for DML mistakes. Have you ever updated every row of a table to the same value because of a poorly written query? I have. A temporal table would have been handy in this case. Perhaps even more useful are the cases where a table is receiving regular inserts and updates, which can be very difficult to recover from with backup files.

    Certainly the majority of us don’t yet have temporal tables, and we might not even set up the option on many tables even if we were running SQL Server 2016. Over time, however, some of us will use these system-versioned objects, and perhaps we will run into a situation where recovery using temporal queries is more efficient than restoring an entire database. If that were to happen, wouldn’t you want to have some skills in this area?

    As SQL Server continues to evolve, many of the techniques and skills we’ve built across time will continue to work. There will be new ways of accomplishing work, based on features and enhancements that we ought to consider, especially when they might be more efficient than our past techniques. As you work with SQL Server, I hope you keep learning about the “new” ways that you might accomplish the tasks for which you’ve developed solutions in the past. Sometimes the old way might prove to be a better choice, but you won’t know that unless you learn, practice, and measure the effects of a new method.

    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.

  • Go Code

    Should we be teaching more people to code? That’s a question I ponder, especially after re-reading an old view against the idea, a newer one, and a pro-code piece. At the end of the day, I think that coding is a basic skill, similar to reading and writing because so many of us, perhaps most of us in the developed world, will need to work with computers.

    I don’t mean to imply that everyone should be able to write an MVC application or produce a graphical application. I also don’t expect most people to understand calculus or produce a thesis. However, I do want a core competency that allows them to work effectively with a checkbook and communicate a point effectively. I want them to understand enough coding to appreciate the logical and methodical way in which computers process instructions. I’d like to have most people appreciate how to create, store,  shuffle, and retrieve a digital deck of cards.

    Certainly I think that those people who continue to learn and advance in many industries can benefit from an understanding of what a database is, how to write a query that might logically fetch information. Even if you use a tool such as Excel, Power BI, Tableau, etc., knowing the ways in which we store information and need to process it can help you better work with the computing machines in your life.

    Perhaps seeing how easy it can be to produce bugs will help people also appreciate the need for better security. I’d hope this would also have them demanding that professional software developers produce better work. Quality matters, and while I might be able to build a car, I would expect that one produced by professionals would be of a much higher quality, and much more reliable than my own efforts.

    Having a basic understanding of how computers think will not only help us understand our systems better (or the people that design them), but can also help us develop thoughts and views on how we should reconcile the digital with analog world. I strongly feel that our understanding of, and the expectations we have in the analog world are very much inadequate for assessing a digital world that can accomplish things many people would have viewed as magic a few years ago. Certainly our legal structures aren’t well equipped to work in a digital era. To help us move forward, I’d like more people to understand computing.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Bring Solutions

    This editorial was originally published on Feb 13, 2013. It is being re-run as Steve is out of the office.

    What’s your job? Most of you will answer “DBA”, or “developer”, or “manager”, or something that corresponds to your title. That’s partially true, but for the most part if you are in Information Technology, I think your job is to solve problems. You should ensure that your systems, or your code, or whatever you work on, is running smoothly for the people that use them.

    That isn’t always possible. There will be times that things break, that bugs crop up or systems fail. When that happens, people don’t want to hear about the inherent problems, or even what went wrong. They might ask, and they might be curious, but really what they want to know is when will the system be fixed and what will it cost.

    I’ve never had a manager that was really interested in the problems that caused a failure when systems were down. I’ve rarely had managers interested in potential problems I’ve noticed in our organization. Managers might be curious about the issues, but they don’t want you to bring them problems. They want you to bring them solutions when you see a problem, multiple choices to fix things, and a recommendation for the option you feel is best. They want a solution that works well, doesn’t cost a lot, and can be implemented quickly.

    Competition for jobs gets more intense all the time and the employees that look for problems and provide solutions without being asked will be the most valuable. They will stand out from their peers and are more likely to not only keep their jobs during down times, but will get asked to solve the interesting and challenging problems.

    Steve Jones