Taking Risks

  • Jeff Moden (10/3/2011)


    Ben Moorhouse (10/3/2011)


    No offence, but who said anything about switching between versions?

    In my mind, 2008 > 2005 isn't a proper backup.

    I have 2005 backing up to a 2005 box and being restored and checked (granted very basic checks) daily.

    If something were to go wrong, then I could just failover to the other box whilst the issue is fixed on the primary box.

    Equally, no offense, but Brad did in his article...

    Upgrading from SQL Server 2005 to SQL Server 2008 is a risk;

    And you've made my very point... trying to a restore from 2k8 to 2k5 to undo a bad upgrade isn't possible. And just failing over to "the other box" would be a futile step even if it were a 2k5 box because, after collecting data on the new 2k8 box for a couple of days, the 2k5 "fail over" box would be quite out of date.

    Would you leave your system without a viable backup for a couple of days, knowing that losing that couple of days worth of data isn't acceptable?

    If it is acceptable however (in my case it SOMETIMES is), then that's fine - fail over to the 2nd box and accept the loss. Do a bit more testing next time to avoid failing twice.

  • "Steve Jones of SQLServerCentral.com, for example, set himself the challenge of running every single day of his life. So far, he has run for over 1,000 consecutive days; a great achievement that few can claim."

    That would make Steve < 3 yrs. old. Quite young for a DBA; a child prodigy, perhaps? :w00t:

    I did most of my risk taking when I was younger. Served aboard an aircraft carrier in the U.S. Navy; free falling from aircraft (with a parachute); scuba diving; scuba diving with sharks (without a cage) among other things.

    A few years ago, I made the jump from mainframe development to Windows and SQL Server. I thought that was pretty risky being a few short years from retirement.

    There's a difference between personal risks and risks on the job. Taking risks on the job should be rare and done only with full backing of management and understanding the consequences. One should not get a thrill from their I.T. job from taking undue risks that can not be undone.

  • Jeff Moden (10/3/2011)


    Ok... you good folks and "risk" takers that have posted so far... 😉

    How many of you are actually willing to install a new product (or even "just" a switch from 2k5 to 2k8) on your production boxes without first testing it on a copy of the production or at least a subset-copy of production?

    I hope the answer would be "none" but I have a feeling that's not going to be the answer.

    Not me - that's why we have dev, qa and prod. boxes.

  • I don't think I was a clear in my editorial as I should have been. In regards to the job, I was specifically referring to those DBAs who adamantly follow the rule of "if it ain't broken, don't fix it" attitude. As I said in my editorial, I think it is "important for DBAs to consider any new technological options carefully, and then take measured, controlled risks, in proportion to the perceived benefit." Any change is a risk, but it can be a controlled risk.

    In regard to risks taking in life, these are completely different than risks taken at work. I included this aspect of the discussion of risk because I wanted to get feedback from DBAs on whether or not they avoid risk in their personal lives, as they often do in their work.

    At work, and in life, I have generally been very conservative. And when it comes to work, I always test carefully before making changes. But occasionally in life, I like to take a risk (not for a thrill), but because I want to challenge myself to something I have never done before. Lately, maybe because I am getting older, I find myself trying new things I would have never thought of trying before. In almost all cases, the risk has been worth the reward, and it has spiced up my life, helping me get out of the often day-to-day routine of life.

    Brad M. McGehee
    DBA

  • jay holovacs (10/3/2011)


    While risk taking is a psychological characteristic, many people including myself, avoid random risk taking, but will take selected risks (Steve might know about about the back road to Hurricane Pass where the wheels of my Jeep were literally inches from a couple thousand foot drop).

    The same applies to systems we run. I am in NO hurry to move stuff off of one database platform that is working just fine onto another unless there is a direct benefit to doing so (like end of support). There are enough unpredictable variables in life, introducing extra ones withoug significant payback I think is counter productive.

    Of course not... that's why backups would be done everyday. The point that I'm trying to make is that the backups from a system migrated to 2k8 don't work on 2k5 and extraordinary steps must be taken to preserve the data in a 2k5 environment "just in case". All of that isn't worth the risk of doing the migration to 2k8. That's all.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • OCTom (10/3/2011)


    I did most of my risk taking when I was younger. Served aboard an aircraft carrier in the U.S. Navy; free falling from aircraft (with a parachute); scuba diving; scuba diving with sharks (without a cage) among other things.

    I served aboard USN submarines and did a large amount of scuba diving. I didn't dive with sharks back then... Instead, I'm now deep diving SQL Server with users (without a cage). 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • No risk, no glory!

  • bradmcgehee@hotmail.com (10/3/2011)


    I don't think I was a clear in my editorial as I should have been. In regards to the job, I was specifically referring to those DBAs who adamantly follow the rule of "if it ain't broken, don't fix it" attitude. As I said in my editorial, I think it is "important for DBAs to consider any new technological options carefully, and then take measured, controlled risks, in proportion to the perceived benefit." Any change is a risk, but it can be a controlled risk.

    I have to say - it burns my bacon to see the presumption that "doing nothing is the safe bet". I think this is what you're getting at, but in business as it is in technology, doing nothing is NOT the safe bet. You will be out of date, out of support and out of customers in a short period of time.

    So, if we now have to look at it as managing risk (instead of the "risk vs no risk" lens mentioned in your editorial), it comes down to: what is the way to do what you need to do while keeping your rewards/risk ratio high? Doing so might require going outside of your comfort zone (or might force you to acquire a new comfort zone), but at the same time, know what you are getting into and controlling what you can so that you don't run risks you don't need to.

    This might be where personal life and professsional life may deviate. While the personal risk-taking is purely up to the individual (meaning you can take unnecessary risks if you so desire), playing with someone else's data means you have to take a serious look and find the lowest risk path. This usually means NOT being an early adopter, NOT being a slow adopter, and NOT going in without a plan, a serious test, and an exit strategy.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Matt Miller (#4) (10/3/2011)


    bradmcgehee@hotmail.com (10/3/2011)


    I don't think I was a clear in my editorial as I should have been. In regards to the job, I was specifically referring to those DBAs who adamantly follow the rule of "if it ain't broken, don't fix it" attitude. As I said in my editorial, I think it is "important for DBAs to consider any new technological options carefully, and then take measured, controlled risks, in proportion to the perceived benefit." Any change is a risk, but it can be a controlled risk.

    I have to say - it burns my bacon to see the presumption that "doing nothing is the safe bet". I think this is what you're getting at, but in business as it is in technology, doing nothing is NOT the safe bet. You will be out of date, out of support and out of customers in a short period of time.

    So, if we now have to look at it as managing risk (instead of the "risk vs no risk" lens mentioned in your editorial), it comes down to: what is the way to do what you need to do while keeping your rewards/risk ratio high? Doing so might require going outside of your comfort zone (or might force you to acquire a new comfort zone), but at the same time, know what you are getting into and controlling what you can so that you don't run risks you don't need to.

    This might be where personal life and professsional life may deviate. While the personal risk-taking is purely up to the individual (meaning you can take unnecessary risks if you so desire), playing with someone else's data means you have to take a serious look and find the lowest risk path. This usually means NOT being an early adopter, NOT being a slow adopter, and NOT going in without a plan, a serious test, and an exit strategy.

    An as you did so many years ago, you've saved my bacon, again. Your post is worded a whole lot better than my few meager attempts. Thanks, Matt.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (10/3/2011)


    OCTom (10/3/2011)


    I did most of my risk taking when I was younger. Served aboard an aircraft carrier in the U.S. Navy; free falling from aircraft (with a parachute); scuba diving; scuba diving with sharks (without a cage) among other things.

    I served aboard USN submarines and did a large amount of scuba diving. I didn't dive with sharks back then... Instead, I'm now deep diving SQL Server with users (without a cage). 😀

    Submariner, eh? You guys were pretty crazy coming into port. I don't know about you personally but I knew some pretty crazy characters who served on subs. I salute you. I could never do that. I need to the sun more often.

    Deep diving SQL server with users can more risky than diving with sharks. The sharks generally left me alone. I can't say the same about users. 😀

  • Would love to take a risk; there are so many times when I feel I just want to walk out that door and see where it will take me. Alas; I I cant... Would certainly do that if I were alone; but not with dependents, esp my family whose demands I need to fulfil.

    And yes, if I had a stash of money to support my family for the time period I dont work; then would certainly take all sorts of risks..

    R - Reckless

    I - Insane

    S - Stupid

    K - Kareless

  • WHITE_DRAGON999 (10/18/2011)


    Would love to take a risk; there are so many times when I feel I just want to walk out that door and see where it will take me. Alas; I I cant... Would certainly do that if I were alone; but not with dependents, esp my family whose demands I need to fulfil.

    And yes, if I had a stash of money to support my family for the time period I dont work; then would certainly take all sorts of risks..

    R - Reckless

    I - Insane

    S - Stupid

    K - Kareless

    I'd like to go trekking in Puru or South America generally. I like to take part in a dig in Egypt. And often fanticised about being born in the early enough to be a pilot for the RAF in WWII.

    Unfortunately, like you, I'm married with a baby and a wife that doesnt even like me taking flying lessons. Feel so old and shrivled 🙁

    Adam Zacks-------------------------------------------Be Nice, Or Leave

  • I also agree with Jeff. I would not take any risk at the data tier. Your data constantly changes and it is your main dependancy for your applications to work. I would not take any risk. The good think in our line of work is we can test to reduce the risk and have our migration/changes with minimal impacts.

    There are other jobs where risks have to be taken, not ours! And I know by experience and you know by experience that most of my/your clients will not take any risk as well.

    I am so happy when my clients are always surprised there was no accident in the migration, code delivery to production I make or that I validated.

    This should be like that with everything!

    It is as simple as that!

    Clement

Viewing 13 posts - 16 through 27 (of 27 total)

You must be logged in to reply to this topic. Login to reply