Voice of the DBA

Category: Editorial

  • It’s Almost Always the Humans

    Today we have an editorial reprinted from Sept 19, 2005 as Steve is on vacation.

    Most breaches of security, stolen data, etc. are almost always the result of some breakdown in the human factor of the equation. By that I mean some interaction between the human “bad guys” and some human in the company. It could be stealing a laptop, sorting through trash or even paying for it. Or perhaps this method.

    I saw this article about bank fraud, but not the kind I expected. After all, I got called last year by my cell phone provider in a similar situation. You are late on your bill, make a telephone payment, presumably because you’re short of time. In my case I didn’t even call them back, which I should have. In this case, the individual writing just called and made a payment over the phone.

    A short time later a suspicious charge appeared. The person tracked it down to customer service that had been outsourced and someone at the outsourcing company was selling or passing along information to criminals that would use it in some type of identity theft crime. No word on what is happening with the investigation or even which company it is.

    To me, this the worst method of saving money, and if this results in security breaches, the name of the company should be publicized. Most of these corporations are not losing money. They are racing to make more, increase the stock price, whatever, and in doing so, they are sending out a piece of their core business. Customer service should be a cornerstone of any company. That is how you show that you are the place someone wants to do business. I’m not sure I even agree with outsourcing IT since that data is critical and vital to your company as well, but there is no way customer service is not a core part of your business.

    If you’re missing that point, you’re missing the function of a business in the world.

  • Does It Count?

    Maintenance in the Army

    I wrote a blog recently about downtime and SLAs, and the need to have not only downtime SLAs, but also a data loss SLA. Thanks to Paul Randal (blog | @PaulRandal) for clueing me in to the need for having both. In the comments someone mentioned that scheduled downtime ought not be counted against your uptime measurements. That’s a debate I’ve had in the past with employers, and I thought it would be a good Friday poll:

    Should scheduled maintenance be counted against your downtime SLA?

    There’s an argument that says since the outage is scheduled, and people are informed, that this shouldn’t really count against your work in keeping servers running. The flip side is that when the database instance is down, it’s not useable, and of limited use to the business.

    I know that companies that calculate the usage of their vehicles, and maintenance counts against usage time. While it’s necessary, the idea is that mechanics should be looking to minimize it, and perhaps ensure that extra checks are done when the vehicle is being worked on to help prevent future issues. A similar argument could be made for database servers.

    Do you feel that scheduled maintenance is downtime? Is it calculated that way at your employer? Let us know this Friday.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72280/)

    The Voice of the DBA Podcasts

  • Master Training

    A Kung Fu Master

    As a kid, growing up on Bruce Lee, Chuck Norris, and Saturday afternoon Kung Fu Theater, I always wanted to be a martial arts master. A few years later, being a Jedi Master caught my interest despite the fact that it wasn’t a viable goal on Earth in 1977. Now I’ve started down the path towards another master, the Microsoft Certified Master.

    Actually I’m not going down that path. I had the chance to take the written test with no downside for me, so I took it. I have no intention of actually pursuing the lab at this time. It’s a lot of work, and not necessarily something that would provide me a lot of benefits right now. I may change my mind if I were looking for consulting work, but I am quite happy with my job right now and don’t want to change.

    I do plan on taking one or two of the MCM training being offered by SQLskills this year, but I won’t be looking for the intensive  4 weeks of training to prepare me for the lab exam. After reading Brent Ozar’s adventures last year, I think I’d need all 4 weeks of class along with a few more weeks of prep to be ready for the lab.

    So why am I taking a class? First, it’s good training. I have had the privilege of seeing both Paul Randal and Kimberly Tripp speak before, and it’s always enjoyable and informative. I come out of their hour long sessions with so many notes and new knowledge that it I feel like I’ve been learning for a full day. I am sure that a week’s training from them will result in a small novel that I’ll need to review over the following months.

    Training can be hard to get funded, but it is often worth it. I hope that more companies would be willing to improve the skills of their people with this type of advanced training, even without paying for the certification testing. The chance to learn from experts in particular areas is an investment that I think is worth making in my career and in yours.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72278/)

    The Voice of the DBA Podcasts

  • What Not To Say

    Don't yell at the boss

    This article on 8 things your boss doesn’t want to hear made me smile. There are a few phrases listed that I would definitely recommend not using if you want to succeed in your current place of employment.

    Having managed a few DBAs in my career, I thought of a few more that I thought might fit the data professionals out there as “things not to say” to your boss:

    I’m not sure if more memory will help: You could substitute CPU or disk drives for memory in this one, but it’s your job to know. If you don’t, learn how to tell what your bottlenecks are and make appropriate recommendations.

    That additional memory didn’t help: The only thing worse than not being able to make a good recommendation is making one that doesn’t improve performance after your boss has approved the purchase. Now you look bad, and you’ve made your boss look bad.

    Company X has offered me $yyyyy. Will you match it? You can get away with this once at a job, or maybe once a decade. If you want to go to your boss with this one, be ready to quit if you don’t get it, and be ready to shine if you receive the raise. No one wants to be put in a corner, and I would be likely to let you move on if you came to me, unless I felt you deserved it. Even then, the second time you ask, I’m showing you the door.

    I downloaded this software off the Internet and it crashed the server: You can’t trust stuff you download, no matter what the Open Source crowd says. Test, test, test. Preferably on a test machine.

    It works on my machine: I have always wanted to answer this with a “Who gives a <insert four letter expletive here>?” My actual responses haven’t been that far away if it’s an important project and you give me this excuse.

    Feel free to add your own “things not to say” to the comments below.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72279/)

    The Voice of the DBA Podcasts