<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Recover Data Using Transaction Log</title>
	<atom:link href="http://www.siusic.com/wphchen/recover-data-using-transaction-log-144.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.siusic.com/wphchen/recover-data-using-transaction-log-144.html</link>
	<description>Random thoughts and news by Andrew Chen and friends</description>
	<pubDate>Thu, 09 Feb 2012 13:10:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: durairaj</title>
		<link>http://www.siusic.com/wphchen/recover-data-using-transaction-log-144.html#comment-135093</link>
		<dc:creator>durairaj</dc:creator>
		<pubDate>Fri, 22 Apr 2011 20:05:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.siusic.com/wphchen/recover-data-using-transaction-log-144.html#comment-135093</guid>
		<description>Great!.  Theory is applied well in practice.

This post gives the most correct explanation of the delete and truncate operations.  There is no free lunch either way!!.  The concept of delete and truncate are very different. However in data protection stand point both work similer.  Only difference is in the operational stand point where truncate frees lots of resources during its course. The comitted transactions can never be rolledback howver can be recovered to prior point in time using properly done full/diff/t-log backups.  Even the log reader is not useful if the truncated/deleted data is changed by 'following transactions'.  So there must be some amount of redoing the work from users stand point. This can not be avoided and there is no possible logic which can avoid this situation. Hence this is the known limitation for ever.

Surprised not to see a single comment on this post. 

- Durairaj Padhmanaban.</description>
		<content:encoded><![CDATA[<p>Great!.  Theory is applied well in practice.</p>
<p>This post gives the most correct explanation of the delete and truncate operations.  There is no free lunch either way!!.  The concept of delete and truncate are very different. However in data protection stand point both work similer.  Only difference is in the operational stand point where truncate frees lots of resources during its course. The comitted transactions can never be rolledback howver can be recovered to prior point in time using properly done full/diff/t-log backups.  Even the log reader is not useful if the truncated/deleted data is changed by &#8216;following transactions&#8217;.  So there must be some amount of redoing the work from users stand point. This can not be avoided and there is no possible logic which can avoid this situation. Hence this is the known limitation for ever.</p>
<p>Surprised not to see a single comment on this post. </p>
<p>- Durairaj Padhmanaban.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

