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

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

第 7 周
SQL*Plus 的成长
随着 Oracle Database 10 g 的发布，这个小而强大的 DBA 工具有了一些引人注目的变化，包括有用的提示符和高级文件处理
数据库管理员每天用得最多的工具是哪一个？对于许多象我一样在 GUI 革命之前的数据库管理员而言，一定是 SQL*Plus 命令行选件。
虽然随着强大和功能丰富的 Enterprise Manager 10 g 的引入， SQL*Plus 在 Oracle Database 10 g 中已经发生了一些变化，但这个普遍存在的小工具仍将继续作为 Oracle 原有系统的一部分 — 对初学者和经验丰富的数据库管理员同样适用。
在本部分中，我们将研究对 SQL*Plus 10.1.0 .2 所作的一些非常有用的改进。切记，要继续下面的操作，您将需要 Oracle Database 10 g 软件的 sqlplus 可执行程序，而不是运行在 10 g 数据库上的 Oracle9 i Database sqlpuls 。
为粗心用户提供的提示符
我在哪里，或我是谁？不，这不是对您精神的拷问；这是关于用户在 SQL*Plus 环境的上下文中位于何处的问题。 SQL*Plus 中的默认提示符 — 简单的 SQL> — 不指出用户是谁，以及用户作为什么连接。在早期的版本中，您必须进行一些麻烦的编码来获取变量，但现在不再需要这样了。在 SQL*Plus 10.1.0 .2 中，您可以使用：
set sqlprompt "_user _privilege> "
SQL*Plus 提示符显示为
SYS AS SYSDBA>
当然，假定用户 SYS 是作为 SYSDBA 登录的。注意两个预先定义的特殊变量 — _user 和 _privilege — 的使用，它们定义了当前的用户和登录的权限。
让我们再增加一些其它的功能：现在还想显示今天的日期。我们需要做的就是用下面这些命令来使提示符显示想得到的信息。
SQL> set sqlprompt "_user _privilege 'on' _date >"
SYS AS SYSDBA on 06-JAN-04 >
再增加数据库连接标识符怎么样？您想知道您在 “ 什么样 ” （在生产或开发中）的情况下，这种方法的确非常有帮助。
SQL> set sqlprompt "_user 'on' _date 'at' _connect_identifier >"
ANANDA on 06-JAN-04 at SMILEY >
到目前为止还不错；但我们可能想要以一种更详细的方式来显示当前的日期（带小时和分钟），以更加有用。
ANANDA on 06-JAN-04 at SMILEY > alter session set nls_date_format = 'mm/dd/yyyy hh24:mi:ss';
 
Session altered.
 
ANANDA on 01/06/2004 13:03:51 at SMILEY >
问题解决了：输入几行命令就得到了能够提供丰富信息的 SQL 提示符。将它保存在 glogin.sql 文件中，您就始终拥有这些特性。
必须使用引号吗？为什么，不！
在 Oracle9 i 中取消了对内部登录的支持之后，全世界许多 DBA 表示反对：他们应当如何在命令行上输入 SYS 的口令并保持安全性？嗯，答案是在操作系统提示符中使用引号：
sqlplus "/ as sysdba"
引号的使用令人遗憾，但还是被大家所接受（虽然有些怨言）。在 Oracle Database 10 g 中不需要这样了。现在您可以在 OS 命令提示符下，输入以下命令，不需要引号
sqlplus / as sysdba
作为 SYSDBA 登录。这种改进不仅意味着您少输了两个字符，还有一些额外的好处，例如在 Unix 之类的操作系统中不需要 escape 字符。
改进的文件处理
假设您在处理一个问题，并使用了一些自由格式的即席 SQL 语句。很明显，它们很有用，您想把它们保存起来，以便将来使用。您会怎么做？您就可以把它们保存在各个文件中，如下所示：
select something1 ....
save 1
select something else ....
save 2
select yet another thing ....
save 3
等等。一段时间以后，您需要收集所有保存的文件，以便将来使用。多麻烦！ SQL*Plus 10.1.0 .2 允许您将语句添加到文件中，进行保存。在前一个例子中，您可以使用：
select something1 ....
save myscripts
select something else ....
save myscripts append
select yet another thing ....
save myscripts append
等等。所有的语句将添加到文件 myscripts.sql 中，从而不再需要保存在单独的文件中，然后把它们连接成单个文件。
这种方法还适用于假脱机。在以前的版本中，命令 SPOOL RESULT.LST 将创建文件 result.lst （如果该文件不存在）；但如果该文件已存在，则将覆盖它，而没有提示。这种行为常常（特别在复杂环境下）可能导致不希望的边缘效应，例如重要的输出文件被覆盖。在 10 g 中， spool 命令可以使文件内容附加在一个现有的文件后面：
spool result.lst append
如果您想覆盖它，那么该怎么做？简单地省略 append 子句，或使用默认值 REPLACE 。以下命令将在写操作之前检查文件是否存在。
spool result.lst create
Use another name or "SPOOL filename[.ext] REPLACE"
这种方法防止覆盖文件 result.lst 。
Login.sql 是用于登录的，是吗？
记得文件 login.sql 和 glogin.sql 吗？本来在任何时候当调用 SQL*Plus 时，都将运行当前目录中的 login.sql 文件。但是，有一个严重的局限。在 Oracle9 i 和更低版本中，假定在文件中有下面这一行。
set sqlprompt "_connect_identifier >"
当您首先启动 SQL*Plus 与数据库 DB1 连接时，提示符显示：
DB1>
现在，如果您从提示符中与另一个数据库 DB2 连接：
DB1> connect scott/tiger@db2
Connected
DB1>
注意提示符。虽然您现在和 DB2 连接在一起，但提示符仍是 DB1 ，。很明显，提示符是不正确的。原因很简单：在连接时没有执行 login.sql 文件，只在 SQL*Plus 启动时执行了该文件。后来的连接没有重新执行该文件，使得提示符没有改变。
在 Oracle Database 10 g 中，消除了该局限。文件 login.sql 不仅在 SQL*Plus 启动时执行，而且在连接时也执行。因此在 10 g 中，如果您当前与数据库 DB1 连接，后来改变了连接，则提示符将改变。
SCOTT at DB1> connect scott/tiger@db2
SCOTT at DB2> connect john/meow@db3
JOHN at DB3>
不希望改变！
如果由于某些原因，您不想使用这些增强的 SQL*Plus ，那该怎么办？很简单，用 -c 选项来调用它：
sqlplus -c 9.2
SQL*Plus 环境将和旧的 9.2 版一样运转。
自由地使用 DUAL
您认为有多少开发人员（还有 DBA ）经常使用这条命令？
select USER into from DUAL
可能非常多。对 DUAL 的每次调用创建逻辑 I/O — 数据库没有逻辑 I/O 也可以工作。在某些情况下必须调用 DUAL ，如在行 := USER 中。因为 Oracle 代码将 DUAL 当作一个专用的表，所以调整表的某些想法可能不适用或不贴切。
Oracle Database 10 g 使得所有这些担心完全消失了：因为 DUAL 是一个专用的表，所以持续获得显著地减少了，并且与从事件 10046 跟踪中看到的优化计划不同。
在 Oracle9 i 中
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL:CHOOSE
1 TABLE ACCESS (FULL) OF 'DUAL'
在 10 g 中
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT MODE:ALL_ROWS
0 FAST DUAL
 
注意新的 FAST DUAL 优化计划的使用，与 Oracle9 i 中的 DUAL 的 FULL TABLE SCAN 相反。这一改进显著地减少了持续读取，从而为频繁使用 DUAL 表的应用程序带来好处。
注意：从技术角度看，这些 DUAL 改进是在 SQL 优化器中实施的，但是，对许多用户而言， SQL*Plus 是用于处理 SQL 的主要工具。
其它有用的信息
其它的 SQL*Plus 增强在本系列的其它地方进行了说明。例如，我在第 5 周关于闪回表的内容中说明了 RECYCLEBIN 的概念。
与一些流传甚广的传言相反， COPY 命令仍然可用，虽然将在以后的版本中废除。（嗯 …… ，我们不是在 Oracle9 i 中就听到这个消息了吗？）如果您有使用这条命令编写的脚本，别沮丧，它不仅可用而且仍被支持。实际上，只错误消息报告方面作了一点改进。如果表有一个 LONG 列，则 COPY 是您创建表的备份的唯一方式，常见的 Create Table As Select 将不能处理带 long 数据类型的列的表。
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（八）

第 8 周
自动存储管理
数据库管理员终于可以将自己从单调而常用的增加、移动和删除存储磁盘的任务中解脱出来了 — 并且无需增加额外的成本。
假设您刚得到一个新的 Oracle 数据库的全新的服务器和存储子系统。除操作系统配置之外，在您能够创建数据库之前，最重要的工作是什么？很明显，就是创建存储系统布局 — 或更具体地说，选择一种保护级别，然后构建必需的冗余磁盘阵列 (RAID) 组。
在大多数数据库安装中安装存储器要花费大量的时间。从多种可能中选择一种特定的磁盘配置需要仔细的规划和分析，并且最重要的是，需要详细了解存储技术、卷管理器和文件系统。在这个阶段的设计任务可以大致说明如下（注意这个列表只是代表性的，任务将随配置而变化）：
•  确认存储器在操作系统级通过了认证，并确定冗余保护的级别，该级别可能已经提供（硬件 RAID ）。
•  集中和构建逻辑卷组，并确定分段或镜像是否也是必需的。
•  在逻辑卷管理器创建的逻辑卷上构建文件系统。
•  设定所有权和权限，以便 Oracle 进程可以对设备进行打开、读和写操作。
•  在文件系统上创建数据库，如果可能的话务必在非 RAID 的位置上创建特殊文件，例如重做日志、临时表空间和重做表空间之类的特殊文件。
在大多数公司中，这些步骤大部分是由对存储系统非常了解的某些人来执行的。这里的 “ 某些人 ” 通常不是数据库管理员。
不过，请注意所有这些任务 — 分段、镜像、逻辑文件系统构建 — 的执行都只支持一种类型的服务器， Oracle 数据库。因此， Oracle 自己提供一些技巧来简化或改进这个过程不是很有意义吗？
Oracle Database 10 g 正是这么做的。一个新的和激动人心的特性 — 自动存储管理 (ASM) — 使 DBA 能够完全在 Oracle 框架内执行上述的许多任务。利用 ASM ，您可以仅利用 Oracle Database 10g 软件自带的功能（无需额外的成本）来将一组磁盘转换成一个高可伸缩的（重点是在 “ 可伸缩 ” 上）和高性能的文件系统 / 卷管理器。并且您不需要是一个磁盘、卷管理器或文件系统管理方面的专家。
在本部分中，您将了解到关于 ASM 大量的基础知识，以开始在实际的应用程序中使用它。正如您的猜测，这个强大的特性无疑将引发全面的讨论，篇幅所限，我们不能在此作过多介绍，如果您想了解更多的内容，在结论部分列出了一些极好的信息来源。
ASM 是什么？
假设您要在数据库中使用 10 个磁盘。利用 ASM ，您不需要在 OS 端创建任何东西，该特性将把一组物理磁盘集合成一个逻辑实体（称为磁盘组）。磁盘组类似于一个分段（和可选镜像）文件系统，但具有重要的差异：它不是一个用于存储用户文件的通用文件系统，并且它不进行缓冲。由于后面的原因，磁盘组提供了直接作为原始设备来访问这个空间，并仍提供文件系统的便利性和灵活性的好处。
逻辑卷管理器一般使用一个函数（如散列函数）来将块的逻辑地址映射到物理块。计算使用 CPU 周期。此外，当增加一个新的磁盘（或 RAID-5 磁盘组）时，这种典型的分段函数需要重新定位整个数据集中的每一位。
相比而言， ASM 使用一个特殊的 Oracle 例程来解决从文件区到物理磁盘块的映射问题。这种设计除了定位文件区非常快速之外，还在增加或删除磁盘时有所帮助，因为文件区的位置不需要调整。这个特殊的 ASM 例程类似于其它的文件系统，必须运行此例程， ASM 才能工作，并且用户不能进行修改。一个 ASM 例程可以在同一台服务器上支持许多 Oracle 数据库例程。
这个特殊的例程只是一个 例程 ，不是用户可以在其中创建对象的数据库。所有关于磁盘的元数据都存储在磁盘组本身中，使得它们能够尽可能地自我描述。
那么概括地说， ASM 的优点是什么？
磁盘增加 — 增加磁盘变得非常容易。无需停机时间，并且文件区域自动重新分配。
I/O 分配 — I/O 自动分布在所有可用的磁盘上，无需人工干预，从而减少了热点出现的可能性。
带区宽度 — 在重做日志文件中分段可以细分（ 128K ，以获得更快的传输速率），对于数据文件，带区则略大一些（ 1MB ，以一次性传输大量的数据块）。
缓冲 — ASM 文件系统不进行缓冲，直接进行输入 / 输出。
核心化的异步 I/O — 实现核心化的异步 I/O 无需特殊的设置，并且无需使用原始或第三方的文件系统（如 Veritas Quick I/O ）。
镜像 — 如果硬件镜像不可用，则可以容易地建立软件镜像。
逐步创建一个基于 ASM 的数据库
下面是如何创建一个基于 ASM 的数据库的具体的示例：
1. 创建一个 ASM 例程
通过指定下列初始化参数，您可以利用数据库创建助手来创建一个 ASM 例程：
INSTANCE_TYPE = ASM
当服务器启动时，您应当启动该例程，而当服务器关闭时，应当最后关闭该例程。
这个参数的默认值是 RDBMS ，适用于常见的数据库。
2. 创建磁盘组
在启动 ASM 例程后，利用可用的磁盘创建一个磁盘组。
CREATE DISKGROUP dskgrp1
EXTERNAL REDUNDANCY
DISK
'/dev/d1',
'/dev/d2',
'/dev/d3',
'/dev/d4',
... and so on for all the specific disks ...
;
在上述命令中，我们使数据库利用名称为 /dev/d1 、 /dev/d2 等的磁盘创建了一个名称为 dksgrp1 的磁盘组。您还可以在 DISK 子句中用通配符指定磁盘名称，而不是分别给定磁盘。
DISK '/dev/d*'
在上述命令中，我们指定了一个子句 EXTERNAL REDUNDANCY ，它指示一个磁盘出现故障将使磁盘组停止工作。这通常是由硬件提供冗余（如镜像）的情况。如果没有基于硬件的冗余，则可以设置 ASM 来在磁盘组中创建一组特殊的磁盘（称为 failgroup ），以提供这种冗余。
CREATE DISKGROUP dskgrp1
NORMAL REDUNDANCY
FAILGROUP failgrp1 DISK
'/dev/d1',
'/dev/d2',
FAILGROUP failgrp2 DISK
'/dev/d3',
'/dev/d4';
d3 和 d4 不是 d1 和 d2 的镜像，虽然看起来似乎是那样。相反， ASM 使用所有的磁盘来创建一个容错系统。例如，可能利用在 d4 上保留的一个备份来在 d1 中创建磁盘组上的一个文件。另一个文件可以利用 d2 上的备份在 d3 上创建。一个特定的磁盘出现故障，则允许使用另一个磁盘上的备份，以使操作可以继续。例如，您可能丢失了磁盘 d1 和 d2 的控制器， ASM 将为全部故障磁盘组的区块的拷贝建立镜像，以保持数据完整性。
3. 创建表空间
现在利用基于 ASM 的存储器中的一个数据文件来在主数据库中创建一个表空间。
CREATE TABLESPACE USER_DATA DATAFILE '+dskgrp1/user_data_01'
SIZE 1024M
/
就这样！创建过程完成了。
注意磁盘组是如何作为一个虚拟文件系统使用的。这种方法不仅在数据文件中有用，在其它类型的 Oracle 文件中也有用。例如，您可以按以下方式创建在线重做日志文件
LOGFILE GROUP 1 (
'+dskgrp1/redo/group_1.258.3',
'+dskgrp2/redo/group_1.258.3'
) SIZE 50M ,
...
甚至存档日志目标也可以设为一个磁盘组。与 Oracle 数据库相关的全部内容都可以在一个基于 ASM 的磁盘组中创建。例如，备份是 ASM 的另一大用途。您可以设置一组廉价的磁盘来创建一个数据库的恢复区， RMAN 可以使用这个恢复区来创建备份数据库文件和存档日志文件。（在下一个关于 Oracle Database 10 g 中的 RMAN 的部分中，您将详细了解如何使用这种功能来为您带来好处。）
请记住，无论 ASM 如何支持仅由 Oracle 数据库创建和读取的文件；它也不能替代一个通用的文件系统，并且不能存储二进制文件和纯文本文件。
维护
让我们看看维护磁盘组所需的一些典型任务。您可能必须经常在磁盘组 dskgrp1 中增加额外的磁盘来适应不断增长的需求。可以执行下面的语句：
alter diskgroup dskgrp1 add disk '/dev/d5';
要查明哪个磁盘在哪个磁盘组中，可以执行下面的语句：
select * from v$asm_disk;
该命令显示了 ASM 例程为所有客户机数据库管理的所有磁盘。在这些磁盘中，您可能决定利用以下命令来删除一个磁盘：
alter diskgroup dskgrp1 drop disk diskb23;
结论
ASM 的引进提供了显著的价值，它使得在 Oracle 数据库中管理文件变得非常容易。利用这个捆绑的特性，您可以从一组磁盘中容易地创建一个高可伸缩和高性能的存储解决方案。任何动态的数据库环境都需要添加、移动和删除磁盘， ASM 提供了必需的工具集，使 DBA 从那些单调的任务中解脱出来。

Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（九）
第 9 周
RMAN
RMAN 的功能更强大，它具有重新设计的增量备份模式、增量备份的脱机恢复、预览恢复、复原日志进行恢复、文件压缩等功能。
大多数人都认同 RMAN 是用于 Oracle 数据库备份的实际工具。但是与它们所具有的强大功能相比， RMAN 的早期版本并未提供人们所期待的一些功能。就像许多 DBA 一样，如果它没有包含我认为必须具有的功能，我将会异常恼怒。
幸运的是， Oracle 数据库 10 g 通过合并人们所想要的许多功能解决了很多这类问题，这使 RMAN 成为一种更强大、更有用的工具。让我们看一下这些功能。
再论增量备份
RMAN 包含一个用于增量备份的选项。但是老实讲，您多久使用一次呢？可能经常用，也可能永远也不会用。
该选项用于指示该工具以相同或较低的级别来备份自上一次增量备份后发生改变的块。例如，在第 1 天采用完全备份 (level_0) ，而在第 2 、 3 天采用两个 level_1 的增量。后面的两个备份只是备份了第 1 天和第 2 天之间，及第 2 天和第 3 天之间更改过的块，而不是跨整个备份时间进行备份。这种策略减少了备份规模、需要的空间较少，并缩小了备份窗口，减少了网络间移动的数据量。
执行增量备份的最重要的原因是：与数据仓库环境关联起来，在该环境中许多操作都是在 NOLOGGING 模式下执行的，并且数据更改不会涉及到存档的日志文件 — 因此，不可能发生介质恢复。考虑到今天的数据仓库的巨大规模，以及其中的大部分数据并没有发生改变的事实，就会知道执行完全备份既不值得又不实际。相反，在 RMAN 中执行增量备份是一个理想的选择。
既然如此，那么为什么许多 DBA 极少执行增量备份呢？一个原因是：在 Oracle 9 i 及其较低的版本中， RMAN 会扫描所有的数据块以确定要备份的内容。这个过程给系统施加了如此大的压力，以致于执行增量备份变得不实际。
Oracle 数据库 10 g RMAN 以消除了该缺陷的方式来执行增量备份。它使用一个文件，类似于文件系统中的日志，来跟踪自上一次备份起更改过的块。 RMAN 读取该文件来确定将要备份的块。
您可以通过发布以下命令来启用该跟踪机制：
SQL> alter database enable block change tracking using file '/rman_bkups/change.log';
该命令将创建一个名为 /rman_bkups/change.log 的二进制文件，以用于跟踪。相反，您可以使用以下命令来禁用跟踪：
SQL> alter database disable block change tracking;
要想查看当前是否启用了对更改的跟踪，您可以查询：
SQL> select filename, status from v$block_change_tracking;
快速恢复区
在 Oracle 9 i 中引入的闪回查询，依赖于撤消表空间来闪回到先前的版本，因此限制了它深入到过去的能力。快速恢复通过创建闪回日志提供了一个可选的解决方案，它类似于重做日志，用于将数据库恢复到先前的状态。 总之，您为数据库创建了一个快速恢复区，指定了其大小，并用如下 SQL 命令将数据库置于快速恢复模式下：
alter system set db_recovery_file_dest = '/ora_flash_area';
alter system set db_recovery_file_dest_size = 2g ;
alter system set db_flashback_retention_target = 1440;
alter database flashback on;
该数据库必须处于存档日志模式下以支持闪回。此过程在目录 /ora_flash_area 中创建了 Oracle 管理文件，其总大小高达 2GB 。对数据库所作的更改将写入到这些文件中，并且可用于将数据库快速恢复到过去的某个点上。
默认情况下， RMAN 还使用 /ora_flash_area 来存储备份文件；因此， RMAN 是存储在磁盘上，而不是磁带上。鉴于此，您就有能力指定您需要备份的天数。在该期限之后，如果需要更多的空间，则会自动将这些文件删除。
快速恢复区不必是一个文件系统或一个目录，但是 — ，它可以是一个自动存储管理 (ASM) 磁盘组。如果是那样的话，就可以通过如下命令来指定快速恢复区：
alter system set db_recovery_file_dest = '+dskgrp1';
因此，结合使用 ASM 和 RMAN ，您就可以使用廉价的磁盘（如 Serial ATA 或 SCSI 驱动）来构建一个高度可伸缩的、容错能力强的存储系统，而不需要额外的软件。（有关 ASM 的详细信息，请参阅本系列中的 第 8 周 的内容。）此过程不但使存储过程更快，也使之能用足够便宜的、基于磁带的方法来完成。
一个额外的好处是防止用户错误。由于 ASM 不是真正的文件系统，使其遭受 DBA 和系统管理员意外破坏的可能性也更小一些。
增量合并
假如您有如下备份计划：
星期天 - 第 0 级（完全），带有标签 level_0
星期一 - 第 1 级（增量），带有标签 level_1_mon
星期二 - 第 1 级（增量），带有标签 level_1_tue
等等。如果数据库在星期天发生故障，在 Oracle 10 g 之前的版本中，您将不得不恢复标签 level_0 ，然后应用所有六个增量。它将持续一段较长的时间，这是许多 DBA 不进行增量备份的另一个原因。
Oracle 数据库 10 g RMAN 从根本上改变了此格局。现在，您的增量备份命令看起来如下所示：
RMAN> backup incremental level_1 for recover of copy with tag level_0 database;
在此，我们指示 RMAN 进行 level_1 增量备份，并将其与带有 level_0 标签的完全备份副本合并。在执行该命令之后， level_0 就成为了那一天的完全备份。
因此，在星期二，带有标签 level_0 的备份，当将其与 level_1 增量备份合并时，它就变得与完全的星期二备份相等。同样地，对于星期六采用的增量，当采用磁盘上的备份时，它将会与完全的 level_0 星期六备份相等。如果数据库在星期六发生故障，您只需恢复 level_0 备份外加一小份存档日志，使数据库一致；在此不需要应用额外的增量。该方法显著地削减了恢复时间、加快了备份速度，并消除了再一次执行完全的数据库备份的需要。
压缩文件
对于快速恢复区中基于磁盘的备份，仍有一个大的限制：磁盘空间。特别是当经网络进行时 — 通常情况下就是这样 — 那么创建一个尽可能小的备份集是明智的。在 Oracle 数据库 10 g RMAN 中，您可以在备份命令内部压缩文件：
RMAN> backup as compressed backupset incremental level 1 database;
注意子句 COMPRESSED 的用法。它将用一个显著不同的方式压缩备份文件：在恢复时， RMAN 不用解压缩就能读取文件。为了确认压缩，检查如下的输出信息：
channel ORA_DISK_1:starting compressed incremental level 1 datafile backupset
此外，您可以通过检查 RMAN 列表输出来验证备份已被压缩：
RMAN> list output;
 
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3 Incr 1 2M DISK 00:00:00 26-FEB-04
BP Key:3 Status:AVAILABLE Compressed:YES Tag:TAG20040226T100154
Piece Name:/ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w 2m3 lr_.bkp
Controlfile Included:Ckp SCN:318556 Ckp time:26-FEB-04
SPFILE Included:Modification time:26-FEB-04
对于任意的压缩过程，该方法都会对 CPU 产生压力。作为折衷，您可以在磁盘上保存更多的 RMAN 备份，它准备好为还原和恢复操作所用。此外，您可以在物理备用数据库上制作 RMAN 备份，它可用于恢复初始的数据库。该方法将备份源卸载到另一台主机上。
在您开始行动之前先看看：恢复预览
在 Oracle 数据库 10 g 中， RMAN 通过提供执行恢复操作所需要的预览备份的能力向前迈进了一大步。
RMAN> restore database preview;
列表 1 显示了该操作的输出结果。您还可以预览特定的恢复操作；例如：
restore tablespace users preview;
预览允许您通过执行周期性的、有规则的检查，来确保您的备份基础架构的恢复准备就绪。
Resetlogs 和恢复
假设您丢失了当前的联机重做日志文件，并且您不得不执行一个不完全的数据库恢复 — 一种很少见但听说过的情况。最大的问题是 resetlogs ；在不完全的恢复之后，您必须用 resetlogs 子句打开数据库，它把日志线程的序列号设置为 1 ，会使您的 RMAN 中的早期备份作废并使恢复操作面临更多的挑战。
在 Oracle 9 i 及其较低的版本中，如果您需要将数据库恢复到执行 resetlogs 操作之前的某个版本，您将不得不恢复到一个不同的拷贝。在 Oracle 数据库 10 g 中，您不必这样做。由于控制文件中额外的基础架构，在执行 resetlogs 之前或之后， RMAN 现在都可以容易地使用所有备份来恢复 Oracle 数据库。它不需要关闭数据库来制作一个备份。这种新功能意味着在执行 resetlogs 操作之后，可以立即为用户社区重新打开数据库。
为 RMAN 作好准备
Oracle 数据库 10 g RMAN 中的增强功能使它成为您的备份策略中的甚至更具强制性的工具。对增量备份过程的改进只会使 RMAN 难以被忽视。
第 10 周
审计告知一切
Oracle 数据库 10 g 审计以一种非常详细的级别捕获用户行为，它可以消除手动的、基于触发器的审计
假定用户 Joe 具有更新那张表的权限，并按如下所示的方式更新了表中的一行数据。
update SCOTT.EMP set salary = 12000 where empno = 123456;
您如何在数据库中跟踪这种行为呢？在 Oracle 9 i 数据库及其较低版本中，审计只能捕获 “ 谁 ” 执行此操作，而不能捕获执行了 “ 什么 ” 内容。例如，它让您知道 Joe 更新了 SCOTT 所有的表 EMP ，但它不会显示他更新了该表中员工号为 123456 的薪水列。它不会显示更改前的薪水列的值 — 要捕获如此详细的更改，您将不得不编写您自己的触发器来捕获更改前的值，或使用 Log Miner 将它们从存档日志中检索出来。
这两种方法都能让您跟踪更改的内容并记录更改前的值，但其成本非常高。使用触发器编写审计数据可能会对性能产生主要的影响；鉴于此，在某些情况下（如在第三方应用中）禁止使用用户定义的触发器。 Log Miner 不会影响性能，但它是依赖于存档日志的可用性来跟踪更改的。
细粒度审计 (FGA) ，是在 Oracle 9 i 中引入的，能够记录 SCN 号和行级的更改以重建旧的数据，但是它们只能用于 select 语句，而不能用于 DML ，如 update 、 insert 和 delete 语句。因此，对于 Oracle 数据库 10 g 之前的版本，使用触发器虽然对于以行级跟踪用户初始的更改是没有吸引力的选择 , 但它也是唯一可靠的方法。
随着 Oracle 10 g 的到来，由于审计能力的两个重大的改变，这些限制也随之而去。由于两种审计类型涉及到 — 标准审计（在所有版本中均可用）和细粒度审计（在 Oracle 9 i 及其以上版本中可用） — 我们将分别对它们进行处理，然后看看它们是如何相互补充以提供一个单一的、强大的跟踪功能。
新特性
首先， FGA 现在除了支持 select 语句外，还支持 DMA 语句。这些更改都记录在同一个位置，即表 FGA_LOG$ 中，并通过 DBA_FGA_AUDIT_TRAIL 视图显示出来。除了 DML 外，您现在可以选择只有在访问了所有或者甚至很少的相关的列后，才可以触发一个线索。（有关 FGA 在 Oracle 10 g 中是如何工作的详细信息，请参阅该主题的我的 技术文章 的内容。）
标准审计，是由 SQL 命令 AUDIT 执行的，可用于为特定的对象快速、容易地设置跟踪。例如，如果您想跟踪对 Scott 所拥有的表 EMP 的所有更新，您可以发出如下命令：
audit UPDATE on SCOTT.EMP by access;
任何用户每一次更新表 SCOTT.EMP 时，该命令都会把所有的更新记录到审计跟踪表 AUD$ 中，可以通过 DBA_AUDIT_TRAIL 视图来查看。
这个功能对于 Oracle 10 g 之前的版本也是可用的。但是，在那些版本中，写到跟踪中的信息仅限于少数相关的项，如：发出该语句的用户、时间、终端标识号等等；它缺少某些重要的信息，如绑定变量的值。在 Oracle 10 g 中，除了以前的版本中所收集到的内容之外，审计操作还捕获了许多这些重要的信息片断。用于审计的原始表 AUD$ ，包含若干个用于记录它们的新列，相应地， DBA_AUDIT_TRAIL 视图也包含这些列。让我们详细地研究一下。
EXTENDED_TIMESTAMP 。 该列以 TIMESTAMP (6) 格式记录了审计记录的时间戳，它是用格林尼治标准时间（也称为全球统一时间）来记录时间的，其小数点后的秒数到 9 为止，并且带有时区信息。以这种格式存储的时间的一个例子如下所示。
2004-3-13 18.10.13 .123456000 -5:0
日期表示为 2004 年 3 月 13 日，是美国的东部标准时间，它比全球统一时间晚 5 小时（用 -5.0 来表示）。
这种以扩展格式显示的时间有助于把审计跟踪精确定位到一个更窄的时间间隔中，从而增强了它们的用途，特别是在数据库横跨多个时区时更是如此。
GLOBAL_UID 和 PROXY_SESSIONID 。 当使用某种身份管理组件如 Oracle Internet Directory 进行身份验证时，用户对数据库的访问权限稍有不同。例如，当将他们访问数据库时，可能将他们视为企业用户。审计这些用户不会在 DBA_AUDIT_TRAIL 视图的 USERNAME 列中记录他们的企业用户标识号，以使该信息无用。在 Oracle 数据库 10 g 中，全局（或企业）用户唯一的标识号记录在 GLOBAL_UID 列中，并且没有作进一步的处理或设置。该列可用于查询目录服务器，以查找有关该企业用户的完整的详细信息。
有时企业用户也许是通过一个代理用户连接到数据库，特别是在多层应用中。可以通过命令为用户提供代理身份验证
alter user scott grant connect to appuser;
该命令将允许用户 SCOTT 以 APPUSER 的身份，作为代理用户连接到数据库。在那种情况下， COMMENT_TEXT 列将通过存储值 PROXY 来记录事实；但是对于 Oracle 9 i 而言，代理用户的会话标识号将不会进行记录。在 Oracle 10 g 中， PROXY_SESSIONID 列记录了它，用于精确标识代理会话。
INSTANCE_NUMBER 。 在 Oracle 真正应用集群 (RAC) 环境中，它可能有助于知道在进行更改时用户连接的是哪一个特定的例程。在 Oracle 10 g 中，该列记录了例程号，它是由该例程的初始化参数文件指定的。
OS_PROCESS 。 在 Oracle 9 i 及其较低的版本中，只会在审计跟踪中记录 SID 值；而不会记录操作系统进程标识号。但是，服务器进程的操作系统进程标识号随后可能是必要的，例如，用于交叉引用一个线索文件。在 Oracle 10 g 中，该值也记录在该列中。
TRANSACTIONID 。 在此就产生了最关键的信息价格。假定用户发出下面的命令
update CLASS set size = 10 where class_id = 123;
commit;
该命令获取一个事务项，并且生成一个审计记录。但是，您怎样知道该审计记录真正记录的是什么内容呢？如果记录是一个事务，该事务标识号就会存储在该列中。您可以使用它把审计跟踪与 FLASHBACK_TRANSACTION_QUERY 视图联接起来。下面是该视图中的列的一个小示例。
select start_scn, start_timestamp,
commit_scn, commit_timestamp, undo_change#, row_id, undo_sql
from flashback_transaction_query
where xid = '<the transaction id>';
除了记录对该事务所做的通常的统计外，如 undo change# 、 rowid 等等， Oracle 10 g 还可以在 UNDO_SQL 列中记录撤消对事务所作更改 SQL 命令，以及在 ROW_ID 列显示的受影响行的 rowid 。
系统更改号。 最终，它记录更改前的值。您怎样执行该操作呢？按 Oracle 9 i 中的 FGA 所指出的那样，更改前的值可以通过闪回查询来获取。但是您需要知道该更改的系统更改号 (SCN) ，它可以在审计跟踪的该列中捕获到。您可以发出下面的命令
select size from class as of SCN 123456
where where class_id = 123;
这将显示用户所看到的内容或更改前的值。
扩展的 DB 审计
记住我们最初的兴趣：为了捕获用户发出的 SQL 语句，以及在标准审计中无法捕获的绑定变量。在 Oracle 数据库 10 g 中进入增强型审计，其中这些任务变得如同更改一个简单的初始化参数一样微不足道。只需把下列代码行放入参数文件中。
audit_trail = db_extended
如果使用该参数，该参数将在各列中记录 SQL 文本和绑定变量值。该值在早期的版本中不可用。
触发器 何时是 必要的
避免误检。 审计跟踪是通过来自于原始事务的自治事务生成的。因此，即使原始事务回滚，它们也会提交。
有一个简单例子演示了这一点。假定我们已在表 CLASS 上为 UPDATE 设置了审计。用户发出一条语句以将数据值从 20 更新为 10 ，然后将其回滚，如下所示。
update class set size = 10 where class_id = 123;
rollback
现在该列的 SIZE 值将变成 20 ，而不是 10 ，好像用户从未做过任何事情。但是，即使回滚，审计跟踪也将捕获该更改。在某些情况下这可能不是人们所想要的，尤其是用户执行了许多回滚时。在这种情况下，您也许不得不使用触发器仅捕获已提交的更改。如果表 CLASS 上有一个触发器用于将记录插入到用户定义的审计线索中，在回滚的基础上审计线索也被回滚。
捕获之前更改的值。 Oracle 提供的审计跟踪不会显示更改前后的值。例如，上述的更改将创建一个审计记录，它显示了语句和更改的 SCN 号，但没有显示更改前的值 (20) 。可以使用闪回查询通过 SCN 号获取该值，但是它依赖于在撤消段中可用的信息。如果该信息无法在由 undo_retention 时间段指定的期限内捕获到，就永远不能检索出先前的值来。使用触发器保证了无需依赖于 undo_retention 时间段即可捕获到该值，并且有时很有用。在这两种环境下，您可以决定继续使用触发器以细粒度的级别来记录审计跟踪。
统一的审计跟踪
由于 FGA 和标准审计捕获的是相同类型的信息，当把它们结合起来使用时可以提供许多重要的信息。 Oracle 数据库 10 g 把这些跟踪合并到一个称为 DBA_COMMON_AUDIT_TRAIL 的通用跟踪中，它是 DBA_AUDIT_TRAIL 视图和 DBA_FGA_AUDIT_TRAIL 视图的一个 UNION ALL 视图。但是，在这两种审计类型之间有一些重大的区别。
结论
在 Oracle 10 g 中，审计已经从一个单纯的 “ 操作记录者 ” 成长为一个 “ 事实记录机制 ” ，它能以一个非常详细的级别来捕获用户的行为，这可以消除您对手动的、基于触发器的审计的需要。它还结合了标准审计和 FGA 的跟踪，这使其更易于跟踪数据库访问，而不用考虑它是如何生成的。
Oracle Database 10 g : 为 DBA 提供的最佳前 20 位的特性（十一）
作者 Arup Nanda 来源： OTN
第 11 周
等待界面
10 g 等待界面为还没有被 ADDM 捕获的即时性能问题提供了有价值的诊断数据
“ 数据库太慢了！ ”
这句话通常出自一位严格的用户之口。如果您和我一样，那么在您的 DBA 生涯中您肯定无数次听到过这句话。
那么，您又怎样解决该问题呢？除了对用户置之不理之外（这是我们大多数人都不敢奢望的想法），您可能要做的第一件事就是查看是否有任何会话在等待数据库内部或外部的任何事件。
Oracle 提供了一个简单但一流的机制来达到此目的： V$SESSION_WAIT 视图。该视图显示了有助于您的诊断的各种信息，如一个会话正在等待或已经等待的事件，以及等待了多长时间和多少次。例如，如果会话在等待事件 "db file sequential read" ，列 P1 和 P2 将显示会话正在等待的块的 file_id 和 block_id 。
对于大多数等待事件而言，这个视图足够了，但它还不是一个强健的调整工具，之所以如此说，至少是因为以下两个重要原因：
该视图是当前情况的一个快照。当等待不再存在时，会话先前出现的那些等待的历史也将消失，从而使得事后诊断非常困难。 V$SESSION_EVENT 提供了累积的但不是非常详细的数据。
V$SESSION_WAIT 包含了只与等待事件相关的信息；要获得所有其它的相关信息（如用户 ID 和终端），您必须将它和 V$SESSION 视图结合使用。
在 Oracle 数据库 10 g 中，等待界面经过了彻底的重新设计，从而只需更少的 DBA 干预即可提供更多的信息。在本文中，我们将浏览这些新的特性，并了解它们如何帮助我们诊断性能问题。对于大多数性能问题，您可以从自动数据库诊断管理器 (ADDM) 中获得扩展分析，但对于还没有被 ADDM 捕获的即时问题，等待界面将提供有价值的诊断数据。
增强的会话等待
第一个增强涉及到 V$SESSION_WAIT 本身。这一点通过示例可以很好地说明。
假定您的用户抱怨会话挂起了。您查明了该会话的 SID ，并在 V$SESSION_WAIT 视图中选中了该 SID 的记录。输出显示如下。
SID 　　　　　　　　 : 269
SEQ# 　　　　　　　　: 56
EVENT 　　　　　　　 :enq:TX - row lock contention
P1TEXT 　　　　　　　:name|mode
P1 　　　　　　　　　: 1415053318
P1RAW 　　　　　　　 : 54580006
P2TEXT 　　　　　　　:usn<<16 | slot
P2 　　　　　　　　　: 327681
P2RAW 　　　　　　　 : 00050001
P3TEXT 　　　　　　　:sequence
P3 　　　　　　　　　: 43
P3RAW 　　　　　　　 :0000002B
WAIT_CLASS_ID 　　: 4217450380
WAIT_CLASS# 　　　: 1
WAIT_CLASS 　　　 : Application
WAIT_TIME 　　　　 : -2
SECONDS_IN_WAIT 　: 0
STATE 　　　　　　 :WAITED UNKNOWN TIME
注意以黑体显示的列；在这些列中， WAIT_CLASS_ID 、 WAIT_CLASS# 和 WAIT_CLASS 是 10 g 中新增的列。列 WAIT_CLASS 指示等待的类型，必须将其作为有效的等待事件解决或者作为空闲的等待事件退出。在上面的例子中，等待类显示为 Application ，这表示它是一个需要您注意的等待。
该列突出显示那些能够证明与您的调整最相关的少数几条记录。例如，您可以使用如下查询来获取事件的等待会话。
select wait_class, event, sid, state, wait_time, seconds_in_wait
from v$session_wait
order by wait_class, event, sid
/
下面是一个样例输出：
WAIT_CLASS EVENT 　　　　　　　　　　　SID 　　　　　STATE 　　　WAIT_TIME 　SECONDS_IN_WAIT
---------- -------------------- ---------- ------------------- ---------- ---------------
Application enq:TX - 　　　　　　　　　269 　　WAITING 　　　　　　　　　0 　　　　　　　73
row lock contention
Idle 　　　　Queue Monitor Wait 　　　 270 　　WAITING 　　　　　　　　  0 　　　　　　　40
Idle 　　　SQL*Net message from client 265 　　WAITING 　　　　　　　　　0 　　　　　　　73
Idle 　　　jobq slave wait 　　　　　　259 　　WAITING 　　　　　　　　　0 　　　　　　8485
Idle 　　　pmon timer 　　　　　　　　 280 　　WAITING 　　　　　　　　　0 　　　　　　　73
Idle 　　　rdbms ipc message 　　　　　267 　　WAITING 　　　　　　　　　0 　　　　　184770
Idle 　　　wakeup time manager 　　　　268 　　WAITING 　　　　　　　　　0 　　　　　　　40
Network 　SQL*Net message to client 　 272 　　WAITED SHORT TIME 　　　 -1 　　　　　　 　0
在这，您可以看到几个事件（如 Queue Monitor Wait 和 JobQueue Slave ）被明确地归为 Idle 事件。您可以将它们作为非阻塞等待消除掉；不过，有时这些 “ 空闲 ” 事件可能指示一个内在的问题。例如，与 SQL*Net 相关的事件可能指示高网络延迟（除其他因素外）。
另一件要注意的重要的事情是， WAIT_TIME 的值为 -2 。某些平台（如 Windows ）不支持快速计时机制。如果在这些平台上没有设定初始化参数 TIMED_STATISTICS ，那么将无法获得准确的计时统计数据。在这种情况下，在 Oracle9 i 中，该列将显示一个非常大的数字，这使问题变得更加不清晰。在 10 g 中，值 -2 指示这种情况 — 平台不支持快速定时机制并且没有设定 TIMED_STATISTICS 。（对于本文剩下的部分，我们将假定存在一个快速计时机制。）
会话也显示等待
记得长期以来一直需要将 V$SESSION_WAIT 与 V$SESSION 结合使用以获得有关会话的其他详细信息吗？嗯，这已经成为历史了。在 10 g 中， V$SESSION 视图还显示由 V$SESSION_WAIT 显示的等待。下面是 V$SESSION 视图其余的列，这些列显示了会话当前等待的等待事件。
EVENT# 　　　　　　　　 NUMBER
EVENT 　　　　　　　　　VARCHAR2(64)
P1TEXT 　　　　　　　　 VARCHAR2(64)
P1 　　　　　　　　　　 NUMBER
P1RAW 　　　　　　　　　RAW(4)
P2TEXT 　　　　　　　　 VARCHAR2(64)
P2 　　　　　　　　　　 NUMBER
P2RAW 　　　　　　　　　RAW(4)
P3TEXT 　　　　　　　　 VARCHAR2(64)
P3 　　　　　　　　　　 NUMBER
P3RAW 　　　　　　　 　 RAW(4)
WAIT_CLASS_ID 　　　　　NUMBER
WAIT_CLASS# 　　　　　　NUMBER
WAIT_CLASS 　　　　　　 VARCHAR2(64)
WAIT_TIME 　　　　　　　NUMBER
SECONDS_IN_WAIT 　　 　NUMBER
STATE 　　　　　　　　　VARCHAR2(19)
这些列与 V$SESSION_WAIT 中的那些列相同，且显示相同的信息，从而不再需要在那个视图中查看它们了。因此，对于等待任意事件的任意会话，您仅需要查看一个视图。
让我们回到原来的问题： SID 为 269 的会话正等待事件 enq:TX — row lock contention ，指示它正等待被另一个会话占用的锁。要诊断该问题，您必须识别占用锁的那个会话。但您如何才能做到这一点？
在 Oracle9 i 及更低版本中，您可能得编写复杂（和极耗资源）的查询来获得占用锁的会话的 SID 。而在 10 g 中，您所要做的就是执行以下查询：
select BLOCKING_SESSION_STATUS, BLOCKING_SESSION
from v$session
where sid = 269
BLOCKING_SE BLOCKING_SESSION
----------- ----------------
VALID 　　　　　　　　　　265
找到了： SID 为 265 的会话阻塞了会话 269 。还能更容易吗？
有多少等待？
用户仍然在缠着您，因为用户的问题仍然没有得到满意的解答。为什么用户的会话花了这么长时间才完成？您可以执行以下命令来找出原因：
select * from v$session_wait_class where sid = 269;
输出返回为：
SID 　SERIAL# WAIT_CLASS_ID WAIT_CLASS# 　WAIT_CLASS 　TOTAL_WAITS TIME_WAITED
---- ------- ------------- ----------- ------------- ----------- -----------
269 　　1106 　4217450380 　　　　　　1 　Application 　　　　　873 　　　261537
269 　　1106 　3290255840 　　　　　　2 　Configuration 　　　　　4 　　　　　　4
269 　　1106 　3386400367 　　　　　　5 　Commit 　　　　　　　　 1 　　　　　　0
269 　　1106 　2723168908 　　　　　　6 　Idle 　　　　　　　　　15 　　 　148408
269 　　1106 　2000153315 　　　　　　7 　Network 　　　　　　　 15 　　 　　　　0
269 　　1106 　1740759767 　　　　　　8 　User I/O 　　　　　　　26 　　　　　 　1
注意这里有关会话等待的大量信息。现在您知道了，该会话已经为与应用程序相关的等待等待了 873 次（共 261,537 厘秒），在与网络相关的事件中等待了 15 次等等。
以此类推，您可以使用以下查询来查看系统范围的等待类的统计数据。同样，时间是以厘秒为单位的。
select * from v$system_wait_class;
WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED
------------- ----------- ------------- ----------- -----------
1893977003 　　　　　　　0 Other 　　　　　　　　2483 　　　　18108
4217450380 　　　　　　　1 Application 　　　　　1352 　　　 386101
3290255840 　　　　　　　2 Configuration 　　　　　82 　　　　　230
3875070507 　　　　　　　4 Concurrency 　　　　　　80 　　　　　395
3386400367 　　　　　　　5 Commit 　　　　　　　　2625 　　　　 1925
2723168908 　　　　　　　6 Idle 　　　　　　　　645527 　　219397953
2000153315 　　　　　　　7 Network 　　　　　　　　2125 　　　　　　2
1740759767 　　　　　　　8 User I/O 　　　　　　　 5085 　　　　 3006
4108307767 　　　　　　　9 System I/O 　　　　　 127979 　　　　18623
大多数问题不是孤立出现的；它们留下了揭示真相的线索，模式可以识别这些线索。可以按如下方式从等待类的一个历史视图中查看模式。
select * from v$waitclassmetric;
这个视图存储了最后一分钟内与等待类相关的统计数据。
select wait_class#, wait_class_id,
average_waiter_count "awc", dbtime_in_wait,
time_waited, wait_count
from v$waitclassmetric
/
WAIT_CLASS# WAIT_CLASS_ID AWC DBTIME_IN_WAIT TIME_WAITED WAIT_COUNT
----------- ------------- ---- -------------- ----------- ----------
　　　　　0 　　1893977003 　　0 　　　　　　　0 　　　　　0 　　　　　1
　　　　　1 　　4217450380 　　2 　　　　　　 90 　　　 1499 　　　　　5
　　　　　2 　　3290255840 　　0 　　　　　　　0 　　　　　4 　　　　　 3
　　　　　3 　　4166625743 　　0 　　　　　　　0 　　　　　0 　　　　　 0
　　　　　4 　　3875070507 　　0 　　　　　　　0 　　　　　0 　　　　　 1
　　　　　5 　　3386400367 　　0 　　　　　　　0 　　　　　0 　　　　　 0
　　　　　6 　　2723168908 　 59 　　　　　　　0 　　 351541 　　　　 264
　　　　　7 　　2000153315 　　0 　　　　　　　0 　　　　　 0 　　　　　25
　　　　　8 　　1740759767 　　0 　　　　　　　0 　　　　　 0 　　　　　 0
　　　　　9 　　4108307767 　　0 　　　　　　　0 　　　　　 8 　　　　 100
　　　　 10 　　2396326234 　　0 　　　　　　　0 　　　　　 0 　　　　　　0
　　　　 11 　　3871361733 　　0 　　　　　　　0 　　　　　 0 　　　　　　0
注意 WAIT_CLASS_ID 和相关的统计数据。对于值 4217450380 ，我们看到 2 个会话在最后一分钟内总共等待了该类 5 次（ 1,499 厘秒）。但该等待类是什么？您可以从 V$SYSTEM_WAIT_CLASS 中获取这一信息（如上所示） — 就是 Application 类。
注意名称为 DBTIME_IN_WAIT 的列，这是一个非常有用的列。在我们 第 6 周 关于自动工作负载信息库 (AWR) 的部分中，您可能还记得在 10 g 中是以更细粒化的方式来报告时间的，并且可以确定在数据库中花费的准确时间。 DBTIME_IN_WAIT 显示在数据库中花费的时间。
一切都留有线索
用户终于离开了，您长舒了一口气。但您可能仍然想寻根究底，希望查明主要是哪些等待造成用户会话中的问题。当然，您可以通过查询 V$SESSION_WAIT 而轻易地得到答案 — 但不幸的是，等待事件现在不存在了，因此该视图没有它们的任何记录。您该怎么办？
在 10 g 中，自动保留活动会话最后 10 个事件的会话等待历史。这个历史可通过 V$SESSION_WAIT_HISTORY 视图查看。要找出这些事件，您可以简单地执行：
select event, wait_time, wait_count
from v$session_wait_history
where sid = 265
/
EVENT 　　　　　　　　　　　　　　WAIT_TIME WAIT_COUNT
------------------------------ ---------- ----------
log file switch completion 　　　　　2 　　　 　1
log file switch completion 　　　　　1　　　 　 1
log file switch completion 　　　　　0　　　 　 1
SQL*Net message from client 　　49852 　　　 　 1
SQL*Net message to client 　　　　　0 　　　 　　1
enq:TX - row lock contention 　　　28 　　　　　1
SQL*Net message from client 　　　131 　　　 　1
SQL*Net message to client 　　　　　0 　　　　　1
log file sync 　　　　　　　　　　　2 　　　　 　1
log buffer space 　　　　　　　　　　1 　　　　　1
当会话变为非活动状态或断开时，记录从该视图中消失。不过，这些等待的历史保留在 AWR 表中，以便进一步分析。从 AWR 中显示会话等待的视图是 V$ACTIVE_SESSION_HISTORY 。（同样，有关 AWR 的更多信息，请参考本系列的 第 6 周 。）
结论
通过 Oracle 数据库 10 g 中的等待模型的增强，分析性能问题变得非常容易。提供的会话等待历史可以帮助您在会话经历等待后诊断问题。将等待归为各种等待类还有助于您了解每种类型等待所造成的影响，这在研究正确的纠正方法时将带来便利。