Voice of the DBA

Author: way0utwest

  • Backups, Encryption and Branding in San Diego

    This weekend is SQL Saturday #249 in San Diego. I’m looking forward to the trip for a few reasons, but mostly because I used to live in the Northern San Diego area and love going back to spend time near the beach. I’m not sure what I’ll have time to do this trip, but since the event is in La Jolla, likely I’ll visit Del Mar, where I used to work and see some sights. A short run in the sand might also be required 😉

    I arrive Thursday because Red Gate Software is hosting a small event Friday with The DBA Team: Grand Fritchey and myself.  This is one of our mini SQL in the City seminars and is targeted to DBAs. We’ve done two so far in 2013, with (I believe) three more to come. I’ll be talking about backups this time while Grant covers monitoring and parameter sniffing. I’m not sure if we’re full, but if you can come, register and we’ll see you Friday.

    Saturday is the SQL Saturday event, at the UCSD Extension campus. I’ll be opening the day talking about encryption and then have the second session on branding yourself. I enjoy these two talks, and they’ve been popular at a number of events across the last couple of years.

    I’m hoping for good weather, especially after a rainy week in Denver.

  • If we can do it, so can you

    We hear constantly about the benefits, and potential pitfalls of cloud based applications. There are certainly reasons to move to the cloud, or stay away, depending on your particular situation and requirements. However one thing I hadn’t thought was viable was software development in the cloud. Most of the companies I’ve seen that host applications in the cloud still do the development on desktops and laptops, with a build server somewhere on site. However Microsoft wants to show us that this isn’t necessary.

    There is a push inside Microsoft to perform more of their development in the cloud. Across the last year or two, various managers inside Microsoft have been moving development to the cloud, typically starting with testing and code analysis. Those are great fits for cloud services, since they are used at discrete periods, but may requite lots of resources. One of the interesting things in the piece was that the first objectives was to speed up the continuous integration process. At Red Gate (my employer), we’ve seen a lot of benefits from implementing continuous integration, both in our applications and databases, and we’ve done a lot of work to smooth out those processes.

    Obviously Microsoft might have an advantage over many of our other companies in terms of Azure resources and cost, but I would bet the reliability is similar for their developers. If they can make it work, on products like Windows, SQL Server, Sharepoint and more, I’d think that many of us could make use of the platform as well. I know a few people that have worked with TFS on Azure, and they’ve been pleased with the performance and reliability. There are any number of other software services, like GitHub, that make use of distributed, cloud-based services for software development.

    However even if you don’t want to use the Azure platform, the idea of using virtual systems, of spinning up and down the machines you need to perform various functions makes lots of sense. You can make better use of your hardware resources, and even schedule continuous integration services (builds, tests, analysis) for different teams (or applications) at different times, improving your efficiency and not only speeding up your development processes, but hopefully improving the quality of the final code.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 22.0MB) feed

    MP4 iPod Video ( 26.4MB) feed

    MP3 Audio ( 5.2MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Risk and Assumptions

    Today’s editorial was originally released on Jan 22, 2009. It is being re-published as Steve is on vacation.

    I was reading Buck Woody’s blog the other day and he had a post on Risk where he quoted Warren Buffet: “Risk comes from not knowing what you’re doing.” I think that’s true and that’s part of the reason we’d had issues in our financial markets over the last couple of years. It’s also the reason that we have issues in many of the systems that we build.

    Often the people building IT systems go through an extensive evaluation to determine the needs and wants of their users. It’s an attempt to identify exactly what to build so that the user is pleased, a good estimation can be made, and everyone finishes the project happy.

    And that almost never happens.

    There are people that are better at this than others, but the overall state of the software development process is pretty poor. That means that any project you undertake, or that your customers or clients ask you to undertake is fraught with risk. I can see why there are plenty of people that don’t want to hire contractors to get software built, or that our management doesn’t want to start new projects with their IT departments.

    I don’t have a solution, and I’m not completely sure where the problems lie, but I do know that as the economy slows, people have less tolerance for risk. That means less IT projects, and potentially the need for less IT staff and contractors. Which then contributes to the slowdown of the economy as there are less people at work.

    If I were working in IT or consulting right now, I would be working to lower risk as much as possible. Adopting techniques that you are confident in, learning new skills and then applying them, even in side projects, can help grow your skills, increase the chances of projects being completed that the client is happy with, and keeping you employed. Now is the time to reassess the way you work, and find ways to show that you can work with your clients to meet their needs in an efficient manner.

    Efficient in their eyes, not yours.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.mevio.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Versions of Disaster

    Today’s editorial was originally released on Jan 13, 2009. It is being re-run as Steve is on vacation.

    I wrote about versioning of old software recently and how I had to restore an old version of SQL Server in response to a lawsuit. We had some challenges because the backup file that we had was from years before and we weren’t sure which version of SQL Server we needed. I forget how we finally determined which service pack was needed, perhaps we read master somehow to get a build.

    In any case, when you apply patches or change how SQL Server functions, you can change the way that code is executed or even the results that might be returned to an application. You would hope that code would break and error out rather than return different results than you expect.

    Since many of us patch servers when Service Packs come out, or when we find a hot fix we need, and we are constantly deploying and changing code, do we pay enough attention to the server version as we make these deployments? I started thinking about this after the last editorial and I think that we often take it for granted that we can easily recreate our environments.

    Consider what would happen in the event of a disaster. Suppose that one of your server instances, any particular instance, died and you had to go back to a backup of the database, would you know what version of SQL Server is needed? Do you know what version each of your instances is using right now?

    In some ways this makes me think that only installing RTM and Service Pack versions in your production environment is a good idea. It’s easier to track things if you keep all your instances within a very narrow band of versions, and the worst case would be attempting a restore on RTM, then SP1, then SP2, etc. until you hit the correct version. Imagine now if you had to work through the various builds on my build list.

    I used to think that I’d want to keep current on my patches. In one large environment, we were actually pretty good about deploying patches to hundreds of instances inside a month, so we always had a large percentage of our servers, and usually all the critical servers, at the same patch level. However if a disaster had occurred within the month, we wouldn’t necessarily have been sure of what versions were installed.

    I really don’t have a great recommendation on how to handle this other than build some automated system that tracks the current build number on a daily basis, perhaps even putting it in each database. At least then you’ll have it handy in the event of a disaster.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.mevio.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.