|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, March 09, 2012 2:36 AM
Points: 171,
Visits: 442
|
|
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.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:51 PM
Points: 32,906,
Visits: 26,789
|
|
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."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, March 09, 2012 2:36 AM
Points: 171,
Visits: 442
|
|
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.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:51 PM
Points: 32,906,
Visits: 26,789
|
|
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."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: Yesterday @ 8:55 AM
Points: 685,
Visits: 1,707
|
|
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 --
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, March 09, 2012 2:36 AM
Points: 171,
Visits: 442
|
|
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.
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 11:48 AM
Points: 2,015,
Visits: 2,843
|
|
"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.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 4:24 AM
Points: 1,158,
Visits: 642
|
|
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.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 1:08 PM
Points: 175,
Visits: 719
|
|
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 Microsoft SQL Server MVP Director of DBA Education, Red Gate Software www.bradmcgehee.com
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:51 PM
Points: 32,906,
Visits: 26,789
|
|
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."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|