March 8, 2011 at 8:53 pm
Comments posted to this topic are about the item Restoring after TRUNCATE TABLE
March 8, 2011 at 9:02 pm
Not sure I get the point of the trick question.
It should be clear that you can restore to ANY point in time (at each 15 minute interval in this example). However, restoring to the 9:30 state will not recover your TRUNCATEd table ... so was that thrown in as a red herring ?
If so, it got me ...
March 8, 2011 at 10:43 pm
I learned something form this question., Nice question.
-----------------
Gobikannan
March 8, 2011 at 11:41 pm
Ol'SureHand (3/8/2011)
Not sure I get the point of the trick question.It should be clear that you can restore to ANY point in time (at each 15 minute interval in this example). However, restoring to the 9:30 state will not recover your TRUNCATEd table ... so was that thrown in as a red herring ?
If so, it got me ...
The question asked: Is it now possible to restore to a given point in time?
It is possible, so the answer is certainly yes. The question didn't ask if it was possible to restore that specific table to any given point in time.
Anyway, nice question.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
March 9, 2011 at 1:00 am
Ol'SureHand (3/8/2011)
Not sure I get the point of the trick question.It should be clear that you can restore to ANY point in time (at each 15 minute interval in this example). However, restoring to the 9:30 state will not recover your TRUNCATEd table ... so was that thrown in as a red herring ?
If so, it got me ...
Hi - I think you may have overthought things a bit - it wasn't meant to be a complicated or trick question, but just to find out if people thought that TRUNCATE TABLE somehow affected the validity of the transaction log. It doesn't.
Thanks for the feedback though, maybe I should have made the question clearer somehow.
Duncan
March 9, 2011 at 1:01 am
Gobikannan (3/8/2011)
I learned something form this question., Nice question.
Thanks, glad you liked it.
Duncan
March 9, 2011 at 1:04 am
Koen Verbeeck (3/8/2011)
Ol'SureHand (3/8/2011)
Not sure I get the point of the trick question.It should be clear that you can restore to ANY point in time (at each 15 minute interval in this example). However, restoring to the 9:30 state will not recover your TRUNCATEd table ... so was that thrown in as a red herring ?
If so, it got me ...
The question asked: Is it now possible to restore to a given point in time?
It is possible, so the answer is certainly yes. The question didn't ask if it was possible to restore that specific table to any given point in time.
Anyway, nice question.
Thanks for the feedback. You read the question as I meant it to be read, so I hope you got it right!
Cheers,
Duncan
March 9, 2011 at 2:04 am
Thanks for the question Duncan. I had a feeling that this question was more at testing our understanding of the truncate statement than the recovery models.
M&M
March 9, 2011 at 2:38 am
Two points for this?
Great!!!
March 9, 2011 at 2:50 am
Duncan Pryde (3/9/2011)
Thanks for the feedback. You read the question as I meant it to be read, so I hope you got it right!
I did 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
March 9, 2011 at 2:56 am
Koen Verbeeck (3/9/2011)
Duncan Pryde (3/9/2011)
Thanks for the feedback. You read the question as I meant it to be read, so I hope you got it right!I did 😀
Good for you! :w00t:
March 9, 2011 at 2:59 am
Easy two points. Thanks.
March 9, 2011 at 3:05 am
mohammed moinudheen (3/9/2011)
Thanks for the question Duncan. I had a feeling that this question was more at testing our understanding of the truncate statement than the recovery models.
It was sort of a bit of both. A misconception appears to be that TRUNCATE TABLE is non-logged or minimally logged. Minimally logged operations occur in BULK_LOGGED (and SIMPLE) recovery and prevent point-in-time restores for affected log backups. TRUNCATE TABLE, even though it behaves similarly to minimally logged operations, is not one and doesn't prevent point-in-time restore - even in BULK_LOGGED recovery.
A good article by Kalen Delaney that explains the difference is here
Duncan
March 9, 2011 at 3:24 am
This is odd. I'm sure I've read stuff that implies TRUNCATE TABLE *does* invalidate log backups until the next full backup is run, which means none of the suggested answers was right--yet everyone is saying this is incorrect and that point-in-time restore is still perfectly possible after doing one of these. I'm confused!
March 9, 2011 at 3:47 am
Duncan Pryde (3/9/2011)
mohammed moinudheen (3/9/2011)
Thanks for the question Duncan. I had a feeling that this question was more at testing our understanding of the truncate statement than the recovery models.It was sort of a bit of both. A misconception appears to be that TRUNCATE TABLE is non-logged or minimally logged. Minimally logged operations occur in BULK_LOGGED (and SIMPLE) recovery and prevent point-in-time restores for affected log backups. TRUNCATE TABLE, even though it behaves similarly to minimally logged operations, is not one and doesn't prevent point-in-time restore - even in BULK_LOGGED recovery.
A good article by Kalen Delaney that explains the difference is here
Duncan
Thanks Duncan for sharing the link.
M&M
Viewing 15 posts - 1 through 15 (of 53 total)
You must be logged in to reply to this topic. Login to reply