Category: Editorial

  • The Intelligence Cloud

    The Air Force Academy Chapel

    I was thinking to call this the “Military Intelligence Cloud” but no one would believe it was true. Apparently the US Air Force has awarded a contract to build an intelligence platform that will allow different branches of the military and agencies to share data. And, by the way, they will be building a cloud based system.

    I’m not sure why the “cloud” is such a buzzword and why everyone thinks it results in cost savings. Supposedly a “private cloud” based system is being used for cost reasons, and because the public cloud services like Windows Azure and Amazon’s EC2 might not be secure enough.

    However what is a private cloud here? Isn’t it just an outsourced set of systems hosted elsewhere? It seems as though many companies and journalists are selling the cloud as some sort of new technology? Isn’t it just a set of hosted servers that are just virtual machines? Or is it just a set of servers that are standardized somehow in their configuration and capabilities?

    It seems that all the press, and all the commercials from Microsoft might be working, and the collective managerial sheep herd is flocking to the cloud as some amazing new change in the way their systems will work. If that’s the case, I’m not sure this new cloud service will be any more intelligent a move than and other outsourcing decision.

    I think there is promise in a more abstract, more ephemeral type of platform in the cloud, but it seems as thought we might be a long way from actually implementing something like that.

    Steve Jones


    The Voice of the DBA Podcasts

  • Temporary Indexes

    Temporary placeholders can be valuable

    Recently I was studying for the MCM exam and one of the things that came up in my research was the idea of temporary indexes. I had never used them before and was intrigued by the idea. I have dropped indexes before a large load and then recreated them, but these are indexes I planned to keep on the table indefinitely.

    There are always processes that you run periodically on some schedule. These might be end of month, or end of year processes where you run a series of reports or queries that aren’t necessarily run at other times in your business cycle.

    Since this was a new concept for me, I wanted to ask and see how many others might actually be using this. Maybe you’ll get an idea for how to speed up some of the periodic, but very important, processes you run. For this Friday:

    Do you use temporary indexes?

    By temporary, I mean indexes that you create for a process and then discard at the end of a process. These could be indexes that you use to supplement some type of data load, perhaps indexes used in staging tables. Or they could be indexes that are added to some OLTP tables for the processing of certain reports in a short period of time.

    However you might implement them, let us know how you use them, and how they have improved performance for you.

    Steve Jones


    The Voice of the DBA Podcasts

  • When To Hire a DBA

    How busy should someone be before you hire a DBA?

    One of the things that I often see on SQLServerCentral’s forumsis a developer struggling with an administration issue or a complex query. It’s natural and even expected since many developers are not as familiar with SQL Server as they are with their development platform. It’s great to see them trying to get help and work through issues and there are many generous volunteers that give their time and knowledge to help.

    Recently I found a post where a developer was struggling with a variety of problems: design, backups, and more. It was obvious this person was overwhelmed and when someone suggested hiring a consultant, this person noted their boss didn’t want a DBA consultant, and wasn’t willing to hire a DBA. Management didn’t feel like there was enough work to justify a full-time employee.

    That’s an issue that I think many companies face. When do they hire a DBA and when is it beneficial for them? I’ve had this conversation before with employers, and while I’ve seen small companies benefit from having me as a DBA, I also know that I’ve contributed in ways other than just with helping with the database platform. I have helped administer systems, develop applications and more.

    I think part of this is the fault of the database professional, who has a stereotype of being difficult, stubborn, and resistant to change. It’s also hard for many database professionals to quantify exactly what they do and show explicit value for their services. They don’t build new features into applications, often don’t interact with customers, and regularly answer question with “it depends.”

    The ROI for a DBA is something that can be hard to explain to management, but it’s something that I think needs attention from all SQL Server professionals. If we can better explain our jobs, develop standard tasks and benefits that DBAs show, we can help ensure that more companies see the benefits and value from employing a DBA. If you have any ideas, please add them to the discussion for this editorial.

    There’s also a nice opportunity here for hybrid DBAs, the kind that come to conferences like SQL Server Connections. Doing a little developer alongside your DBA work might get you some jobs in smaller, more flexible, and more fun companies.

    Steve Jones


    The Voice of the DBA Podcasts

  • Showing Its Age

    Are these computer too old to be in production?

    I went to register a new car recently at the DMV and couldn’t do it. Apparently the state DMV system in Colorado was down that week, and had been down for two weeks because of a DR situation. The primary system had failed, and after being down, the state agency moved to their older, backup system. However when that failed, many of the remote offices were down and were issuing extensions to car owners for registrations.

    I am guessing that the Colorado state DMV system runs on some sort of mainframe or mini, and not on a 15 year old PC architecture. However I do know lots of companies that are working on older software, often on older versions of Operating Systems that might struggle to work on newer hardware. It makes me wonder if we will start seeing these types of problems for database applications over time as companies look to extend the lifetime of their IT infrastructure.

    There was a time when it seemed many companies were refreshing servers every 2-3 years, and they would upgrade to a new version of their OS or database platform whenever the vendor released it. However the last 5-6 years have seen many people holding on to older systems. I know lots of companies that are on 4 or 5 year hardware refresh cycles, and there are still lots of SQL Server 2000 instances still running out there.

    For awhile it felt like keeping a database application alive for 10 years was a stretch, but as I look at the evolution of SQL Server, and the power that we have with modern hardware, it doesn’t seem like a stretch. The advances in virtualization can prevent newer hardware architectures from being a problem, and perhaps even extend the lifetime of old software significantly.

    I do think that the latest releases of SQL Server are much, much more efficient and powerful than previous versions. Today’s hardware can even be more cost effective given the price of power and cooling. However if all you need are core database engine features, I’m not sure it’s worth upgrading. Just be sure that you have a better backup plan than the CO DMV.

    Steve Jones


    The Voice of the DBA Podcasts