Voice of the DBA

Author: way0utwest

  • Who Wants to Be Rich?

    This editorial was originally published on Oct 18, 2008. It is being republished as Steve is on vacation.

    I think everyone would like more money, but I’m not sure how many of you really want to be rich. In reading through my list of blogs, I stumbled upon Mark Cuban’s entry on How to Get Rich and thought it was an interesting read. He gives you some of the advice I would, the most important being “there are no shortcuts.” If you remember nothing else, remember that.

    I remember years ago, driving around with my Mom in the car. We were on some errand or something, I can’t remember, but I know that I was saying I wanted to do something. She told me an interesting story she’d picked up from somewhere, perhaps Reader’s Digest since it sounds like something they’d publish. It goes like this: a famous violinist was giving a concert and afterwards attended a party nearby. People were all there to basically see him and one lady was gushing with praise for his performance and told him “I’d give anything to be like you.” The violinist stopped and looked at her, saying “No, you wouldn’t.”

    Naturally people stop and stare and the lady is a bit flustered, “oh but I would, ” she protests. The violinist then repeats she wouldn’t and continues. “You wouldn’t give the one thing you must, time.”

    He meant practice, effort, dedication, etc., and that’s really the secret to being rich. You have to really invest in yourself, believe in yourself, and put lots of effort in. Most people don’t really want to do that, instead looking for some way to shortcut the process. There are ways to do it, but they either involve picking the correct 6 numbers on the correct week or placing a big bet on a single number, card, roll of the dice, or stock. And it’s far more likely that you’ll end up losing big with big bets.

    I saw an article recently that said half of all US taxpayers make less than $32,000 a year. I’m not sure if that’s true, but the article cites the IRS statistics for taxes paid. If you make more than $65k a year, you’re in the top 25%. In many places that might be considered rich, and if that’s the case, I think the majority of people in IT, especially DBAs, are doing well. It might not be what you want, but it’s a good living you’re earning.

    I think there’s a lot more to life than money. Not that I don’t want to make good money, but there are definitely important things that aren’t related to money. Now it’s easy for me to say that, I’ve been successful, my wife works, and we don’t have trouble paying our bills, but I’m a long way behind the Cube. Hopefully most of you are in a similar situation.

    If you want to get rich, and crack into the top 5%, earning more than $150k a year, likely you really need to start your own business. If that’s a goal, good luck and I’d love to hear about your trials and success. I’d also you to build a business you enjoy, make decisions you’re proud of and would tell your kids about. Be fair, honest, and work hard, and send me a note. Maybe I’ll even start featuring a few of those down home efforts here.

    If that’s not your goal, I really hope you enjoy your life and get to do what makes you happy. That’s what’s important, or should be, to all of us.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 35.6MB) feed

    MP4 iPod Video ( 31.6MB) feed

    MP3 Audio ( 6.4MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Patch Problems

    I ran across this article a week or so ago, but hadn’t had a chance to put anything out. There were three patches put out in July for various products that caused issues with other software, one of which was SQL Server.  can cause issues with SQL Server 2012, though it looks like the patch was pulled. Be careful if you have administrators that tend to apply the monthly security patches.

    Overall, despite the tone of the article, I’m not sure how bad this is in terms of patches. While the errors are problematic and annoying, I’m not sure these are critical issues. These aren’t causing reboots or re-installations of Windows. I’ve certainly seen worse patches released, though not in quite some time. The most disturbing item in the piece was the fact that the Windows 8/RT servicing stack update cannot be uninstalled. That’s a bit of an issue, and it concerns me as we move towards a more automated, bulk patch process.

    It’s one thing for me to uninstall an application on my phone and reinstall a patched one when there’s an issue. I’ve had this happen, with vendors releasing a new version in a day or two (or for all I know, the old version), that I can reinstall. It’s quite another thing for a large vendor like Microsoft to release a patch that cripples large numbers of devices. It’s easy to pick on Microsoft, but imagine Apple, Verizon, Dropbox, etc. releases a version that crashes machines or devices. It might be significantly harder to even reconnect these devices to recover from patches that crashed core, kernel level software.

    Software has bugs, and it will always have bugs. Patches will always be needed, and IMHO, should be included as part of some warranty for digital goods. However I think patching needs to be considered at the beginning, with installation and removal, as well as user option-to-install, built into all software for sale.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 17.5MB) feed

    MP4 iPod Video ( 20.8MB) feed

    MP3 Audio ( 4.2MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • T-SQL Tuesday #45–Follow the Yellow Brick Road

    tsqltuesdayIt’s T-SQL Tuesday time again, and this month Mickey Stuewe hosts the party. It’s an interesting topic, and one that I think is important, and will be more important, as we capture, store, analyze, and depend on more and more data.

    The topic this month is auditing, and you can read the invitation on Mickey’s blog. I think it’s amazing no one has asked us to write on this in the past, and I expect we’ll see some interesting stories that people will share.

    This is a monthly blog party and all you have to do to participate is write a post on the 2nd Tuesday of the month. The topic comes out about a week before, and you can schedule something to go out on the appropriate day. Be sure you leave a comment on the host blog or a pingback.

    Auditing

    I’ve never been bound by regulatory requirements for strict auditing. When I worked in industries that had bounds, they weren’t really updated for computer systems, and lots of our practices slipped by because no one thought to look. A few times that was scary.

    However I’ve implemented auditing in various systems, in various ways. The most common way to do this in the past was with triggers, though I had a situation where I had to build a unique solution that would capture changes being made to systems.

    I worked for a small company one time and we had a few critical systems our clients regularly accessed remotely for various functions. This was in the era of client server systems, and we delivered software to our clients that connected to our servers. We had lots of buggy software, and when we released new features, I’d cringe as I knew we would have calls and complaints for a few weeks as we patched things.

    I ran a team of 3 DBAs, and we had 5 or 6 developers working for another manager, including a few remote developers. We had agreed to limit changes to known times, and document the packages being deployed so that we were aware of changes and could better troubleshoot issues. Our environment was complex enough with multiple processes communicating with each other and SQL Server without adding the issues of unknown changes. We communicated things to our development staff, and though they grumbled everyone agreed.

    One day I came in to find that a process that had worked the day before had failed. We were struggling to get it working, and eventually discovered that a schema had been changed. This was in response to another enhancement, but it caused an import process to change. We hadn’t scheduled a change, which must have occurred overnight. No one admitted to making a change, and after a long day, I had to drop it.

    But not completely.

    I went back and set up a server side trace to run and capture information for object changes. I let this run constantly, rolling over the files periodically. It was a bit of a load on our system, but I felt it would be short term and it was important enough to understand what was happening.

    A few days went back and we were having an issue with another part of the system. Clients were screaming at my boss, who was coming to the development area to complain to DBAs and developers alike. As we tried to reproduce the problem on test systems, suddenly it started working.

    Relieved, but concerned, I decided to check my trace. Sure enough, I found a change to an object logged, by none other than that craft “sa”. Digging in further, we discovered that a piece of middleware had a timestamp of a few minutes before the system started working.

    It can be hard to track down who is using an “sa” account, which is why it is not recommended as an account to use by individuals. Cross referencing some information from the network team, we discovered our remote developers were slinging code changes on the system whenever they felt like it, using sa and “Administration” on Windows.

    They patched systems at times, but often these were patches to fix issues in poorly written software they’d deployed in the first place. They were also patching patches when thing didn’t work. Whether this was in reducing the time of problems or not was difficult to determine, but it certainly meant a lot of wasted time when we tried to troubleshoot issues with no idea what had changed. We also found lots of their changes weren’t being added to version control.

    My boss agreed this was an issue, and it allowed me to change all system administrator passwords, as well as revoke all rights to production systems from developers. Eventually we achieved more stability in our systems than the company had ever found. I’d attribute this to preventing cowboy coding changes to systems, which seem to cause as many issues as they fix.

    Auditing is something I’ve depended on, especially for myself. As I’ve worked with more and more systems concurrently, I find that it’s easy to forget about changes made in a hurry, or forget which change occurred on which systems. Logging and auditing allows me to retrace my own steps, as well as those of others.

  • I Hesitate to Commit

    At work my boss this week my boss gave me some quotes about me. We solicit feedback twice a year from co-workers and use that to evaluate how employees are doing. This goes up and down the chain, so everyone from the CEO down gets anonymous quotes.

    A few of mine were that I am pleasant and helpful and always looking to do things when people ask.

    My boss laughed, and said those obviously weren’t from her. They weren’t because she has to struggle with me to get me to do new things. I get a lot done and don’t need management, but I hesitate to tackle new projects or agree to get them done. She has to ask me more than a few times and remind me if I haven’t committed.

    Why?

    Here’s a great example of why:

    Hard Earned Lessons Spots – Raw

    I wrote an article recently on disaster recovery. One of the marketing people wanted some video ad spots to use. A 30s one and a 1 minute one. She asked me, and I said I might be able to. My boss asked, and reminded me a few times. I didn’t commit because of time. I think she, probably everyone, wondered how hard is it to make a 30s spot?

    During out meeting she reminded me that I had said I’d try to get it done by this Friday (today). I explained I’d try, but not promises.

    I took a 2 paragraph script, 10 things and an opening and closing and had to work with it for 30-45 minutes. I practiced it, timed it, realized it was long and had to cut it to a few versions. I finally felt comfortable and loaded it into the prompter.

    I went to shoot it, thinking this would be a 5 minute effort like my podcasts. It was 12+ minutes of video, along with some setup to move things around, and then a nice 30 minutes of editing to cut out the green corner, check audio, cut out the mistakes, etc. and just send the raw 3 versions over.

    With the issues in loading the video to the computer, this was 2+ hours out of my day and frustrating, but also funny.