July 19, 2017 at 10:24 pm
Comments posted to this topic are about the item Disaster Recovery Preparations
July 20, 2017 at 1:59 am
In my opinion RTO is playing a role as well, for example in live data collection systems, where downtime is very critical.
July 20, 2017 at 2:18 am
palotaiarpad - 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 🙁
July 20, 2017 at 4:49 am
Unlike yesterday's question, today's question is specified clearly. It's an interesting topic about important things. Thanks for that Steve. 🙂
July 20, 2017 at 5:16 am
George Vobr - Thursday, July 20, 2017 4:49 AMUnlike yesterday's question, today's question is specified clearly. It's an interesting topic about important things. Thanks for that Steve. 🙂
Agreed about the question. It's completely clear.
If the first duty of a DBA is to protect the data, then both RPO and RTO are very important. However, the question wasn't about both.
July 20, 2017 at 7:16 am
edwardwill - 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 think it's a bad question. I only added a comment about the importance of RTO.
July 20, 2017 at 7:30 am
palotaiarpad - 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.
The question is talking about the concept of how much data is acceptable to lose. RTO has nothing to do with that at all. RTO is the amount of time it takes to get the system back and up and running after a disaster. RPO is how much data you can lose after the disaster.
_______________________________________________________________
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 7:32 am
edwardwill - 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.
_______________________________________________________________
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 7:32 am
Sean Lange - Thursday, July 20, 2017 7:30 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.The question is talking about the concept of how much data is acceptable to lose. RTO has nothing to do with that at all. RTO is the amount of time it takes to get the system back and up and running after a disaster. RPO is how much data you can lose after the disaster.
Precisely. They're different sides of the same coin, but the focus is different.
July 20, 2017 at 7:49 am
Sean Lange - Thursday, July 20, 2017 7:30 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.The question is talking about the concept of how much data is acceptable to lose. RTO has nothing to do with that at all. RTO is the amount of time it takes to get the system back and up and running after a disaster. RPO is how much data you can lose after the disaster.
RTO certainly does deal with data loss. As long as your system is down, there's data you're not collecting. That is data lost.
RPO is NOT "how much data you can lose", but the specific point-in-time state (usually defined as an interval relative to the point of failure) to which you restore the database (Recovery Point Objective). Data loss is implied, not addressed directly, by this term.
Both of them deal with data loss. Neither of them deal with it directly. You can argue that RPO deals with it "more directly", but that's not really the point.
July 20, 2017 at 8:19 am
sknox - Thursday, July 20, 2017 7:49 AMRTO certainly does deal with data loss. As long as your system is down, there's data you're not collecting. That is data lost.RPO is NOT "how much data you can lose", but the specific point-in-time state (usually defined as an interval relative to the point of failure) to which you restore the database (Recovery Point Objective). Data loss is implied, not addressed directly, by this term.
Both of them deal with data loss. Neither of them deal with it directly. You can argue that RPO deals with it "more directly", but that's not really the point.
I disagree. Data you are not collecting is not data lost. How can you lose something you never had? Yes downtime is a critical aspect of disaster recovery but the concept of RTO is not related to losing data. It seems that Paul Randal agrees. https://www.sqlskills.com/blogs/paul/the-accidental-dba-day-6-of-30-backups-understanding-rto-and-rpo/
In my opinion data not being collected as the result of downtime is not data lost, it is an opportunity cost. There is data you could have collected but were not able to.
_______________________________________________________________
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 9:06 am
sknox - Thursday, July 20, 2017 7:49 AMRTO certainly does deal with data loss. As long as your system is down, there's data you're not collecting. That is data lost.
I completely disagree. You're conflating the abliity to collect data with the storage. There are many architectures that handle data collection (queues, client retries, etc.) separately from the database system being down and incurring RTO.
RPO is the point set back from the disaster where we ensure we have data. That's data loss.
July 20, 2017 at 9:08 am
Sean Lange - Thursday, July 20, 2017 8:19 AMI disagree. Data you are not collecting is not data lost. How can you lose something you never had? Yes downtime is a critical aspect of disaster recovery but the concept of RTO is not related to losing data. It seems that Paul Randal agrees. https://www.sqlskills.com/blogs/paul/the-accidental-dba-day-6-of-30-backups-understanding-rto-and-rpo/In my opinion data not being collected as the result of downtime is not data lost, it is an opportunity cost. There is data you could have collected but were not able to.
"Data you are not collecting is not data lost." Replace "data" with "money" and I think I see the point sknox is making.
RTO may be the technically correct answer for this question, but "RPO and RTO" is probably the correct answer for the business. If a system is down, even though the data not collected cannot be lost (because it has not yet been collected), the impact of lost time can result in lost data (customers leaving, reputation harm, etc.).
- 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 9:56 am
webrunner - Thursday, July 20, 2017 9:08 AM"Data you are not collecting is not data lost." Replace "data" with "money" and I think I see the point sknox is making.RTO may be the technically correct answer for this question, but "RPO and RTO" is probably the correct answer for the business. If a system is down, even though the data not collected cannot be lost (because it has not yet been collected), the impact of lost time can result in lost data (customers leaving, reputation harm, etc.).
- webrunner
What you are describing here is RTO, the amount of time the system can be down. Not sure why so many people here are getting confused. Yes the amount of downtime can result in unhappy customers and such but that is NOT lost data. This is why RTO is generally expected to be a small number. RPO is referring to the amount of data it is acceptable to lose after a disaster.
_______________________________________________________________
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:06 am
Sean Lange - Thursday, July 20, 2017 9:56 AMWhat you are describing here is RTO, the amount of time the system can be down. Not sure why so many people here are getting confused. Yes the amount of downtime can result in unhappy customers and such but that is NOT lost data. This is why RTO is generally expected to be a small number. RPO is referring to the amount of data it is acceptable to lose after a disaster.
I'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 that hasn't been collected yet.
- 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
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply