RMAN除了单纯的备份恢复功能，已经被赋予了越来越多的责任，比如创建Standby数据库，比如跨平台传输表空间中的表空间转换。Oracle11g的RMAN倒是没有太多飞跃性的更新。

1. 自定义archivelog删除策略

我们知道在11g之前，只有backupset的删除策略可以定义，比如保留多长时间的备份或者保留多少份有效备份，而删除归档日志只有在delete命令中定义删除全部备份完毕的或者删除从哪一个时间点到哪一个时间点的。而在11g中我们已经可以通过configure命令来定义归档日志的删除策略的，比如增加了下面的语法，只有在磁带上备份了2次的归档日志才会被delete命令删除。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;

当然，仅仅是增加语法那就只能称为比较无聊的新功能了，除了configure语法之外，现在在11g中通过APPLIED ON
STANDBY关键字可以定义只有对于所有的standby站点都已经applied的归档日志才会被删除，或者定义所有被成功传送到standby站点的归档日志就可以被删除。而以前这些都需要DBA自己撰写脚本从数据字典中查询到相关信息然后再通过脚本删除。

2. 直接通过网络复制数据库

在11g之前如果要使用duplicate命令来复制一份数据库，那么则需要源数据库，需要在目标机器上的一份有效备份，需要目标数据库，在11g中这一切被大大简化。通过FROM ACTIVE DATABASE关键字，我们只需要有一个源数据库，就可以简单地通过网络在另外一台机器上复制一个相同的数据库了。Oracle会通过一系列Memory Script在内存中recover并且open目标数据库。

另外，在11g之前，duplicate数据库是不会自动复制spfile的，而现在，我们通过下面的语句，就可以让Oracle在复制过程中自动生成一份spfile，并且其中的初始化参数允许额外定义。

在11g中使用duplicate复制一个数据库的准备步骤只需要目标数据库（AUXILIARY实例）：
a. 通过一个最简单的pfile把实例启动到nomount状态，这个pfile中只需要包含DB_NAME和REMOTE_LOGIN_PASSWORFILE参数即可
b. password文件必须事先建好，而且SYS密码需要跟source数据库中相同，这个通过orapwd可以轻松完成
c. 目录结构需要事先创建好并且具有正确的权限

3. 并行备份大文件

现在Oracle数据库中单个数据文件可以最大到128T，而在以前的版本中RMAN的最小备份单位就是datafile，那么对于以后可能出现的这种超大数据文件，RMAN备份就几乎无法操作了。在11g中，通过backup命令中的SECTION SIZE关键字，我们可以对数据文件指定section了，每个section都作为一个独立单位来处理，每个数据文件可以最多指定256个section。

Section的好处在于，一可以并行备份多个section，提高备份速度；二可以分多个时间分别备份一个大文件的多个section，时间上化整为零，更具有操作性。

4. RMAN Catalog管理性增强

IMPORT CATALOG命令允许我们将一个catalog库中的信息转储到另外一个catalog库，这在以前完全需要手工操作。

推出Virtual Recovery Catalogs概念，这是VPD的实例应用，对于一个集中管理的catalog设置多个用户的虚拟catalog，每个用户只能管理自己的数据，安全性的进一步提高。

下一篇介绍Invisible Indexes。

Oracle Oracle11g

一个月一度的征期到了，在上次存储调整之后平稳度过了数月之后，这次客户又来紧急电话，从上周三下午开始数据库服务器I/O负载忽然陡升到100%，申报要40分钟，各大厅纳税人开始骂娘。。。

每个月的征期有一周，而纳税人通常都憋到最后几天才开始出动，也就是这一周的最后两天将是系统负载的最高峰，而上周三仅仅是刚进入征期而已。

在被变幻莫测的雷雨天气延误了3个小时之后，飞机从首都机场起飞了，即将到达目的地的时候，忽然遇到暴雨天气，飞机在剧烈颤动了良久之后，忽然间好似过山车一样急降，这个急降大概持续了3秒左右，心都被扔到了嗓子眼，全机舱忽然之间鸦雀无声，等急降结束了好一阵儿逐渐平稳以后，才听到周遭各式各样的大吐气。爽啊。

降落目的地，客户来接机，然后请吃饭，这么隆重的待遇是因为总局，省局，市局，分局的各级领导都到了，如果征期挺不过去，领导会很生气，后果会很严重。

回到酒店，打开刚拿到的周三下午的statspack report，心里面一块石头落地了，非常幸运，太明显的性能问题了。cache buffer chains latch free占据90%以上的等待时间，buffer gets top SQL中一条select distinct的语句在一张报表中占据了60%以上，另外一张居然占据了143.2%，每次执行这个SQL都会有8,725,441.7的buffer gets，在半个小时里面一共执行了150次左右。

虽然不知道相关表的数据量和执行计划，但是很明显这就是罪魁祸首，于是安心睡觉。

今天上午到客户处，直接告诉客户90%的原因是由于这条SQL语句，然后连上服务器，开始tuning。

两张表，A表1679679条记录，B表839889条记录。

就是这么简单的语句，执行计划是对A表索引的index fast full scan，然后根据B表的index range scan做filter，最后sort返回结果。执行计划看上去问题不大，执行一次大概需要20秒左右，但是对于将近200万记录的index fast full scan已经是不小的IO，再做循环filter，更可怕的是，每一笔开票之前都需要有这样一个操作，典型的hot block问题。

跟开发商沟通之后，知道这是两张同步记录表，也就是每次业务开始会在A表中insert一条数据，然后开始同步，同步成功之后再在B表中insert一条数据，之后每次业务再开始就先找一下在A表中已经insert了的但是在B表中还不存在的（在B表中不存在就是表示还没同步），很明显业务是不应该如此设计的，在一张表中做标志位也比两张表联合查询只增不减的同步记录要好。但是现在讨论业务已经没有实际意义了。

同步成功之后的记录是没有用处的，可惜没有一个默认的删除策略，于是开始设想删除A表的无用数据，按照执行计划，B表的数据量跟执行效率关系不大，只需要删除A表数据就行。写了一个存储过程，每删除10000条记录commit一次。

在还没有开始删除的时候，客户的投诉电话已经开始络绎不绝了，各个大厅报客户端死机一样慢，有些纳税人出去转了一趟回来申报还没保存成功。。。。 删除同步记录的存储过程运行了20分钟，最后剩下了将近40000条记录，此时各个大厅已经报业务可以成功了，大概每次业务需要开将近10分钟。

这仍然不是我想要的结果，10分钟？不可能这么慢的，再次运行statspack，居然。。。又出现另外一条跟这两个表相关的SQL，FT，还有不一样的写法。。。这次是加了条件的，结果直接在A表中full table scan了，40000条记录的FTS仍然是不小的开销，而且仍然存在hot block，所以仍然是latch free。

加hint，测试了一下，速度激增，但是开发商说，这是前台程序，没有办法现在立刻更改立刻发布。那就只能再加索引了，根据SQL添加了一个normal index，再次执行SQL，飞一样的速度啊。创建完索引，刚把操作步骤记录下来，客户那边已然欢歌笑语，3秒钟！客户扭头问我，你做了什么？现在只要3秒钟就完成业务了。我说，呵呵，加了一个索引。

40分钟->10分钟->3秒钟。工作圆满完成。This is tuning。

这是你传给我的Video，我记得。
惶恐于自己一个月的咒语，无地自容，真的是恶魔吗。
我为厦门的海边准备了相机。

No tag

如果不是今天看到Fenng的给 Larry Ellison 的公开信，事关 AWR 与 ASH文章中提到Mark Brinsmead的这封公开信，我也不知道AWR/ADDM/ASH这样几乎完全内置在数据库中的功能也是需要额外收费的。

仔细查了一下Oracle® Database Licensing Information，果然如此，汗。

Command-Line APIs

Diagnostics Pack features can also be accessed by way of database server APIs and command-line interfaces:

* The DBMS_WORKLOAD_REPOSITORY package is part of this pack.
* The DBMS_ADVISOR package is part of this pack if you specify ADDM as the value of the advisor_name parameter, or if you specify for the value of the task_name parameter any value starting with the ADDM prefix.
* The V$ACTIVE_SESSION_HISTORY dynamic performance view is part of this pack.
* All data dictionary views beginning with the prefix DBA_HIST_ are part of this pack, along with their underlying tables.
* All data dictionary views with the prefix DBA_ADVISOR_ are part of this pack if queries to these views return rows with the value ADDM in the ADVISOR_NAME column or a value of ADDM* in the TASK_NAME column or the corresponding TASK_ID.
* The following reports found in the /rdbms/admin/ directory of the Oracle home directory are part of this pack: awrrpt.sql, awrrpti.sql, addmrtp.sql, addmrpti.sql, awrrpt.sql, awrrpti.sql, addmrpt.sql, addmrpti.sql, ashrpt.sql, ashrpti.sql, awrddrpt.sql, awrddrpi.sql, awrsqrpi.sql, awrsqrpt.sql.

即使作为Oracle的员工，恐怕我也得私下里支持一下这位DBA的提议。在公开信中回复的comment中包含“SIGNATORY”字样就表示电子签名了。

如果说awrrpt.sql这样的脚本在不购买Oracle Diagnostic Pack的license情况下不允许使用，倒也还能控制，但是连内置在数据库里面的毫无限制的性能视图都不允许去查询，这样的license确实有些离奇，我想没有人能控制住自己不敲下select …. from V$ACTIVE_SESSION_HISTORY吧。

License Oracle