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