作者 Arup Nanda 来源： OTN

第 13 周
Enterprise Manager 10 g

最后，讨论一种管理和运用 Oracle 的一站式工具 — 无论对于初学者还是专家

您在日常的 DBA 相关活动中使用什么工具？我最近在一个用户群会议中提出了这个问题。

答案依 DBA 的工作经验而有所不同。大部分高级管理员偏爱简单的命令行 SQL*Plus （我的个人偏好），而其余的人则偏爱使用一些第三方产品。但是，同一个问题在入门级 DBA 那里却得到了不同反应：在这一群体中， Enterprise Manager (EM) 显然是他们的选择。

这些偏好不难理解。 Oracle Enterprise Manager 自从几年前推出以来一直不断进行完善，它开始时是字符模式显示的 SQL*DBA ，随后发展为基于操作系统的客户端工具，最后具有了 Java 风格。 EM 提供的信息非常详细，足够完成大多数 DBA 任务，可作为不愿或者无暇了解新语法并且希望使用 GUI 工具来管理常见数据库任务（如添加用户、修改数据文件和检查回退段）的用户的解决方案。诊断程序包为性能调节提供了非常需要的 GUI 支持。

但是，阻碍 EM 广泛使用的一个主要问题是它无法跟上数据库服务器本身的发展。例如， EM 的 Oracle9 i 数据库版本不支持子分区（该特性在 Oracle8 i 中首次引入）。

Oracle 数据库 10 g 中的 EM 新版本改变了这种情况。它具有新的体系结构和新的界面，而最重要的是，它具有一个功能非常强大而完善的工具箱，提供从初学者到高级用户所需的所有 DBA 技能集。而最好之处在于，它是安装本身的一部分，无需额外费用。如果您正在评估第三方工具，您当然可以将 EM 加入评估行列中，从而使竞争更加激烈。即使您是那种 “ 笃信命令行 ” 的 DBA （象我这样），您也会非常欣赏 EM 在某些情况下能为您所提供的帮助。

在本文中，我将为您介绍新的 EM 。由于该工具所涉范围甚广，因此不可能在此讨论所有的特性；我将在此介绍几个基本特性，并提供其他材料的线索。我将遵循本系列之精神提供实际的示例，演示如何使用该工具解决实际问题。

体系结构

缺省情况下，在安装 10 g 软件时 , 即安装 EM 10 g 时 , 在概念上它与以前版本的不同之处在于，它不是客户端安装的工具；实际上它是位于数据库服务器本身上的 HTTP 服务器（称为 DB 控制台）。（参见图 1 。）您可以使用任何浏览器查看 EM 界面。

图 1 ： EM 体系结构

DB 控制台的端口号可在 $ORACLE_HOME/install/portlist.ini 中找到。以下是一个文件的示例；对于您来说，端口可能不相同。

Ultra Search HTTP port number = 5620

iSQL*Plus HTTP port number = 5560

Enterprise Manager Agent Port =

Enterprise Manager Console HTTP Port (starz10) = 5500

Enterprise Manager Agent Port (starz10) = 1830

从这个文件中我们了解到，数据库 starz10 的代理程序监听端口 1830 ，而 EM 控制台监听 5500 。我们可以通过输入以下 URL 来调用 EM 登录画面：

http://starz/em/console/logon/logon

该 URL 调出登录画面，从中您可以以 DBA 用户登录。在我们的示例中，我们将以 SYS 登录。

主数据库主页

登录后即出现主数据库主页。主页的上部提供对重要细节的快速浏览。（参见图 2 。）

图 2 ：主数据库主页（上部）

在上图中已圈出了最重要的一些部分，并用本文中编号的引用对其进行了标注。首先，请注意标为 “General”(1) 的部分；这一部分显示了有关数据库的一些最基本细节，如数据库从 3 月 20 日起已经启动，以及实例名称等。 Oracle Home 显示为一个超链接，当单击该链接时，将显示所有产品以及共享该主目录的所有其他 Oracle 数据库。 Listener 的超链接显示注册到监听器（其名称就显示在紧靠它的下方）的所有数据库和实例。最后，显示主机名 (starz) 。

在名为 “Host CPU”(2) 的部分中，醒目地显示了 CPU 的详细信息。 “Active Sessions”(3) 部分显示了活动的会话及其当前状态 (4) 。从上面我们看到， 99% 的时间被处于等待状态的会话所占用。（我们稍后将找出导致这些等待的原因。） “High Availability”(5) 部分显示了与可用性相关的信息。例如， “Instance Recovery Time” 的值（实例的 MTTR Target 的值）确定实例崩溃恢复可能需要的时间。

“Space Usage”(6) 部分很有趣：它显示与 23 个段相关的警告。（同样，稍后再详细介绍这些警告。） “Diagnostic Summary”(7) 部分提供数据库良好运行的概要信息。所发现的性能问题的数量表示自动数据库诊断监控程序 (ADDM) — 在 10g 中新增的自诊断引擎 — 主动识别出多少问题。 EM 还自动分析您的环境，以确定是否违反了所建议的最佳实践；此分析的结果显示在 “Policy Violation” 部分。最后， EM 扫描警报日志，并显示任何最新的 ORA 错误。这种信息非常有价值 — 在警报日志中自动扫描 Oracle 错误使您避免了手动搜索这些错误的很多麻烦。

在数据库主页的下部，如图 3 所示，我们可以更详细地查看其中的一些消息。 “Alerts”(1) 部分显示了需要您注意的所有相关警报，每个警报都可以方便地进行配置。以第一个警报 (2) 为例，它显示 Archiver 进程因为某种原因而挂起。当然，下一步就是确定其原因。要查明原因，只需单击它即可。您将从包含该错误的 alert.log 文件中获得更多详细信息。在此情形下，故障点是一个已经填满的闪回恢复区；我们只需将其清空， Archiver 即可重新开始工作。

图 3 ：主数据库主页（下部）

另一个警报 (3) 是有关等待的：数据库在 69% 的时间中等待一个与等待类 “Application” 相关的等待。还记得主页上部是如何显示一个会话处于等待状态的吗？这个警报向我们显示它正在等待什么。单击超链接将会立即为您显示实际的等待。

下一个警报 (4) 显示一个审计项目，即用户 SYS 从特定的客户端机器连接到数据库。同样，通过单击超链接，您可以显示有关该连接的所有详细信息。最后一个警报 (5) 显示某些对象无效。单击超链接，您将转到对象被验证无效的画面。

如您所见，数据库主页犹如显示需要您注意的所有事项的仪表板。该界面没有将详细信息堆积在屏幕上，其界面相当简洁，只需单击即可获得这些详细信息。您可以手动搜集所有这些信息，但这可能会花费很多时间和精力。 EM 10 g 提供了随取随用的解决方案。

一般应用

让我们来看看如何使用新的 EM 来完成一些较常见的任务。

一项常见的任务是变更表及其相应的索引。在数据库主页，如图 3 所示选择 “Administration” 选项卡，并引用标记为 6 的项目。在本页中，您可以管理数据库来配置回退段、创建表空间和模式对象、设置资源管理器、使用新的调度程序（将在以后的文章中介绍）以及更多事项。在此处选择 “Tables” ，这将调出如图 4 所示的画面。

图 4 ：表管理

注意红色圆圈中高亮显示的手电筒标志；这是用于调出数值列表的按钮。在图中所示画面中，您可以单击 LOV 标志，调出数据库中的用户列表，并从列表中选择一个用户。单击按钮 “Go” ，出现该用户的表的一个列表。您还可以使用 “%” 符号指定通配符 — 例如，通过使用 %TRANS% ，可以找出名称中带有单词 TRANS 的所有表。

让我们来看一个示例。选择表 TRANS ，更改其中的一列。单击超链接，调出如图 5 所示的 “ 编辑表 ” 画面。

图 5 ：表管理

如果您要将列 ACTUAL_RATE 从 NUMBER(10) 改为 NUMBER(11) ，则可以更改数字（引用 1 ），然后单击 “Apply” 。要查看完成该任务的实际 SQL 语句，可以单击按钮 “Show SQL” 。

在同一画面上还可以获得另一条重要信息：增长趋势。您将在以后一篇有关段管理的文章中了解到，观察一段时间内的对象增长情况是可能的。该画面提供了相同的信息，但却是以图形方式表示的。要查看该画面，可单击选项卡 “Segments” （ 图 5 引用 2 ）。该操作调出段画面，如图 6 所示。

图 6 ：段画面

注意红色圆圈中标记的项目。该画面显示有多少空间分配给段 (2) 、实际使用了多少 (1) 以及浪费了多少 (3) 。在该画面的下部 (4) ，您可以看到一幅有关对象所用空间以及分配给对象的空间的图形。在本示例中，表的使用模式已经稳定 — 因此是直线。

您可以对表执行其他管理操作，方法是使用那些用于该目的的选项卡，如用于管理约束的 “Constraints” 。

使用 EM 进行性能调节

到目前为止您已经了解到，虽然 EM 的外观已经更改，但它提供了至少与以前的 Java 版本同样多的功能。但是，与后者不同的是， EM 现在还支持更新的 Oracle 数据库功能。例如， EM 现在能够处理子分区。

但是，有经验的 DBA 希望这种工具能完成更多的工作 — 尤其是在故障诊断或主动性能调节方面。让我们举个例子。回忆前文中我们的数据库正在 “Application” 等待类上处于等待状态，如数据库主页所示（ 图 3 引用 3 ），而我们需要诊断其原因。在任何调整过程中需要了解的关键事情之一是有多少种组件（如 CPU 、磁盘和主机子系统）在相互作用，这样有助于在上下文环境中综合观察所有这些变量。为此，可在数据库主页中选择 “Performance” 选项卡。此操作调出如图 7 所示的画面。

图 7 ： “Performance” 选项卡

请注意所有量度已在同一时间轴上对齐，这样更容易观察它们的相互依赖性。注意尖峰 (3) ，它对应于调度程序任务。它表明，在该时刻约有七个会话正在等待与调度程序相关的等待事件。那么，影响因素是什么？注意处于同一位置（绿色区域）的 CPU 量度 — 它们显示了曾经使用过的最大 CPU 使用率，在图形中以虚线 (4) 表示。在该点前后，我们没有看到 CPU 尖峰出现，这就提供了一条线索。注意 CPU 运行队列长度中的尖峰 (1) ，这是调度程序的直接后果，调度程序可能产生了过多的内存需求，导致增加了分页活动 (2) 。如您所见，所有现象集中在一起，促进了对数据库负载 “ 概况 ” 的了解。

注意在时间轴末尾的尖峰 — 增加了运行队列长度 (5) 和分页速率 (6)— 它们与物理读取的另一个尖峰相关 (7) 。原因是什么？

通过比较图形 “Sessions:Waiting and Working” 与尖峰发生的时间，我们可以看到，大部分会话都在 “Application” 等待类上进行等待。但是我们需要确切地查明它在该时期内正在等待什么？单击该时间的区域，调出活动会话画面，如图 8 所示。

图 8 ：活动会话等待

该画面显示会话正在等待的等待事件是 enq:TX ?row lock contention 。那么导致此问题的 SQL 语句是什么？很简单：画面本身显示了语句 8rkquk6u9fmd0 的 SQL ID （在红色圆圈中）。单击该 SQL ID ，调出如图 9 所示的 SQL 画面。

图 9 ： SQL 详细信息

在该画面上，您可以看到关于它的 SQL 语句以及相关的详细信息，包括执行计划。它表明，这条 SQL 导致行锁争用，因此应用程序设计可能是问题的根源。

栓锁争用

假设单击 “Performance” 选项卡出现类似图 10 所示的画面。

图 10 ： “Performance” 选项卡，示例 2

在图中，请注意红色矩形中高亮显示的量度。您可以看到在 12:20AM 左右有很多与 CPU 相关的等待，这导致在 CPU 中出现庞大的运行队列。我们需要诊断这一等待。

首先，单击显示 CPU 争用区域的图形（在图上标有 “Click Here” ），以详细查看该特定等待，如图 11 所示。

图 11 ：活动会话等待

注意在 “Active Sessions Working:CPU Used” 图形中带阴影的框 (1) 。您可以使用鼠标拖动它来放置焦点。此操作导致以下的饼形图（ 2 和 3 ）只在该框所包含的时段内进行计算。在这里我们看到，一个具有 id 8ggw94h7mvxd7 的特定 SQL 正在非常困难地运行 (2) 。我们还看到，具有用户名 ARUP 和 SID 265 的用户会话是最主要的运行会话 (3) 。单击该会话，查看其详细信息。此操作调出 “Session Details” 画面。单击选项卡 “Wait Events” ，调出该会话所经历的等待事件的详细信息，其画面类似于图 12 所示。

图 12 ：等待事件的详细信息

在该画面中，请注意在红色圆圈中高亮显示的 118 厘秒的最长等待，它在等待库高速缓存。当您单击 “Latch:Library Cache” 的超链接时，将会看到类似图 13 所示的画面。

图 13 ：等待直方图

该画面提供了 10 g 数据库之前所没有提供的一些独特信息。在诊断这个栓锁争用问题时，如何知道这 118 厘秒的等待是由几个会话中的多个小等待组成，还是只是由一个会话中的一个大等待组成，从而使数据出现偏差呢？

在这里，直方图可以帮助我们。从图上看，您知道大约 250 次会话拥有 1 毫秒的等待（在圆圈中高亮显示）。会话在 4 与 8 毫秒之间的某处等待了大约 180 次。该画面显示，这些等待的时间通常很短，因而它们不是栓锁争用的主要症状。

在数据库主页上，您可以通过单击标为 “Advisor Central” 的选项卡来访问 ADDM 、 SQL Access Advisor 以及其他顾问程序。 ADDM 在收集量度时自动运行，并且结果立即发布在 Advisor Central 页中；当单击该页时，将显示由 ADDM 给出的建议。 SQL Tuning Advisor 也检查这些量度，并在此页上发布其建议。（我们将在以后的文章中更加详细地研究 ADDM 和 SQL Tuning Advisor 。）

简化维护

数据库主页上标为 “Maintenance” 的选项卡是常用维护活动 — 如备份和恢复、数据导出或导入（ 数据泵 ）、数据库克隆以及更多活动 — 的启动控制台。在该画面上，您还可以对策略验证警报所基于的最佳实践的基本原理进行编辑。

结论

如先前所述，这篇文章所涉及的只是巨大冰山的一角。在本文中，我的目的不是为了提供全面的概述；而是希望提供对一些跨多个技能集的特定活动的快速浏览。

Oracle 10 g EM 为 DBA 新手提供了足够的资源，以便很快地了解 Oracle 数据库管理的微妙之处。一本有关使用 EM 的任务及技术的好提纲是 Oracle “ 两日速成 DBA” 参考手册 。我强烈建议您阅读它，尤其是在您刚开始学习的时候。

1.1     X$表

这一部分表是Oracle数据库的运行基础，在数据库启动时由Oracle应用程序动态创建。

这部分表对数据库来说至关重要，所以Oracle不允许SYSDBA之外的用户直接访问，显示授权不被允许。

如果显示授权你会收到如下错误:

SQL> grant select on x$ksppi to eygle;

grant select on x$ksppi to eygle

                *

ERROR at line 1:

ORA-02030: can only select from fixed tables/views

1.2     GV$和V$视图

从Oracle8开始，GV$视图开始被引入，其含义为Global V$.

除了一些特例以外，每个V$视图都有一个对应的GV$视图存在。

GV$视图的产生是为了满足OPS环境的需要，在OPS环境中，查询GV$视图返回所有实例信息，而每个V$视图基于GV$视图，增加了INST_ID列判断后建立，只包含当前连接实例信息。

注意，每个V$视图都包含类似语句：

where inst_id = USERENV('Instance')

用于限制返回当前实例信息。

我们从GV$FIXED_TABLE和V$FIXED_TABLE开始

SQL> select view_definition from v_$fixed_view_definition where view_name='V$FIXED_TABLE';

VIEW_DEFINITION

------------------------------------------------------------------------------

select NAME , OBJECT_ID , TYPE , TABLE_NUM from GV$FIXED_TABLE where inst_id = USERENV('Instance')

这里我们看到V$FIXED_TABLE基于GV$FIXED_TABLE创建。

SQL> select view_definition from v_$fixed_view_definition where view_name='GV$FIXED_TABLE';

VIEW_DEFINITION

------------------------------------------------------------------------------

select inst_id,kqftanam, kqftaobj, 'TABLE', indx from x$kqfta

union all

select inst_id,kqfvinam, kqfviobj, 'VIEW', 65537 from x$kqfvi

union all

select inst_id,kqfdtnam, kqfdtobj, 'TABLE', 65537 from x$kqfdt

这样我们找到了GV$FIXED_TABLE视图的创建语句，该视图基于X$表创建。

1.3     GV_$,V_$视图和V$,GV$同义词

这些视图是通过catalog.ql创建。

当catalog.sql运行时:

create or replace view v_$fixed_table as select * from v$fixed_table;

create or replace public synonym v$fixed_table for v_$fixed_table;

create or replace view gv_$fixed_table as select * from gv$fixed_table;

create or replace public synonym gv$fixed_table for gv_$fixed_table;

我们注意到，第一个视图V_$和GV_$首先被创建，v_$和gv_$两个视图。

然后基于V_$视图的同义词被创建。

所以，实际上通常我们访问的V$视图，其实是指向V_$视图的同义词。

而V_$视图是基于真正的V$视图(这个视图是基于X$表建立的)。

而v$fixed_view_definition视图是我们研究Oracle对象关系的一个入口，仔细理解Oracle的数据字典机制，有助于深入了解和学习Oracle数据库知识。

1.4     再进一步

1.4.1    X$表

关于X$表，其创建信息我们也可以从数据字典中一窥究竟。

首先我们考察bootstrap$表，该表中记录了数据库启动的基本及驱动信息。

SQL> select * from bootstrap$;

     LINE#       OBJ# SQL_TEXT

------------------------------------------------------------------------------

        -1         -1 8.0.0.0.0

         0          0 CREATE ROLLBACK SEGMENT SYSTEM STORAGE (  INITIAL 112K NEXT 1024K MINEXTENTS 1 M

         8   8 CREATE CLUSTER C_FILE#_BLOCK#("TS#" NUMBER,"SEGFILE#" NUMBER,"SEGBLOCK#" NUMBER)

         9          9 CREATE INDEX I_FILE#_BLOCK# ON CLUSTER C_FILE#_BLOCK# PCTFREE 10 INITRANS 2 MAXT

        14         14 CREATE TABLE SEG$("FILE#" NUMBER NOT NULL,"BLOCK#" NUMBER NOT NULL,"TYPE#" NUMBE

         5         5 CREATE TABLE CLU$("OBJ#" NUMBER NOT NULL,"DATAOBJ#" NUMBER,"TS#" NUMBER NOT NULL

         6         6 CREATE CLUSTER C_TS#("TS#" NUMBER) PCTFREE 10 PCTUSED 40 INITRANS 2 MAXTRANS 255

         7         7 CREATE INDEX I_TS# ON CLUSTER C_TS# PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE (

....

这部分信息，在数据库启动时最先被加载，跟踪数据库的启动过程，我们发现数据库启动的第一个动作就是:

create table bootstrap$ ( line#         number not null,   obj#

  number not null,   sql_text   varchar2(4000) not null)   storage (initial

  50K objno 56 extents (file 1 block 377))

这部分代码是写在Oracle应用程序中的，在内存中创建了bootstrap$以后，Oracle就可以从file 1,block 377上读取其他信息，创建重要的数据库对象。从而根据这一部分信息启动数据库，这就实现了数据库的引导，类似于操作系统的初始化。

这部分你可以参考biti_rainy的文章。

X$表由此建立。这一部分表可以从v$fixed_table中查到：

SQL> select count(*) from v$fixed_table where name like 'X$%';

  COUNT(*)

----------

       394 

共有394个X$对象被记录。

1.4.2    GV$和V$视图

X$表建立以后，基于X$表的GV$和V$视图得以创建。

这部分视图我们也可以通过查询V$FIXED_TABLE得到。

SQL> select count(*) from v$fixed_table where name like 'GV$%';

  COUNT(*)

----------

       259

这一部分共259个对象。

SQL> select count(*) from v$fixed_table where name like 'V$%';

  COUNT(*)

----------

       259 

同样是259个对象。

v$fixed_table共记录了:

394 + 259 + 259 共 912 个对象。

我们通过V$PARAMETER视图来追踪一下数据库的架构:

SQL> select view_definition from v$fixed_view_definition a where a.VIEW_NAME='V$PARAMETER';

VIEW_DEFINITION

------------------------------------------------------------------------------

select  NUM , NAME , TYPE , VALUE , ISDEFAULT , ISSES_MODIFIABLE , ISSYS_MODIFIA

BLE , ISMODIFIED , ISADJUSTED , DESCRIPTION, UPDATE_COMMENT from GV$PARAMETER wh

ere inst_id = USERENV('Instance')

我们看到V$PARAMETER是由GV$PARAMETER创建的。

SQL> select view_definition from v$fixed_view_definition a where a.VIEW_NAME='GV$PARAMETER';

VIEW_DEFINITION

-----------------------------------------------------------------------------

select x.inst_id,x.indx+1,ksppinm,ksppity,ksppstvl,ksppstdf,  decode(bitand(kspp

iflg/256,1),1,'TRUE','FALSE'),  decode(bitand(ksppiflg/65536,3),1,'IMMEDIATE',2,

'DEFERRED',                                  3,'IMMEDIATE','FALSE'),  decode(bit

and(ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE'),  decode(bitand(ksppstvf,2)

,2,'TRUE','FALSE'),  ksppdesc, ksppstcmnt  from x$ksppi x, x$ksppcv y where (x.i

ndx = y.indx) and  ((translate(ksppinm,'_','#') not like '#%') or (ksppstdf = 'F

ALSE'))

在这里我们看到GV$PARAMETER来源于x$ksppi,x$ksppcv两个X$表。 x$ksppi,x$ksppcv 基本上包含所有数据库可调整参数，v$parameter展现的是不包含"_"开头的参数。以"_"开头的参数我们通常称为隐含参数，一般不建议修改，但很多因为功能强大经常使用而广为人知。