<?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: Saving Rows from Corrupt Blocks</title>
	<atom:link href="http://kerryosborne.oracle-guy.com/2009/02/saving-rows-from-corrupt-blocks/feed/" rel="self" type="application/rss+xml" />
	<link>http://kerryosborne.oracle-guy.com/2009/02/saving-rows-from-corrupt-blocks/</link>
	<description>Just another Oracle blog</description>
	<pubDate>Thu, 29 Jul 2010 12:17:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: osborne</title>
		<link>http://kerryosborne.oracle-guy.com/2009/02/saving-rows-from-corrupt-blocks/#comment-306</link>
		<dc:creator>osborne</dc:creator>
		<pubDate>Fri, 13 Mar 2009 21:44:20 +0000</pubDate>
		<guid isPermaLink="false">http://kerryosborne.oracle-guy.com/?p=922#comment-306</guid>
		<description>Toon,

  Nice to meet you too. I enjoyed the first half of your talk this year (I skipped the second half to listen to someone else - that I can't remember now). Anyway, you had me nodding my head up and down on the whole talk. I think moving the majority of code towards the database and away from the application is absolutely the way to go. 

  Your paper on working around block corruption was very helpful on this particular situation. While it wasn't actually block corruption (which we have other mechanism to solve now), the approach worked great. We had a billion+ row table. Fortunately it was partitioned and we were able to export by partition - only a couple of sub-partitions had the problem - so those we ran through block by block, row by row. Got it all back but 2 blocks - about 100 records I think (out of 1.3 billion or so). Not bad!

  Thanks for writing that paper!

Kerry</description>
		<content:encoded><![CDATA[<p>Toon,</p>
<p>  Nice to meet you too. I enjoyed the first half of your talk this year (I skipped the second half to listen to someone else - that I can&#8217;t remember now). Anyway, you had me nodding my head up and down on the whole talk. I think moving the majority of code towards the database and away from the application is absolutely the way to go. </p>
<p>  Your paper on working around block corruption was very helpful on this particular situation. While it wasn&#8217;t actually block corruption (which we have other mechanism to solve now), the approach worked great. We had a billion+ row table. Fortunately it was partitioned and we were able to export by partition - only a couple of sub-partitions had the problem - so those we ran through block by block, row by row. Got it all back but 2 blocks - about 100 records I think (out of 1.3 billion or so). Not bad!</p>
<p>  Thanks for writing that paper!</p>
<p>Kerry</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://kerryosborne.oracle-guy.com/2009/02/saving-rows-from-corrupt-blocks/#comment-305</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Fri, 13 Mar 2009 20:44:22 +0000</pubDate>
		<guid isPermaLink="false">http://kerryosborne.oracle-guy.com/?p=922#comment-305</guid>
		<description>Kerry, I was pleasantly suprised to hear that a paper written over 15 years ago, still helped out someone. Nice meeting you at Hotsos.

Toon</description>
		<content:encoded><![CDATA[<p>Kerry, I was pleasantly suprised to hear that a paper written over 15 years ago, still helped out someone. Nice meeting you at Hotsos.</p>
<p>Toon</p>
]]></content:encoded>
	</item>
</channel>
</rss>
