Voice of the DBA

Category: Editorial

  • Security and Patching Struggles

    A couple weeks ago we had a huge security issue with the WannaCry ransomware racing across the world. I was out of the office, and mostly offline, so I was a bit out of touch. However, many organizations were affected, and I’m sure many infrastructure people were scrambling to patch and protect vulnerable systems, possibly even restore affected systems. I certainly hope that most (or all) organizations didn’t pay any ransoms. For the future, my view is it’s better to lose a little data and restore systems than pay ransoms.
    I can remember when we got patches at random times, as vendors wanted to provide more functionality or finally had enough bugs fixed to release a patch. Sysadmins struggled to deploy these patches, being out of practice from the infrequency and struggling with non-standardized ways of applying updates. There was also the concern about the quality of patches, many of which introduced more bugs and issues. In the Windows world, I found many companies wanting to wait until an SP2 was released before applying, or even upgrading, many systems.
    That changed, with many companies moving to regular patches, and standard ways of applying, or even slipstreaming, patches easily onto machines. I welcomed the Microsoft Patch Tuesdays, as this provided a regular release, an expectation, and both admins and users became comfortable with the idea of regular patches. I haven’t loved the auto patches in Windows 10, but I find myself agreeing with Troy Hunt that we should just be patching. In an organization you may want someone to be responsible, but for home users, just patch.
    And, by the way, vendors, you need to do more work, and be more responsive to any issues that come up from patches. Your quality issues lead to greater security issues.
    If you want to ready about the WannaCry issue, there’s a good general post, as well as some guidance from the SQL Server perspective. If you haven’t patched, that’s something you should do ASAP, and while you’re at it, be sure you have the latest security patches for SQL Server applied. I’ve got a series of Build Lists at SQLServerCentral, one for each version. I’m still nervous about applying Cumulative Updates too quickly, but I certainly would download and have them ready, perhaps applying each a month late once once the early adopters have had a chance to report any major problems.
    Patching is a reality for the modern software world. We get regular patches for applications, but our core infrastructure (including servers, desktops, and various devices) also need patches to the OS and platforms. There’s a balance between ensuring stability with known softwre versions and keeping up with patches to prevent problems. We need to find a balance, which is probably different for each organization, and re-evaluate periodically if we are updating an an appropriate level. I lean towards fewer patches when I can, but I always want to keep up with security patches. We never know when someone will take advantage of those.
    Steve Jones

  • Less QA?

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

    Throughout most of my career, people have complained that software is never tested enough, not tested well, and certainly not enough time is allocated in project plans. I’d also argue that all too often we don’t have people building software with experience in how to perform extensive testing. Most developers only have a rudimentary knowledge of software testing and that part of their skill set doesn’t receive constant training. However I’ve found plenty of QA people that were in the same situation. Some educate themselves and learn how to test better, but many go through the motions. They don’t take pride in their role as a software tester.

    There have been lots of advances in automated testing and TDD methodologies over the years, which means that developers have been taking more of the responsibility, and effort, for testing code. It’s hard to know if this has resulted in higher quality code, lower quality, or a mix. Overall I think that the latter is likely. Code quality is all over the board, probably based more on the skill and talent of the individual developer than on any process.

    That’s good for the companies that have hired strong developers, but not so great for our industry as a whole. We still produce lots of software that takes too long to develope, costs too much, and often has too many bugs. Overall we are sloppy and inconsistent in how we build software. Some of that is the nature of our business, one with such a low bar of entry that anyone can give software development a try.

    I don’t know how we improve the quality of software, though I do think continuing to educate and train people on what works well is a good start. However I also think that we still need QA groups. We need people that will use software in ways that automated tests won’t. People that will press buttons, enter values, and push software in ways that developers would never consider using it. Most of all, we need QA and testing to be treated as a valuable part of our industry. We need QA people that view testing as a valid career path, not a stepping stone for junior developers that look to move on as soon as possible.

    Steve Jones

  • Balloons and Data

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

    We see a lot of questions at SQLServerCentral repeated over the years as workers new to the platform encounter some of the issues that many of us have dealt with repeatedly over the years. One of the more common questions that I see in the SQLServerCentral forums has to do with tempdb growth.

    Many people coming to the SQL Server platform realize tempdb is a workspace, but they don’t always understand how it works. Many times I see questions where people don’t understand why tempdb will grow from it’s default size. Even more surprising is that they don’t understand why it doesn’t shrink back to the default size. After all, it contains temporary information, and when it’s not being used, the size should shrink, right?

    If only that were true, it would make administration simpler, though performance might be worse. Many people view the files in a computer like balloons. We add data and they grow. We remove data, and they shrink. However that’s not the model for SQL Server files. Our mdf/ldf/ndf files are allocations, and once we allocate space, we don’t remove it if no data is present. The allocations are available for the next time we need them, minus the time we spent requesting and receiving the allocation from the Operating System.

    The space you need for tempdb is the peak space you need for the largest set of temporary operations in your workload. Even if all your data sets are small, say 100kb, if you have 1000 of them occurring at once, you’ll need 100MB of space. With sorts, intermediate worktables, and more, you could easily have an average data set above 10kb, which is why your tempdb size might need to grow.

    Just like with any other database, you need to monitor the size and load for tempdb. Adjust it as needed, based on your requirements, so that it will be properly sized each time to start the instance. The administration level isn’t high for tempdb, as long as you have monitoring in place and you periodically perform the administration to appropriately size your system.

    Steve Jones

  • Three Days and a Notebook

    This is a short week of work for me, really just today before heading off to attend Microsoft Build 2017. I’ll spend the rest of the week watching Microsoft show off their latest tools, ideas, technology, and more at the developer’s conference. I’m not speaking (I think) and am looking forward to three days of learning, watching, and getting excited about building software that for the most part depends on data in some way. I’m not sure what will be presented, as the schedule hadn’t been posted as of the time I wrote this, but I’m sure there will be plenty of Azure and SQL to go with all the Windows and .NET sessions. I’m especially interested in ways that DevOps is making its way into the Microsoft stack and looking forward to seeing the creative solutions out there.

    I haven’t attended Build since it was the PDC many years ago. It’s been since the early 2000’s when I went to a few of these events as a software developer. I first saw Microsoft showcase XML tools in the late 90s and tablets a few years later.  I always enjoyed these shows and after a few years off was looking forward to going back. Then they cancelled the event before it was reborn as Build. I’ve been trying to schedule a trip for the last 4 years, but scheduling keeps getting in the way. I know, it’s a hard life, and I’m not complaining. It’s been disappointing for me.

    Last year I was actually offered the chance to go speak on behalf of Redgate at a session, and I did go, but with volleyball trips planned with my daughter, I was in San Francisco about 24 hours, saw 1/2 of the keynote and part of one session (besides my own) and then left. Not much of a Build event for me. I didn’t even have time to go through the HoloLens line and give it a try. However, I had a few days with my daughter, so I can’t complain at all.

    This year I didn’t have anything scheduled for May and got the chance to register early. I plan to try and leave my computer in the hotel room and work little. Instead, I’ll walk around with my notebook, jot down ideas, and just think a bit about software, my career, and where Microsoft is going. This will be my thinking time for the week. Actually, I haven’t had much thinking time this year, so I’m looking forward to the break.

    I rarely attend any events or training without having some sort of commitment or responsibility these days. I try to fit in a few sessions or a pre-con here and there, but training time and focused time on something other than work is rare. For the first time in many years, I’ll actually going as an attendee and doing the things many of you do at SQL Saturdays, SQL Bits, the Pass Summit, and other events. I’ll be learning, focusing, racing from session to session, networking, and hopefully overdosing on new technology.

    I’ll try to summarize notes in a few blogs, and maybe even give a short recap as an editorial one day, but this should be a fun technology week for me.

    Steve Jones

    The Voice of the DBA Podcast

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