<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>《找出11g undo 回滚段名称》的评论</title>
	<atom:link href="https://www.xifenfei.com/2012/02/%e6%89%be%e5%87%ba11g-undo-%e5%9b%9e%e6%bb%9a%e6%ae%b5%e5%90%8d%e7%a7%b0.html/feed" rel="self" type="application/rss+xml" />
	<link>https://www.xifenfei.com/2012/02/%e6%89%be%e5%87%ba11g-undo-%e5%9b%9e%e6%bb%9a%e6%ae%b5%e5%90%8d%e7%a7%b0.html</link>
	<description>提供7*24专业数据库(Oracle,SQL Server,MySQL,PostgreSQL等)恢复和技术支持@Tel:17813235971</description>
	<lastBuildDate>Thu, 11 Dec 2025 02:46:14 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>作者：惜 分飞</title>
		<link>https://www.xifenfei.com/2012/02/%e6%89%be%e5%87%ba11g-undo-%e5%9b%9e%e6%bb%9a%e6%ae%b5%e5%90%8d%e7%a7%b0.html/comment-page-1#comment-682</link>
		<dc:creator><![CDATA[惜 分飞]]></dc:creator>
		<pubDate>Sun, 19 Feb 2012 06:39:40 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=2552#comment-682</guid>
		<description><![CDATA[_OFFLINE_ROLLBACK_SEGMENTS is a unsupported init.ora parameter which can allow you to cause logical database corruption. 
&lt;br&gt;
_CORRUPTED_ROLLBACK_SEGMENTS is  more dangerous parameter  than _OFFLINE_ROLLBACK_SEGMENTS. It basically prevents access to the  listed rollback segments headers and assumes all transactions in them are committed.  This can very easily cause logical database corruption.]]></description>
		<content:encoded><![CDATA[<p>_OFFLINE_ROLLBACK_SEGMENTS is a unsupported init.ora parameter which can allow you to cause logical database corruption.<br />
<br />
_CORRUPTED_ROLLBACK_SEGMENTS is  more dangerous parameter  than _OFFLINE_ROLLBACK_SEGMENTS. It basically prevents access to the  listed rollback segments headers and assumes all transactions in them are committed.  This can very easily cause logical database corruption.</p>
]]></content:encoded>
	</item>
	<item>
		<title>作者：惜 分飞</title>
		<link>https://www.xifenfei.com/2012/02/%e6%89%be%e5%87%ba11g-undo-%e5%9b%9e%e6%bb%9a%e6%ae%b5%e5%90%8d%e7%a7%b0.html/comment-page-1#comment-681</link>
		<dc:creator><![CDATA[惜 分飞]]></dc:creator>
		<pubDate>Sun, 19 Feb 2012 05:57:34 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=2552#comment-681</guid>
		<description><![CDATA[以前的strings命令找出相应回滚段方法测试
[shell]
[oracle@localhost odu]$ strings /u01/oradata/first/system01.dbf &#124; grep _SYSSMU &#124; cut -d $ -f 1 &#124; sort -u &gt;/tmp/system.txt
[oracle@localhost odu]$ more /tmp/system.txt 
              and substr(drs.segment_name,1,7) != &#039;_SYSSMU&#039; 
D&#039;              and substr(drs.segment_name,1,7) != &#039;&#039;_SYSSMU&#039;&#039; &#039; );
_SYSSMU10_3459578018
_SYSSMU10_4131489474
_SYSSMU11_1017459875
_SYSSMU12_537332688
_SYSSMU1_3133714326
_SYSSMU13_856144422
_SYSSMU14_1282242678
_SYSSMU15_3732347774
_SYSSMU1_592353410
_SYSSMU16_3892484933
_SYSSMU17_2605132257
_SYSSMU18_1698028356
_SYSSMU19_1313888654
_SYSSMU20_1688883760
_SYSSMU2_849237456
_SYSSMU2_967517682
_SYSSMU3_1204390606
_SYSSMU3_50029197
_SYSSMU4_1003442803
_SYSSMU4_2580388194
_SYSSMU5_3406574735
_SYSSMU5_538557934
_SYSSMU6_162144149
_SYSSMU6_2897970769
_SYSSMU7_2865732393
_SYSSMU7_3517345427
_SYSSMU8_1312276615
_SYSSMU8_3901294357
_SYSSMU9_1735643689
_SYSSMU9_2252183395
[/shell]
在这里可以看出，每个回滚段都有两个(时间戳不一样)，在使用的时候，我们就不能确定使用哪个比较合适(因为不知道哪个此时真正的需要的回滚段，而在spfile中同时标明一个回滚段的两个名称，前面一个会被覆盖)，由此可以看出，这种方法暂时不太合适（而且在win的系统中很难使用，即使第三方工具可以打开system表空间数据文件，要找到相关内容并非易事，而且也可以有类此linux中现象出现）]]></description>
		<content:encoded><![CDATA[<p>以前的strings命令找出相应回滚段方法测试</p>
<pre class="brush: bash; title: ; notranslate">
[oracle@localhost odu]$ strings /u01/oradata/first/system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u &gt;/tmp/system.txt
[oracle@localhost odu]$ more /tmp/system.txt 
              and substr(drs.segment_name,1,7) != '_SYSSMU' 
D'              and substr(drs.segment_name,1,7) != ''_SYSSMU'' ' );
_SYSSMU10_3459578018
_SYSSMU10_4131489474
_SYSSMU11_1017459875
_SYSSMU12_537332688
_SYSSMU1_3133714326
_SYSSMU13_856144422
_SYSSMU14_1282242678
_SYSSMU15_3732347774
_SYSSMU1_592353410
_SYSSMU16_3892484933
_SYSSMU17_2605132257
_SYSSMU18_1698028356
_SYSSMU19_1313888654
_SYSSMU20_1688883760
_SYSSMU2_849237456
_SYSSMU2_967517682
_SYSSMU3_1204390606
_SYSSMU3_50029197
_SYSSMU4_1003442803
_SYSSMU4_2580388194
_SYSSMU5_3406574735
_SYSSMU5_538557934
_SYSSMU6_162144149
_SYSSMU6_2897970769
_SYSSMU7_2865732393
_SYSSMU7_3517345427
_SYSSMU8_1312276615
_SYSSMU8_3901294357
_SYSSMU9_1735643689
_SYSSMU9_2252183395
</pre>
<p>在这里可以看出，每个回滚段都有两个(时间戳不一样)，在使用的时候，我们就不能确定使用哪个比较合适(因为不知道哪个此时真正的需要的回滚段，而在spfile中同时标明一个回滚段的两个名称，前面一个会被覆盖)，由此可以看出，这种方法暂时不太合适（而且在win的系统中很难使用，即使第三方工具可以打开system表空间数据文件，要找到相关内容并非易事，而且也可以有类此linux中现象出现）</p>
]]></content:encoded>
	</item>
</channel>
</rss>
