Voice of the DBA

Author: way0utwest

  • Are You a Tech Company?

    Are you a tech company. That’s an interesting question. I’m sure some of you might not think so, working for a commercial organization that has some physical product you sell or some service you provide. You might not consider yourself a tech company. However, your organization might be, at least according to this essay at Medium.

    I certainly think software has changed, and will continue to change the world. I think data becomes is an important part of our system, but in conjunction with software and the ease with which we can gather, process, extract, and analyze the information inside of our data. In order to do that, I do believe that we need ways to better build and deploy software, whether that’s database software or application software.

    To do that, can we be afraid of mistakes? I think not. The opening premise of the piece is looking at rapid delivery from two points of view. Can a system be secure if you change it multiple times a day? Or perhaps it can’t be secure if you don’t have the ability to change things. Either view could be true, and most of us lean one way or the other. My view is towards the latter, not because I want to release multiple times a day, but because if there are issues, bugs, or security holes, I need to be able to change my software that day. I can’t wait for weeks or months.

    That’s one of the problems I’ve seen with quite a few systems in the past. The time to release a new version, to patch an issue, is far, far too long when potentially hundreds, or thousands, of malicious attackers could take advantage of a flaw this week. Or our company could lose customers because a feature is broken for long periods of time. While I don’t think the cost of fixing mistakes is zero, I do think that the cost of not fixing issues is also more than zero. Certainly at times the cost of not fixing something might be much, much higher than our organization would tolerate.

    Mistakes will happen. However, the point the essay makes is valid. We should learn from mistakes, and not try to avoid them, but continually push forward to improve our software. Above all, we need to find ways to engage our employees and get them to believe they can produce better software and are empowered to do so.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The 10X Programmer

    Is there such a thing as a 10x programmer? It’s an interesting idea, and one that is discussed from a few perspectives in this Q&A. There’s some talk about how to define “x” as well as the idea that the environment and project might make a big difference in productivity. Certainly the baseline of the staff measured makes a difference. If most of your programmers aren’t very productive, then a more talented developer might easily outperform the average by a factor of 10. Depending on how you measure productivity.

    I wonder, though, is there a 10x DBA or database developer? What would that look like? If we examined the effectiveness of a DBA managing systems, I have seen DBAs that managed 10x the absolute number of databases and instances. Working inefficiently, connecting the individual systems to apply updates or check statuses could easily make you ten times less efficient then the DBA making use of scripting and the ability to apply changes across many systems, not to mention managing them for issues.

    In terms of database development, if we have some programmers that can produce code using 10x less resources than others, I’d consider that a 10x programmer. Given the state of questions I see asked on SQLServerCentral and other sites, it definitely seems that there are plenty of developers being paid to produce poorly written T-SQL code. We don’t have great definitions of how we can measure productivity, but there is plenty of code posted that can be dramatically optimized. It’s the rare week that I don’t see someone noting they’ve reduced the runtime of some code from hours to minutes. Isn’t that 10x more productive?

    Ultimately one of the amazing things about software is that we aren’t bound to a particular structure once it’s created and used. We can quickly, and easily, change the way the code is built so that it works differently, does more, runs efficiently, or really anything we want. Of course, testing that the code produces the desired effects and deploying that to different environments in a way that minimally impacts clients is a challenge, but a challenge many in our industry work on constantly, seeking improvement.

    I think there are definitely 10x programmers, but that really depends on your situation and how you utilize the people working for you.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Why We Need Backups First

    One of the things I show when I talk about TDE is that the backup of the certificate is very important. When you create a certificate, SQL Server warns you right away that a backup of the certificate is needed. Following Murphy’s Law, if you continue on with enabling TDE, right after the encryption is completed, your master database will become corrupt and you won’t be able to get to your data. It just takes a few seconds, so back up your certificates.
    I was reminded of this while reading a short piece on some police body camera footage being lost. I don’t want to focus on the police actions or cameras or anything but this statement: ” A backup system had been purchased but hadn’t been set up. “
    That’s a fairly egregious breach of duty for some IT personnel in this case. The system was installed in 2009, and this event apparently occurred during a software upgrade in 2012. While I understand a backup system might not get configured immediately, I think 3 years stretches the limit of an acceptable delay. However, even if the backup system were not in place at the time of the software upgrade, wouldn’t a backup before upgrade be required? Isn’t that a standard practice?
    There have been other reports of similar issues, which is disconcerting. It appears the use of technology for archival of data isn’t well developed, or properly understood by the IT staff in charge of the process. Of course, this happens in plenty of enterprises and other organizations where IT staff seem to think that backups are important in and of themselves. In case you’re confused, they are not. Restores are the important things to have, which means you must verify your backup process allows the data to be retrieved.
    Many of us have scripted methods that practice this regularly, refreshing other environments, restoring databases for DBCC, or some other task. Few of us actually practice this ourselves across all databases on a regular basis, ensuring our skills for tail log backups, NORECOVERY and STANDBY restores are fresh and ready for emergencies. However, we should not take this task lightly. It is important that we are able to recover data in almost all situations.
    If we can’t do that, then we are truly disregarding our duty as the custodians of data.
    Steve Jones

  • The Danger of xp_cmdshell

    Securing a computer is a challenge. There are all sorts of potential issues in every platform, and ensuring safety for your data can be less a reflection of your ability and more the good fortune there isn’t a focused effort to attack your systems. However, we certainly also face issues with inside users, many of which may make mistakes that are accidental more than malicious. It’s for these reasons that we look for secure by default applications and a reduced surface area for any system.

    Many people refuse to turn on xp_cmdshell as an option for scripting in SQL Server. This is disabled by default, and quite a few DBAs are glad of this setting. However, there are plenty of people that think xp_cmdshell isn’t a big security risk. There are certainly ways to mitigate the usage by non-privileged users, and this can be a tool that is very handy for accomplishing work without a lot of development time.

    This week, as security issues become more important to us all, I’m curious how you feel.

    Do you think xp_cmdshell is dangerous?

    I have to admit that I’m torn. I don’t think this inherently dangerous. It does open up some attack vectors, but the last few versions of SQL Server have allowed some limitations, so I would enable this if needed to solve some issues without too many concerns. However, I wonder if many of you feel the same way.

    Steve Jones

    The Voice of the DBA Podcast

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