Oracle Database 10g:为 DBA 提供的最佳前 20 位的特性（一到六）

http://www.cndw.com/tech/data/2006051167731.asp

Oracle Database 10g:为 DBA 提供的最佳前 20 位的特性（一）
作者 Arup Nanda 来源： OTN
在过去的 27 年中， Oracle 已经在其核心数据库产品中进行了大量的改进工作。现在，该产品不仅是世界上最可靠和性能最好的数据库，而且是用于企业计算的完整软件基础架构的组成部分。随着每个新版本的出现，有时会推出夺目的新功能和特性，有时会让开发人员、 IT 经理甚至经验丰富的 DBA 疑惑哪些新特性会为他们带来最大的利益。
随着 Oracle Database 10 g 的推出， DBA 将会得到 Oracle 历来提供的最深奥的新版本之一。因此，对于那些花时间来理解如何将新的 Oracle 技术正确应用到其日常工作中的 DBA 来说，他们将会喜欢许多省时并且最终会省钱的新功能。
Oracle Database 10 g 提供了许多新的工具，它们帮助 DBA 更加高效（也可能更加愉快）地工作，使他们解放出来，进行更具有战略性、创造性的工作 — 而不是谈论他们在夜间和周末的加班工作。 Oracle Database 10 g 确实 是 DBA 的得力工具。
在新的 20 周时间中，我将通过给出我所认为的 Oracle Database 10 g 为数据库管理任务提供的最佳前 20 位的新特性，帮助您详细了解这个功能强大的新版本。该列表包含了从基本特性（如为创建用户而设置默认表空间）到高级特性（如新的自动存储管理特性）等内容。
在本系列中，我将提供对这些有趣的新工具和技术的简要、集中的分析。其目的是概述特性的功能和优点，以便您能够尽快将其应用到您的环境中。
欢迎您对本系列提出您的想法、意见和问题。祝您愉快！
第 1 周

得到电影而不是图片：闪回版本查询
不需要设置，立即识别对行的所有更改
在 Oracle9 i Database 中，我们看到它推出了以闪回查询形式表示的 “ 时间机器 ” 。该特性允许 DBA 看到特定时间的列值，只要在还原段中提供该数据块此前镜像的拷贝即可。但是，闪回查询只提供某时刻数据的固定快照，而不是在两个时间点之间被更改数据的运行状态表示。某些应用程序，如涉及到外币管理的应用程序，可能需要了解一段时期内数值数据的变化，而不仅仅是两个时间点的数值。由于闪回版本查询特性， Oracle Database 10 g 能够更方便高效地执行该任务。
查询对表的更改
在本示例中，我使用了一个银行外币管理应用程序。其数据库含有一个名称为 RATES 的表，用于记录特定时间的汇率。
SQL> desc rates
Name Null?Type
----------------- -------- ------------
CURRENCY VARCHAR2(4)
RATE NUMBER(15,10)
该表显示 US$ 与各种其他货币的汇率，在 CURRENCY 列中显示。在金融服务行业中，汇率不但在变更时进行更新，而且被记录在历史中。需要这种方式的原因是银行交易可能在 “ 过去时间 ” 生效，以便适应由于汇款而耗费的时间。例如，对于一项在上午 10:12 发生但在上午 9:12 生效的交易，其有效汇率是上午 9:12 的汇率，而不是现在的汇率。
直到现在，唯一的选择是创建一个汇率历史表来存储汇率的变更，然后查询该表是否提供历史记录。另一种选择是在 RATES 表本身中记录特定汇率适用性的开始和结束时间。当发生变更时，现有行中的 END_TIME 列被更新为 SYSDATE ，并插入一个具有新汇率的新行，其 END_TIME 为 NULL 。
但是在 Oracle Database 10 g 中，闪回版本查询特性不需要维护历史表或存储开始和结束时间。使用该特性，您不必进行额外的设置，即可获得某行在过去特定时间的值。
例如，假定该 DBA 在正常业务过程中数次更新汇率 — 甚至删除了某行并重新插入该行：
insert into rates values ('EURO',1.1012);
commit;
update rates set rate = 1.1014;
commit;
update rates set rate = 1.1013;
commit;
delete rates;
commit;
insert into rates values ('EURO',1.1016);
commit;
update rates set rate = 1.1011;
commit;
在进行了这一系列操作后， DBA 将通过以下命令获得 RATE 列的当前提交值
SQL> select * from rates;
CURR RATE
---- ----------
EURO 1.1011
此输出显示 RATE 的当前值，没有显示从第一次创建该行以来发生的所有变更。这时使用闪回查询，您可以找出给定时间点的值；但我们对构建变更的审计线索更感兴趣 — 有些类似于通过便携式摄像机来记录变更，而不只是在特定点拍摄一系列快照。
以下查询显示了对表所做的更改：
select versions_starttime, versions_endtime, versions_xid,
versions_operation, rate
from rates versions between timestamp minvalue and maxvalue
order by VERSIONS_STARTTIME
/
VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.12 PM 01-DEC-03 03.57.30 PM 0002002800000C 61 I 1.1012
01-DEC-03 03.57.30 PM 01-DEC-03 03.57.39 PM 000A 000A 00000029 U 1.1014
01-DEC-03 03.57.39 PM 01-DEC-03 03.57.55 PM 000A 000B00000029 U 1.1013
01-DEC-03 03.57.55 PM 000A 000C 00000029 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A 000D00000029 I 1.1016
01-DEC-03 03.58.17 PM 000A 000E00000029 U 1.1011
注意，此处显示了对该行所作的所有更改，甚至包括该行被删除和重新插入的情况。 VERSION_OPERATION 列显示对该行执行了什么操作 (Insert/Update/Delete) 。所做的这些工作不需要历史表或额外的列。
在上述查询中，列 versions_starttime 、 versions_endtime 、 versions_xid 、 versions_operation 是伪列，与 ROWNUM 、 LEVEL 等其他熟悉的伪列相类似。其他伪列 — 如 VERSIONS_STARTSCN 和 VERSIONS_ENDSCN — 显示了该时刻的系统更改号。列 versions_xid 显示了更改该行的事务标识符。有关该事务的更多详细信息可在视图 FLASHBACK_TRANSACTION_QUERY 中找到，其中列 XID 显示事务 id 。例如，使用上述的 VERSIONS_XID 值 000A 000D00000029 ， UNDO_SQL 值显示了实际的语句。
SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = ' 000A 000D00000029';
UNDO_SQL
----------------------------------------------------------------------------
insert into "ANANDA"."RATES"("CURRENCY","RATE") values ('EURO','1.1013');
除了实际语句之外，该视图还显示提交操作的时间标记和 SCN 、查询开始时的 SCN 和时间标记以及其他信息。
找出一段时期中的变更
现在，让我们来看如何有效地使用这些信息。假设我们需要找出下午 3:57:54 时 RATE 列的值。我们可以执行：
select rate, versions_starttime, versions_endtime
from rates versions
between timestamp
to_date('12/1/2003 15:57:54','mm/dd/yyyy hh24:mi:ss')
and to_date('12/1/2003 16:57:55','mm/dd/yyyy hh24:mi:ss')
/
RATE VERSIONS_STARTTIME VERSIONS_ENDTIME
---------- ---------------------- ----------------------
1.1011
此查询与闪回查询类似。在以上的示例中，开始和结束时间为空，表示汇率在该时间段中没有更改，而是包含一个时间段。还可以使用 SCN 来找出过去的版本值。可以从伪列 VERSIONS_STARTSCN 和 VERSIONS_ENDSCN 中获得 SCN 号。以下是一个示例：
select rate, versions_starttime, versions_endtime
from rates versions
between scn 1000 and 1001
/
使用关键词 MINVALUE 和 MAXVALUE ，可以显示还原段中提供的所有变更。您甚至可以提供一个特定的日期或 SCN 值作为范围的一个端点，而另一个端点是文字 MAXVALUE 或 MINVALUE 。例如，以下查询提供那些只从下午 3:57:52 开始的变更，而不是全部范围的变更：
select versions_starttime, versions_endtime, versions_xid,
versions_operation, rate
from rates versions between timestamp
to_date('12/11/2003 15:57:52', 'mm/dd/yyyy hh24:mi:ss')
and maxvalue
order by VERSIONS_STARTTIME
/
VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.55 PM 000A 000C 00000029 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A 000D00000029 I 1.1016
01-DEC-03 03.58.17 PM 000A 000E00000029 U 1.1011
最终的分析
闪回版本查询随取随用地复制表变更的短期易变数值审计。这一优点使得 DBA 能够获得过去时间段中的所有变更而不是特定值，只要还原段中提供数据，就可以尽情使用。因此，最大的可用版本依赖于 UNDO_RETENTION 参数。
有关闪回版本查询的更多信息，请参见 Oracle Database Concepts 10g Release 1 (10.1) 指南的 相关部分
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（二）
第 2 周
还要多长时间？：回滚监视
为用户提供对回滚操作时间的准确评估
我们还在这地方吗？还要多长时间？
听起来熟悉吗？这些问题可能是您在前往孩子们最喜爱的主题公园的路上，从汽车后座上提出来的，并且经常是不断地、越来越频繁地提出来。您不想告诉他们还确切需要多长时间吗 — 或者更简单些，您自己知道答案吗？
同样，在回滚长期运行的事务时，经常会有些用户不停地询问相同的问题。这些问题是合理的，因为该事务进行了锁定，正常的处理经常受到回滚进程的影响。
在 Oracle 9 i Database 及更低的版本中，您可以执行查询
SELECT USED_UREC
FROM V$TRANSACTION;
该语句返回由当前事务所使用的重做记录的数量，而如果重复地执行该语句，将会显示连续减少的数值，因为回滚进程在其处理过程中会释放重做记录。随后您可以通过对一段间隔进行快照来计算其速率，然后推断出评估结束时间的结果。
虽然在视图 V$TRANSACTION 中有一个名为 START_TIME 的列，但该列只显示整个事务的起始时间（也就是在回滚执行之前）。因此，除了推断，您没有办法知道回滚实际上是在什么时间执行的。
事务回滚的扩展统计信息
在 Oracle Database 10 g 中，这种操作很简单。当事务回滚时，事件被记录在视图 V$SESSION_LONGOPS 中，该视图显示长期运行的事务。用于回滚，如果进程耗时超过六秒，则记录出现在该视图中。在回滚执行以后，您可能会隐藏所查看的监视屏幕并执行以下的查询：
select time_remaining
from v$session_longops
where sid = < sid of the session doing the rollback >;
既然您意识到这个视图 V$SESSION_LONGOPS 的重要性，就让我们来看它必须提供的其他信息。该视图在 Oracle Database 10 g 的预览版中提供，但没有捕获关于回滚事务的信息。为了以一种易读的方式显示所有的列，我们将使用由 Tom Kyte 在 AskTom.com 中所描述的 PRINT_TABLE 函数。此过程简单地以表格方式而不是常用的行方式来显示列。
SQL> set serveroutput on size 999999
SQL> exec print_table('select * from v$session_longops where sid = 9')
SID : 9
SERIAL# : 68
OPNAME :Transaction Rollback
TARGET :
TARGET_DESCid:0x000e .01c .00000067
SOFAR : 20554
TOTALWORK : 10234
UNITS :Blocks
START_TIME :07-dec-2003 21:20:07
LAST_UPDATE_TIME :07-dec-2003 21:21:24
TIME_REMAINING : 77
ELAPSED_SECONDS : 77
CONTEXT : 0
MESSAGE :Transaction Rollback:xid:0x000e .01c .00000067 :
10234 out of 20554 Blocks done
USERNAME ： SYS
SQL_ADDRESS :00000003B719ED08
SQL_HASH_VALUE : 1430203031
SQL_ID :306w 9c 5amyanr
QCSID : 0
注意，此处显示对行的所有更改，即使删除并重新插入行时也是如此。 VERSION_OPERATION 列显示对该行执行的操作 (Insert/Update/Delete) 。完成这些操作不需要历史表或额外的列。
让我们仔细检查这些列中的每一列。在会话中可能会有超过多个长期运行操作 — 特别是因为视图中包含以前的会话中所有长期运行操作的历史。列 OPNAME 显示该记录用于 “ 事务回滚 ” ，这为我们指出了正确的方向。列 TIME_REMAINING 显示所评估的剩余时间秒数，这在前面已经描述过，而列 ELAPSED_SECONDS 显示到目前为止所消耗的时间。
那么该表如何提供对剩余时间的评估呢？可以在列 TOTALWORK 中找到线索，该列显示要完成的 “ 工作 ” 总量，还有 SOFAR 显示到目前为止已经完成了多少工作。工作的单位显示在列 UNITS 中。在本例中以数据块为单位；因此，到目前为止已经回滚了 20,554 个数据块中共计 10,234 个数据块。此操作到目前为止已消耗了 77 秒。因此，剩余数据块将消耗：
77 * ( 10234 / (20554-10234) ) ? 77 秒
但您不必利用这种方法来获得该数值，它已经清楚地显示出来了。最后，列 LAST_UPDATE_TIME 显示有关当前视图内容的时间，这将用于加强您对结果的解释。
SQL 语句
另一部分重要的新信息是正在被回滚的 SQL 语句的标识符。在早先， SQL_ADDRESS 和 SQL_HASH_VALUE 用于获取正在被回滚的 SQL 语句。新的列 SQL_ID 对应于视图 V$SQL 的 SQL_ID ，如下所示：
SELECT SQL_TEXT
FROM V$SQL
WHERE SQL_ID = < value of SQL_ID from V$SESSION_LONGOPS >;
该查询返回所回滚的语句，因此提供了额外的校验以及 SQL 语句的地址和散列值。
并行实例恢复
如果 DML 操作是并行操作，则列 QCSID 显示并行查询服务器会话的 SID 。在并行回滚事件中，如实例恢复以及随后的故障事务恢复期间，经常用到该信息经常。
例如，假设在大型的更新期间，实例异常关闭。当实例启动时，发生故障的事务被回滚。如果启用了用于并行恢复的初始化参数值，则回滚并行地而不是串行地发生，如同它发生在常规事务回滚中一样。下一步的任务是评估回滚进程的完成时间。
视图 V$FAST_START_TRANSACTIONS 显示为回滚故障事务所产生的事务。类似的视图 V$FAST_START_SERVERS 显示对回滚进行处理的并行查询服务器的数量。这两个视图都在以前的版本中提供，但显示事务标识符的新列 XID 使得联接更方便了。在 Oracle9 i Database 以及更低的版本中，您必须通过三列（ USN — 重做段号， SLT — 重做段中的存储区号， SEQ — 序列号）来联接视图。其父集显示在 PARENTUSN 、 PARENTSLT 和 PARENTSEQ 中。在 Oracle Database 10 g 中，您只需将其联接到 XID 列，其父 XID 由直观的名称表示： PXID 。
最有用的信息部分来自于 V$FAST_START_TRANSACTIONS 视图中的列 RCVSERVERS 。如果发生并行回滚，则该列中显示并行查询服务器的数量。您可以查看该列，了解启动了多少并行查询进程：
select rcvservers from v$fast_start_transactions;
如果输出是 1 ，则事务正在由 SMON 进程进行串行回滚 — 显然这是完成工作的一种不充分的方法。您可以将初始化参数 RECOVERY_PARALLELISM 的值改为除 0 或 1 以外的值，重新启动实例进行并行回滚。随后您可以执行 ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = HIGH ，按 CPU 数量的 4 倍创建并行服务器。
如果上述查询的输出显示不是 1 ，则正在进行并行回滚。您可以查询同一视图 (V$FAST_START_TRANSACTIONS) 来获得父事务和子事务（父事务 id — PXID ，而子事务 id — XID ）。 XID 还可用于联接此视图与 V$FAST_START_SERVERS ，以获得其他详细信息。
结论
总之，当在 Oracle Database 10 g 中回滚长期运行的事务时 — 无论是并行实例恢复会话还是用户执行的回滚语句 — 您所需做的一切就是查看视图 V$SESSION_LONGOPS 并评估还需要多少时间。
现在，如果能预测到达主题公园的时间就好了！
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（三）
作者 Arup Nanda 来源： OTN
第 3 周
名字中包含了什么？：改善的表空间管理
表空间管理得到了重大的改进，这可以归因于一个 sparser SYSTEM 、为用户定义一个默认表空间的支持、新的 SYSAUX 、甚至重命名
您曾经多少次因用户在 SYSTEM 表空间中创建了非 SYS 和 SYSTEM 的段而伤透脑筋？
在 Oracle9 i Database 之前，如果在创建用户时没有指定默认表空间，那么它将默认为 SYSTEM 表空间。如果用户在创建一个段时没有显式地指定一个表空间，那么这个段将在 SYSTEM 中创建 — 前提是用户在 SYSTEM 表空间中拥有配额（要么显式地授予，要么通过系统权限 UNLIMITED TABLESPACE 来授予）。 Oracle9 i 允许 DBA 为所有未用显式的临时表空间子句创建的用户指定一个默认的临时表空间，从而减少了这个问题。
在 Oracle Database 10 g 中，您可以类似地为用户指定一个默认表空间。在数据库创建期间， CREATE DATABASE 命令可以包含子句 DEFAULT TABLESPACE 。在创建之后，您可以通过发出以下命令来使一个表空间变成默认表空间
ALTER DATABASE DEFAULT TABLESPACE <tsname>;
未用 DEFAULT TABLESPACE 子句创建的所有用户将以 作为它们的默认表空间。您可以在任何时候通过这个 ALTER 命令来改变默认表空间，从而允许您在不同的节点上将不同的表空间指定为默认表空间。
重要注意事项：拥有旧的表空间的 所有 用户的默认表空间都被修改为 ，即使有些表空间是为某些用户显式指定的。例如，假定用户 USER1 和 USER2 的表空间分别是 TS1 和 TS2 — 它们是在用户创建期间显式指定的。数据库当前的默认表空间是 TS2 ，但之后，数据库的默认表空间变为 TS1 。即使 USER2 的默认表空间是显式指定为 TS2 的，它也将变为 TS1 。小心这种边界效应！
如果在数据库创建期间没有指定默认表空间，它将默认为 SYSTEM 。但您如何才能知道现有的数据库的默认表空间是哪一个？发出以下查询：
SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'DEFAULT_PERMANENT_TABLESPACE';
DATABASE_PROPERTIES 视图显示默认表空间之外，还显示一些非常重要的信息 — 例如默认临时表空间、全局数据库名、时区等。
非必要模式的默认表空间
几种模式（如智能代理用户 DBSNMP 、数据挖掘用户 ODM ）与用户操作不直接相关，但对数据库完整性仍很重要。这些模式中的一些曾经用 SYSTEM 作为它们的默认表空间 — 这是在 SYSTEM 表空间内对象增殖的又一个原因。
Oracle Database 10 g 引进了一个新的称为 SYSAUX 的表空间，它用来保存这些模式的对象。这个表空间是在数据库创建期间自动创建的，并在本地进行管理。唯一允许修改的是数据文件的名称。
这种方法在 SYSTEM 损坏需要完整的数据库恢复时，为恢复提供支持。 SYSAUX 中的对象可以被恢复为任意正常的用户对象，同时数据库本身保持运行。
但如果您想将 SYSAUX 中的这些模式中的一些转移到一个不同的表空间中时，该怎么办？例如，考虑 LogMiner 使用的对象，这些对象的大小经常增长，直到最终填满表空间。出于可管理性的原因，您可能考虑将它们转移到它们自己的表空间中。但实现这一目的的最好的方法是什么？
作为一个数据库管理员，了解转移这些特殊对象的正确过程对您而言是很重要的。幸运的是， Oracle Database 10 g 提供了一个新的视图使要凭猜测来做的工作形象化。这个视图， V$SYSAUX_OCCUPANTS ，列出了表空间 SYSAUX 中的模式的名称、它们的说明、当前使用的空间，以及如何转移它们。（参见 表 1 。）
注意 LogMiner 如何被清楚地显示为占用 7,488 KB 的空间。它归模式 SYSTEM 所有，而要转移对象，您需要执行打包的过程 SYS.DBMS_LOGMNR_D.SET_TABLESPACE 。不过，对于 STATSPACK 对象，这个视图推荐使用导入 / 导出方法；而对于流，没有转移过程 — 因而您不能容易地将它们从 SYSAUX 表空间中转移出来。列 MOVE_PROCEDURE 默认显示 SYSAUX 中存在的几乎所有工具的正确的转移过程。也可以逆向使用转移过程来使对象回到 SYSAUX 表空间中。
重命名一个表空间
在数据仓库环境中（典型地，对于数据中心体系结构），在数据库之间传输表空间是很常见的。但源数据库和目标数据库必须不存在拥有相同名称的表空间。如果存在两个拥有相同名称的表空间，则目标表空间中的段必须转移到一个不同的表空间中，然后重新创建这个表空间 — 这个任务说起来容易做起来难。
Oracle Database 10 g 提供了一个方便的解决方案：您可以用以下命令来简单地重命名一个现有的表空间（ SYSTEM 和 SYSAUX 除外） — 无论是永久表空间还是临时表空间：
ALTER TABLESPACE <oldname> RENAME TO <newname> ;
这个功能还将应用在存档过程中。假定您有一个按范围分区的表，用于记录销售历史数据，每个月的这个分区位于按这个月份命名的一个表空间中 — 例如， 1 月份的分区命名为 JAN ，并位于一个名称为 JAN 的表空间中。这样您就拥有了一个将信息保留 12 个月的策略。在 2004 年 1 月，您将能够存档 2003 年 1 月的数据。大致的操作流程类似于以下操作：
利用 ALTER TABLE EXCHANGE PARTITION 从分区 JAN 中创建一个独立的表 JAN03 。
将表空间重命名为 JAN03 。
为表空间 JAN03 创建一个可传输表空间集。
将表空间 JAN03 重新命名为 JAN 。
将空的分区交换回表中。
第 1 、 2 、 4 和 5 步很简单，并且不会过度地消耗资源（如重做和撤消空间）。第 3 步只是拷贝文件并只为 JAN03 输出数据字典信息，这也是个非常轻松的过程。如果您需要恢复之前存档的分区，这个过程也非常简单，您只需要将相同的过程反过来就行了。
Oracle Database 10 g 在处理这些重命名的方式上相当智能化。如果您重命名作为 UNDO 或默认临时表空间的表空间，这可能产生混淆。但数据库将自动调整必要的记录来反映这种变化。例如，将默认表空间的名称从 USERS 修改为 USER_DATA 将自动修改视图 DATABASE_PROPERTIES 。在修改之前，查询：
select property_value from database_properties
where property_name = 'DEFAULT_PERMANENT_TABLESPACE';
返回 USERS 。在运行下面的语句之后
alter tablespace users rename to user_data;
上述查询返回 USER_DATA ，因为所有对 USERS 的引用都被修改为到 USER_DATA 。
修改默认临时表空间的情况一样。甚至修改 UNDO 表空间的名称也将触发 SPFILE 中的变化，如下所示：
SQL> select value from v$spparameter where name = 'undo_tablespace';
VALUE
--------
UNDOTBS1
SQL> alter tablespace undotbs1 rename to undotbs;
Tablespace altered.
SQL> select value from v$spparameter where name = 'undo_tablespace';
VALUE
--------
UNDOTBS
结论
在最近的几个 Oracle 版本演变的过程中，对象处理得到了稳定的增强。 Oracle8 i 引进了表从一个表空间到另一个表空间的转移， Oracle 9 i Database R2 引进了列重命名，现在 — 在最新的版本中 — 表空间自身的重命名成为可能。这些增强显著地减轻了数据库管理员的任务 — 特别是在数据仓库或数据中心环境中。
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（四）
作者 Arup Nanda 来源： OTN
第 4 周
高速的导出 / 导入： Oracle Data Pump
利用 Oracle Database 10 g 实用工具数据移动得到了很大的提高。
迄今为止，导出 / 导入工具集仍是跨多个平台转移数据所需劳动强度最小的首选实用工具，尽管人们常常抱怨它速度太慢。导入只是将每条记录从导出转储文件中读出来，然后使用常见的 INSERT INTO 命令将其插入到目标表中，因此导入可能是个很慢的过程，这一点并不让人感到吃惊。
进入 Oracle Data Pump ， Oracle Database 10 g 中的导出 / 导入工具包的更新更快的同类工具，它被设计来成倍地加速这个过程。
Data Pump 反映了整个导出 / 导入过程的彻底革新。它不是使用常见的 SQL 命令，而是应用专用 API 来以更快得多的速度加载和卸载数据。在我的测试中，我看到导出性能比在直接模式下提高了 10-15 倍，导入过程性能提高了 5 倍。此外，与使用导出实用工具不同，它还能够只取出特定类型的对象（如过程）。
Data Pump 导出
这个新的实用工具称为 expdp ，以和原来的导出 exp 区分开。在本例中，我们将用 Data Pump 来导出一个大表 CASES ，大小约为 3GB 。 Data Pump 在服务器端使用文件处理来创建和读取文件；因此，目录作为位置使用。在这种情况下，我们将使用文件系统 /u02/dpdata1 来保存转储文件。
create directory dpdata1 as '/u02/dpdata1';
grant read, write on directory dpdata1 to ananda;
接下来，我们将导出数据：
expdp ananda/abc123 tables=CASES directory=DPDATA1
dumpfile=expCASES.dmp job_name=CASES_EXPORT
让我们来分析该命令的各个部分。用户 ID/ 口令组合、表和转储文件参数的意义是显而易见的。与原来的导出不同，文件是在服务器（不是客户端）上创建的。位置由目录参数值 DPDATA1 指定，它指向之前创建的 /u02/dpdata1 。这个进程还在目录参数指定的位置上创建一个日志文件（同样在服务器上）。默认地，这个进程使用一个名称为 DPUMP_DIR 的目录；因此可以创建它来代替 DPDATA1 。
注意上面的参数 job_name ，这是个特殊的参数，在原来的导出中没有。所有的 Data Pump 工作都通过作业来完成。 Data Pump 作业 — 与 DBMS 作业不同 — 只是服务器进程，它代表主进程处理数据。主进程（称为主控制进程）通过高级队列 (AQ) 来协调这项工作；它通过在运行期内创建的一个特殊的表（称为主表）来实现这个目的。在我们的例子中，如果您在 expdp 运行时检查用户 ANANDA 的模式 ，您将注意到一个表 CASES_EXPORT 的存在（对应参数 job_name ）。当 expdp 结束时，这个表被丢弃。
导出监控
当 Data Pump Export (DPE) 运行时，按 Control-C ；它将阻止消息在屏幕上显示，但不停止导出进程本身。相反，它将显示 DPE 提示符（如下所示）。进程现在被认为处于 “ 交互式 ” 模式：
Export>
这种方法允许在这个 DPE 作业上输入几条命令。要查看概要，在提示符下使用 STATUS 命令：
Export> status
Job:CASES_EXPORT
Operation:EXPORT
Mode:TABLE
State:EXECUTING
Degree: 1
Job Error Count: 0
Dump file:/u02/dpdata1/expCASES.dmp
bytes written = 2048
Worker 1 Status:
State ： EXECUTING
Object Schema:DWOWNER
Object Name:CASES
Object Type:TABLE_EXPORT/TBL_TABLE_DATA/TABLE/TABLE_DATA
Completed Objects: 1
Total Objects: 1
Completed Rows: 4687818
记住，这只是状态显示。导出在后台工作。要继续在屏幕上查看消息，从 Export> 提示符下使用命令 CONTINUE_CLIENT 。
并行操作
您可以通过 PARALLEL 参数为导出使用一个以上的线程来显著地加速作业。每个线程创建一个单独的转储文件，因此参数 dumpfile 应当拥有和并行度一样多的项目。您可以指定通配符作为文件名，而不是显式地输入各个文件名，例如：
expdp ananda/abc123 tables=CASES directory=DPDATA1
dumpfile=expCASES_%U.dmp parallel=4 job_name=Cases_Export
注意 dumpfile 参数拥有一个通配符 %U ，它指示文件将按需要创建，格式将为 expCASES_nn.dmp ，其中 nn 从 01 开始，然后按需要向上增加。
在并行模式下，状态屏幕将显示四个工作进程。（在默认模式下，只有一个进程是可见的。）所有的工作进程同步取出数据，并在状态屏幕上显示它们的进度。
分离访问数据文件和转储目录文件系统的输入 / 输出通道是很重要的。否则，与维护 Data Pump 作业相关的开销可能超过并行线程的效益，并因此而降低性能。并行方式只有在表的数量多于并行值并且表很大时才是有效的。
数据库监控
您还可以从数据库视图获得关于运行的 Data Pump 作业的更多信息。监控作业的主视图是 DBA_DATAPUMP_JOBS ，它将告诉您在作业上有多少个工作进程（列 DEGREE ）在工作。另一个重要的视图是 DBA_DATAPUMP_SESSIONS ，当它与上述视图和 V$SESSION 结合时将给出主前台进程的会话 SID 。
select sid, serial#
from v$session s, dba_datapump_sessions d
where s.saddr = d.saddr;
这条指令显示前台进程的会话。更多有用的信息可以从警报日志中获得。当进程启动时， MCP 和工作进程在警报日志中显示如下：
kupprdp:master process DM00 started with pid=23, OS id=20530 to execute -
SYS.KUPM$MCP.MAIN('CASES_EXPORT', 'ANANDA');
kupprdp:worker process DW01 started with worker id=1, pid=24, OS id=20532 to execute -
SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');
kupprdp:worker process DW03 started with worker id=2, pid=25, OS id=20534 to execute -
SYS.KUPW$WORKER.MAIN('CASES_EXPORT', 'ANANDA');
它显示为数据泵操作启动的会话的 PID 。您可以用以下查询找到实际的 SID ：
select sid, program from v$session where paddr in
(select addr from v$process where pid in (23,24,25));
PROGRAM 列将对应警报日志文件中的名称显示进程 DM （为主进程）或 DW （为工作进程）。如果一个工作进程使用了并行查询，比如说 SID 23 ，您可以在视图 V$PX_SESSION 中看到它，并把它找出来。它将为您显示从 SID 23 代表的工作进程中运行的所有并行查询会话：
select sid from v$px_session where qcsid = 23;
从视图 V$SESSION_LONGOPS 中可以获得其它的有用信息来预测完成作业将花费的时间。
select sid, serial#, sofar, totalwork
from v$session_longops
where opname = 'CASES_EXPORT'
and sofar != totalwork;
列 totalwork 显示总工作量，该列的 sofar 数量被加和到当前的时刻 — 因而您可以用它来估计还要花多长时间。
Data Pump 导入
不过，数据导入性能是 Data Pump 真正出色的地方。要导入先前导出的数据，我们将使用
impdp ananda/abc123 directory=dpdata1 dumpfile=expCASES.dmp job_name=cases_import
导入进程的默认行为是创建表和所有相关的对象，然后在表已存在时产生一个错误。如果您想把数据添加到一个现有的表中，您可以在上述命令行中使用 TABLE_EXISTS_ACTION=APPEND 。
和使用 Data Pump 导入一样，在进程中按 Control-C 将进入 Date Pump Import (DPI) 的交互模式；同样，提示符是 Import> 。
处理特定对象
您是否有过只需要从一个用户导出特定的过程，以在一个不同的数据库或用户中重新创建这些过程的情况？与传统的导出实用工具不同， Data Pump 允许您只导出特定类型的对象。例如，以下命令让您只导出过程，而不导出其它任何东西 — 不导出表、视图、甚至函数：
expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp include=PROCEDURE
要只导出一些特定的对象 — 比如说，函数 FUNC1 和过程 PROC1 — 您可以使用
expdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp
include=PROCEDURE:\"=\'PROC1\'\",FUNCTION:\"=\'FUNC1\'\"
这个转储文件充当了源对象的一个备份。您甚至可以用它来创建 DDL 脚本，以供之后使用。一个称为 SQLFILE 的特殊参数允许创建 DDL 脚本文件。
impdp ananda/iclaim directory=DPDATA1 dumpfile=expprocs.dmp sqlfile=procs.sql
该指令在 DPDATA1 指定的目录中创建一个名称为 procs.sql 的文件，并将对象的脚本包含在导出转储文件中。这种方法帮助您快速地在另一个模式中创建源对象。
利用参数 INCLUDE 允许您从转储文件中定义要包含或排除的对象。您可以使用子句 INCLUDE=TABLE:"LIKE 'TAB%'" 来仅导出那些名称以 TAB 开头的表。类似地，您可以使用结构 INCLUDE=TABLE:"NOT LIKE 'TAB%'" 来排除所有名称以 TAB 开头的表。作为另一种选择，您可以使用 EXCLUDE 参数来排除特定的对象。
通过外部表， Data Pump 还可以用来传输表空间；它非常强大，能够即时地重定义并行方式，将更多的表添加到一个现有的进程中等等（这超出了本文的范围；关于更多详细信息，请参考 Oracle Database Utilities 10g Release 1 10.1 ）。以下命令显示 Data Pump 导出实用工具提供的所有参数的列表：
expdp help=y
类似地， impdp help=y 将显示 DPI 中的所有参数。
当 Data Pump 作业在运行时，您可以通过在 DPE 或 DPI 提示符下发出 STOP_JOB 来暂停它们，然后用 START_JOB 来重起它们。这个功能在您空间不足和想在继续执行之前进行修改时非常方便。
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（五）
作者 Arup Nanda 来源： OTN
第 5 周
闪回表
使用 Oracle Database 10 g 中的闪回表特性，可以毫不费力地恢复被意外删除的表
以下是一个不该发生却经常发生的情况：用户删除了一个非常重要的表 — 当然是意外地删除 — 并需要尽快地恢复。（在某些时候，这个不幸的用户可能就是 DBA ！）
Oracle9 i Database 推出了闪回查询选项的概念，以便检索过去某个时间点的数据，但它不能闪回 DDL 操作，如删除表的操作。唯一的恢复方法是在另一个数据库中使用表空间的时间点恢复，然后使用导出 / 导入或其他方法，在当前数据库中重新创建表。这一过程需要 DBA 进行大量工作并且耗费宝贵的时间，更不用说还要使用另一个数据库进行克隆。
请使用 Oracle Database 10 g 中的闪回表特性，它使得被删除表的恢复过程如同执行几条语句一样简单。让我们来看该特性是如何工作的。
删除那个表！
首先，让我们查看当前模式中的表。
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------ ------- ----------
RECYCLETEST TABLE
现在，我们意外地删除了该表：
SQL> drop table recycletest;
Table dropped.
现在让我们来查看该表的状态。
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
BIN$04LhcpndanfgMAAAAAANPw==$0 TABLE
表 RECYCLETEST 已不存在，但是请注意出现新表 BIN$04LhcpndanfgMAAAAAANPw==$0 。这就是所发生的事情：被删除的表 RECYCLETEST 并没有完全消失，而是重命名为一个由系统定义的名称。它存在于同一个表空间中，具有与原始表相同的结构。如果在该表上定义了索引或触发器，则它们也被重命名，使用与表相同的命名规则。任何相关源（如过程）都失效；原始表的触发器和索引被改为放置在重命名的表 BIN$04LhcpndanfgMAAAAAANPw==$0 上，保持被删除表的完整对象结构。
表及其相关对象被放置在一个称为 “ 回收站 ” 的逻辑容器中，它类似于您 PC 机中的回收站。但是，对象并没有从它们原先所在的表空间中删除；它们仍然占用那里的空间。回收站只是一个列出被删除对象目录的逻辑结构。在 SQL*Plus 提示符处使用以下命令来查看其内容（您需要使用 SQL*Plus 10.1 来进行此操作）：
SQL> show recyclebin
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ ------------------
RECYCLETEST BIN$04LhcpndanfgMAAAAAANPw==$0 TABLE 2004-02-16 :21:13:31
结果显示了表的原始名称 RECYCLETEST ，并显示了回收站中的新名称，该名称与我们看到的删除后所创建的新表名称相同。（注意：确切的名称可能因平台不同而不同。）为恢复该表，您所需要做的就是使用 FLASHBACK TABLE 命令：
SQL> FLASHBACK TABLE RECYCLETEST TO BEFORE DROP;
FLASHBACK COMPLETE.
SQL> SELECT * FROM TAB;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
RECYCLETEST TABLE
瞧 ！表毫不费力地恢复了。如果现在查看回收站，它将是空的。
记住，将表放在回收站里并不在原始表空间中释放空间。要释放空间，您需要使用以下命令清空回收站：
PURGE RECYCLEBIN;
但是如果您希望完全删除该表而不需要使用闪回特性，该怎么办？在这种情况下，可以使用以下命令永久删除该表：
DROP TABLE RECYCLETEST PURGE;
此命令不会将表重命名为回收站中的名称，而是永久删除该表，就象 10 g 之前的版本一样。
管理回收站
如果在该过程中没有实际删除表 — 因而没有释放表空间 — 那么当被删除的对象占用了所有空间时，会发生什么事？
答案很简单：这种情况根本不会出现。当表空间被回收站数据完全占满，以至于必须扩展数据文件来容纳更多数据时，可以说表空间处于 “ 空间压力 ” 情况下。此时，对象以先进先出的方式从回收站中自动清除。在删除表之前，相关对象（如索引）被删除。
同样，空间压力可能由特定表空间定义的用户限额而引起。表空间可能有足够的空余空间，但用户可能将其在该表空间中所分配的部分用完了。在这种情况下， Oracle 自动清除该表空间中属于该用户的对象。
此外，有几种方法可以手动控制回收站。如果在删除名为 TEST 的特定表之后需要从回收站中清除它，可以执行
PURGE TABLE TEST;
或者使用其回收站中的名称：
PURGE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0";
此命令将从回收站中删除表 TEST 及所有相关对象，如索引、约束等，从而节省了空间。但是，如果要从回收站中永久删除索引，则可以使用以下命令来完成工作：
purge index in_test1_01;
此命令将仅仅删除索引，而将表的拷贝留在回收站中。
有时在更高级别上进行清除可能会有用。例如，您可能希望清除表空间 USERS 的回收站中的所有对象。可以执行：
PURGE TABLESPACE USERS;
您也许希望只为该表空间中特定用户清空回收站。在数据仓库类型的环境中，用户创建和删除许多临时表，此时这种方法可能会有用。您可以更改上述命令，限定只清除特定的用户：
PURGE TABLESPACE USERS USER SCOTT;
诸如 SCOTT 等用户可以使用以下命令来清空自己的回收站
PURGE RECYCLEBIN;
DBA 可以使用以下命令清除任何表空间中的所有对象
PURGE DBA_RECYCLEBIN;
可以看到，可以通过多种不同方法来管理回收站，以满足特定的需要。
表版本和闪回功能
用户可能会经常多次创建和删除同一个表，如：
CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (1);
commit;
DROP TABLE TEST;
CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (2);
commit;
DROP TABLE TEST;
CREATE TABLE TEST (COL1 NUMBER);
INSERT INTO TEST VALUES (3);
commit;
DROP TABLE TEST;
此时，如果您要对表 TEST 执行闪回操作，那么列 COL1 的值应该是什么？常规想法可能认为从回收站取回表的第一个版本，列 COL1 的值是 1 。实际上，取回的是表的第三个版本，而不是第一个。因此列 COL1 的值为 3 ，而不是 1 。
此时您还可以取回被删除表的其他版本。但是，表 TEST 的存在不允许出现这种情况。您有两种选择：
使用重命名选项：
•  FLASHBACK TABLE TEST TO BEFORE DROP RENAME TO TEST2;
•  FLASHBACK TABLE TEST TO BEFORE DROP RENAME TO TEST1;
这些语句将表的第一个版本恢复到 TEST1 ，将第二个版本恢复到 TEST2 。 TEST1 和 TEST2 中的列 COL1 的值将分别是 1 和 2 。或者，
使用表的特定回收站名称进行恢复。为此，首先要识别表的回收站名称，然后执行：
•  FLASHBACK TABLE "BIN$04LhcpnoanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST2;
•  FLASHBACK TABLE "BIN$04LhcpnqanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO TEST1;
这些语句将恢复被删除表的两个版本。
警告 ……
取消删除特性使表恢复其原始名称，但是索引和触发器等相关对象并没有恢复原始名称，它们仍然使用回收站的名称。在表上定义的源（如视图和过程）没有重新编译，仍然保持无效状态。必须手动得到这些原有名称并应用到闪回表。
信息保留在名为 USER_RECYCLEBIN 的视图中。在对表进行闪回操作前，请使用以下查询来检索原有名称。
SELECT OBJECT_NAME, ORIGINAL_NAME, TYPE
FROM USER_RECYCLEBIN
WHERE BASE_OBJECT = (SELECT BASE_OBJECT FROM USER_RECYCLEBIN
WHERE ORIGINAL_NAME = 'RECYCLETEST')
AND ORIGINAL_NAME != 'RECYCLETEST';
OBJECT_NAME ORIGINAL_N TYPE
------------------------------ ---------- --------
BIN$04LhcpnianfgMAAAAAANPw==$ 0 IN _RT_01 INDEX
BIN$04LhcpnganfgMAAAAAANPw==$0 TR_RT TRIGGER
在表进行闪回操作后，表 RECYCLETEST 上的索引和触发器将按照 OBJECT_NAME 列中所示进行命名。根据以上查询，可以使用原始名称重新命名对象，如下所示：
ALTER INDEX "BIN$04LhcpnianfgMAAAAAANPw==$0" RENAME TO IN_RT_01;
ALTER TRIGGER "BIN$04LhcpnganfgMAAAAAANPw==$0" RENAME TO TR_RT;
一个值得注意的例外情况是位图索引。当删除位图索引时，它们并不放置在回收站中 — 因此无法检索它们。约束名称也无法从视图中检索。必须从其他来源对它们进行重命名。
闪回表的其他用途
闪回删除表功能不仅限于恢复表的删除操作。与闪回查询类似，您还可以使用它将表恢复到不同的时间点，利用表的 “ 过去 ” 版本来替代整个表。例如，以下语句将表恢复到系统更改号 (SCN) 2202666520 。
FLASHBACK TABLE RECYCLETEST TO SCN 2202666520;
此特性使用 Oracle 数据泵技术来创建不同的表，使用闪回功能将该 SCN 处的数据版本填充到表中，然后用新表替代原始表。为找出能够在何种程度上对表进行闪回操作，可以使用 Oracle Database 10 g 的版本控制特性。（更多详细信息请参见本系列第 1 周的内容。）在闪回子句中也可以指定时间戳记而不是指定 SCN 。
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（六）
第 6 周
自动工作负载信息库
学习使用新的特性，这些特性采集数据库性能统计数据和量度，以供分析和调整，并显示在数据库中花费的准确时间，甚至保存会话信息
当您有数据库性能问题时，要解决它您首先要作的是什么？一种常见的方法是看是否存在一种模式：回答诸如 “ 相同的问题是否重复出现？ ” ， “ 它是否在某个特定的时间段出现？ ” 和 “ 两个问题之间是否有联系？ ” 之类的问题，将几乎总会带来更好的诊断结果。
作为一个数据库管理员，您可能已经投资购买了第三方工具或使用自己开发的工具来在数据库运行期间采集详细的统计数据，并从这些统计数据中导出获得性能量度。在紧急的情况下，您可以访问这些量度来与当前的情况作比较。再度查看这些过去的事件可以给当前的问题带来一些启发，因此不断采集相关的统计数据对于性能分析变得很重要。
一段时间以来， Oracle 在这个领域中的解决方案是它内置的工具 Statspack 。虽然某些情况下证明它是非常有价值的，但常常缺少性能故障诊断实践所需的强健性。 Oracle Database 10 g 提供了一个显著改进的工具：自动工作负载信息库 (AWR) 。 AWR 和数据库一起安装，不但采集统计数据，还采集导出的量度。
快速测试驱动程序
通过运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本， AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本从外观和感觉上类似于 Statspack ，它显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出：文本格式（类似于 Statspack 报表的文本格式但来自于 AWR 信息库）和默认的 HTML 格式（拥有到部分和子部分的所有超链接），从而提供了非常用户友好的报表。现在运行该脚本以查看报表，从而对 AWR 的功能有一个了解。
实施
现在，让我们来看看 AWR 是如何设计和构建的。 AWR 实质上是一个 Oracle 的内置工具，它采集与性能相关的统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题。与 Statspack 不同，快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间，采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。要查看当前的设置，您可以使用下面的语句：
select snap_interval, retention
from dba_hist_wr_control;
 
SNAP_INTERVAL RETENTION
------------------- -------------------
+00000 01:00:00.0 +00007 00:00:00.0
这些 SQL 语句显示快照每小时采集一次，采集的数据保留 7 天。要修改设置 — 例如，快照时间间隔为 20 分钟，保留时间为两天 — 您可以发出以下命令。参数以分钟为单位。
begin
dbms_workload_repository.modify_snapshot_settings (
interval => 20,
retention => 2*24*60
);
end;
AWR 使用几个表来存储采集的统计数据，所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下，并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。（您可能已经猜到， H 代表 “ 历史数据 (historical)” 而 M 代表 “ 元数据 (metadata)” 。）在这些表上构建了几种带前缀 DBA_HIST_ 的视图，这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关；例如，视图 DBA_HIST_SYSMETRIC_SUMMARY 是在 WRH$_SYSMETRIC_SUMMARY 表上构建的。
AWR 历史表采集的信息比 Statspack 多许多，这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以通过以下命令从数据字典中看到：
select view_name from user_views where view_name like 'DBA\_HIST\_%' escape '\';
视图 DBA_HIST_METRIC_NAME 定义 AWR 采集到的重要的量度、它们所属的组和采集它们的单位。例如，下面是一个记录（竖直格式）：
DBID : 4133493568
GROUP_ID : 2
GROUP_NAME : System Metrics Long Duration
METRIC_ID : 2075
METRIC_NAME : CPU Usage Per Sec
METRIC_UNIT : CentiSeconds Per Second
它显示一个量度 “ 每秒 CPU 使用率 ” 以 “ 每秒的厘秒数 ” 为单位进行测量，并且该量度属于一个量度组 “System Metrics Long Duration” 。这条记录可以和其它的表（如 DBA_HIST_SYSMETRIC_SUMMARY ）结合，以获得数据库的活动信息，形式如下：
select begin_time, intsize, num_interval, minval, maxval, average, standard_deviation sd
from dba_hist_sysmetric_summary where metric_id = 2075;
 
BEGIN INTSIZE NUM_INTERVAL MINVAL MAXVAL AVERAGE SD
----- ---------- ------------ ------- ------- -------- ----------
11:39 179916 30 0 33 3 9.81553548
11:09 180023 30 21 35 28 5.91543912
 
... and so on ...
下面我们看看 CPU 时间是如何消耗的（以厘秒为单位）。标准差加入到了我们的分析中，它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中，平均值是每秒消耗 CPU 时间 3 厘秒，但标准差是 9.81 ，这意味着平均值 3 不能反映工作负载。在第二个例子中，平均值为 28 ，标准差为 5.9 ，这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。
使用统计数据
迄今为止，我们看到了 AWR 所采集的内容，现在让我们看看它将如何处理数据。
大多数性能问题并不是孤立存在的，而留有指示性的迹象，这些迹象将通向问题最终的根源。让我们使用一个典型的调整实践来说明这一点：您注意到系统很慢，于是决定查看等待的原因。您检查发现 “ 缓冲区忙等待 ” 非常高。问题可能出在哪里呢？有几种可能：可能有一个单调增加的索引，可能一个表太满了，以至于要求将单个数据块非常快速地加载到内存中，或其它一些因素。无论在哪种情况下，您都首先要确定存在问题的段。如果它是一个索引段，那么您可以决定重新构建它，把它修改为一个反向键索引，或把它转换成一个在 Oracle Database 10 g 中引进的散列分区索引。如果它是一个表，您可以考虑修改存储参数来使它不那么密集，或者利用自动段空间管理把它转移到一个表空间中。
您的处理计划一般是有规律的，并且通常基于您对各种事件的了解和您处理它们的经验。现在设想相同的事情由一个引擎来完成，这个引擎采集量度并根据预先确定的逻辑来推出可能的计划。您的工作不就变得更轻松了吗？
现在在 Oracle Database 10 g 中推出的这个引擎称为自动数据库诊断监控程序 (ADDM) 。为了作出决策， ADDM 使用了由 AWR 采集的数据。在上面的讨论中， ADDM 可以看到发生了缓冲区忙等待，然后取出相应的数据来查看发生缓冲区忙等待的段，评估其特性和成分，最后为数据库管理员提供解决方案。在 AWR 进行的每一次快照采集之后，调用 ADDM 来检查量度并生成建议。因此，实际上您拥有了一个一天二十四小时工作的自动数据库管理员，它主动地分析数据并生成建议，从而把您解放出来，使您能够关注更具有战略意义的问题。
要查看 ADDM 建议和 AWR 信息库数据，请使用在名称为 DB Home 的页面上的新的 Enterprise Manager 10 g 控制台。要查看 AWR 报表，您可以从管理转至工作负载信息库，然后转至 Snapshots 来查看它们。在以后的部分中，我们将更详细地讨论 ADDM 。
您还可以指定根据特定的情况来生成警报。这些警报称为服务器生成警报，它们被推送到高级队列中，在其中它们可以被任意监听它的客户端使用。一个这样的客户端是 Enterprise Manager 10 g ，在其中警报被突出显示。
时间模型
当您有性能问题时，要缩短响应时间您最先想到的是什么？很明显，您希望消除（或减少）增加时间的因素的根源。您如何知道时间花费在哪里 — 不是等待，而是真正在进行工作？
Oracle Database 10 g 引进了时间模型，以确定在各个地方花费的时间。花费的总的系统时间记录在视图 V$SYS_TIME_MODEL 中。下面是查询和输出结果。
STAT_NAME VALUE
------------------------------------- --------------
DB time 58211645
DB CPU 54500000
background cpu time 254490000
sequence load elapsed time 0
parse time elapsed 1867816
hard parse elapsed time 1758922
sql execute elapsed time 57632352
connection management call elapsed time 288819
failed parse elapsed time 50794
hard parse (sharing criteria) elapsed time 220345
hard parse (bind mismatch) elapsed time 5040
PL/SQL execution elapsed time 197792
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 593992
Java execution elapsed time 0
bind/define call elapsed time 0
注意名称为 DB Time 的统计量，它代表自从例程启动起在数据库中花费的时间。运行示例工作负载，并再次从视图中选中统计值。统计值的差异将代表该工作负载在数据库中花费的时间。在又一个调整回合之后，执行相同的分析，统计值的差异将显示在调整之后 DB Time 的变化，这可以与第一次修改进行比较，以查看调整动作对数据库时间的影响。
除数据库时间之外， V$SYS_TIME_MODEL 视图显示了很多其它的统计量，如在不同类型的分析，甚至在 PL/SQL 编译中花费的时间。
这个视图还显示了总的系统时间，不过您可能对一个更加详细的视图感兴趣：会话级时间。时间统计数据还在会话级进行采集，如视图 V$SESS_TIME_MODEL 中所示，在其中可以看到当前连接的会话（活动和不活动的）的所有统计数据。额外的列 SID 指示显示的统计数据的会话的 SID 。
在早期的版本中，这种分析是不可能得到的，用户被迫进行猜测或从各种来源进行分析。在 Oracle Database 10 g 中，获得这种信息轻而易举。
活动会话历史
Oracle Database 10 g 中的视图 V$SESSION 得到了改善；所有这些改善中最有价值的是包含了等待事件和它们的持续时间，从而不再需要查看视图 V$SESSION_WAIT 。不过，因为这个视图只反映实时的值，所以当稍后查看它时，一些重要的信息丢失了。例如，如果您选择从这个视图中检查是否有任何会话在等待任何非空闲的事件，如果有的话，调查这个事件，您可能发现不了任何东西，因为到您选中它的时候等待一定已经结束了。
进入新的特性活动会话历史 (ASH) ，它类似于 AWR ，在一个缓冲区中存储会话性能统计数据，以便稍后进行分析。不过，与 AWR 不同，存储不是永久性地在一个表中进行，而是在内存中进行，并在视图 V$ACTIVE_SESSION_HISTORY 中显示。数据每秒轮询一次，并且只有轮询活动会话。随着时间进行，旧的项目在一个循环缓冲区中被删除，以容纳新的项目，并且这些旧的项目将在视图中显示。要找出有多少个会话在等待某些事件，您可以使用下面的命令
select session_id||','||session_serial# SID, n.name, wait_time, time_waited
from v$active_session_history a, v$event_name n
where n.event# = a.event#
这条命令告诉您事件的名称和等待花费了多少时间。如果您想要深入调查某个特定的等待事件， ASH 的额外的列也将帮助您实现这一目的。例如，如果会话等待的事件之一是缓冲区忙等待，那么正确的诊断必须指出发生等待事件的段。您可以从 ASH 视图列 CURRENT_OBJ# 中获得这一信息，然后该列可以和 DBA_OBJECTS 结合，以获得存在问题的段。
ASH 还记录并行查询服务器会话，这对诊断并行查询等待事件非常有用。如果记录是针对一个并行查询从属进程，那么协调服务器会话的 SID 由 QC_SESSION_ID 列指定。列 SQL_ID 记录产生等待事件的 SQL 语句的 ID ，该列可以和 V$SQL 视图结合，以获取存在问题的 SQL 语句。为了方便一个共享用户环境（如 web 应用程序）中的客户端的识别，也显示了 CLIENT_ID 列，这可以由 DBMS_SESSION.SET_IDENTIFIER 来设置。
既然 ASH 信息这么有价值，那么如果以一种类似于 AWR 的永久方式来保存这种信息不是很好吗？幸运的是，它是以这种方式来进行保存的；由 MMON 从进程将信息刷新到 AWR 表中，从而保存在磁盘上，并且信息可以通过视图 DBA_HIST_ACTIVE_SESS_HISTORY 来查看。
人工采集
快照默认是自动采集的，但您也可以按需要采集它们。所有的 AWR 功能都在程序包 DBMS_WORKLOAD_REPOSITORY 中实施。要采集一次快照，只需发出下面的命令：
execute dbms_workload_repository.create_snapshot
它立即采集一次快照，快照被记录在表 WRM$_SNAPSHOT 中。采集的量度是针对 TYPICAL 级别的。如果您想采集更详细的统计数据，您可以在上面的过程中将参数 FLUSH_LEVEL 设置为 ALL 。统计数据自动删除，但也可以通过调用过程 drop_snapshot_range() 来手动删除。
基准线
一次典型的性能调整实践从采集量度的基准线集合、作出改动、然后采集另一个基准线集合开始。可以比较这两个集合来检查所作的改动的效果。在 AWR 中，对现有的已采集的快照可以执行相同类型的比较。假定一个名称为 apply_interest 的高度资源密集的进程在下午 1:00 到 3:00 之间运行，对应快照 ID 56 到 59 。我们可以为这些快照定义一个名称为 apply_interest_1 的基准线：
exec dbms_workload_repository.create_baseline (56,59,'apply_interest_1')
这一操作将快照从 56 到 59 编号，作为上面指定的基准线的一部分。查看现有的基准线：
select * from dba_hist_baseline;
 
DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID
---------- ----------- -------------------- ------------- -----------
4133493568 1 apply_interest_1 56 59
在一些调整步骤之后，我们可以创建另一个基准线 — 假设名称为 apply_interest_2 ，然后只为那些与这两条基准线相关的快照比较量度。像这样把快照分隔在仅仅几个集合中有助于研究调整对于性能量度的影响。您可以在分析之后使用 drop_baseline() 来删除基准线；快照将保留。此外，当清除例程开始删除旧的快照时，与基准线相关的快照不会被清除，从而允许进行进一步的分析。
结论
这一部分的目的只是介绍 AWR 非常基本的方面。关于更完整的内容，请参见 Oracle Database 10 g 文档 。此外，关于 AWR 和 ADDM 的一个极好的论述可以在技术白皮书 自我管理的数据库：自动性能诊断 中找到。在第 15 周，您将了解到关于 ADDM 及使用它来解决实际问题的更多内容，。