Oracle Database 10g:为 DBA 提供的最佳特性－前5到8周（转贴）

[title2]Oracle Database 10g:为 DBA 提供的前几位最佳特性[/title2]

第 5 周

闪回表

使用 Oracle Database 10g 中的闪回表特性，可以毫不费力地恢复被意外删除的表

以下是一个不该发生却经常发生的情况：用户删除了一个非常重要的表 — 当然是意外地删除 — 并需要尽快地恢复。（在某些时候，这个不幸的用户可能就是 DBA！）
Oracle9i Database 推出了闪回查询选项的概念，以便检索过去某个时间点的数据，但它不能闪回 DDL 操作，如删除表的操作。唯一的恢复方法是在另一个数据库中使用表空间的时间点恢复，然后使用导出/导入或其他方法，在当前数据库中重新创建表。这一过程需要 DBA 进行大量工作并且耗费宝贵的时间，更不用说还要使用另一个数据库进行克隆。
请使用 Oracle Database 10g 中的闪回表特性，它使得被删除表的恢复过程如同执行几条语句一样简单。
让我们来看该特性是如何工作的。
删除那个表！
首先，让我们查看当前模式中的表。
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;
此命令不会将表重命名为回收站中的名称，而是永久删除该表，就象 10g 之前的版本一样。
管理回收站 如果在该过程中没有实际删除表 — 因而没有释放表空间 — 那么当被删除的对象占用了所有空间时，会发生什么事？
答案很简单：这种情况根本不会出现。当表空间被回收站数据完全占满，以至于必须扩展数据文件来容纳更多数据时，可以说表空间处于“空间压力”情况下。此时，对象以先进先出的方式从回收站中自动清除。
在删除表之前，相关对象（如索引）被删除。
同样，空间压力可能由特定表空间定义的用户限额而引起。表空间可能有足够的空余空间，但用户可能将其在该表空间中所分配的部分用完了。在这种情况下，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 10g 的版本控制特性。（更多详细信息请参见本系列第 1 周的内容。）在闪回子句中也可以指定时间戳记而不是指定 SCN。

第 6 周

自动工作负载信息库

学习使用新的特性，这些特性采集数据库性能统计数据和量度，以供分析和调整，并显示在数据库中花费的准确时间，甚至保存会话信息 当您有数据库性能问题时，要解决它您首先要作的是什么？一种常见的方法是看是否存在一种模式：回答诸如“相同的问题是否重复出现？”，“它是否在某个特定的时间段出现？”和“两个问题之间是否有联系？”之类的问题，将几乎总会带来更好的诊断结果。
作为一个数据库管理员，您可能已经投资购买了第三方工具或使用自己开发的工具来在数据库运行期间采集详细的统计数据，并从这些统计数据中导出获得性能量度。在紧急的情况下，您可以访问这些量度来与当前的情况作比较。再度查看这些过去的事件可以给当前的问题带来一些启发，因此不断采集相关的统计数据对于性能分析变得很重要。
一段时间以来，Oracle 在这个领域中的解决方案是它内置的工具 Statspack。虽然某些情况下证明它是非常有价值的，但常常缺少性能故障诊断实践所需的强健性。Oracle Database 10g 提供了一个显著改进的工具：自动工作负载信息库 (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 10g 中引进的散列分区索引。如果它是一个表，您可以考虑修改存储参数来使它不那么密集，或者利用自动段空间管理把它转移到一个表空间中。
您的处理计划一般是有规律的，并且通常基于您对各种事件的了解和您处理它们的经验。现在设想相同的事情由一个引擎来完成，这个引擎采集量度并根据预先确定的逻辑来推出可能的计划。您的工作不就变得更轻松了吗？
现在在 Oracle Database 10g 中推出的这个引擎称为自动数据库诊断监控程序 (ADDM)。为了作出决策，ADDM 使用了由 AWR 采集的数据。在上面的讨论中，ADDM 可以看到发生了缓冲区忙等待，然后取出相应的数据来查看发生缓冲区忙等待的段，评估其特性和成分，最后为数据库管理员提供解决方案。在 AWR 进行的每一次快照采集之后，调用 ADDM 来检查量度并生成建议。因此，实际上您拥有了一个一天二十四小时工作的自动数据库管理员，它主动地分析数据并生成建议，从而把您解放出来，使您能够关注更具有战略意义的问题。
要查看 ADDM 建议和 AWR 信息库数据，请使用在名称为 DB Home 的页面上的新的 Enterprise Manager 10g 控制台。要查看 AWR 报表，您可以从管理转至工作负载信息库，然后转至 Snapshots 来查看它们。在以后的部分中，我们将更详细地讨论 ADDM。
您还可以指定根据特定的情况来生成警报。这些警报称为服务器生成警报，它们被推送到高级队列中，在其中它们可以被任意监听它的客户端使用。一个这样的客户端是 Enterprise Manager 10g，在其中警报被突出显示。
时间模型 当您有性能问题时，要缩短响应时间您最先想到的是什么？很明显，您希望消除（或减少）增加时间的因素的根源。您如何知道时间花费在哪里 — 不是等待，而是真正在进行工作？
Oracle Database 10g 引进了时间模型，以确定在各个地方花费的时间。花费的总的系统时间记录在视图 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 10g 中，获得这种信息轻而易举。
活动会话历史 Oracle Database 10g 中的视图 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 10g 文档
。此外，关于 AWR 和 ADDM 的一个极好的论述可以在技术白皮书自我管理的数据库：自动性能诊断中找到。在第 15 周，您将了解到关于 ADDM 及使用它来解决实际问题的更多内容。

第 7 周

SQL*Plus 的成长

随着 Oracle Database 10g的发布，这个小而强大的 DBA 工具有了一些引人注目的变化，包括有用的提示符和高级文件处理 数据库管理员每天用得最多的工具是哪一个？对于许多象我一样在 GUI 革命之前的数据库管理员而言，一定是 SQL*Plus 命令行选件。
虽然随着强大和功能丰富的 Enterprise Manager 10g 的引入，SQL*Plus 在 Oracle Database 10g 中已经发生了一些变化，但这个普遍存在的小工具仍将继续作为 Oracle 原有系统的一部分 — 对初学者和经验丰富的数据库管理员同样适用。
在本部分中，我们将研究对 SQL*Plus 10.1.0.2 所作的一些非常有用的改进。切记，要继续下面的操作，您将需要 Oracle Database 10g 软件的 sqlplus 可执行程序，而不是运行在 10g 数据库上的 Oracle9i 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 文件中，您就始终拥有这些特性。
必须使用引号吗？为什么，不！
在 Oracle9i 中取消了对内部登录的支持之后，全世界许多 DBA 表示反对：他们应当如何在命令行上输入 SYS 的口令并保持安全性？嗯，答案是在操作系统提示符中使用引号：
sqlplus "/ as sysdba" 引号的使用令人遗憾，但还是被大家所接受（虽然有些怨言） 。在 Oracle Database 10g 中不需要这样了。
现在您可以在 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 （如果该文件不存在）；但如果该文件已存在，则将覆盖它，而没有提示。这种行为常常（特别在复杂环境下）可能导致不希望的边缘效应，例如重要的输出文件被覆盖。在 10g 中，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 文件。但是，有一个严重的局限。在 Oracle9i 和更低版本中，假定在文件中有下面这一行。
set sqlprompt "_connect_identifier >"
当您首先启动 SQL*Plus 与数据库 DB1 连接时，提示符显示：
DB1>
现在，如果您从提示符中与另一个数据库 DB2 连接：
DB1> connect scott/tiger@db2
Connected
DB1>
注意提示符。虽然您现在和 DB2 连接在一起，但提示符仍是 DB1， 。很明显，提示符是不正确的。原因
很简单：在连接时没有执行 login.sql 文件，只在 SQL*Plus 启动时执行了该文件。后来的连接没有重新
执行该文件，使得提示符没有改变。
在 Oracle Database 10g 中，消除了该局限。文件 login.sql 不仅在 SQL*Plus 启动时执行，而且在连接
时也执行。因此在 10g 中，如果您当前与数据库 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 10g 使得所有这些担心完全消失了：因为 DUAL 是一个专用的表，所以持续获得显著地减少了，并且与从事件 10046 跟踪中看到的优化计划不同。
在 Oracle9i 中
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL:CHOOSE
1 TABLE ACCESS (FULL) OF 'DUAL'

在 10g 中
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT MODE:ALL_ROWS
0 FAST DUAL

注意新的 FAST DUAL 优化计划的使用，与 Oracle9i 中的 DUAL 的 FULL TABLE SCAN 相反。这一改进显著地减少了持续读取，从而为频繁使用 DUAL 表的应用程序带来好处。 注意：从技术角度看，这些 DUAL 改进是在 SQL 优化器中实施的，但是，对许多用户而言， SQL*Plus 是用于处理 SQL 的主要工具。
其它有用的信息 其它的 SQL*Plus 增强在本系列的其它地方进行了说明。例如，我在第 5 周关于闪回表的内容中说明了 RECYCLEBIN 的概念。
与一些流传甚广的传言相反，COPY 命令仍然可用，虽然将在以后的版本中废除。 （嗯……，我们不是在 Oracle9i 中就听到这个消息了吗？）如果您有使用这条命令编写的脚本，别沮丧，它不仅可用而且仍被支持。实际上，只错误消息报告方面作了一点改进。如果表有一个 LONG 列，则 COPY 是您创建表的备份的唯一方式，常见的 Create Table As Select 将不能处理带 long 数据类型的列的表。

第 8 周

自动存储管理

数据库管理员终于可以将自己从单调而常用的增加、移动和删除存储磁盘的任务中解脱出来了 — 并且无需增加额外的成本。
假设您刚得到一个新的 Oracle 数据库的全新的服务器和存储子系统。除操作系统配置之外，在您能够创建数据库之前，最重要的工作是什么？很明显，就是创建存储系统布局 — 或更具体地说，选择一种保护级别，然后构建必需的冗余磁盘阵列 (RAID) 组。
在大多数数据库安装中安装存储器要花费大量的时间。从多种可能中选择一种特定的磁盘配置需要仔细的规划和分析，并且最重要的是，需要详细了解存储技术、卷管理器和文件系统。在这个阶段的设计任务可以大致说明如下（注意这个列表只是代表性的，任务将随配置而变化）：
1. 确认存储器在操作系统级通过了认证，并确定冗余保护的级别，该级别可能已经提供（硬件
RAID）。
2. 集中和构建逻辑卷组，并确定分段或镜像是否也是必需的。
3. 在逻辑卷管理器创建的逻辑卷上构建文件系统。
4. 设定所有权和权限，以便 Oracle 进程可以对设备进行打开、读和写操作。
5. 在文件系统上创建数据库，如果可能的话务必在非 RAID 的位置上创建特殊文件，例如重做日志、临时表空间和重做表空间之类的特殊文件。
在大多数公司中，这些步骤大部分是由对存储系统非常了解的某些人来执行的。这里的“某些人”通常不是数据库管理员。
不过，请注意所有这些任务 — 分段、镜像、逻辑文件系统构建 — 的执行都只支持一种类型的服务器，Oracle 数据库。因此，Oracle 自己提供一些技巧来简化或改进这个过程不是很有意义吗？
Oracle Database 10g 正是这么做的。一个新的和激动人心的特性 — 自动存储管理 (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 10g 中的 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 从那些单调的任务中解脱出来。