天天看点

undo backup optimization does not work on 11.2.0.1?

Backup Undo Optimization是11g的新特性之一,RMAN将避免备份撤销表空间上那些已提交事务的撤销数据。且该特性无法被禁用(You can enable and disable backup optimization, but backup undo optimization is built-in behavior.)。 我们在11.2.0.1版本上具体测试一下这个新特性:

<a href="http://blog.51cto.com/maclean/1277135#">?</a>

<code>SQL&gt; </code><code>select</code> <code>* </code><code>from</code> <code>v$version;</code>

<code>BANNER</code>

<code>--------------------------------------------------------------------------------</code>

<code>Oracle </code><code>Database</code> <code>11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production</code>

<code>PL/SQL Release 11.2.0.1.0 - Production</code>

<code>CORE    11.2.0.1.0      Production</code>

<code>TNS </code><code>for</code> <code>Linux: Version 11.2.0.1.0 - Production</code>

<code>NLSRTL Version 11.2.0.1.0 - Production</code>

<code>/*  为了避免undo自动调优干扰我们的测试,修改_undo_autotune参数禁用该特性 */</code>

<code>SQL&gt; </code><code>alter</code> <code>system </code><code>set</code> <code>"_undo_autotune"</code><code>=</code><code>false</code><code>;</code>

<code>System altered.</code>

<code>/* 创建一个新的undo表空间,清理现场 */</code>

<code>SQL&gt; </code><code>create</code> <code>undo tablespace UNDOTEST datafile </code><code>size</code> <code>500M autoextend </code><code>on</code> <code>next</code> <code>50M maxsize unlimited;</code>

<code>Tablespace created.</code>

<code>SQL&gt; </code><code>alter</code> <code>system </code><code>set</code> <code>undo_tablespace=UNDOTEST;</code>

<code>/* 列出相关的undo参数,可以看到这里undo_retention参数设为极短的10s */</code>

<code>SQL&gt; show parameter undo;</code>

<code>NAME</code>                                 <code>TYPE        VALUE</code>

<code>------------------------------------ ----------- ------------------------------</code>

<code>_undo_autotune                       boolean     </code><code>FALSE</code>

<code>undo_management                      string      AUTO</code>

<code>undo_retention                       </code><code>integer</code>     <code>10</code>

<code>undo_tablespace                      string      UNDOTEST</code>

<code>RMAN&gt; list backup;</code>

<code>specification does </code><code>not</code> <code>match </code><code>any</code> <code>backup </code><code>in</code> <code>the repository</code>

<code>RMAN&gt; backup tablespace UNDOTEST;</code>

<code>RMAN&gt; list backup </code><code>of</code> <code>tablespace UNDOTEST;</code>

<code>BS </code><code>Key</code>  <code>Type LV </code><code>Size</code>       <code>Device Type Elapsed </code><code>Time</code> <code>Completion </code><code>Time</code>

<code>------- ---- -- ---------- ----------- ------------ ---------------</code>

<code>4       </code><code>Full</code>    <code>1.90M      DISK        00:00:00     25-AUG-10</code>

<code>/* undo表空间初始的备份大小为1.9M  */</code>

<code>SQL&gt; conn maclean/maclean</code>

<code>Connected.</code>

<code>SQL&gt; </code><code>select</code> <code>count</code><code>(*) </code><code>from</code> <code>YOUYUS;</code>

<code>  </code><code>COUNT</code><code>(*)</code>

<code>----------</code>

<code>    </code><code>579808</code>

<code>/* YOUYUS表有大约60万条数据,我们批量删除这些数据,将产生大量的undo*/</code>

<code>SQL&gt; </code><code>delete</code> <code>YOUYUS;</code>

<code>579808 </code><code>rows</code> <code>deleted.</code>

<code>/*  此时再次执行备份undo表空间操作 */</code>

<code>RMAN&gt;  list backup </code><code>of</code> <code>tablespace UNDOTEST;</code>

<code>5       </code><code>Full</code>    <code>134.43M    DISK        00:00:03     25-AUG-10</code>

<code>/*  在存在大量active undo数据的情况下,备份文件增大到134M */</code>

<code>SQL&gt; </code><code>commit</code><code>;</code>

<code>Commit</code> <code>complete.</code>

<code>SQL&gt; </code><code>exec</code> <code>dbms_lock.sleep(20);</code>

<code>PL/SQL </code><code>procedure</code> <code>successfully completed.</code>

<code>SQL&gt; </code><code>select</code> <code>status,</code><code>sum</code><code>(blocks) </code><code>from</code> <code>dba_undo_extents </code><code>group</code> <code>by</code> <code>status;</code>

<code>STATUS    </code><code>SUM</code><code>(BLOCKS)</code>

<code>--------- -----------</code>

<code>UNEXPIRED        2696</code>

<code>EXPIRED         32936</code>

<code>/* </code><code>commit</code><code>后等待20s,确定没有active的撤销段 */</code>

<code>6       </code><code>Full</code>    <code>134.49M    DISK        00:00:02     25-AUG-10</code>

<code>/* 备份文件还要大于</code><code>commit</code><code>前,undo backup optimization居然没有起作用? */</code>

<code>/* 这个会是BUG吗? */</code>

根据以上情况我提交了SR,ORACLE GCS给出的回复:

Bug 6399468: UNDO OPTIMIZATION ====&gt; Undo optimization was changed from 'all undo not needed' to 'undo not in use older than 1 hour' In unpublished bug 6399468 DEV has confirmed the Undo optimization was changed from 'all undo not needed' to 'undo not in use older than 1 hour'. For your last test case please wait for 1 hour and try backup again.

居然又是一个unpublished的BUG,Oracle DEV部门确认了backup undo optimization所避免备份的是1个小时以上未被尝试使用的undo,而非所有不再需要的undo。这是典型的开发部门和文档撰写部门间没有充分交流造成的问题!

<code>/* 尝试等待3600s */</code>

<code>SQL&gt; </code><code>exec</code> <code>dbms_lock.sleep(3600);</code>

<code>/* 3600s还真漫长....... */</code>

<code>10      </code><code>Full</code>    <code>15.01M     DISK        00:00:00     25-AUG-10</code>

<code>/* 备份集缩小到15m,undo backup optimization起到了作用!*/</code>

<code>That's great!</code>

本文转自maclean_007 51CTO博客,原文链接:http://blog.51cto.com/maclean/1277135