Voice of the DBA

Author: way0utwest

  • Bad Management

    Many people know that a good manager can make a huge difference in the productivity of a staff. A bad manager can also lower productivity, but only to an extent. Fear of losing a job, or avoiding punishment can motivate plenty of staff to get work done, even when you have a poor, or even absent, manager.

    Some companies don’t value strong management skills much, some do. I think most of us would prefer to work for a company that does, but we don’t always get the choice. That’s one reason why I do promote the idea of branding yourself and ensuring you have other options for employment. The more options you have, and the more demand there is for your staff’s services, the more likely that your company will make an effort to work with, rather than lord over, their employees.

    For those of you that are managers, or those that might want to help their manager build some skills, I ran across an interesting story from David Haney on his experiences as a manager at StackOverflow. It’s a good set of principles that I tried to keep in mind as I managed people in the past. For those managers that might not know why their staff leaves, there’s a good warning that good IT staff are in short supply, and companies should make an effort to retain them in various ways.

    For many of us in the IT sector, we can provide a strategic advantage for our businesses as we enhance and extend software. Many of us are important insurance that keep systems running, hopefully at a peak level. Bad management can impact the effectiveness of our technology organizations, and it’s silly to accept bad managers. This is something that can be fixed with some training and accountability for the manager, with a little effort. Make a few suggestions, or try to show how a better manager (or style) might help you get more done.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Poor Soul

    This editorial was originally published on May 11, 2011. It is being re-run as Steve is away at SQL in the City.

    I recently had someone post this after I made a comment about someone taking responsibility for their database server.

    “So Steve, what would you recommend then for those poor souls?  As being one of them it drives me nuts to constantly be told I can’t get more training as it’s not my true job position yet I’m responsible for making the databases work. “

    I’ve been in this spot a few times, in and out of IT. I’ve been tossed into cooking or bartending jobs without training and had to learn quickly how to do the job, and I’ve had the same thing happen in IT. In a few cases the companies knew it was a bad situation and they eventually got me training, in others they didn’t. Here’s the advice I have for you.

    Ultimately you are responsible for the job. Tough love, but you’re being paid for that job, so you are responsible.  That means you have to learn how the technology in your environment works and how to solve the problems you have.

    First, get your resume up to date. Make sure it is ready for submission, and you are prepared to get fired every week.  Keep an eye on the job market and save some extra money, because to me, the financial security for my family comes first.

    Second, learn to restore data and then make sure you have backups in place. This is secondary because if you have a failure quick, you want to be ready to get a new job. But ultimately no matter what breaks or doesn’t work, getting data back first is crucial.

    As you go through all of this, you might be fighting fires. So while you practice restores or document the environment, you might be trying to fix things and asking questions of others, but invest the time to get yourself into a solid position.

    I’d also talk to my boss regularly. Every time I found a place I didn’t know something, I’d make a note and let my boss know this is a hole. Maybe I can learn it, maybe I can’t, but I could use help. That might be the best ROI for conferences. Go, make friends, get contacts that can fill your knowledge holes. Or find consultants you can call.

    Steve Jones

  • Traveling in Wales

    It’s SQL Relay Cardiff day today. This is my first time in Wales, and it’s a busy day at SQL Relay. It’s a bit of deja vu with me delivering the same session on Version Control today that I presented 18 ours ago at SQL Relay Bristol.

    It’s interesting being on part of the SQL Relay tour, with some of the same speakers, some different, the rapid travel from one city to the next, and orienting myself in a new environment. The venues are much different, with a set of hotel conference rooms yesterday and a large arena facility (the Motorpoint Arena) today.  It’s surprisingly confusing trying to find toilets, speaker rooms, and more.

    However the people are nice, and friendly, although quiet. I got lots of good questions both days, on a semi-confusing topic, and that will help me revisit the session and make some changes over the next few days.

    I get to help on a second session today as we have a speaker that’s ill. Then it’s some work as I prep for travel back to London and SQL in the City in London on Friday.

     

  • Learn to Use Filegroups

    This editorial was originally published on May 12, 2011. It is being re-run as Steve is away at SQL Relay today.

    In SQL Server, filegroups are a management technique that I don’t see many people using. It’s amazing how many people ask questions about filegroups on the discussion forums, often unsure of how they fit into a well architected SQL Server. I have tended to use filegroups mostly as a space management technique, when I need to add more disks to my server, but they can be used in many more places.

    We continue to grow our data sizes all the time. While many databases are still measured in the single digits of gigabytes (or smaller), it is fairly common to find many database servers with over a terabyte of disk space. Our disks grow larger and larger, but it seems that data grows faster than disks, requiring larger storage subsystems all the time.

    While our storage grows larger, the tolerance for delays shrinks and demands for better performance increase. That means that data professionals need to be more cognizant of not only how their code is written, but also how they design storage. Tiering storage is one idea that I think has merit, but one that requires some planning.

    In SQL Server, we can’t split a table across filegroups. Or can we? We can partition a table (Enterprise Edition and higher), which can allow us to manage performance and storage appropriately. There is also the recommended practice of only having system objects in the primary partition and using separate filegroups for user data. That allows you to bring a partial database online, again, in Enterprise Edition only, while you restore different filegroups.

    This isn’t the first thing I would recommend you learn about SQL Server, but as you advance your knowledge, you should better understand when and how filegroups can help you. You will use them at some point and being comfortable with a filegroup restore is one of the skills that separates the accidental DBA from the data professional.

    Steve Jones