July 20, 2017 at 10:13 am
webrunner - Thursday, July 20, 2017 10:06 AMI'm not confused - that is why I said "RTO may be the technically correct answer for this question." My response is not trying to legislate the correct answer to this question.
My response is about sknox's valid point that downtime can affect existing data *indirectly*. A lost customer means that customer is removed (however the system handles it) from the system. = lost. Also may mean lost existing money (lawsuit, refunds), not just lost future money.- webrunner
Those are business costs and yes they are unfortunate and potentially expensive. But in the universe of disaster recovery planning it has nothing to do with it. RPO is the amount of data that was already captured that you are willing to lose. In the DBA world this means how frequently do we need to make sure we take backups so that we can do a point in time recovery to how many minutes prior to the outage. What you and sknox are discussing are theoretical pieces of data that might be lost. I guess we just have to agree to disagree.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
July 20, 2017 at 10:19 am
Sean Lange - Thursday, July 20, 2017 10:13 AMThose are business costs and yes they are unfortunate and potentially expensive. But in the universe of disaster recovery planning it has nothing to do with it. RPO is the amount of data that was already captured that you are willing to lose. In the DBA world this means how frequently do we need to make sure we take backups so that we can do a point in time recovery to how many minutes prior to the outage. What you and sknox are discussing are theoretical pieces of data that might be lost. I guess we just have to agree to disagree.
I see what you are saying and I agree with it. I do think there is a bigger picture (not always merely theoretical in the case of businesses) that can indirectly affect even existing data, but you are correct that the definition of RPO intentionally excludes those cases from its definition.
Cheers,
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
July 20, 2017 at 10:49 am
webrunner - Thursday, July 20, 2017 10:19 AMI see what you are saying and I agree with it. I do think there is a bigger picture (not always merely theoretical in the case of businesses) that can indirectly affect even existing data, but you are correct that the definition of RPO intentionally excludes those cases from its definition.Cheers,
webrunner
Absolutely agree that the business cases you and sknox are discussing should be part of a disaster discussion as those are valid concerns when discussing disasters. That falls under the "how do we continue to function as normally as possible when the primary system is down" category.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
July 20, 2017 at 11:25 am
Sean Lange - Thursday, July 20, 2017 10:49 AMwebrunner - Thursday, July 20, 2017 10:19 AMI see what you are saying and I agree with it. I do think there is a bigger picture (not always merely theoretical in the case of businesses) that can indirectly affect even existing data, but you are correct that the definition of RPO intentionally excludes those cases from its definition.Cheers,
webrunnerAbsolutely agree that the business cases you and sknox are discussing should be part of a disaster discussion as those are valid concerns when discussing disasters. That falls under the "how do we continue to function as normally as possible when the primary system is down" category.
Agreed. 🙂
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
July 20, 2017 at 1:04 pm
Sean Lange - Thursday, July 20, 2017 7:32 AMedwardwill - Thursday, July 20, 2017 2:18 AMpalotaiarpad - Thursday, July 20, 2017 1:59 AMIn my opinion RTO is playing a role as well, for example in live data collection systems, where downtime is very critical.I agree. A very poorly worded and incoherent question 🙁
I don't see how this question is poorly worded or incoherent. Perhaps you could share how you would write it to make it more clear? It was extremely clear and straight forward to me with absolutely no level of ambiguity or missing clarity at all.
On reflection I would have to agree, but I had in mind a situation when, as someone else mentioned, you are not collecting data. Users spend 35 minutes recording data on paper which they may either lose or not input afterwards, while a recovery takes place. Could be loss of revenue or loss of bonus! Just a thought.
...
July 20, 2017 at 2:31 pm
Both losing committed changes and having the data unavailable for any changes are generally undesirable, of course, but the latter is still rather different from losing committed changes.
Nobody is suggesting that RTO is somehow less important, can't lead to lost revenue, etc., nor did the QotD. Loss of uptime is just a different thing than loss of committed changes; the fact that they are both bad and can lead to "loss" of something or another doesn't make RTO an equally valid answer to this question.
Goodness knows there are times when the QotD is worded in an unfortunate way with incorrect or misleading answers, but here I'm just not seeing it 🙂
Cheers!
July 21, 2017 at 2:19 pm
I agree that the question has it right. Sean and Jacob and others have made the case for that already, but it probably won't do any harm to try again to convince those who disagree.
When planning disaster recovery there are several objectives that need to be set. One is the amount of data lost at the point of failure that must never be exceeded (which determines the RPO). Another is the maximum acceptable duration of the downtime until normal service can be resumed after the failure (which determines the RTO). Both of these have an impact on the business and on its relationship with its customers. For some buinesses (eg banks providing close to real time online or telephone banking) the RPO is the critical bit because not knowing what trasactions have occurred during a long period would be pretty catastrophic, while being out of service for a while is less damaging (although it s of course inconvenient for customers, it's probably not as important to customers as would be losing all their transactions that took place in the last couple of days). For other businesses the balance of importance between RPO and RTO can be very different from that. But whatever that balance is it remains true that one(RPO) is about the amount of data not recovered while the other (RTO) is about the duration of downtime.
Tom
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply