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> </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> </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> </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> </code><code>alter</code> <code>system </code><code>set</code> <code>undo_tablespace=UNDOTEST;</code>
<code>/* 列出相关的undo参数,可以看到这里undo_retention参数设为极短的10s */</code>
<code>SQL> 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> 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> backup tablespace UNDOTEST;</code>
<code>RMAN> 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> conn maclean/maclean</code>
<code>Connected.</code>
<code>SQL> </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> </code><code>delete</code> <code>YOUYUS;</code>
<code>579808 </code><code>rows</code> <code>deleted.</code>
<code>/* 此时再次执行备份undo表空间操作 */</code>
<code>RMAN> 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> </code><code>commit</code><code>;</code>
<code>Commit</code> <code>complete.</code>
<code>SQL> </code><code>exec</code> <code>dbms_lock.sleep(20);</code>
<code>PL/SQL </code><code>procedure</code> <code>successfully completed.</code>
<code>SQL> </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 ====> 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> </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