Voice of the DBA

Category: Editorial

  • 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

  • Less Pay, More Convenience

    Would you want to work here instead of your office?

    Would you take a pay cut to be able to telecommute? I would, and I have in the past. I took a pretty substantial pay cut to work full time for SQLServerCentral almost a decade ago. It was an impact to me life, both positive and negative, but overall I think it was for the better. We had less money to spend, but I got more time with my kids, which was infinitely more valuable to me.

    It seems that I’m not alone as over a third of IT professionals surveyed would take some pay cut to stay home. The quality of life increase, lower costs, and less stress are definitely worth the trade off and I think more and more people are starting to try to convince their employers to allow remote work.

    However employers are slow to catch on. Most of the jobs that are posted don’t have telecommuting as an option, and many managers are reluctant to allow remote work. I know that I interviewed for two jobs in 2002/2003 and in both cases, they were reluctant to allow me to work at home. For one job I offered to take less money and work from home 4 days a week, but my offer was refused.

    I think we are a long way from telecommuting becoming a common way of working in IT. It will likely take a newer generation of managers and directors that have grown up with the idea of working remotely and with the technology that allows effective work from home to change the prevailing attitude.

    Not everyone wants to telecommute, which is fine. However for those people that do, I think you should make a case for remote work, show examples of how it can work and maybe even decide on some SLA for the way you work. Show your manager that you are willing to work with them to prove it can work and maybe you’ll get the chance to perform an experiment.

    Steve Jones

    The Voice of the DBA Podcasts