2.3 Oracle 的 Grid Control 工具_循序渐进Oracle：数据库管理、优化与备份恢复-QQ阅读男生都市网

上QQ阅读APP看书，第一时间看更新

2.3 Oracle 的 Grid Control 工具

现如今的数据中心涉及各种各样的平台、硬件、网络、存储以及应用软件组件，如何有效管理数据中心便成为了一个热点话题。为此，各大IT厂商都在尝试给出自己的解决方案。Oracle的解决方案便是扩充了Enterprise Manager 本身的功能，推出了更为强大的Enterprise Manager Grid Control工具，此工具提供了管理数据中心的一整套解决方案。

本节将介绍Enterprise Manager Grid Control的体系结构及详细部署安装方法。与此同时，以Grid Control对Oracle物理Data Guard部署和管理为例，展示了Grid Control的强大功能与魅力。

2.3.1 Grid Control体系结构简介

使用Enterprise Manager Grid Control可以使用单一的管理控制台集中管理数据中心中涉及的所有资源，而不再仅仅局限于Oracle 数据库这个层面。通过在Grid Control 上附加具体的插件，不仅可以支持Oracle产品线上的全部产品（Oracle应用服务器、WebLogic服务器、PeopleSoft、Siebel、Oracle EBS以及Oracle虚拟机等），还支持非Oracle产品的集中管理，如IBM DB2、微软SQL Server、IBM WebSphere、JBoss、SAP、存储以及网络设备等（详细信息可以参考Oracle在线帮助文档）。

Grid Control 的体系结构主要包含 3 个重要组成部分，它们分别是 Oracle Management Repository、Oracle Management Service（OMS）以及Oracle Management Agent。这3个组成部分可以集中部署在同一台服务器上也可以按照管理需求和数据中心规模分别部署在独立专属服务器上，如图2-39所示。

图2-39 Grid Control体系结构图

Oracle Management Agent 作用是监控被管理目标对象，采集被管理对象的可用信息、配置信息以及运行性能数据，将收集到的数据发送给Oracle Management Service（OMS）。OMS与Oracle Management Agent是一对多的关系，即每一个 Management Agent 都与一个 OMS 进行通信，而OMS是为多个Management Agent服务的。另外要注意，每一台主机上仅需部署一套Management Agent。

Oracle Management Service（OMS）作用是将Management Agent采集到的信息发送给Repository数据库，OMS仅与一个Repository数据库进行交互操作。OMS另外一个作用是根据Repository数据库中的信息生成用于Grid Control console显示终端的信息。与此同时OMS也是管理员的接口，通过OMS，管理员可以向特定的Management Agent发出管理指令。

Oracle Management Repository是一个集中存放着所有用于Grid Control管理信息的数据库。该数据库管理着所有被监控对象的可用信息、运行性能信息以及相关配置信息。可以说Repository数据库便是所有Grid Control信息资源的集散地，需要重点保护。与Repository数据库相关的两个表空间为MGMT_TABLESPACE和MGMT_ECM_DEPOT_TS。

2.3.2 Grid Control OMS部署方法

以下通过Oracle Enterprise Linux4.8上部署安装Enterprise Manager 10g Grid Control为例，详细介绍了Grid Control的安装方法。

Oracle Enterprise Manager Grid Control（下文部分情况下缩写为Grid Control）需要使用专用的数据库来存放管理数据，即Oracle Management Repository 数据库，以下测试使用已经建立好的数据库作为 Repository 数据库来部署安装 Grid Control。Grid Control 将部署安装在ocmdb2主机上，Grid Control所使用的Repository Database已经事先在ocmdb1主机上安装完毕。

1．安装Grid Control准备工作

首先需要下载 Grid Control 安装软件，这可以从 Oracle 的官方网站上下载与 Grid Control相关的安装软件。

Oracle Enterprise Manager Grid Control官方下载地址如下：

http://www.oracle.com/technetwork/oem/grid-control/downloads/index.html。

选择具体的平台进行下载，本文以Linux平台为例，下载链接如下：

http://www.oracle.com/technetwork/oem/grid-control/downloads/linuxsoft-099441.html。

目前最新版本是11.1，而10g的最高版本为10.2.0.5，如图2-40所示是相关的下载页面。

图2-40 Grid Control的下载页面

安装的系统需要确保满足以下需求：

建议主机内存大于1GB；

可用磁盘空间不少于10GB；

确保图形化安装界面可以顺利启动；

确保与Grid Control相关的主机名设置正确；

确保系统需要的rpm包均安装妥当。

OEL操作系统安装完成后系统会完成Oracle用户和组的创建。若Oracle用户和组未创建成功，可以使用下面的方法进行手工创建。

# groupadd oinstall -g 501

# groupadd dba -g 502

# groupadd oper -g 503

# useradd oracle -u 500 -g oinstall -G dba,oper

# passwd oracle

内核参数使用OEL系统默认的内核参数即可。使用下面的命令完成软件安装所需目录的创建。

# mkdir -p /u01/app/oracle

# chown -R oracle:oinstall /u01

# chmod -R 775 /oracle

检查/etc/hosts，测试配置如下：

[root@ocmdb2 ~]#more /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

192.168.190.32 ocmdb2.localdomain ocmdb2

192.168.190.31 ocmdb1.localdomain ocmdb1

2．安装repository database实例

对于 repository 数据库，通常建议使用全新的数据库安装，以防止出现额外的异常故障；如果使用现有的数据库作为 repository 数据库，则需要进行一些调整，否则会在安装部署的过程中遇到错误，给整个软件的部署安装带来不必要的麻烦。

图2-41 需调整参数错误提示

具体调整内容如下。

（1）常见报错信息。

根据提示需要调整3个参数。

session_cached_cursors：提示要求将参数session_cached_cursors调整到200以上（含200），该参数默认值是20。

job_queue_processes：提示要求将参数job_queue_processes调整到10以上（含10），该参数默认值是5。

open_cursors：提示要求将参数open_cursors调整到300 以上（含300），该参数默认值是50。

通过修改spfile文件的方法调整这3个参数：

SQL> alter system set session_cached_cursors = 201 scope=spfile;

System altered.

SQL> alter system set job_queue_processes = 11 scope=spfile;

System altered.

SQL> alter system set open_cursors = 301 scope=spfile;

System altered.

停起数据库使调整后的参数生效（注意这里谈到的报错内容并不是致命的，既可以在安装Grid Control之前对数据库进行调整，亦可在出现这个错误提示后进行调整，调整完成之后安装可以继续完成）。

（2）执行脚本dbmspool.sql脚本。

SQL> @?/rdbms/admin/dbmspool.sql

Package created.

Grant succeeded.

View created.

Package body created.

脚本注释信息如下：

rem $Header: dbmspool.sql 15-jun-99.08:54:18 mjungerm Exp $

rem

Rem Copyright (c） 1991, 1996, 1997, 1998, 1999 by Oracle Corporation

Rem NAME

Rem dbmspool.sql - dbms_shared_pool utility package.

Rem DESCRIPTION

Rem This package allows you to display the sizes of objects in the

Rem shared pool, and mark them for keeping or unkeeping in order to

Rem reduce memory fragmentation.

（3）解锁DBSNMP用户。

在Grid Control安装过程中需要使用到DBSNMP用户，默认情况下给用户是被锁定不可访问状态，因此需要手工完成用户的解锁操作。具体的解锁方法如下。

SQL> alter user DBSNMP identified by oracle1 account unlock;

User altered.

3．Grid Control安装过程

首先在root用户下执行“xhost+”命令保证图形化安装界面可以正常启动：

[root@ocmdb2 ~]# xhost +

access control disabled, clients can connect from any host

（1）切换到oracle用户下，执行./runInstaller进行安装。

[root@ocmdb2 ~]# su - oracle

[oracle@ocmdb2 ~]$ cd /hsw_media/Disk1/

[oracle@ocmdb2 Disk1]$ ./runInstaller

Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be enterprise-4, enterprise-5, redhat-3, redhat-4, redhat-5, redhat-5.1, SuSE-9, SuSE-10, UnitedLinux-1.0, asianux-1 or asianux-2

Passed

All installer requirements met.

（2）选择安装类型。这里选择“Enterprise Manager 10g Grid Control Using an Existing Database”选项，单击“Next”按钮，如图2-42所示。

图2-42 Installation Type

（3）安装路径和先决条件检查。修改Parent Directory内容为“/u01/app/oracle/OracleHomes”，单击“Next”按钮，如图2-43所示。

（4）提供Repository Database信息。提供事先准备好的Repository Database的基本信息，单击“Next”按钮，如图2-44所示。

注意：下面表空间的位置需要重点修改一下，保证 Repository Database 所在的主机上存在相应的目录。

图2-43 选择安装路径执行条件检查

图2-44 Specify Repository Database Configuration

（5）其他可选配置页，这里保持默认，不进行配置，单击“Next”按钮，如图2-45所示。

图2-45 Specify Optional Configuration

（6）密码安全设定。这里给定的密码要求至少是5位，并且需要包含数字，我们这里统一设置为“oracle1”！

当给定的密码不符合约定的规则时，会给出如下的错误提示，这个错误提示中给出了密码要求的描述，如图2-46所示。

图2-46 密码规则提示

（7）安装配置总结页面，确保无误后单击“Install”按钮进行安装。

（8）安装完成后，需要在root用户下执行allroot.sh脚本，执行完成后单击“OK”按钮进入到漫长的配置页面。

[root@ocmdb2 ~]# sh /u01/app/oracle/OracleHomes/oms10g/allroot.sh

Starting to execute allroot.sh .........

……

Finished execution of /u01/app/oracle/OracleHomes/agent10g/root.sh ......

（9）配置页面，如图2-47所示，这里是最耗时，但也是最省心的无人值守的阶段，可以小憩一下。

图2-47 Configuration Assistants

注意：一定要保证这个配置过程的完整和正确，否则会对使用产生重大的影响，如发现问题，按照提示查看报错日志中给出的内容。

可以使用“find .-cmin 1”命令辅助获得涉及的安装日志文件。

（10）配置结束界面。部署安装Grid Control完成。

（11）通过网页登录Grid Control。打开FireFox浏览器，地址栏中输入“http://ocmdb2.local domain:4889/em”进入到Grid Control登录页面。

（12）输入用户名“sysman”，密码“oracle1”进入到 Grid Control 的首页，如图 2-48所示。

图2-48 Grid Control页面

（13）单击“Targets”，因为没有添加其他 Agent，此时只能看到本机的信息，如图 2-49所示。

图2-49 Grid Control-Targets

到此 Grid Control 成功部署安装完毕。整个安装过程比较耗时，请做好心理准备。需要配置的参数最好一次性的设置正确，否则可能会干扰安装过程。

2.3.3 Grid Control Agent部署方法

完成 Grid Control 的 Agent 部署有很多种方法，这里给出最快速的方法：使用 agentDown load.linux完成Grid Control Agent的部署安装。使用这种方法的特点：一次只能部署一个Agent；使用 Grid Control 服务器上 pull 的技术；可以针对具体环境对脚本进行修改；非交互性静默类型的操作；纯文本输出等。本例使用的操作系统是OEL4.8。

1．先决条件

（1）需要为Oracle创建用户和组；

（2）保证wget命令可用，因为安装过程中需要使用这个命令从Grid Control服务器上下载安装文件；

（3）在oracle用户下完成安装；

（4）保证oracle用户下Java程序jar可用；

（5）确定Agent安装的目录，这里指定的是“/u01 /app/oracle/agent”。

2．agentDownload.linux脚本

agentDownload.linux脚本完成的任务列表如下：

（1）创建所需的目录；

（2）下载installation response file；

（3）下载jarred OUI；

（4）静默模式下安装Agent；

（5）自动发现主机上的targets，并启动主机上的Agent。

3．Agent安装过程

（1）将ocmdb2主机中agentDownload.linux拷贝到ocmdb1主机上。

[oracle@ocmdb1 　　　　　　　~]$ 　　　　　　　　　　　scp ocmdb2:/u01/app/oracle/OracleHomes/oms10g/sysman/agent_download/10.2.0.1.0/linux/ agentDownload.linux .

oracle@ocmdb2's password:

agentDownload.linux 100% 22KB 22.3KB/s 00:00

（2）给脚本授予执行权限。

[oracle@ocmdb1 ~]$ chmod 755 agentDownload.linux

（3）执行agentDownload.linux完成在Agent的部署安装，其中“/u01/app/oracle/agent”表示Agent部署的路径。

[oracle@ocmdb1 ~]$ ./agentDownload.linux -b /u01/app/oracle/agent

……省略输出的 log信息……

/u01/app/oracle/agent/agent10g/root.sh needs to be executed by root to complete this installation.

注意安装完成之后，安装日志最后输出的内容，需要在root用户下执行root.sh脚本。

（4）在root用户下执行root.sh脚本。

[oracle@ocmdb1 ~]$ su - root

Password:

[root@ocmdb1 ~]# sh /u01/app/oracle/agent/agent10g/root.sh

Running Oracle10 root.sh script...

……

Finished product-specific root actions.

到此，整个Agent就安装完毕了。

4．配置新发现的数据库实例

在Grid Control服务器上配置新发现的数据库实例。因为在ocmdb1主机上部署完成Agent后会自动发现其上运行着的数据库实例，我们这里是ocmdb实例和ocmgc实例。只需要简单地配置一下便可在Grid Control中对其进行监控和管理，具体步骤如下。

（1）单击“Targets”，可以在“Hosts”栏目中看到Grid Control识别到了两台主机，如图2-50所示。

图2-50 Grid Control-Targets

（2）进一步单击“Database”可以看到，Grid Control 自动识别到了ocmdb1 主机上的两个数据库实例，如图2-51所示。

图2-51 Grid Control-Targets

（3）单击“Configure”对ocmdb实例进行配置，这里仅需要给出dbsnmp用户的密码（这里输入“oracle1”）即可，其他内容是自动返填出来的，单击“Next”按钮，如图2-52所示。

（4）此时，直接进入到最后的Review阶段，确定没有问题，单击“Submit”按钮。

（5）稍等片刻，提示ocmdb实例的属性已经被更新，如图2-53所示。

（6）刚刚配置完毕时，ocmdb的状态信息还不是很完整（如图2-54的左图所示）此时可以单击右上角的Refresh图标观察实例的状态变化，最终该实例的所有状态信息都会显示出来（如图2-54的右图所示）。

图2-52 Configure

图2-53 Database Instance Configuration Result

图2-54 Grid Control-Targets-信息

（7）同样的流程配置ocmgc实例，最终的状态如下，如图2-55所示。

图2-55 Grid Control-Targets-双实例完整信息

在Agent部署和Grid Control配置的过程中，一定要确保相关数据库实例中的dbsnmp 用户为解锁状态！否则会在部署 Agent 的过程中出现问题。这里仅介绍了最快速的使用agentDownload.linux完成Grid Control Agent部署安装的过程，也可以根据需要也可以使用其他方法完成Agent的安装。

2.3.4 Grid Control部署注意事项及常见问题

1．卸载及重新部署安装Grid Control OMS

当Grid Control的OMS使用过程中出现极端问题，或计划将OMS迁移到其他物理服务器上，我们就需要考虑重新部署OMS并对原有Agent进行调整。

（1）重新部署安装Grid Control OMS。

停止AGENT和OMS服务，然后停止repository database所在服务器的Agent：

[oracle@ocmdb1 bin]$ $AGENT_HOME/bin/emctl stop agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

Stopping agent ... stopped.

停止Grid Control OMS服务器上的Agent及OMS服务：

[oracle@ocmdb2 ~]$ $AGENT_HOME/bin/emctl stop agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

Stopping agent ... stopped.

[oracle@ocmdb2 ~]$ $OMS_HOME/bin/emctl stop oms -all

Oracle Enterprise Manager 10g Release 10.2.0.1.0

Oracle Management Server is Down.

（2）删除Grid Control OMS所在主机中所有与Grid Control相关的内容。

需要在oracle用户下删除的信息：

$ rm -rf /u01/app/oraInventory

$ rm -rf /u01/app/oracle/ *

$ rm -rf /tmp/ *

需要在root下删除的信息：

# su - root

# rm -f /etc/oratab

# rm -f /usr/local/bin/ *

重新启动操作系统：

# reboot

（3）Grid Control repository database中需要完成的删除动作。

删除SYSMAN和MGMT_VIEW用户，此步骤是为了防止在OMS配置过程中因数据库对象存在导致报错。

SQL> drop user SYSMAN cascade;

User dropped.

SQL> drop user MGMT_VIEW cascade;

User dropped.

删除表空间：

[oracle@ocmdb1 ~]$ export ORACLE_SID=ocmgc

[oracle@ocmdb1 ~]$ sqlplus / as sysdba

SQL> select tablespace_name from dba_tablespaces where tablespace_name like 'MGMT%';

TABLESPACE_NAME

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

MGMT_ECM_DEPOT_TS

MGMT_TABLESPACE

SQL> drop tablespace MGMT_ECM_DEPOT_TS including contents and datafiles;

Tablespace dropped.

SQL> drop tablespace MGMT_TABLESPACE including contents and datafiles;

Tablespace dropped.

在按照上述处理完成之后，Grid Control OMS的卸载工作结束，此时可以在新的服务器上重新安装Grid Control OMS软件。注意，在完成Grid Control OMS部署之后是无法正常读取到原Agent信息的，需要做对原Agent做进一步的调整。

2．重新配置Agent以应对OMS服务器的变化

上文提到，如果Grid Control OMS发生了变化，OMS无法自动发现原有的Agent，需要对Agent做相应的调整才能重新加入到Grid Control OMS的管理列表中。Agent端需要调整的内容如下。

（1）确保Agent处于停止状态。

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl status agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

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

Agent is Not Running

如果仍然是运行状态，使用“$AGENT_HOME/bin/emctl stop agent”命令可将Agent停掉。

（2）调整emd.properties参数文件。

如果更换了Grid Control OMS需要调整这个参数文件中的REPOSITORY_URL参数。

[oracle@ocmdb1 ~]$ vi $AGENT_HOME/sysman/config/emd.properties

……

REPOSITORY_URL=https://ocmdb2.localdomain:1159/em/upload

……

有关REPOSITORY_URL参数可以在Grid Control OMS所在主机中获得：

[oracle@ocmdb2 ~]$ $AGENT_HOME/bin/emctl status agent | grep Repository

Repository URL : https://ocmdb2.localdomain:1159/em/upload

（3）删除Agent服务器上遗留的文件并完成Agent的清理。

[oracle@ocmdb1 ~]$ rm -rf $AGENT_HOME/sysman/emd/state/ *

[oracle@ocmdb1 ~]$ rm -rf $AGENT_HOME/sysman/emd/collection/ *

[oracle@ocmdb1 ~]$ rm -rf $AGENT_HOME/sysman/emd/upload/ *

[oracle@ocmdb1 ~]$ rm -rf $AGENT_HOME/sysman/log/ *

[oracle@ocmdb1 ~]$ rm -f $AGENT_HOME/sysman/emd/lastupld.xml

[oracle@ocmdb1 ~]$ rm -f $AGENT_HOME/sysman/emd/agntstmp.txt

[oracle@ocmdb1 ~]$ rm -f $AGENT_HOME/sysman/emd/blackouts.xml

[oracle@ocmdb1 ~]$ rm -f $AGENT_HOME/sysman/emd/protocol.ini

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl clearstate agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

EMD clearstate completed successfully

（4）使用emctl的secure选项重新配置Agent。

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl secure agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

Enter Agent Registration password : --此处需要输入密码，这里密码为oracle1

Agent is already stopped... Done.

Securing agent... Started.

Requesting an HTTPS Upload URL from the OMS... Done.

Requesting an Oracle Wallet and Agent Key from the OMS... Done.

Check if HTTPS Upload URL is accessible from the agent... Done.

Configuring Agent for HTTPS in CENTRAL_AGENT mode... Done.

EMD_URL set in /u01/app/oracle/agent/agent10g/sysman/config/emd.properties

Securing agent... Successful.

（5）启动Agent。

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl start agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

Starting agent ......... started.

（6）使用emctl的upload选项将Agent上传到OMS。

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl upload

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

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

EMD upload completed successfully

（7）最后确认Agent运行情况。

[oracle@ocmdb1 ~]$ $AGENT_HOME/bin/emctl status agent

Oracle Enterprise Manager 10g Release 10.2.0.1.0.

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

Agent Version : 10.2.0.1.0

OMS Version : 10.2.0.1.0

Protocol Version : 10.2.0.0.0

Agent Home : /u01/app/oracle/agent/agent10g

Agent binaries : /u01/app/oracle/agent/agent10g

Agent Process ID : 27716

Parent Process ID : 27701

Agent URL : https://ocmdb1.localdomain:3872/emd/main/

Repository URL : https://ocmdb2.localdomain:1159/em/upload

Started at : 2010-07-12 22:19:14

Started by user : oracle

Last Reload : 2010-07-12 22:19:14

Last successful upload : 2010-07-12 22:19:51

Total Megabytes of XML files uploaded so far : 7.48

Number of XML files pending upload : 2

Size of XML files pending upload(MB) : 0.01

Available disk space on upload filesystem : 87.52%

Last successful heartbeat to OMS : 2010-07-12 22:19:21

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

Agent is Running and Ready

此时Agent运行正常。至此，Grid Control OMS端页面便可以查看到相应的Agent已经添加完毕。Agent向OMS的添加任务到此结束。如存在多个Agent，可以依次按照上述操作过程进行调整和配置。

3．Repository Database不要安装EM组件

如果在安装准备Grid Control使用的Repository Database时选择安装了EM，则在上述Grid Control安装的第（5）步骤中单击“Next”按钮时会报如下错误，如图2-56所示。

图2-56 删除Database Control提示信息

处理方法在报错的同时已经给出，按照提示的处理方法进行操作即可。此处由于我们使用的非RAC数据库作为Repository Database，因此使用提示中的第一种处理方法即可。具体执行过程记录如下。

$ emca -deconfig dbcontrol db -repos drop

STARTED EMCA at Mar 5, 2011 8:26:31 PM

EM Configuration Assistant, Version 10.2.0.1.0 Production

Enter the following information:

Database SID: secgc

Listener port number: 1521

Password for SYS user:

Password for SYSMAN user:

Do you wish to continue? [yes(Y)/no(N)]: y

INFO: Repository successfully dropped

Enterprise Manager configuration completed successfully

FINISHED EMCA at Mar 5, 2011 8:28:11 PM

处理完之后单击“OK”按钮，便可完成这个问题的处理。

4．Repository数据库不要使用模板创建

在安装Grid Control用到的Repository Database时不建议使用模板进行创建，建议使用全新创建的方式完成数据库实例的创建。否则会对Grid Control部署产生一定的影响。以下面这个报错问题为例，如图2-57所示。

图2-57 勿设置dispatchers参数提示

错误提示数据库dispatchers参数不可有值。该问题便是由于采用模板建库带来的小问题。处理该问题的方法很简单，仅需手工将dispatchers参数设置为空即可。

SQL> alter system set dispatchers='';

System altered.

调整完成后单击图2-57中的“Retry”按钮，便可以正常解决这个问题，继续完成后续的安装任务。

5．无法找到jar工具导致Agent安装失败的处理方法

前文提到使用Download方式安装Agent的很多先决条件。这里将给大家展示一下如果没有找到jar文件会出现的报错信息，以便做到防患于未然。

关于环境变量PATH的正确设置方法：防止出现因jar工具导致Agent安装失败的最有效的方法便是正确地设置操作系统的PATH环境变量，保证在Agent部署安装过程中可以顺利地使用对应的jar。

PATH环境变量的正确设置方法如下：

exportPATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:$PATH

其中$ORACLE_HOME/jdk/bin便是jar文件藏身之处。为了保证Agent的顺利部署，建议将PATH环境变量在系统profile中设置正确。

当无法找到jar文件时的报错信息如下：

[oracle@secdb1 ~]$ ./agentDownload.linux -b /u01/app/oracle/agent

agentDownload.linux invoked on Sun Sep 2 22:22:43 CST 2010 with Arguments "-b /u01/app/oracle/agent"

Platform=Linux, S=linux

GetPlatform.:returned=0, and os is set to: linux, platform=Linux

……省略部分输出信息……

Downloaded UnzipUtility with status=0

which: no jar in ((null))

The jar to be used=

which: no jar in ((null))

Can't find the jar utility. Add jar to your PATH and try again.

Removing the copied stuff.....

Removed: /home/oracle/agentDownload10.2.0.1.0Oui/oui_linux.jar

Removed: /home/oracle/agentDownload10.2.0.1.0Oui/agent_download.rsp

Removed:/home/oracle/agentDownload10.2.0.1.0Oui/Disk1

Log 　　name 　　of 　　　　　installation 　　can 　　be 　　　　　　at: found "/u01/app/oracle/agent/agent10g/agentDownload.linux080110142243.log"

在错误的提示信息中已经给出处理方法：“Add jar to your PATH and try again.”。将jar位置添加到环境变量中，然后重新安装。

往往报错信息本身便给出了指引我们前进的方向，这些信息可以协助我们快速解决问题，不容错过。但现实情况是，很多朋友将错误提示作为过眼云烟，更有可能连“过眼”的机会都不给！希望给大家一些启示。

6．密码文件异常导致 Grid Control OMS安装失败

部署安装 Grid Control 的 OMS 之前一定要创建实例对应的密码文件，否则在安装 Grid Control过程中将会提示无效的用户名和密码。

原因很简单，因为在OMS配置过程中需要以SYSDBA身份登录SYS用户远程登录数据库实例，因此如果没有配置密码文件，远程用户以SYSDBA身份登录系统将会被禁止。进而提示无效的用户名和密码错误。

正常情况，如果是因为缺少了密码文件，会提示ORA-01031错误，错误内容如下：

$ sqlplus sys/oracle@ora10g as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Sep 3 21:59:31 2010

ERROR:ORA-01031: insufficient privileges

Enter user-name:

ERROR:ORA-01017: invalid username/password; logon denied

如果是根据ORA-01031错误提示，比较容易定位问题的出处，但是在Grid Control OMS安装过程中出现的无效的用户名和密码错误一时会让人难以捉摸。万变不离其宗，一切问题都有其根本的渊源，按图索骥便是。通过手工创建密码文件的方法可以解决这个问题。

2.3.5 Grid Control应用之物理Data Guard创建与管理

1．Grid Control快速部署Oracle物理Data Guard

Grid Control是监控和管理数据库好帮手，同时也是一把双刃剑。“熟练”应用Grid Control，可以大幅度地提高管理和维护数据库的效率；反之，如果对其隐含的细节没有全面的掌握，很容易带来不必要的麻烦和故障。以下通过实践操作展示一下使用 Grid Control 快速部署Oracle物理Data Guard的详细过程。

登录到Grid Control管理界面，依次单击Targets Databases，此时可以看到被Grid Control管理的两个Oracle数据库实例，secdb实例是物理Data Guard主数据库实例，secgc是Grid Control工具对应的数据库实例，如图2-58所示。

图2-58 Grid Control-Targets-Database

单击secdb实例，进入secdb实例的Home页面。单击“Maintenance”进入到secdb实例的维护页面。

在右侧可以寻觅到Data Guard的身影，单击Data Guard下面的“Setup and Manage”，如图2-59所示。此时需要提供管理用户及密码信息，单击“Login”按钮。

图2-59 Grid Control-All Targets-Maintenance

单击“Add Standby Database”，此页面中给出了使用Grid Control创建和管理Data Guard的优势，如图2-60所示。

分别有4个选项供选择：新建物理备库、新建逻辑备库、管理一个存在的备库、仅做主库的备份。本例中保持默认的第一个选项（新建物理备库），单击“Continue”按钮，如图 2-61所示。

有两个选项“Perform a live backup of the primary database”和“Use a backup from a previous standby database creation”。保持默认选中第一个选项不变，单击“Next”按钮。此时已经进入到 step-by-step 的配置阶段，因为之前没有备份介质可用，因此这里我们选择生成备份。

图2-60 Add Standby Database

图2-61 选择备库类型

此处需要提供备份介质存放的目录及备份选项。备份目录指定为“/home/oracle”；为了节省空间选择压缩备份，相应的备份时间也会有所增加；保留备份介质供不时之需，如图2-62所示。

物理Data Guard的实例名这里指定为secdg；输入oracle用户名和密码；在此配置下，新部署的备库和主库均在主机secdb1上，如图2-63所示。

图2-62 备份设置

图2-63 物理Data Guard位置

接下来的步骤是设定文件对应关系，这一步骤非常关键。此处一定不要急于单击Next进入到下一环节，我们需要单击“Customize”按钮对文件目录进行定制（如图2-64所示）。否则， standby_file_management参数将会被设置为“MANUAL”，db_file_name_convert及log_file_name_convert参数将会被设置为空。在这种设置情况下，当主库添加数据文件后，备库将无法正常将其正常应用。关于该问题的模拟及处理方法后文将会做详细描述。

图2-64 File Location

默认情况下数据文件、临时文件、日志文件和控制文件的创建路径如图 2-65 至图 2-67 所示，是不是有一种目瞪口呆的感觉，如果按照这个路径部署会对后期的管理和维护带来很大的麻烦，因此，这些路径内容急需调整。

为了简便，我们将所有的数据库对应的文件都指定到“/u01/app/oracle/oradata/secdg”。

注意：仅仅给出路径是不够的，一定要单击路径后面的“Go”按钮。只有这样，给出的路径名才会真正得到应用，否则无济于事。

图2-65 File Location-Data files

图2-66 File Location-Log files

图2-67 File Location-Control Files

（1）一一修改，确保修改全面后单击“OK”按钮，如图2-68所示。

图2-68 File Location-Datafiles

（2）单击“OK”按钮后，此时会收到如下的提醒信息。该警告信息是由于我们指定的目录事先没有创建导致的，单击“Yes”按钮，系统将自动创建，如图2-69所示；又回到File Locations界面，似乎什么都没有发生，但什么事情都有所改变。单击“Next”按钮继续。

图2-69 File Location-Data files-Warning

2．配置界面

配置界面需要给出备库的Unique Name、Target Name和Standby归档路径信息。

按照图中内容进行修改，修改后单击“Next”按钮，如图2-70所示。此处会弹出警告信息，同样是由于设置的Standby归档路径不存在导致的，单击“Yes”按钮让系统自动创建。

图2-70 File Location-Data files-Warning

3．检查确认参数

（1）仔细检查主备库的基本参数信息是否正确。

（2）仔细检查主备数据库数据文件、临时文件、日志文件和控制文件的对应关系是否调整正确。一切确认无误后单击“Finish”按钮，此后将进入到无人值守的自动创建阶段。

4．自动创建过程

如果之前配置的没有问题，稍等片刻后，一个鲜活的物理Data Guard将会呈现在世人的面前。

（1）初始化Job，用于后续的自动创建。

（2）自动创建Job后台自动运行，此时可以单击“Creation in progress”跟踪整个Job的运行过程。

（3）此时，整个物理Data Guard的创建工作已完成。总用时369秒，不到7分钟（如图2-71所示）。此时Job的status会显示为“Succeeded”，创建成功。

图2-71 创建DG成功

5．确认主备库

最后，从Targets -Databases界面已经可以看到成功加入的secdg实例的信息，它便是secdb的物理Data Guard数据库，如图2-72所示。

图2-72 主备库状态

6．故障排除

在2.3.5节中提到，在创建物理Data Guard时，如果standby_file_management和db_file_name_convert设置不当，会导致主库添加的数据文件无法应用到备库，我们就此故障进行再现并给出解决方案。

（1）故障再现。

① 主库创建全新表空间tbs_sec1：

SQL> create tablespace tbs_sec1 datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' size 10m;

Tablespace created.

② 手工切换日志：

SQL> alter system switch logfile;

System altered.

③ 此时在备库告警日志中便可以查看到如下报错信息。

Tue Aug 10 16:16:21 2010

RFS[2]: No standby redo logfiles created

RFS[2]: Archived Log: '/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc'

Tue Aug 10 16:16:22 2010

Media Recovery Log /SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc

File#6 added to control file as 'UNNAMED00006'because　

theparameterSTANDBY_FILE_MANAGEMENT is set toMANUAL　

The file should be manually created to continue.

Errors with log /SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc

MRP0: Background Media Recovery terminated with error 1274

Tue Aug 10 16:16:22 2010

Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_15738.trc:

ORA-01274: cannot add datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' - file could not be created

Some recovered datafiles maybe left media fuzzy

Media recovery may continue but open resetlogs may fail

Tue Aug 10 16:16:24 2010

MRP0: Background Media Recovery process shutdown (secdg)

对应的trace文件中记录的报错信息与告警日志中记录的相同。

（2）故障原因。

导致这个故障发生的原因是没有正确设置standby_file_management和db_file_name_convert参数。但此时，在已经出现问题的前提下修改这个参数，已经于事无补。

尝试此时将db_file_name_convert参数调整为正确值。

SQL> alter system setdb_file_name_convert='/u01/app/oracle/oradata/secdb/',　

'/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;　

System altered.

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

SQL> startup nomount;

ORACLE instance started.

SQL> alterdatabasemount standbydatabase;　

Database altered.

SQL> alterdatabase recovermanaged standbydatabasedisconnect from session;

Database altered.

此时告警日志中仍然会记录如下报错信息：

Tue Aug 10 16:24:36 2010

alter database recover managed standby database disconnect from session

Tue Aug 10 16:24:36 2010

Attempt to start background Managed Standby Recovery process (secdg)

MRP0 started with pid=23, OS id=16942

Tue Aug 10 16:24:36 2010

MRP0: Background Managed Standby Recovery process started (secdg)

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1111

Tue Aug 10 16:24:41 2010

Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_16942.trc:

ORA-01111:name fordata file6 isunknown - rename to correct file　

ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'

ORA-01157: cannot identify/lockdata file6 - seeDBWR trace file　

ORA-01111: name for data file 6 is unknown - rename to correct file

ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'

Tue Aug 10 16:24:41 2010

MRP0: Background Media Recovery process shutdown (secdg)

Tue Aug 10 16:24:42 2010

Completed: alter database recover managed standby database disconnect from session

可见，故障依旧！单纯的调整参数已经无法解决该问题。

（3）正确处理方法。

在这种故障场景下，我们可以通过调整数据文件指向的方法在备库端进行调整。

获得备库的数据文件信息：

SQL> select name from v$datafile;

NAME

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

/u01/app/oracle/oradata/SECDG/datafile/o1_mf_system_661zb5rh_.dbf

/u01/app/oracle/oradata/SECDG/datafile/o1_mf_undotbs_661zc97r_.dbf

/u01/app/oracle/oradata/SECDG/datafile/o1_mf_sysaux_661zd3d0_.dbf

/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006

可见，此时列出的最后一个数据文件便是问题之所在。将其调整为正确的路径及名称。

SQL> alter database create datafile　'/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006' as'/u01/app/oracle/oradata/SECDG/datafile/tbs_sec1.dbf';　

Database altered.

到此，对应的数据文件已经恢复为应用的状态，该问题已经得到比较圆满的解决。

（4）杜绝出现该问题的方法。

防止该问题出现的的根本方法是在创建物理 DataGuard 的过程中就将 standby_file_management、db_file_name_convert及log_file_name_convert参数设置正确。手工调整方法如下。

① 调整standby_file_management参数为AUTO：

SQL> alter system set standby_file_management=auto;

② 设置db_file_name_convert参数：

SQL> alter system set db_file_name_convert='/u01/app/oracle/oradata/secdb/',

'/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;

③ 设置log_file_name_convert参数：

SQL> alter system set log_file_name_convert='/u01/app/oracle/oradata/secdb/',

'/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;

如何通过Grid Control工具规避这个故障在2.3.5.1节中已有描述，这里不赘述。关于物理DataGuard 的配置，每一个参数都要细细揣摩。此故障一旦出现，会给我们带来很多不必要的麻烦。无论是使用Grid Control还是通过命令行脚本来创建物理Data Guard，创建完毕后建议对数据库的每个与Data Guard相关参数做最终的检验和确认。

如果一切顺利，使用GridControl创建示例数据库的物理DataGuard大约仅需10分钟左右，可谓速度惊人。在得到便捷的同时，该方法也隐藏了很多实现细节，不便于深入了解DataGuard的运行原理。若想深入了解物理Data Guard的细节，建议以脚本创建为主Grid Control创建为辅的原则来探求DataGuard的真谛。

7．调整Oracle物理Data Guard备库为Read Only

如果是在命令行界面完成调整Oracle物理Data Guard备库为Read Only，需要的仅仅是两条简单的命令，在Grid Control中完成这一动作需要的仅仅是动一动鼠标。

单击界面下方Data Guard Status中的“Normal”，如图2-73所示。此时系统处于“Online”状态，即日志应用状态，如图2-74所示。

图2-73 Data Guard Status

图2-74 Data Guard Status-General

选择“Read only”选项，单击“Apply”按钮之后，即可完成 Read Only 状态的变换，如图2-75所示。

如果您是一位命令行操作的忠实践行者，很有可能不能很快地在 Grid Control 中找到调整物理Data Guard备库为“Read only”的地方，按照本文描述内容进行操作即可。

注意：如果是使用Grid Control来维护Data Guard，建议不要过多地使用命令行操作进行干预，反之亦然。这样可以减少因维护操作带来的故障几率。

8．调整物理Data Guard数据保护模式

关于物理 Data Guard 数据保护模式调整的命令行操作方法这里不赘述，本文将介绍通过Grid Control工具完成物理Data Guard数据保护模式的方法。

依次单击secdb- Maintenance -Data Guard中的Setup and Manage，便可以进入到Data Guard的管理页面，如图2-76所示。

图2-75 Data Guard Status-General

图2-76 Data Guard

单击Protection Mode后面的“Maximum Performance”，进入到数据保护模式调整页面，此处我们选择将数据保护模式调整为“Maximum Availability（最大可用）”，单击“Continue”按钮，如图2-77所示。

图2-77 Data Guard Protection Mode

从最大性能模式到最大保护模式的调整需要配置Standby Redo Log Files，在Grid Control的这个页面中给出了添加向导，此处可以保持默认单击“Continue”按钮，如图2-78所示。

图2-78 Data Guard Protection Mode

数据保护模式调整的确认页面，单击“Yes”按钮后便会进入到自动调整阶段，如图 2-79所示。

图2-79 Data Guard Protection Mode

一切都是自动完成的，调整完毕后的页面如下。注意此处Protection Mode后面的提示内容已经Maximum Availability。调整完毕，如图2-80所示。

图2-80 Data Guard

使用Grid Control完成Oracle物理Data Guard数据保护模式的调整可谓简单快捷。建议各位好朋友有机会也体验一下这个畅快的过程。但是，简单快捷的背后隐藏着诸多未知世界。对于一名优秀的DBA来说，如果存在未知，那一定是危险的！试问，有多少生产数据库勇于尝试该方法进行切换？一旦遇到切换故障，处理起来将是痛苦的。我们可以体验便捷，但不要让便捷成为我们的障碍。

9．使用Grid Control对Oracle物理Data Guard进行Switchover切换

使用 Grid Control 完成 Switchover 切换可谓是“一键式”切换，一切皆由系统自动完成，方便快捷。进入到Grid Control的Data Guard管理页面，单击“Switchover”（单击导航上的Targets- Databases -选择具体的数据库实例，这里是secdb - Maintenance - Data Guard中的Setup and Manage），如图2-81所示。

图2-81 Data Guard

在确认页面，单击“Yes”按钮，如图2-82所示。

图2-82 确认Switchover

一切来得就是这么直接和简便，此时已经进入到无人值守的自动切换阶段。如图2-83所示，建议此时密切关注主备节点的alert日志，实时地掌握自动切换过程中的每一个细节，你会发现很多有趣的现象。主备切换完毕，图2-84便是切换完毕后的最终页面。

提示：如果是一主带多备的架构，使用Grid Control完成切换后会自动配置其他备库，单就这个功能来说，的确便捷许多。

同样的操作过程，我们可以完成主备库的再次Switchover切换。

图2-83 自动切换阶段

图2-84 切换完毕

真实的生产环境中如果要完成主备数据库的Switchover切换任务，往往需要制定非常周密的切换计划和回退计划。不要贸然地使用文中描述的 Grid Control 方法完成切换。体验便捷值得推崇，但不可在未经充分测试的前提下触碰这种便捷，否则痛苦将远远大于便捷带来的快乐。

10．使用Grid Control对Oracle物理Data Guard进行健康检查

在配置完毕物理Data Guard之后，如何快速的验证配置的是否存在问题？Grid Control提供的“Verify Configuration”功能可以很便捷地完整这个小任务。这相当于为物理Data Guard进行了一次健康检查。

进入到Data Guard的Grid Control管理页面，单击导航上的Targets - Databases - 选择具体的数据库实例，这里是secdb- Maintenance -Data Guard中的Setup and Manage，如图2-85所示。执行完毕便可以看到生成的检查报告，以下两个截图是检验后的结果信息，如图2-86所示。

仅需轻按鼠标，Data Guard检验便轻松完成，省时省力。同样的提醒，在使用自动化工具体验快捷的同时建议深入到细节，只有真正了解其运行原理之后，这些工具才不会带给我们“方便的障碍”。

图2-85 Data Guard健康检查

图2-86 Data Guard健康检查结果

2.3.6 Grid Control 11g的增强

Oracle Enterprise Manager Grid Control11g较之10g版本又有了一些变化，最主要的变化在于中间件产品上，由原来的Oracle Application Server调整为WebLogic Server。新的架构变化如图2-87所示。

图2-87 Grid Control 11g体系结构变化

Grid Control 11g在部署上也有了很多变化，首先，需要提前准备好用于Grid Control的Repository数据库，数据库的版本至少需要Oracle 10.2.0.4，这里建议使用Oracle 11g 版本的数据库作为 Repository 数据库，从Grid Control 11g版本之后，安装过程不再像10g版本中那样提供“Enterprise Manager 10g Grid Control Using a New Database”选项，即必须在创建好的数据库实例上部署Grid Control，如图2-88 所示。另外，新部署的数据库实例上确保不要存在SYSMAN用户。

由于新版本Grid Control 是基于WebLogic 中间件技术，因此必须提前部署安装WebLogic Server，注意需要WebLogic Server 10.3.2版本，并且在安装的过程中需要选用“Typical”类型，如图2-89所示，若在64位操作系统上部署安装，同时需要安装JDK。

图2-88 Grid Control安装类型选项

部署安装Grid Control 11g的过程中的配置界面较之以前版本少了许多，可见在安装的设计上也做了比较精心的调整。Grid Control 安装界面如图2-90所示。

图2-89 使用Typical类型安装WebLogic

Grid Control 11gR1版本较之早期版本功能上有了非常大的发展，可见Oracle在Grid Control这个管理产品上的投入之大不可小视。这里将Grid Control 11g版本中引进的新特性做一个简单的介绍。

1．数据库管理

数据库管理方面的增强。支持Oracle 11gR2版本中的所有新特性。在性能诊断、SQL优化以及高可用等方法面都有了全面的增强，如图2-91所示。

图2-90 Grid Control 11gR1安装步骤

（1）性能诊断。

增强了数据库性能页面。

ADDM调查结果对TOP活动的影响。

备用数据库Top活动，例如用于报告的Active Data Guard数据库。

图2-91 Grid Control 11g数据库管理页面

（2）SQL调优。

为Realtime SQL Monitoring和SQL Details提供主动报告支持。

SQL Monitoring中的PL/SQL执行监控。

SQL Tuning Advisor中可根据实时或历史性能识别备用执行计划。

SQL Tuning Advisor中提供了并行SQL概要文件建议，支持并行执行长期查询。

（3）真正应用集群（RAC）。

完全支持11.2的基于策略管理的集群数据库。

添加新实例或重定位现有实例时会自动发现基于策略管理的实例。

将单个实例数据库转换成基于策略管理的集群数据库。

（4）高可用性。

Oracle MAA最佳实践配置的实现更加自动化。

增强了Oracle 流和高级复制管理和监控。

（5）Oracle Clusterware。

监控和管理应用资源类型和应用资源。

配置和管理Server Pools。Server Pools是将集群内的服务器逻辑分割成一个一个组，每个组就是一个 server pool。可以定义每个 server pool所需要的最多、最少服务器数以及重要度。

将关于Oracle Clusterware资源的基线警告发送给Enterprise Manager。

启动和关闭Oracle Clusterware。

（6）Oracle Grid Infrastructure。

监控Oracle Restart，Oracle Restart是Oracle Grid Infrastructure的重要组件。当重启计算机或遇到故障时可以自动重启数据库实例、ASM实例、监听以及其他一些相关资源。

管理ASM Cluster File System。

管理ACFS、动态卷和ACFS快照。

监控ACFS组件的可用性、磁盘使用和性能。

为ASM文件和卷提供最佳磁盘布局。

支持增强的安全模型，包括SYSDBA和SYSASM权限的分离。

（7）数据遮蔽（Data Masking）增强。

在遮蔽定义中预先遮蔽SQL支持。

遮蔽操作提供EMCLI支持，比如导入遮蔽定义、生成脚本和执行遮蔽。

支持异构数据库遮蔽，如SQL Server、DB2、using Oracle Database Gateways。

（8）变更管理增强。

向外部文件导出和导入词典基准，在Enterprise Manager环境间迁移。

实时跟踪Oracle Database 11g支持的模式变更。

（9）真正应用测试（RAT）增强。

支持Relay过滤器；

为SQL Performance Analyzer提供主动报告支持。

2．中间件管理

Grid Control 11g中间件管理页面，如图2-92所示。

图2-92 Grid Control 11g中间件管理页面

（1）增强管理Oracle Fusion Middleware 11g的界面。

用于管理Oracle Fusion Middleware 11g的界面更丰富、更简单易用。页面左侧提供了导航树控制右侧显示的详细信息。此外，上下文敏感的菜单使您能轻松访问常用操作和特性。Oracle Enterprise Manager 11g Fusion Middleware Control 和 Oracle WebLogic Server Administration Console管理界面提供了上下文内钻取功能。

（2）管理和监控Oracle Fusion Middleware 11g组件。

Enterprise Manager Grid Control现在支持Oracle Fusion Middleware 11g整个组件家族的发现、监控和集中管理。这些新特性使您能在 Enterprise Manager Grid Control 内直接管理所有Fusion Middleware 目标，无需在Enterprise Manager Grid Control, Fusion Middleware Control和WebLogic Server Administration Console用户界面之间切来切去。

（3）自定义Oracle Fusion Middleware11g的性能摘要。

Enterprise Manager 11g Grid Control Release 1为Oracle Fusion Middleware 11g组件提供了可自定义的性能摘要页面。可修改性能摘要页面的默认设置。

（4）Oracle Fusion Middleware 11g的支持工作台。

支持工作台用于调查和报告Fusion Middleware环境中的问题，该工具进行了扩展，可以支持Oracle Fusion Middleware 11g。通过支持工作台，您可以收集首次故障后的诊断数据、获得支持请求号，并尽快向Oracle支持团队上传诊断数据。

（5）发现和管理WebLogic服务器的功能。

Oracle Enterprise Manager 11g Grid Control Release 1 中添加了 WebLogic Server 和其他Oracle Fusion Middleware目标，改进了用户体验。

（6）WebCenter套件监控。

Enterprise Manager Grid Control现在为Oracle WebCenter和Oracle WebLogic Portal提供了应用性能管理功能。

自动发现关键组件。

上下文钻取功能，让您更容易发现Oracle WebCenter和Oracle WebLogic Portal环境中的性能瓶颈，提供关键测量数据，帮您快速找到问题所在。

变更检测确保识别组件间相互关系和依附关系的底层模型总是最新的。

（7）Oracle Fusion Middleware SOA套件监控。

Fusion Middleware 11g Service-Oriented Architecture(SOA)构件和基础架构的管理得到了增强，提供了监控、故障管理、配置管理、SLM和部署功能。

（8）克隆SOA部件。

提供了很多新部署程序，支持自动化SOA部件的配置。

（9）Web服务管理与策略。

Enterprise Manager Grid Control现在提供了管理Fusion Middleware的Web服务的功能。支持Web服务测试功能，包括测试REST样式的Web服务端点。

（10）新的Oracle身份与访问管理功能。

之前的身份管理插件被包含在了Enterprise Manager Grid Control的基本安装中。这样无需安装单独的插件即可监控 Oracle Identity Management Suite 10g，而且部署流程也更为简单。Enterprise Manager Grid Control提供了管理Oracle Identity Management 11g组件的功能。

3．与My Oracle Support集成

与MyOracle Support（原Metalink）完美集成，进一步增强了Enterprise Manager Grid Control单独为企业提供管理和支持的能力。现在无需离开Enterprise Manager Grid Control 用户界面即可无缝访问My Oracle Support控制台页面，管理服务请求、部署补丁和阅读知识库文章，如图2-93所示。

图2-93 Grid Control 11g的My Oracle Support登录页面

4．生命周期管理与配置

（1）Oracle Database 11g Release 2 (11.2) 产品套件的补丁支持。

此功能支持精心安排物理备份和Oracle Data Guard环境中的补丁顺序，支持在数据恢复环境中以单一自动的流程滚动打补丁，无需下载。可以精心安排Oracle Database 11g Release 2的补丁。

（2）Oracle数据库机供应。

现在支持在 Sun Oracle Database Machine 上自动部署和配置 RAC。使用基于 Enterprise Manager的部署流程，可以大大简化RAC部署和配置，只有少数几个地方需要输入。

（3）RAC部署现在支持Oracle Database 11g Release 2(11.2)。

现有部署应用程序仅支持在集群机器上部署Oracle Database 10g和11gR1 RAC堆栈，新特性支持在数据库集群中部署所有RAC堆栈。Enterprise Manager的RAC部署应用程序提供了一个统一的方法，在一组集群计算机上安装、向上和向下扩展RAC堆栈。

（4）单实例数据库部署支持Oracle Database 11g Release 2 (11.2)。

可下载的动态的前置条件的检查确保您为数据库部署做好充分准备。此功能还包括新的部署流程，可帮您通过 Automated Storage Management (ASM)部署 11.2 Oracle Restart 和 Grid Infrastructure，并增强了现有的部署流程，支持Oracle Database 11gR2 (11.2)。

（5）Oracle Fusion Middleware Domain Provisioning。

新的部署流程帮您通过参考WebLogic Server Domain安装轻松克隆软件和配置。

（6）Oracle Fusion Middleware Domain Scale Up。

新的部署步骤，使您能轻松给现有 WebLogic 服务器域增强容量，可向该域添加新的托管服务器或克隆该域中已经存在的托管服务器。

5．应用性能管理

（1）Enterprise Manager Grid Control中集成了JVMDiagnostics。

新的JVM Diagnostics功能将Application Diagnostics for Java（AD4J）之前的特性与来自WebLogic Server、Domain页面以及来自Application Dependency、Performance、Request Monitoring的其他深入测量数据和相关上下文结合。凭借此特性，Java虚拟机在Enterprise Manager 11g Grid Control Release 1内被表示成了目标。此外，该功能还允许从一个集中的起始点访问测量数据，并提供了与AD4J用户界面的其他集成点。

（2）Enterprise Manager Grid Control整合了Application Dependency and Performance功能。

此功能提供了一个综合的解决方案，允许您通过连贯、统一的视图管理应用。之前独立的Composite Application Monitor and Modeler (CAMM)的功能现在集成到了 Enterprise Manager Grid Control中。用户可以从一个集中的起始点访问深入的测量数据和上下文视图（拓扑、功能视图和结构视图），轻松访问Application Dependency and Performance功能。

（3）JavaEE应用的请求监控。

Request Monitoring功能提供了对部署到WebLogic Server的Java应用的请求的端到端可见性。它会建立一个清晰的视图，让你了解在多层Java环境中流动的请求。

6．Enterprise Manager Grid Control框架

（1）增强高可用性支持。

Enterprise Manager Grid Control进行了几处增强，加速高可用配置。

通过单一配置工具（OMSCA）简化了向环境中添加更多OMS实例的流程

无需停止或重启实例即可更新OMS实例的配置属性，例如调整debug级别。

简化了软件负载均衡器的配置，处理此类任务不再需要手动编辑Oracle HTTP Server配置文件。

（2）扩展审计操作。

审计功能进行了扩展，包括了下列操作：

变更特定目标的监控设置；

创建、修改和删除监控模板；

数据库启动/关闭事件。

7．Grid Control 11g的安装部署

Oracle针对Grid Control 11g给出了完整的安装介质，作为一个全新的版本发布，不需要基于较早的版本进行升级。这样做一方面是因为Grid Control 11g体系结构上的重大变化，另一方面是出于部署的便捷性考虑的，统一完整的安装介质可以有效地降低部署安装过程中异常的出现。

在安装配置Grid Control 11g 时，同样需要提前准备好用于Grid Control的Repository 数据库，这里对数据库的版本也有具体的要求，需要Oracle 10.2.0.4 及以上版本，建议使用Oracle 11g 版本的数据库作为Repository数据库，从Grid Control 11g 版本之后，安装过程不再像10g版本中那样提供“Enterprise Manager 10g Grid Control Using a New Database”选项，即必须在创建好的数据库实例上部署 Grid Control。另外，新部署的数据库实例上确保不要存在SYSMAN用户。

以下简要介绍Grid Control 11g的安装部署过程，其中使用现有数据库，不再介绍数据库的部署。

（1）WebLogic的安装部署。

由于新版本Grid Control 是基于WebLogic 中间件技术，因此必须提前部署安装WebLogic Server，注意需要WebLogic Server 10.3.2版本，并且在安装的过程中需要选用“TYPICAL”类型，若在64位操作系统上部署安装，同时需要安装JDK。

下载WebLogic Server安装介质。

注意这里需要下载 10.3.2 版本的 WebLogic 安装介质。Linux x86 平台下载链接：http://download.oracle.com /otn/linux/middleware/11g/wls/wls1032_linux32.bin。

赋予安装介质执行权限。

[oracle@secdb2 oemgc11g]# chmod +x wls1032_linux32.bin

创建安装的目录。

[oracle@secdb2 ~]# mkdir -p /u01/app/oracle/Middleware

启动安装WebLogic Server。

注意，需要在oracle用户下部署安装，如图2-94所示。

图2-94 执行安装

Middleware home与更新注册。

以下步骤指定安装路径，确定是否绑定 My Oracle Support，如果没有My Oracle Support账户，这里也可以不提供，取消复选框，单击“Next”按钮，如图2-95所示。

图2-95 安装选项

安装类型与安装路径。

这里需要选择“Typical”类型，确定产品安装路径，如图2-96所示。

确认安装。

确认无误后，单击“Next”按钮，开始安装，如图2-97所示。

成功页面。

可以选择开启Quickstart教程。安装完毕后会看到如图2-98的右图所示的帮助页面。

图2-96 典型安装

图2-97 安装概要

图2-98 成功安装

到此，整个WebLogic的安装过程结束。

（2）Grid Control 11g的安装部署。

在部署完毕WebLogic之后，接下来可以进行Grid Control的安装，这里使用11.1.0.1版本的GC软件。

初始化安装。

下载获得软件之后，解压，再使用runInstaller 启动Grid Control 图形化安装界面，注意安装过程是在oracle用户下完成的，如图2-99所示。

MOS的支持绑定。

安装的第一个步骤体现了Grid Control 11gR1与My Oracle Support紧密结合的新特性。此处可以提供 MOS 的邮箱和密码，不提供亦可，单击“Next”按钮，确认相关提示即可。数据库、WebLogic的安装过程都有类似的步骤，如图2-100的左图所示；如果绑定MOS信息，数据库服务器又可以联网，则Oracle支持从MOS检查更新，直接获得中间补丁等，这里选择最后一个选项，暂时不进行MOS检测升级，如图2-100的右图所示。

图2-99 Linux下的安装

图2-100 MOS支持选项

安装类型选择页面。

注意这里已经不再像10g中那样可以创建数据库实例作为Repository数据库，需要使用已经事先安装好的数据库实例作为Repository数据库，如图2-101所示。

图2-101 安装类型

单击“Product Languages...”按钮可以获得语言支持方面的信息，根据具体应用进行选择。

Oracle Inventory目录与先决条件检查。

Inventory Location这里给定的目录是“/oracle/u01/app/oraInventory”，如图2-102的左图所示。

图2-102 安装目录与先决条件检查

执行先决条件检查，如果发现不满足需求的内容会给出具体的提示，如图 2-102 的右图是条件全部满足的情况。如果出现不满足先决条件的情况，一般情况下可以选择“Ignore All”选项。当然，为了完美，最好将需要调整的内容一一修改正确。

安装路径指定。

给定安装路径，这里对应的信息如下，单击“Next”按钮（此处如果设置出现问题会给出比较详细的描述，很贴心。例如，如果Middleware home location非空，会给出相应指导提示），如图2-103所示。

图2-103 定义安装位置

创建WebLogic Server的Domain。

Domain的名字是固定的“GCDomain”，UserName默认是“weblogic”，可以保持不变，如图2-104所示。这里需要的密码需要以字母开头，8位以上，包含数字。

图2-104 创建WebLogic域

Repository数据库设置。

给出所需的Repository数据库连接信息，这里选用的是在secdb1服务器上的secgc数据库实例，监听端口是默认的1521。同时提供SYS用户的密码，如图2-105的左图所示；如果对应的repository数据库中的个别参数设置不正确，这里会给出提示，按照提示对数据库进行调整即可，如图 2-105 的右图提到的几个参数都是静态参数，修改后需要重启数据库才能生效。

图2-105 数据库定义

接下来需要配置SYSMAN用户，检查数据文件信息，这里缺省给出的路径已经是正确的，如图2-106所示，不用进行调整，此处相比10g的GC进步了很多，10g中默认的路径一般是不准确的，很有可能在调整路径的过程中出现问题，而这个问题对安装过程有着致命性的伤害。

图2-106 配置档案库

OMS安全信息。

设置OMS安全选项，设定密码，后两个选项也保持默认的选中状态，如图2-107所示。

图2-107 安全选项

定义Grid Control各组件的端口。

定义各个组件所使用的端口，如果没有特殊需求这里保持默认值即可，如图2-108所示。

图2-108 自定义端口

安装前的汇总界面。

确认无误后单击“Install”按钮进入安装界面，如图2-109所示。

图2-109 安装部署

使用root用户执行脚本。

以root执行两个脚本，进行必要的权限更改等，如图2-110所示。

安装配置。

这里能做的就是等待，如果顺利的话，最终的成功界面等着你，如图2-111的右图所示。

登录Grid Control。

输入用户名“sysman”密码，单击“Login”按钮进行登录，首次登录Grid Control会进入到许可协议的确认界面，单击“IAccept”按钮同意，就可以进入强大的Grid Control管理中心，如图2-112所示。

图2-110 root的脚本执行

图2-111 完成安装

图2-112 Grid Control 11g

图2-112 Grid Control 11g（续）

整个Grid Control 11gR1安装结束。如若需要部署Agent可以建议使用Grid Control中Push方法在图形化界面中完成。

2.3.7 Grid Control小结

Oracle Enterprise Manager Grid Control 作为一款集中式图形化管理工具，提供给我们一种便捷的数据中心资源管理途径。本节从Grid Control 的体系结构入手，展示了Grid Control 的部署安装过程。通过具体实例展示了Grid Control 在物理Data Guard 创建和管理上的应用。Grid Control 功能极其强大，仅从数据库管理功能角度出发，除在Data Guard 上的应用外还可以部署和管理高级复制、对数据库运行性能进行监控分析和调整、升级数据库以及管理数据库的备份和恢复等。