Voice of the DBA

Category: Editorial

  • Work To Live

    This editorial was originally published on May 2, 2012. It is being re-run as Steve is at SQL Bits.

    I’m halfway through my career, having spent about 20 years since college working in technology with another twenty to go. The rest of the community is probably spread out around me, some older, some younger. It doesn’t matter what part of your life you are in, there are a few things about work that I think always apply. The first is that we work to live, and don’t live to work. The second is I like to hope for the best, but plan for the worst.

    It’s all too common for people in this business to overwork themselves, work very long hours, and neglect the rest of their life. I have rarely seen someone that is retired or late in life complain that they didn’t work enough over their lifetime, and I’d caution you to keep that in mind as you go through life. There will always be more work, more things to do, and more requests from clients and customers. Keep a balance in your life, and remember to enjoy it along the way.

    The second part of my advice can apply in many parts of our career, but it ought to apply to our finances and our retirement. Unfortunately, I’ve seen a few articles like this one that notes many people have not funded their retirements well. We all have expenses, and it’s easy to delay the investments in our life until later, but that is a bad idea. Whether it’s your IRA/401K or your health, you’d be better off sacrificing a little today for a little more security later.

    In the US, many employers match contributions and you ought to take advantage of that. There are all sorts of options for retirement, like ROTH IRAs, that it seems many people aren’t aware of. I also meet many people that don’t realize they can borrow against their 401K as well, taking a loan whose interest goes back to your own account. There are few excuses to not plan for the future. Enjoy today, but plan to live a long time and to enjoy your retirement.

    How much money you might need depends on your lifestyle, and that’s something you should spend time thinking about and talking with your family about. Many of us may not be able to retire at 65, or count on social security, but I’d hate to have to work longer than I want to because I cannot afford to retire.

    Steve Jones

     

  • Promoting Engineers

    This editorial was originally published on May 1, 2012. It is being re-run as Steve is at SQL Bits.

    Never, ever promote your best salesperson.

    That’s the advice that Scott Horowitz got from his father. He talks a little about how this relates to technical people who find themselves looking at management to further their careers, or are sometimes even get promoted just because they’re the strongest technical employee in a group. Mr. Horowitz sees the transition as one that rarely works well, though he has some good advice on how you can increase the likelihood of success.

    In my career I’ve moved to management a few times and back again to a technical role, though never at the same company. I am sure it would be a strange move to be in charge and then move back to a contributing employee, but I do know some other people that have done it successfully in their careers. I have enjoyed both roles, and at different times in my career, the different role has fit me better.

    Many companies struggle with their technical people as they advance in their careers. Few companies think ahead and build dual career tracks in both the technical and managerial areas for their staff. As a result, many technical people find their career stalled in a company and may look to leave for another position. Setting aside a technical track that allows an employee to advance as a strong technical worker, and continue to grow their challenges and salary seems like a no-brainer, but it’s something rarely implemented outside of technology-oriented companies.

    Perhaps senior technical people can’t continue to add the same value as a manager or director in an organization. There are definitely lots of technical people that have a lot of seniority in a company, but do not necessarily bring a lot of additional value for all their experience. However some do, and those are often the people that a company should not let go. If they continue to grow their knowledge, and add more value, there ought to be a career advancement track for them in the technical area.

    Steve Jones

  • Install Cumulative Updates

    For years I haven’t recommended installing Cumulative Updates (CU) as they are released. The main reason is that Microsoft has had language associated with their CUs that say customers should not install a particular CU unless they are experiencing the specific issues the CU corrects. Each CU has (in the past) also noted that you should stick with the latest Service Pack otherwise. That disclaimer has been enough for me to be concerned about CUs in a general sense, despite the insistence that the CUs were tested as well as SPs. My thought was that if the testing was the same, that disclaimer wouldn’t exist.
    Well, things have changed. The latest CUs have this language in the section where a KB says that Microsoft recommends CUs as they are release:
    • SQL Server CUs are certified to the same levels as Service Packs, and should be installed at the same level of confidence.
    • Historical data shows that a significant number of support cases involve an issue that has already been addressed in a released CU.
    • CUs may contain added value over and above hotfixes. This includes supportability, manageability, and reliability updates.
    That’s good news, though as Kendra Little notes, you still need to test. Bugs will still exist in patches, and really all software, so it’s important that you test in your own environment. That means you need a test plan that can easily run, preferably an automated test plan. If nothing else, this is a good reason to use tSQLt and have tests written for your system. At least you can verify important queries and systems are working. Kendra has a good list, so read her post.
    While I think the quality of CUs is up and they are probably as safe as most of the Windows patches we get every month (and are often installed no matter our individual feelings), I’d still be wary. If you can’t test, if you’re busy, if this is a month you can’t afford for things to fail, then don’t install the CU. This is like throwing your own developers’ code into production without any testing. Make sure you know what is being changed, and you look for obvious problems. No one will be too upset of an obscure issue, but if your scheduled jobs start failing, you’ll dramatically reduce the confidence people have in you.
    I am still wary of all patches. They’re disruptions, to both your routine, and potentially to availability as well. Make sure you test, but if you have the time, I’d say keeping up with patches is worth doing. Microsoft is constantly fixing issues, and you want to take advantage of their hard work, if you can verify the patches don’t degrade your system.
    Steve Jones

  • Stress Testing

    Many of the DBAs that manage production systems will at some point determine what level of hardware is needed to support a workload. Whether this is a physical server purchase or a cloud “rental”, someone has to decide what hardware is needed. How many cores, the amount of RAM, the number of disks, which hopefully correspond to some level of IOPs, and more. Even in the Azure SQL Database world, you must decide what database capacity you will pay for.

    Since this is a big decision, and changes can be hard to make, many DBAs overbuy hardware. After all, no one wants to have a slow server. This is true for Azure as well, at least for many people I know. While changing from an S3 to a P2 is quick and easy in the Azure portal, it’s not such an easy sell to management. If they’ve budgeted $150/month and you tell them we want to go to $900/month, the technical change is the easiest part of this.

    As a result, I’m surprised that we don’t really have better ways to determine if hardware will support our workload. I see this question asked all the time, and although there are tools and techniques suggested, I’ve yet to see many people have a set, known standard way of evaluating hardware and a particular workload.

    One one hand, I think there should be better tools to do this, whether from Microsoft or someone else. I suspect since this is such a rare activity and businesses have been willing to overbuy hardware (or deal with substandard performance), that there isn’t any large impetus to solve this issue.

    However I wanted to ask if any of you actually stress test hardware? Either your current hardware or new purchases. If you don’t know what your level your current hardware performs at, how do you compare that to new hardware?

    Do you have a way to replay and measure a workload? Do you have the time to do so when new hardware arrives? Is there a documented method you use? Apart from discussing this today, I’d love to see some articles that detail exactly how you test hardware from a technical tool perspective, and then a followup that examines and evaluates the results.

    Steve Jones

    The Voice of the DBA Podcast

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