Voice of the DBA

Author: way0utwest

  • New Looks

    It’s been quite a few years since I updated the Hawaiian shirt wardrobe. I bought a series of 5 shirts for TechEd years ago, having “SQLServerCentral.com” embroidered on each of them. I had 3 copies of each shirt, with Andy, Brian, and myself having a selection of shirts to wear.

    In the in between years I’ve purchased a couple more, but no customization. However this year I needed to outfit my “Scary DBA bouncer” for the SQLServerCentral party. He made a joke about getting a shirt like the one I wore for the Baton Rouge SQL Saturday keynote, and I decided it was time to get a few more for myself, so I started searching around.

    The last time I was looking for someone that would customize the shirts. I didn’t find a lot of places in 2004, but there are more now. However I was a little worried about turnaround. So I looked locally. After pinging 3 or 4 places in the Denver area, Burbank Embroidery said they’d be able to handle a few pieces (I was thinking 6 or 7 shirts) at a reasonable rate and have them done by Oct 29th.

    So then I was searching for shirts. For some reason I wandered onto Beanteacher Hawaiian Wear and found some great shirts. They had a nice online store, and when one of my shirts was out of stock, they promptly emailed me with a few choices and I picked one. My order arrived within a week, and I was happy with the qualify and service from them.

    The shirts are at the shop, and I should pick them up next week sometime, just in time for them to accompany me to SQL Connections in November. And in time to get the Scary DBA properly dressed.

  • SQL Saturday Advice – Extra Food

    No matter whether you provide the food or have people pay for it, it seems that at every SQL Saturday I’ve attended, there is extra food left over. Sometimes it’s a very significant quantity. At one of the events I think there were over 50 boxes lunches left over.

    You need a disposal plan.

    Now it’s easy to toss the food, or give some to volunteers if they want it, however I’d encourage you to think a little wider, or maybe even more socially. Think about how you put that food to good use.

    At the Rocky Mountain Tech Trifecta that we’ve run for a few years we typically have no issues with leftover pizza. Plenty of students are wandering the halls on a Saturday and are more than happy to help us dispose of a few slices. I like to think we’re doing a good thing by allowing students a free meal after the attendees have eaten.

    In many events, however, there isn’t a large group of people walking around the area that would appreciate the food. After both the Denver and Kansas City SQL Saturdays, the leftover food was donated to local missions that used it to feed those people who are down on their luck. I know a few other events have done this as well, and I’d encourage everyone to consider a local mission in your area. If you are having trouble finding one, contact a few churches nearby your event and I’m sure they can help.

    I’d like to think that those of us in IT are fairly well off compared to many people in the world. And I think that we can do a bit more to give back to others that might not be as fortunate. Have a disposal plan for extra food and don’t let it go to waste.

  • Plan for Capacity

    In many applications, it seems that performance often falls off a cliff at some point because no one is planning for capacity increases. Everyone talks about the potential load on the system when it’s first being built. However since we often over-buy hardware, we rarely monitor the load until something goes wrong.

    I was reminded up this with a write-up from Simon Sabin recently that examined a lesson on capacity planning from FourSquare. Apparently FourSquare had some capacity issues with their MongoDB server. Despite the realization that they were growing and the addition of a second node to their database, they didn’t learn the lesson and didn’t add a third or fourth node until they were over capacity.

    Most of us don’t experience this type of hyper-growth in our systems. The majority of applications I’ve seen have undergone a quick growth in load at some point, but then leveled off to a steady, or slowly growing load on the system. However that doesn’t necessarily change the planning needed for growth. It just means that you need to grow your system at different times than if you were doubling in size every few months.

    A solid monitoring plan, and buy-in from management that you will periodically need to upgrade your servers, is necessary. Typically you will add storage over time, perhaps RAM, and potentially new CPUs or servers. You might not be able to exactly predict when you will have performance issues, but you can plan for issues. You can proactively let management know that space is running low, or that you may run into issues if data sets continue to grow in size.

    Funding is often hard to get, but by preparing people in advance that your database will need improvements over time, you are more likely to be able to respond quickly when there are performance issues.

    Steve Jones

  • Boulder SQL Server User’s Group – Common SQL Server Mistakes

    The first iteration of my presentation on Common SQL Server Mistakes, based on the various things I’ve seen in the forums over the years as well as written about on this blog, was last night.

    It went fairly well, though not a lot of questions from the group and I ended up running ahead of schedule. Afterwards we had a nice debate on triggers, which I need to blog about as well.

    Good getting up to Boulder, or Broomfield in this case, for the meeting. It’s at Level 3, which is a great facility, and I’m hoping that we can hold another event there at some point.

    I’ve uploaded the presentation to SQLServerCentral if you are interested in seeing the deck.