Voice of the DBA

Category: Editorial

  • Personal Development

    This editorial was originally published on July 14, 2010. It is being re-run as Steve is on holiday.

    When we go to upgrade an instance, most of us have a process. We have a list of things we need to do, things like perform a backup, copy files, apply patches, etc. There is some definite order to what we do, and the most successful people I know in technology take the time to actually write out a list of steps to be sure they don’t forget anything, checking each item off as it’s completed.

    Why don’t we do that for our careers? Arguably that’s more important than some silly old server.

    One of the presentations that I  give at user groups and SQL Saturdays is my talk on The Modern Resume. I talk in there about some of the things that you can do to raise your profile, build a personal brand, and become more likely to get that next job. However I haven’t really addressed the making of a plan, which is something I need to add after I saw this link on a personal development plan posted by Brian Kelley.

    A personal development plan is a map for your career. A map that’s unique to you and what you want to accomplish. Whether that’s growing your skills in some area, getting a new job, or something else, the plan you build can help focus you and allow you to move clearly in the direction that’s important to you.

    It’s hard to build a plan, harder to stick to it, but perhaps hardest to figure out what to write down your plan. I’d suggest that you start with some short term goals, things that will make your job easier, or provide your employer a short term payback. This is often low hanging fruit, and can help get you thinking about your career. Then move on to longer term, or larger, goals that fit the place you want to be in a year or two.

    Don’t neglect your career as you grow. Give it at least as much attention as you gave that last server migration. You deserve that much from yourself.

    Steve Jones

  • Minimal Meetings

    This editorial was originally published on April 24, 2010. It is being re-run as Steve is out of town at the PASS Summit.

    I read something the other day that struck me. It’s obvious, but I hadn’t really thought about it in that way before. If you invite nine people to a one hour meeting, then is isn’t a one hour meeting. It’s a ten hour  meeting to the company with all the lost productivity.

    That’s a lot of time lost.

    Especially if you are meeting with developers or DBAs. They often have code to write, or problems to think about, and embedding them in a meeting for an hour, especially multiple people, can do more damage to your project than a lot of bad code. No wonder there isn’t enough time to do testing?

    There’s no good solution, especially since meetings can be productive ways to ensure information is shared in a group. They can help reset everyone to the same view of a project or situation. But you should also look to minimize their impact.

    Don’t invite people to meetings if they can read about a decision later, or if they are just getting a status update. A meeting ought to be for people whose job is affected. They need to give input on a decision, or make the decision. Everyone else is just task switching away from their job and losing time that could be put to better use.

    It’s tempting to invite all stakeholders, and anyone who might be needed “just in case.” Resist that temptation and let people spend more time actually building software.

    Steve Jones

  • Consolidating Again and Again and Again

    This editorial was originally published on November 12, 2009. It is being re-run as Steve is on holiday. 

    In reading about virtualization, one of the main things that drives its acceptance is cost. It’s the reduction in actual physical resources needed to run multiple servers that makes it popular with many IT departments. It doesn’t help with administrative costs, at least not the costs of the system administrators because you still have the same number of servers to manage. There are just less physical servers to buy, less power needed, less cooling, and probably other savings if you virtualize.

    Virtualization is really a one-time cost savings. Once you’ve virtualized a server, you can’t do I again, so there are no repeat savings from this event. Is consolidation the same? After all, the main driving force for that process is also cost, and once you’ve consolidated a server you can’t do it again.

    Or can you?

    There’s a great white paper by Allan Hirt that talks about the process of consolidation, and I’d urge you to read it before beginning a consolidation project. However I don’t know that consolidation is, or should be, a large, one-time project.

    If I consolidate 3 or 5 SQL Server instances onto one machine, I have a choice of how I can do this. It can be by moving databases to a new instance, having multiple instances, or even using virtual machines. But is that the end? It’s not because I can add more databases later, or I could even move a database that is receiving a heavy load back to its own server and find other instances to consolidate onto this one.

    Consolidation, unlike  virtualization ought to be something you periodically examine in your environment. On a regular basis review your baseline for all instances and see if it makes sense to perform some consolidation. Server sprawl can creep up on you, but with a little management and the multi-instance nature of SQL Server, you can keep it under control.

    And if you don’t have a baseline to examine, consider setting one up.

    Steve Jones

  • How Often Does Production Drift?

    One of the new products that Red Gate Software is working on is SQL Lighthouse, which is designed to track and alert you on “database drift“, which are the changes in your schema. I hadn’t really heard the concept in the past, though I’ve found there are a few people using the term to describe the changes being made to production that aren’t inline with the development project that created (and updates) the database.

    Vendors that sell products backed by a SQL Server database, like Microsoft Dynamics, often consider database drift to be a violation of their EULA. When a customer changes the database, even by just adding indexes, it causes them support costs, though arguably those costs are lower than if no indexes were ever added by enterprising DBAs.

    However this also happens in databases built by companies. It seems there’s no shortage of “quick fixes” in production, in addition to the “improvements” that DBAs and others seem to make to their live databases in order to solve some short term issue. I know there’s a need for this, and even seen recommendations to ensure production differs from development schemas. However I haven’t had many issues with this in the past and I’ve tried to prevent any drift.

    Maybe because I’m a controlling DBA, or maybe because I’ve been lucky. In either case, while I’ve had to implement hot fixes and changes in production, it’s been rare. Most of the time I’ve been able to backfill these changes in development (and test) environments, or delay the fix until it could be tested.

    However I’m sure there’s a need for a way to manage drift, and detect it as the number of databases you manage grows, so I’m excited by SQL Lighthouse and hope it helps DBAs avoid those late night phone calls by being aware of what’s changing in their systems.

    Steve Jones

    The Voice of the DBA Podcast

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