Voice of the DBA

Category: Editorial

  • The Final Service Packs

    There was an announcement recently that Service Pack 3 for SQL Server 2008 R2 was released. This is the final SP for that version and is mostly a rollup of all the previous cumulative updates (CU), though there are a couple additional items included.

    This is good news, and if you are running the “R2” version, I’d test this and install it. No more CUs will be released, though you’ll want this SP installed in case additional security patches are released during extended support. The last thing you’ll want is a crisis situation where you need to install a security patch based on SP3, and you haven’t tested this update.

    Earlier this year, Microsoft announced that we’d get one last SP for both SQL Server 2008 and 2008 R2. That was good news as many people are running these versions, and they haven’t installed all the previous CUs. I can understand this situation, and it would be good to bundle all the changes together in one final patch for companies that find the platform suits their needs. It’s also a fair request for customers that paid Microsoft for  a platform and should receive all patches developed during its lifecycle. Including a final patch that closes out support.

    I’m still waiting for an SP4 for SQL Server 2008 and I hope we get one soon. I’m not sure what the plans are for SQL Server 2012, 2014 and future releases, but I’d like to continue to see the bi-monthly CUs, an annual SP, and a final SP when each version transitions from mainstream to extended support.

    Steve Jones

    UPDATE: SQL Server 2008 SP4 was released just after this was written. It is available here: http://www.microsoft.com/en-us/download/details.aspx?id=44278

    The Voice of the DBA Podcast

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

  • Life Logging

    This editorial was orignally published on Dec 8, 2009. It is being re-run as Steve is on vacation.

    There’s a new book from Microsoft Research called Total Recall. It’s actually on my list to read soon. It’s from Gordon Bell of Microsoft Research, and it talks about the idea of life logging, of capturing things about what you do and what you’ve done, in audio, video, and text. These might be things that are private, available to you and not the public. Or things that you might want to share with some people, like your family, but not others. Dr. Bell actually carried around devices to record his life for a long time, with the idea of working through the technological hurdles of life logging.

    Whether you think you’d like this in your life or not, it’s an interesting knowledge idea for companies or individuals. Maybe it’s a good idea for programmers or DBAs. What if you could have all the code you’d ever written? What about tests of that code and the applications where it had been used? Would a walkthrough of tuning efforts you’d made for some types of SQL or even queries that solved particular challenges be useful? What about a walkthrough of the changes to your schema across time?

    There are some interesting possibilities here in terms of your career work. If you could add meta data, annotations, correlations between emails, requests for work, problems, your particular implementation, and then the later results,  you might learn from your mistakes quicker. You could perform some type of root-cause analysis of your efforts across time, or on a system and find out what you are doing wrong, or what you’re doing well.

    I don’t know how well you could analyze someone’s work and help them find out what they’re doing well or not well. I also have some serious concerns about the privacy and security of the details about someone’s efforts being shared without their consent, or even the ownership of this data. But I think there are some great possibilities here as we develop new, and cheaper, ways to collect and store all kinds of data.

    At the very least having a “life log” of a server might prove to be a very valuable troubleshooting tool.

    Steve Jones

     

  • Challenge Yourself

    I am a proponent of blogging as a way to build your brand. Your work showcases your knowledge, thought process, and interests. It provides a way for potential employers to perform due diligence and determine if you are a good fit for their team and position. Blogging can also help you to learn more about your craft and focus your learning. After all, it’s been said that if you can’t explain something to others, perhaps you don’t really understand it.

    As I meet people, and talk to them about blogging, I often get asked “what should I write about?”. The easy answer is to write about the things that you do on a regular basis, the problems you solve at work, and the solutions you implement. However, what do you write about if you don’t do much at work and are looking to learn new topics. If you want to show that you are building experience with SQL Server in a way that isn’t required at your current position?

    I think it’s easy, and I’ll give you a few ideas. First, build a lab at home. These days it’s easy (and free) with VirtualBox and a little memory, both of which can be had for relatively small investments. Next, start following the #tsql2sday tag on Twitter and challenge yourself to get a post written every month. However don’t stop there. I keep a list of previous topics and you can go back and write a post for every one of those topics. Your effort won’t be in the recap, but you’ll force yourself to learn, or at least explain, your thoughts in those areas.

    If you want additional challenges, read a question like this one on splitting strings. Don’t read the replies, but try to answer the question on your own by writing a blog that explains your solution. You can link to the post and show how you would solve the issue if you encountered it. If you want to press yourself further, go through my list of article requests and pick one. It doesn’t matter if the article has been written and published or not. Write your own solution on your own blog, as I saw Jason Carter do here for this request on exporting XML files. Feel free to submit your post as an article, and maybe we’ll publish your solution as well.

    There are so many ways to challenge yourself and learn more about SQL Server that it could be a full time endeavor by itself. Please don’t make it one, and remember to balance your career growth with the rest of your life. However, do continue to work regularly on your career, and showcase your knowledge. It’s good practice for your communication skills, and you never know when you might count on the wide breadth of knowledge you’ve documented to help you land that dream job.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Database Checkups

    I am most definitely a fan of continuous delivery (CD) and the idea that we have the ability to both release our software at any time, for any change, but also have the process and mindset in place to rapidly push enhancements and patches through our development process. However I’m also no naive enough to think that the processes of Agile, Lean, Scrum, Continuous Integration, or any other methodology make this happen. It requires belief and effort by your entire team, including management, to evolve your software quicker.

    There is a downside. The faster, and more often, you release changes to your production system, the more likely you are to cause an issue. This isn’t really any different from traditional waterfall processes, which also cause issues in production, but it does mean that the perception of issues is a bit changed. People expect higher quality when they implement a CD process, and while quality might be higher (there is debate on this), it certainly isn’t perfect.

    Walgreens has implemented a CD process, and they rapidly deploy changes, but they’ve also had issues. In fact, there’s a piece that talks about an issue during a database deployment, and offers some guidance on preparation to deal with problems in your deployment process. The ideas of monitoring (which is critical), planning for recovery, coordinating development, etc are all things that we need to do in any production environment, but they are especially important in a CD process where people expect changes quickly. Whether those changes are enhancing the application, or rolling back a problematic deployment, they need to happen quickly.

    Over time, which may be decades, I expect that more and more organizations and end users will expect patches and changes to their software to happen in the background, while the system is being used. This might mean we need to plan for application architectures with sections that can be upgraded separately, or maybe we will develop ways to modify executable code without ending the process. In either case, the ideas behind CD will become more and more useful, and the more you understand them, the better off you’ll be.

    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.