Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Taking Risks Expand / Collapse
Author
Message
Posted Monday, October 3, 2011 5:41 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:11 AM
Points: 171, Visits: 444
I deal with fairly low numbers of users on most databases (~14,000 people) so I don't have a massive issue with diving straight in, because quite often the benefit of just doing it far outweighs the risk of it going wrong.
That being said, there are backups around should something hit the fan.

As I said - it's all about balancing risk with benefit, not completely ignoring it or being governed by it.
Post #1184442
Posted Monday, October 3, 2011 5:48 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:48 PM
Points: 35,547, Visits: 32,133
Heh... have you ever tried to restore a 2k8 backup back into a rebuilt 2005 server after a couple of days when you find out some of the lesser used features of your legacy apps don't work so well with 2k8? Tons'o'fun. Even on relatively "small" databases, it's just not worth taking the risk for.

But, to each their own. I think Brad's article was more of a "poll" anyway.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1184445
Posted Monday, October 3, 2011 5:55 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:11 AM
Points: 171, Visits: 444
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.
Post #1184449
Posted Monday, October 3, 2011 6:09 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:48 PM
Points: 35,547, Visits: 32,133
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.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1184457
Posted Monday, October 3, 2011 6:47 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Yesterday @ 10:04 AM
Points: 762, Visits: 1,945
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.


...

-- FORTRAN manual for Xerox Computers --
Post #1184483
Posted Monday, October 3, 2011 6:52 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:11 AM
Points: 171, Visits: 444
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.
Post #1184486
Posted Monday, October 3, 2011 6:55 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:14 PM
Points: 2,627, Visits: 4,026
"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?

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.
Post #1184489
Posted Monday, October 3, 2011 8:02 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, October 24, 2014 5:46 AM
Points: 1,416, Visits: 804
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.
Post #1184558
Posted Monday, October 3, 2011 8:09 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 16, 2014 10:06 AM
Points: 176, Visits: 728
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
Post #1184565
Posted Monday, October 3, 2011 8:11 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:48 PM
Points: 35,547, Visits: 32,133
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1184568
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse