oracle_RAC集群

来源：欧得旅游网

11.1 实时应用集群(RAC) ........................................................................................ 2

11.1.1 并行数据库 .......................................................................................... 3 11.1.2 Oracle RAC的体系结构........................................................................ 4 11.1.3 Oracle RAC系统的内部工作方式.......................................................... 6

2. 全局缓存资源(GCS)和全局队列服务(GES) .............................................. 7

3. 缓存熔合和资源协调 ............................................................................ 7 4. 以前图像 ............................................................................................... 8 11.1.4 SCN 处理.............................................................................................. 8

1．RAC不会崩溃吗...................................................................................... 8

2. 小结 ...................................................................................................... 9 11.1.5 RAC性能调整概述 ............................................................................10

1．RAC集群互连性能 .................................................................................10 2．互连通信量——会话等待 ..........................................................................10 11.1.6 RAC等待事件和互连统计数据 ..............................................................12

1. GES锁定阻塞者和等待者(Blocker and Waiter)....................................15 2. 熔合读写 ..............................................................................................17 11.1.7 集群互连调整—— 硬件等级....................................................................18 11.1.8 使用企业管理器网格控制调整RAC .......................................................25

数据库性能标签 .........................................................................................27

Oracle的并行服务器首先由Oracle 6.1(beta)和Oracle 6.2(有限客户版本产品)引入，但只在VAX/VMS上广泛使用。直到出现Oracle 9i，Oracle才真正有了集群产品(实时应用集群，Real Application

Clustering，RAC)，当时他们几乎全部(据说是95%)重写产品代码。在Oracle 10g中，RAC不但已经变得成熟，而且已经成为了网格计算(整个使用Oracle RAC或集群体系结构的服务器网格)的奠基石。

除了使用多个服务器来增强可用性和提高性能以外，Oracle还改进了Oracle 7.1中首先引入的并行查询技术。并行查询选项(Parallel Query Option，PQO)现在称为并行执行选项(Parallel Executions Option，PEO)，它使查询操作和DML语句可以并行执行，从而显著提升性能。每一个版本的RDBMS内核都对PEO进行了增强处理。在Oracle 10g中，绝大多数操作都可以并行执行，包括查询(并行SQL执行)、DML和DDL操作、分区内并行处理、数据复制和恢复的并行处理及数据加载；多个并行查询服务器进程甚至可以在同一个分区上执行。

本章主要内容：

● 实时应用集群(RAC)概述和体系结构 ● 调整RAC互连 ● 查找RAC等待事件

● 使用企业管理器网格控制(Enterprise Manager Grid Control)调整网格(大范围RAV实现方式)

● 并行操作的基本概念 ● 并行DML、DDL语句和操作 ● Oracle 9i的并行DML语句和操作 ● 并行处理和分区

● 操作之间和操作内部的并行处理 ● 使用并行操作生成表和索引的示例 ● 并行DML语句和示例 ● 通过V$视图监控并行操作

● 在并行操作时使用EXPLAIN PLAN和AUTOTRACE ● 调整并行执行和Oracle 9i初始化参数 ● 并行加载

● 性能比较和监控并行操作 ● 其他并行处理的注意事项

11.1 实时应用集群(RAC)

信息系统的高性能和高可用性是企业日常操作的主要需求。随着最近几十年对存储信息依赖性的不断增长，需要积累和分析大量数据。因此对高性能的数据库的需求以及保持这种数据库随时联机的认知和要求也不断增加。全局操作和电子商务的增长也非常依赖高可用性的存储数据。由于对数据库系统的不均匀和不可预知加载，许多商业团体迫切需要寻找高性能系统和合适的并行系统来支持复杂的大型数据库系统。可伸缩性是另一种重要特性。随着业务的增长，数据积累和数据交互也随之增长。越来越多的用户和应用程序开始使用数据库系统。数据库系统应当能够满足数据日益增长的需要，同时又不会降低性能、减少可伸缩性的范围。Oracle 9i引入了实时应用集群(RAC)来解决这些问题。本节没有涵盖RAC功能的所有方面，只是着重介绍了RAC的一些重要概念及其内部工作方式。本书的这一部分没有专门讨论RAC。

11.1.1 并行数据库

并行集群数据库是一种复杂的应用程序，它能够并发地从集群中的任何服务器访问同一个数据库(数据表组、索引和其他对象)，同时不会破坏数据的完整性。并行数据库通常包含多个同时访问相同物理存储器或数据的实例(节点/服务器)。依据存储访问类型，并行系统有两种实现方式：无共享模型或磁盘共享模型。

在无共享模型(也称为数据分区模型)中，每个系统都有一部分数据库，每个分区只能由所属系统读取或修改。数据分区让每个系统都能够本地缓存处理器内存中的部分数据库，而不需要跨系统通信来提供数据访问并发性和一致性控制。IBM和Microsoft的数据库都能够这样操作，以前的也能这样。而Oracle采用磁盘共享模型，这使得它们在网格计算中遥遥领先。

在磁盘共享模型中，集群的所有节点都可以访问包含数据的所有磁盘。磁盘共享体系结构需要合适的锁定管理技术来控制更新并发控件。集群中的每个节点都能直接访问保存共享数据的所有磁盘。每个节点都有局部数据库缓冲区缓存。Oracle的RAC数据库就这样运行。为了突出高可用性和高性能，Oracle很早就已经提供了Oracle并行服务器(Oracle Parallel Server，OPS)。在Oracle 9i中，它融入下一代，将OPS重新构建为实时应用集群(RAC)。RAC采用磁盘共享模型，因此也能访问所有共享磁盘，同时也广泛包含协调节点间资源的机制。磁盘共享技术在过去几年得到了快速发展，给RAC也带来了许多好处。存储区网络(SAN)技术对服务器隐藏了硬件单元、控制器、磁盘驱动和互连的许多复杂方面，它只提供存储卷(storage volume)。同样，集群中的一组服务器提供单个系统图像和计算资源。另一方面，有些新的技术公司(例如Egenera)对处理区网络(PAN)的兴趣也越来越浓厚(参见

www.egenera.com/pdf/system_data.pdf)。BladeFrame计算在增加其他节点和管理方面提供了不容置疑的可伸缩性。所有这些硬件发展只会让RAC的故事更加引人注目。

11.1.2 Oracle RAC的体系结构

从高级别上来看，RAC是访问单个Oracle数据库的多个Oracle实例(节点)。该数据库是存储在共享存储系统上的物理数据库。每个实例都在单独的主机(也称为节点或服务器)上。所有节点都通过私有互连集群，所有节点都能访问共享存储。所有节点都可以并发执行相同数据库中的事务。集群管理软件(通常由集群供应商提供)提供单个系统图像，控制节点成员，监控节点状态。从广义上说，主要组件包括：

● 节点/服务器

● 高速私有互连(将节点连接在一起) ● 集群管理器或OSD(操作系统依赖层) ● 共享磁盘或存储器 ● 集群文件系统或原始设备 ● 卷管理器 ● 公共网络

集群互连

如果一块数据在一个节点上，而用户在另一个节点需要它，Oracle使用缓存熔合通过互连(连接节点的电线，或是某种类型的开关/纤维)将数据块传递到另一个节点。并行处理依赖在多个处理器中传递消息。运行并行程序的处理器需要数据和指令，然后执行计算。每个处理器定期检查其他节点或主节点，然后计划下一步动作，或同步结果提交。这些活动依赖消息传递软件，例如满足行业标准的消息传递接口(Message Passing Interface，MPI)。

在并行数据库中，有大量消息传递和数据库块或页面要传递到另一个节点的本地缓存。大多数功能和性能取决于传输媒介或方法的效率。对于集群的整体性能和并行应用的使用而言，它变得至关重要。因为并行数据库没有对用户可以连接和访问哪些节点强加任何约束条件，所以用户可以选择连接到集群中的任何节点。不考虑应用程序的本质，OLTP或存储数据库的数据，使用互连将数据块从一个节点移动到另一个节点是一种广泛做法。集群互连提供某种类型的扩充缓存来压缩所有节点的缓存，这种作用是集群最重要的设计特性之一。通常，集群互连可用于下面这些高级功能：

● 健康、状态和消息同步 ● 分布式锁定管理器(DLM)消息 ● 访问远程文件系统 ● 应用程序专用通信量 ● 集群别名路由

通过在集群内一组节点之间分布计算而获得的高性能需要集群互连来提供高数据传输率和节点间的低等待通信。同时，互连需要能够检测和隔离错误，使用备用路径。互连的一些基本要求有：

● 短消息的低延迟

● 大量消息高速并可持续的数据率 ● 每条消息的低主CPU利用率

● 流程控制、错误控制和心跳连续性监控

● 执行控制程序直接与主机进程交互(操作系统迂回)的主机接口 ● 可测量的交换网络

许多集群供应商都创造了非常具有竞争力的技术。下面描述的许多互连产品接近SMP(symmetric multiprocessing，对称多处理)总线的延迟级别。表11-1总结了各种互连性能(此时它们仍然比较快)。

● HP内存通道内存通道互连是一种高速网络互连，它为应用程序提供集群内地址空间。

应用程序将地址空间映射到它们自己的虚拟地址空间作为8KB页面，然后就像使用正常的内存一样，从该地址空间读取或写入该地址空间。

● Myrinet Myrinet是一种高效、高性能的数据包通信和交换技术。它广泛用于Linux

集群。Myrinet软件支持大多数常见主机和操作系统。该软件是开源的。

● 可伸缩的互连(SCI) SCI是Sun公司的最佳集群互连，因为它具有高数据率和低延迟。

与使用低性能方法相比，使用SCI能够更好地伸缩强调互连的应用程序。Sun SCI实现远程共享内存(Remote Shared Memory，RSM)，一种绕过Solaris TCP/IP通信系统开销的特性。这样可以提高集群性能。

● Veritas 数据库版本/高级集群(DBE/AC)通信由LLT(低延迟传输)和GAB(组成员和原

子广播)服务组成。LLT提供内核到内核的通信，并可作为IP堆栈的性能推进器。使用LLT代替IP可以减少IP堆栈的延迟和系统开销。它现在称为存储器基础(Storage Foundation)。 ● HP HyperFabric 消息传递协议(Hyper Messaging Protocol，HMP) HP Hyper

Fabric支持IP上的标准TCP/UDP和HP所有的HMP。HyperFabric通过提供多个网络接口卡之间连接通信量的透明加载平衡，扩充TCP/UDP的可伸缩性和可读性。HMP加上操作系统迂回性能和对协议缺载的硬件支持，提供低延迟和非常低的CPU利用率。

要构建高性能的Oracle实时应用集群，选择正确的互连至关重要。选择适合环境的适当技术时要小心。可以与供应商协商以获得最新的可用硬件。见表11-1。

表11-1 一些互连产品及其性能度量标准典型的SMP总线内存通道 Myrinet SCI Gigabit Ethernet 延迟(微秒) 0.5 3 7到9 9 100 CPU系统开销(微秒) < 1 < 1 < 1 每秒的消息数(百万) > 10 > 2 硬件带宽 (MB/秒) > 500 > 100 ~ 250 ~ 50 这里的关键是，进入磁盘在毫秒范围内，而通过互连则在微秒或单个数字的毫秒范围内。

11.1.3 Oracle RAC系统的内部工作方式

在Oracle 9i RAC中，我们不再讨论DLM、PCM、非PCM、锁定监控器等。在Oracle 10g中，大多数功能被以全局缓存服务(Global Cache Service)的名义取代或实现。现在将锁定作为保留资源。以前版本中的后台进程仍然存在但发挥的作用不同。

1. RAC实例和进程

RAC是多实例数据库。多个实例同时访问同一个数据库。从RAC实例和Oracle实例之间的结构方面来看没有太多区别。除了所有普通Oracle进程(例如PMON、SMON、LGWR和DBWR)之外，还有许多专门进程，它们可以协调实例内通信，利用集群中节点之间共享的资源。因为有实例内缓冲动作和新的数据块(称为以前图像数据块，用来保持数据的完整性)，所以使用了SGA的其他资源。

● LMON 全局队列服务监控器(LMON)通过监控整个集群来管理全局队列和资源。LMON管

理实例和进程终止以及全局缓存服务的相关恢复。

● LMD 全局队列服务守护程序(Global Enqueue Service Daemon，LMD)是锁定代理进程，

它管理对全局缓存服务队列的队列管理器服务请求，从而控制对全局队列和资源的访问。LMD进程也处理死锁检测和远程队列请求。

● LMSn 这些全局缓存服务进程(LMSn)是全局缓存服务(GCS)的进程。RAC软件提供多达

10个全局缓存服务进程。LMSn的数量随着集群中节点间消息通信量数量的变化而变化。LMSn进程完成如下操作：

• 处理全局缓存服务资源的远程实例的中断。 • 为共享资源管理资源请求和跨实例调用操作。

• 构建一列无效锁定元素，在恢复过程中确认锁定元素。 • 处理全局锁定死锁检测，监控锁定转换超时。

● LCK进程管理全局队列请求和跨实例广播。

● DIAG Diagnosability Daemon监控实例的健康状况。它捕获实例进程失败的数据。

2. 全局缓存资源(GCS)和全局队列服务(GES)

GCS和GES(它们都是基本的RAC进程)发挥了关键作用。GCS确保数据的单个系统图像，即使数据被多个实例访问。GCS和GES是实时应用集群的集成组件，它们协调对共享数据库的同时访问，还协调对数据库和数据库缓存内共享资源的同时访问。GES和GCS共同维护全局资源目录(Global Resource Directory，GRD)来记录有关资源和队列的信息。GRD保存在内存中，存储在所有实例上。每个实例都管理部分目录。分布式特性是RAC容错的关键点。

协调共享缓存服务器内的并发任务称为同步。同步使用私有互连和大量消息传输。下面这些类型的资源需要同步：数据块和队列。GCS整体维护数据块模式，并负责实例间的数据块传输。LMS进程处理GCS消息，并完成大多数GCS处理。

队列是一种共享内存结构，它串行化对数据库资源的访问。它可以是局部的，也可以是全局的。Oracle在3种模型中使用队列：①空(N)模式；②共享(S)模式；③独占(X)模式。数据块是读写入和读写出缓冲器的基本结构。它通常是最经常被请求的资源。

GES维护或处理字典缓存、库缓存、事务锁定和DDL锁定的同步。换句话说，GES管理队列而不是数据块。为了同步访问数据字典缓存，需要在独占模式和单节点集群数据库中使用闩锁。在集群数据库缓存中使用全局队列。

3. 缓存熔合和资源协调

因为实时应用集群中的每个节点都有自己的内存(缓存)(不与其他节点共享)，所以RAC必须协调不同节点的缓存，同时减少可能降低性能的其他磁盘I/O。缓存熔合这种技术使用高速互连来提供集群中实例之间从缓存到缓存的数据块传输。缓存熔合功能允许脏数据块的直接内存写，从而不需要强迫磁盘写和重读(或ping)提交的数据块。然而，这不是说不会发生磁盘写。缓存取代和出现检查点时仍然需要磁盘写。缓存熔合解决了涉及实例间并发性的问题：多个节点上的并发读操作、不同节点上的并发读写、不同节点上的并发写操作。

如果数据块不一定总是在实例的缓存中，那么Oracle只从磁盘读取它们。因为推迟了数据块的写，所以它们通常包含来自多个事务的修改。只有当出现检查点时，修改过的数据块才会被写到磁盘。进一步讨论之前，我们需要熟悉Oracle 9i RAC中引入的一些概念：资源模式和资源角色。因此相同数据块可以同时存在于多个实例中，所以有两个标识符可以帮助协调这些数据块：

● 资源模式。模式有空模式、共享模式和独占模式。数据块可以用不同模式保存，取决于资源占有者是要修改数据还是只读它们。

● 资源角色。这些角色可以局部管理和全局管理。

全局资源目录(GRD)不是数据库。它是内部结构的集合，用来查找数据块的当前状态。当数据块传输出本地缓存之外，并传输到另一个实例的缓存中，就更新了GRD。在GRD中可用下面有关资源的信息：

● 数据块标识符(Data Block Identifier，DBA) ● 大多数当前版本的位置 ● 数据块的模式(N、S、X) ● 数据块的角色(局部或全局)

4. 以前图像

要保持数据的完整性，在RAC的9i版本中引入了以前图像(Past Image，PI)这个新概念。数据块的以前图像在发送数据块之前保存在内存中，作为它是不是脏数据块的标志。当失败时，GCS可以通过读PI来重构数据块的当前版本。这个PI不同于CR数据块，重构读一致性图像时需要它。数据块的CR版本表示某个时间点上数据的一致图。例如，实例A的事务A已经更新数据块5上的行2，后来实例B的事务B更新了同一个数据块5上的行6。数据块5从实例A转换为实例B。同时，在实例A上创建了数据块5的PI。

11.1.4 SCN 处理

系统变更数(System Change Number，SCN)专门确定提交的事务和它进行的变更。SCN是逻辑时戳，定义某个时间点上数据库的提交版本。Oracle给每个提交的事务分配一个唯一的SCN。

在RAC内，因为有多个实现提交的实例，所以需要在实例内维护SCN变更，但同时它们必须在集群内的所有实例之间同步。所以，SCN由全局缓存服务使用Lamport SCN生成模式、硬件时钟或专门的SCN服务器处理。SCN记录在重做日志中，以便在Oracle 9i RAC中可以同步恢复操作。 1．RAC不会崩溃吗

RAC会崩溃吗？当然会。不好的设计或选择会让它崩溃。除了数据库本身之外，还有许多组件与提供数据库服务有关。RAC可以准备就绪并运行，但客户不能实现它。在涉及的客户机和数据库服务器之间有中间网络组件。它们可能失败。破坏所有硬件的自然灾难——例如火灾、洪水和地震——可能让集群和数据库不能运行。

假设组件可能失败，RAC会提供最大限度的保护，并提供连续的数据库服务。即使丢失许多组件，RAC集群仍然可以运行。但它需要依据涉及的所有组件提供冗余设计。设计是关键字。建立两个或更多节点还不够；

双重互连、到存储单元的双路径、双存储单元、双电源、双公共网络接口等将创建健壮的实时应用集群。表11-2显示单个组件失败的结果。

表11-2 单个组件失败的结果结果组件失败的结果可行 CPU panic/崩溃节点失败，其他节点仍然有用可行内存崩溃节点失败，其他节点仍然有用可行互连双重互连，可行 (续表)

结果组件失败的结果崩溃互连交换节点不能通信可行 OS失败/冻结节点失败，其他节点仍然有用崩溃集群管理器s/w 集群冻结，所有节点失效可行 DB实例崩溃在其他节点上运行的实例提供数据库服务可行控制文件(破坏/丢失) 使用多元化控制文件可行重做日志文件多元化重做文件崩溃丢失的数据文件需要媒介恢复崩溃人为错误取决于错误类型崩溃删除的对象 DB可用，但应用程序停止崩溃 DB软件故障 DB可能在所有实例上停止只要有一个Oracle实例在集群中可用，客户应用程序就有数据访问，可以毫无疑问地执行其应用程序。 2. 小结

本节绝对没有涵盖RAC功能的所有方面。它仅仅着重讨论了RAC的一些重要概念和内部运行方式(当然，这也会改变)。理解特定RAC要求和全局共享缓存的实现方式有助于正确设计RAC及其应用。充分讨论RAC可能需要一整本书的篇幅，而接下来几节将通过调整RAC来帮您理解它。

11.1.5 RAC性能调整概述

与RAC实现方式相关的性能问题应该依次关注以下方面：

● 传统数据库调整和监控(本书的大部分内容) ● RAC集群互连性能(本章和第5章)

● 监控工作量性能(本书大部分内容，特别是第5章) ● 监控特别与RAC相关的争用(本章)

● 在调整RAC特定操作之前，应该分别调整每个实例：

• 应用调整 • 数据库调整 • 操作系统调整

● 然后开始调整RAC。正常或传统数据库监控在本书的其他章节(特别是第5章)讨论。本章讨论与RAC相关的数据库性能。单独调整每个实例之后，再关注通过集群互连通信的进程。

1．RAC集群互连性能

RAC调整最复杂的方面涉及监控和与全局服务目录(GSD)相关的进程的后续调整。与GSD相关的一组进程是GES和GCS。GSD进程通过集群互连通信。如果没有将集群互连配置为有效处理数据包，那么整个RAC实现方式的性能就会很糟糕。不管与性能相关的调整和其他方面的配置如何，结果总是这样。 2．互连通信量——会话等待

等待影响互连通信量的非空闲等待事件的会话由查询监控，该查询使用全局动态性能视图gv$session_wait列出GCS等待。在STATSPACK或AWR报表中也可以查看这些等待。监控的主要等待如表11-3所示。

表11-3 监控的主要等待等待等待描述全局缓存遇忙当会话要等待完成资源上正在进行的操作时出现的等待事件 gc缓存遇忙当进程必须等待数据块变得可用(因为另一个进程正在获得该数据块的资源)时发生的等待事件缓存遇忙全局CR 通过全局缓存一致读取(读所需的数据块)上的等待要确定经历系统上等待的会话，就要完成下面的任务。查询

V$SESSION_WAIT，确定是不是所有会话都要经历与RAC相关的等待(当前)。确定导致这些会话争用的对象。尽量调整对象或查询以减少争用。例如，查询v$session_wait，确定是不是所有会话都会经历与RAC缓存相关的等待。注意，经常使用GV$视图来显示整个集群的统计数据，而V$视图仍然会显示单个节点的统计数据。如果计划使用RAC，必须将多个节点的V$视图和查询扩充为GV$视图。本节只是帮助您查看所有组件的初级指导。本书这一部分没有专门讨论RAC，但这些内容有助于您调整RAC。

SELECT inst_id, event, p1 FILE_NUMBER, p2 BLOCK_NUMBER, WAIT_TIME FROM gv$session_wait

WHERE event IN ('buffer busy global cr', 'global cache busy',

'buffer busy global cache');

该查询的输出结果如下所示：

INST_ID EVENT FILE_NUMBER BLOCK_NUMBER WAIT_TIME ------- ----------------------------- ----------- ------------ ----------

1 global cache busy 9 150 15 2 global cache busy 9 150 10

运行该查询来确定导致这些会话争用的对象，确定与返回的每个file _number/block

_number组合的文件和数据块相对应的对象(该查询比较慢)：

SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = 9

AND 150 BETWEEN block_id AND block_id+blocks-1;

输出结果如下所示：

OWNER SEGMENT_NAME SEGMENT_TYPE ---------- -------------------- --------------- SYSTEM MOD_TEST_IND INDEX

完成如下操作，调整对象以减少应用程序争用的机率：

● 减少每个数据块的行数 ● 将数据块的大小调整得更小 ● 修改INITRANS和FREELISTS

11.1.6 RAC等待事件和互连统计数据

如果要运行RAC，下面的报表就会列出RAC事件(多个实例)。如上所述，需要为每个实例运行STATSPACK或AWR报表。对于statspack而言，您要运行需要监控的每个节点上的statspack.snap过程和

spreport.sql脚本，以便与其他实例比较。查看节点是否在有效运行的最好方法之一是，将那个节点的报表与访问相同数据库的另一个节点的报表进行比较。第5章讨论了网格控制调整。单个实例调整应该在试图调整通过集群互连通信的进程之前完成，记住这一点非常重要。换句话说，在将单个实例移动到RAC之前调整其中的系统。

下面简要列举了您可能遇到的一些顶级等待事件，第14章将更详细讨论等待事件。需要注意的顶级全局缓存(gc)等待事件包括：

● gc当前数据块遇忙当实例请求CURR数据块(要完成某个DML)和要传输的数据块正在使用时会出现这种情

况。

● gc缓存遇忙当会话必须等待资源上正在进行的操作完成时出现的等待事件，因为数据块正在使用。进程必须

等待数据块变得可用，因为另一个进程正在获取该数据块的资源。

● gc cr请求当实例等待另一个实例的缓存的数据块时发生(通过互连发送)。这种等待说明，当前实例在本地

缓存中没有找到数据块的一致性读(CR)版本。如果数据块不在远程缓存中，那么这种等待之后就是db文件连续读等待。调整SQL，它会产生大量从节点到节点的读。尽量将使用相同数据块的用户放在相同的实例上，以便数据块不会在实例间移动。有些非Oracle应用服务器会在节点间移动相同的进程，以便查找最快的节点(未意识到它们在节点间移动相同的数据块)，将这些长进程绑定到相同的节点。如果与较小缓存相关的缓慢I/O有问题，就要潜在增加本地缓存的大小。监控V$CR_BLOCK_SERVER，查看是否有像读取UNDO字段这样的问题。将P1,P2,P3=file, block, lenum的值与等待相关(查看V$LOCK_ELEMENT，查找lock_element_addr将相同值作为lenum的行)。当实例请求CR数据块以及要传输的数据块没有到达请求实例时会发生这种情况。这是最常见的情况，通常是因为SQL没有调整好，以及许多索引数据块在实例间来回移动。

图11-1显示AWR报表的RAC部分。可以看到集群中有6个实例(节点)。

您也可以看到发送和接收的数据块的数量，以及本地缓存中访问的数据块相对于磁盘或另一个实例的数量(93.1%)。您可能会猜想到，访问本地缓存中的数据块会更快，但访问另一个节点上的远程缓存几乎总是比访问磁盘快(假设有足够快的互连，同时没有互连饱和)。

下面是另一个获得会话等待信息的有价值的查询。INSTANCE_ID列出保存等待会话的实例。SID是等待会话的唯一标识符(gv$session)。p1、p2和p3列列出了事件专用信息，这些信息可能有助于调试。LAST_SQL列出等待会话执行的最后SQL。

SET NUMWIDTH 10

COLUMN STATE FORMAT a7 tru COLUMN EVENT FORMAT a25 tru COLUMN LAST_SQL FORMAT a40 tru

SELECT sw.inst_id INSTANCE_ID, sw.sid SID, sw.state STATE, sw.event EVENT,

sw.seconds_in_wait SECONDS_WAITING, sw.p1, sw.p2, sw.p3, sa.sql_text LAST_SQL

FROM gv$session_wait sw, gv$session s, gv$sqlarea sa

WHERE sw.event NOT IN ('rdbms ipc message','smon timer','pmon timer',

'SQL*Net message from client','lock manager wait for remote message', 'ges remote message', 'gcs remote message', 'gcs for action', 'client message', 'pipe get', 'null event', 'PX Idle Wait', 'single-task message', 'PX Deq: Execution Msg',

'KXFQ: kxfqdeq - normal deqeue', 'listen endpoint status', 'slave wait','wakeup time manager')

AND sw.seconds_in_wait > 0

AND (sw.inst_id = s.inst_id and sw.sid = s.sid)

AND (s.inst_id = sa.inst_id and s.sql_address = sa.address) ORDER BY seconds_waiting DESC;

图11-1 AWR报表RAC统计数据

下面的查询描述上一节中事件的参数名称：

COLUMN EVENT FORMAT a30 tru

COLUMN p1text FORMAT a25 tru COLUMN p2text FORMAT a25 tru COLUMN p3text FORMAT a25 tru

SELECT DISTINCT event EVENT, p1text, p2text, p3text FROM gv$session_wait sw

WHERE sw.event NOT IN ('rdbms ipc message','smon timer','pmon timer',

'SQL*Net message from client','lock manager wait for remote message', 'ges remote message', 'gcs remote message', 'gcs for action', 'client message','pipe get', 'null event', 'PX Idle Wait', 'single-task message', 'PX Deq: Execution Msg',

'KXFQ: kxfqdeq - normal deqeue','listen endpoint status', 'slave wait','wakeup time manager')

AND seconds_in_wait > 0 ORDER BY event;

GV$SESSION_WAIT视图的内容如表11-4所示。

表11-4 GV$SESSION_WAIT视图的内容列数据类型描述 INST_ID NUMBER RAC配置中实例的编号 SID NUMBER 会话标识符 SEQ# NUMBER 唯一确定该等待的序列号，随着每个等待递增 EVENT VARCHAR2() 会话等待的资源或事件 P1TEXT VARCHAR2() 第一个附加参数的描述 P1 NUMBER 第一个附加参数 P1RAW RAW(4) 第一个附加参数 P2TEXT VARCHAR2() 第二个附加参数的描述 P2 NUMBER 第二个附加参数 P2RAW RAW(4) 第二个附加参数 P3TEXT VARCHAR2() 第三个附加参数的描述 P3 NUMBER 第三个附加参数 P3RAW RAW(4) 第三个附加参数 WAIT_CLASS_ID NUMBER 等待类的标识符 WAIT_CLASS# NUMBER 等待类的编号 WAIT_CLASS VARCHAR2() 等待类的名称 WAIT_TIME NUMBER 非零值是会话的最后等待时间。零值表示会话正在等待 (续表)

列数据类型描述 SECONDS_IN_WAIT NUMBER 如果WAIT_TIME = 0，那么SECONDS_IN_WAIT 就是当前等待条件下花费的秒数。如果WAIT _TIME > 0，那么SECONDS_IN_WAIT 就是从最后等待开始的秒数，SECONDS_IN_WAIT – WAIT _TIME / 100是从最后等待结束开始的活动秒数 STATE VARCHAR2(19) 状态 Oracle 10g中新增了WAIT_CLASS列，它代表12个基本等待类，其

中之一是集群等待类。

技巧：

使用V$SESSION_WAIT或GV$SESSION _WAIT、Statspack或AWR报表来查找RAC等待

事件。

1. GES锁定阻塞者和等待者(Blocker and Waiter)

保存全局锁定(永久中断其他锁定)的会话对实现RAC可能存在问题，

并且它存在于许多与应用设计有关的实例中。等待锁定释放的会话会挂起，并要求调查中断的对象以便确定状态。大量保存全局锁定的会话会创造大量互连通信量，从而降低性能。

-- GES LOCK BLOCKERS:

--INSTANCE_ID The instance on which a blocking session resides

--SID Unique identifier for the session

--GRANT_LEVEL Lists how GES lock is granted to user associated w/ blocking session --REQUEST_LEVEL Lists the status the session is attempting to obtain --LOCK_STATE Lists current status the lock has obtained --SEC Lists how long this session has waited SET numwidth 10

COLUMN LOCK_STATE FORMAT a16 tru; COLUMN EVENT FORMAT a30 tru;

SELECT dl.inst_id INSTANCE_ID, s.sid SID ,p.spid SPID,

dl.resource_name1 RESOURCE_NAME,

decode(substr(dl.grant_level,1,8),'KJUSERNL','Null','KJUSERCR','Row-S (SS)', 'KJUSERCW','Row-X (SX)','KJUSERPR','Share','KJUSERPW','S/Row-X (SSX)', 'KJUSEREX','Exclusive',request_level) AS GRANT_LEVEL,

decode(substr(dl.request_level,1,8),'KJUSERNL','Null','KJUSERCR','Row-S (SS)', 'KJUSERCW','Row-X (SX)','KJUSERPR','Share','KJUSERPW','S/Row-X (SSX)', 'KJUSEREX','Exclusive',request_level) AS REQUEST_LEVEL,

decode(substr(dl.state,1,8),'KJUSERGR','Granted','KJUSEROP','Opening', 'KJUSERCA','Canceling','KJUSERCV','Converting') AS LOCK_STATE, s.sid, sw.event EVENT, sw.seconds_in_wait SEC

FROM gv$ges_enqueue dl, gv$process p, gv$session s, gv$session_wait sw WHERE blocker = 1

AND (dl.inst_id = p.inst_id and dl.pid = p.spid) AND (p.inst_id = s.inst_id and p.addr = s.paddr) AND (s.inst_id = sw.inst_id and s.sid = sw.sid) ORDER BY sw.seconds_in_wait DESC; GES LOCK WAITERS:

--INSTANCE_ID The instance on which a blocking session resides --SID Unique identifier for the session

--SEC Lists how long this session has waited SET numwidth 10

COLUMN LOCK_STATE FORMAT a16 tru; COLUMN EVENT FORMAT a30 tru;

SELECT dl.inst_id INSTANCE_ID, s.sid SID, p.spid SPID,

dl.resource_name1 RESOURCE_NAME,

decode(substr(dl.state,1,8),'KJUSERGR','Granted','KJUSEROP','Opening', 'KJUSERCA','Canceling','KJUSERCV','Converting') AS LOCK_STATE, s.sid,sw.event EVENT, sw.seconds_in_wait SEC

FROM gv$ges_enqueue dl, gv$process p,gv$session s,gv$session_wait sw WHERE blocked = 1

AND (dl.inst_id = p.inst_id and dl.pid = p.spid) AND (p.inst_id = s.inst_id and p.addr = s.paddr) AND (s.inst_id = sw.inst_id and s.sid = sw.sid) ORDER BY sw.seconds_in_wait DESC;

2. 熔合读写

当需要将另一个实例以前改变的数据块写到磁盘以响应检查点或缓存老化时，就会出现熔合写。出现这种情况时，Oracle会发送消息通知另一个实例：会执行熔合写将数据块移动到磁盘。熔合写不需要另外写到磁盘，它们是一个实例产生的所有物理写的子集。DBWR熔合写/物理写的比率显示Oracle管理的写与熔合写的比例。下面这个查询确定缓存熔合写操作的比率：

SELECT A.inst_id \"Instance\

A.VALUE/B.VALUE \"Cache Fusion Writes Ratio\"

FROM GV$SYSSTAT A, GV$SYSSTAT B WHERE A.name='DBWR fusion writes'

AND B.name='physical writes' AND B.inst_id=a.inst_id ORDER BY A.INST_ID;

以下是示例输出：

Instance Cache Fusion Writes Ratio --------- -------------------------

1 .216290958 2 .131862042

缓存熔合写操作比率的大值表示：

● 缓存不够大 ● 检查点不够

● 根据缓存取代或检查点写的大量缓冲器

11.1.7 集群互连调整—— 硬件等级

集群互连调整是集群配置的重要方面。Oracle依赖集群互连在实例间传输数据。专门私有网络用于互连非常重要。下面的查询有助于确定实例是否正确注册了网络地址：

SQL> SELECT * FROM GV$CLUSTER_INTERCONNECTS;

INST_ID NAME IP_ADDRESS IS_ SOURCE

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

1 eth1 10.16.0.168 NO Oracle Cluster Repository 2 eth1 10.16.0.170 NO Oracle Cluster Repository

SOURCE列表示互连与OCR(Oracle集群仓库)集成。该列可能的值有：

● Oracle集群仓库使用OCR配置的互连信息。

● 集群互连使用参数CLUSTER_INTERCONNECT配置的互连信息。

● 操作系立配置第三方集群管理器，Oracle集群件只是Oracle RDBMS和第三方

集群管理器之间的纽带。

对集群互连的重要测试应该从硬件配置测试开始。确定传输率对实际实现数据包大小的测试应该确保安装了所有说明。从Oracle数据库10g版本2开始，不支持在配置两个节点间的互连时使用交叉电缆。因此需要交换作为参与集群的节点之间的纽带。确定系统的性能时，必须于互连的速度确定交换的速度，以确定交换和互连的实际延迟。

集群互连的速度完全依赖硬件供应商(见表11-1)和分层的操作系统。当前版本的Oracle依赖操作系统和在集群互连间发送信息数据包的硬件。例如，SUN 4800之间支持的一种集群互连是用户自带寻址信息协议(User Datagram Protocol，UDP)。然而，这种特定版本互连协议上的Solaris在数据传输方面有K数据包大小的操作系统。要通过该互连协议传输相当于256K的数据，就要在4个往返上采用这种配置。在具有大量互连通信量的高级事务系统上，这可能会导致严重的性能问题。在最初硬件和操作系统级别测试确认互连的数据包大小之后，后续测试会使用缓存到缓存数据传输或缓存熔合技术通过Oracle数据库完成，以确保没有任何严重的附加延迟。随后的查询提供系统上一致数据块请求的平均延迟。这些视图中的数据是从上次启动Oracle实例以来的累积数字。这些视图中的数据没有反映互连的实际性能，也没有显示数据传输中延迟的真实情况。要获得更现实的性能情况，最好再次启动所有Oracle实例和测试。要获得良好的性能，重要的是集群互连之间的延迟要尽可能低。集群互连上延迟可能由下列原因造成：

● 运行队列中有大量进程等待CPU或计划延时

● 平台专用操作系统参数设置影响IPC缓冲或进程安排 ● 缓慢、遇忙或不完善的互连

Oracle建议一致数据块请求的平均延迟通常不应该超过15毫秒(取决于系统配置和量)。通过互连发送许多数据块时，它实际上很高(特别是进入磁盘通常这样)。对于high-volume系统而言，它应该在单个数字的毫秒到微秒的范围。一致数据块请求的平均延迟是一致读取请求往返——从请求实例到保存实例再返回请求实例——的平均延迟。

set numwidth 20

column \"AVG CR BLOCK RECEIVE TIME (ms)\" format 9999999.9 select b1.inst_id, b2.value \"GCS CR BLOCKS RECEIVED\

b1.value \"GCS CR BLOCK RECEIVE TIME\

((b1.value / b2.value) * 10) \"AVG CR BLOCK RECEIVE TIME (ms)\"

from gv$sysstat b1, gv$sysstat b2

where b1.name = 'gc cr block receive time' and b2.name = 'gc cr blocks received' and b1.inst_id = b2.inst_id;

INST_ID GCS CR BLOCKS RECEIVED GCS CR BLOCK RECEIVE TIME AVG CR BLOCK RECIVE TIME (ms) ------ ------------------- -------------------- ------------------------

1 2758 112394 443.78 2 1346 1457 10.8

2 rows selected.

在前面的输出结果中，注意AVG CR BLOCK RECEIVE TIME是443.78毫秒；当Oracle推荐的预期平均延迟不应该超过15毫秒时，它已经非常高。如果CPU的空闲时间有限，而且系统通常处理长时间查询，那么就可能出现高值。然而，使用用户模式IPC时，平均延迟可能低于1毫秒。DB_MULTI_BLOCK_READ_COUNT参数的高值也可能影响延迟。这是因为请求进程可以依据该参数的设置给数据块发出多个请求。这样请求进程可能必须等待更长时间。这种高延迟要求进一步调查集群互连配置，必须在操作系统级别执行这些测试。当互连有这种高延迟时，另一个好的测试是在操作系统级别通过检查实际连接时间来执行测试。这有助于确定操作系统级别有没有问题。毕竟，RAC环境内的数据传输不会产生性能问题。

除了能够在操作系统级别完成的基本数据包传输测试之外，还可以执行其他检查和测试，以确保正确配置集群互连。在参与集群的节点之间有冗余的私有高速互连。实现网络接口卡(network interface card，NIC)连接或配对有助于互连负载平衡和某个互连失败时的故障恢复。用户网络连接不会影响集群互连通信量，也就是说它们彼此分离。

在操作系统级别，netstat和ifconfig命令显示与网络相关的数据结构。下面的输出结果(来自netstat-i)显示配置有4个网络适配器，并且实现了NIC配对：

[oracle@oradb3 oracle]$ netstat –i Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

bond0 1500 0 3209 0 0 0 4028 0 0 0 BMmRU

bond0:1 1500 0 4390 0 0 0 37 0 0 0 BMmRU bond1 1500 0 7880 0 0 0 10874 0 0 0 BMmRU eth0 1500 0 1662 0 0 0 2006 0 0 0 BMsRU eth1 1500 0 17 0 0 0 2022 0 0 0 BMsRU eth2 1500 0 4390 0 0 0 37 0 0 0 BMRU eth3 1500 0 3490 0 0 0 4437 0 0 0 BMRU lo 136 0 7491 0 0 0 7491 0 0 0 LRU

Iface列中的值有如下含义：

● bond0 它是使用连接功能创建的公共互连(连接eth0和eth1)。 ● bond0:1 它是分配给bond0的VIP(虚拟IP)。

● bond1 它是使用连接功能创建的私有互连(连接eth2和eth3)。

● eth0和eth1 这些是物理公共接口，它们连接/配对在一起((bond0)。 ● eth2和eth3 这些是物理私有接口，它们连接/配对在一起((bond1)。

● lo 这是回送，即输出结果也说明配置了回送选项。使用ORADEBUG命令可以验证Oracle是否在使用回送选项，

这将在本节稍后讨论。回送IP的使用取决于每个节点上定义的路由表的完整性。修改路由表可能导致互连不能运行。

前面netstat的输出结果还包括MTU(最大传输单元)，它设置为1500字节(这是UDP的标准设置)。MTU定义不包括数据链标题。然而，数据包大小计算包括数据链标题。各种工具显示的最大数据包大小等于MTU加上数据链标题的长度。要获得互连的最大好处，应该将MTU配置为支持的最高可能值。例如，使用大型架构将它设置为9K，这有助于提高互连带宽和数据传输。

除了能够在操作系统级别完成的基本数据包传输测试之外，还可以执行其他检查和测试，以确保集群互连配置正确。还要从Oracle实例执行检查以确保互连协议配置正确。如果将下面的命令作为用户“SYS”执行，就会在用户转储目标目录中生成跟踪文件，该目录包含某些属于UDP /IPC配置的诊断信息。(关于DEBUG功能的更多信息请参考第13章)。在阅读有关它的Oracle文档之前请不要使用它。

SQL> ORADEBUG SETMYPID

ORADEBUG IPC EXIT

下面的代码摘自附属于互连协议的跟踪文件。输出结果证明集群互连正用于实例到实例的消息传输。 SSKGXPT 0x3671e28 flags SSKGXPT_READPENDING info for network 0 socket no 9 IP 172.16.193.1 UDP 59084 sflags SSKGXPT_WRITESSKGXPT_UP

info for network 1

socket no 0 IP 0.0.0.0 UDP 0 sflags SSKGXPT_DOWN

context timestamp 0x4402d

no ports

前面的输出结果摘自Sun 4800，它显示了IP地址，同时说明使用的协议是UDP。在某些操作系统上(例如Tru)，跟踪输出结果不显示集群互连信息。下面操作系统级别的NDD Unix命令会证明实际UDP大小的定义。下面的输出结果出自SUN环境：

oradb1:RAC1:oracle # ndd -get /dev/udp

name to get/set ? udp_xmit_hiwat value ? length ? 8192

name to get/set ? udp_recv_hiwat value ? length ? 8192

输出结果显示UDP被配置为8K数据包。将这种查找应用于从Oracle视图收集的数据，这样可以显示在集群互连间传输的所有数据块会执行14050次往返(112394/8 =14050)。如果将它设置为K，那么往返的次数会大大减少(112394/ = 1756)。

影响互连通信量的另一个参数是DB_FILE_MULTIBLOCK_READ_ COUNT。这个参数说明每次从磁盘读取的数据块数量。数据需要通过集群互连传输时，该参数确定读取传输过程中每个实例从另一个实例请求的数据块的大小。应该按照互连延迟和硬件供应商定义的数据包大小，并且在考虑操作系统(例如，SUN UDP最大设置只有K)之后确定该参数的大小。下面的内核参数定义udp参数设置：

● udp_recv_hiwat ● udp_xmit_hiwat

将这些参数设置为65536会将udp缓冲大小增加为K。

另一个参数CLUSTER_INTERCONNECTS提供有关其他集群互连可用性的Oracle信息，其他这些集群互连可用于通过集群互连的缓存熔合活动。该参数用优先集群通信量网络重写操作系统级别的默认互连设置。该参数通过减少这种延迟，的确能为关注高互连延迟的系统提供优势，但配置这个参数会影响互连高可用性的特性。换句话说，通常不明显的互连失败可能导致Oracle集群失败，因为Oracle仍然试图访问网络接口。

资源可用性

任何计算机、节点上，或者提供给Oracle实例的可用资源都是有限的，也就是说它们不是无限可用的，如果系统上的进程需要它们，这些资源也许不能立即可用。任何系统上的可用资源数量都有物理。例如，处理器资源受系统上可用CPU数量的，内存或缓存区的数量受系统上可用物理内存的。对于Oracle进程而言，它进一步受到分配给SGA的内存的实际数量的。在SGA内，从共享池区再次预先分配共享池、缓冲区缓存等。这些都是正常的单实例配置使用的内存分配方式。

在RAC环境中，没有参数分配任何全局特定资源，例如全局缓存大小或全局共享池区。Oracle从SGA中分配部分可用资源用于全局活动。可以使用GV$RESOURCE_LIMIT视图监控全局资源的可用性。例如，下面的查询显示可用于全局活动的资源的当前数量。在下面的输出结果中，资源的可用性受“LIMIT_VALUE”列的，当这些资源偏低时，增加限度的方法是增加SHARED_POOL_SIZE。

下面查询生成的输出结果包含资源的当前利用率：

SELECT RESOURCE_NAME, CURRENT_UTILIZATION CU, MAX_UTILIZATION MU,

INITIAL_ALLOCATION IA, LIMIT_VALUE LV

FROM GV$RESOURCE_LIMIT WHERE MAX_UTILIZATION > 0 ORDER BY INST_ID, RESOURCE_NAME;

RESOURCE_NAME CU MU IA LV --------------------- ---------- ---------- ---------- ----------

cmtcallbk 0 1 187 UNLIMITED dml_locks 2 59 748 UNLIMITED enqueue_locks 19 27 2261 2261 enqueue_resources 22 45 968 UNLIMITED gcs_shadows 2259 2579 18245 18245 ges_big_msgs 27 28 9 UNLIMITED ges_cache_ress 338 1240 0 UNLIMITED ges_procs 35 36 320 320 ges_reg_msgs 44 81 1050 UNLIMITED max_rollback_segments 11 11 187 65535 max_shared_servers 1 1 UNLIMITED UNLIMITED processes 31 34 150 150 sessions 37 40 170 170 sort_segment_locks 0 1 UNLIMITED UNLIMITED transactions 2 4 187 UNLIMITED (truncated output)

SHARED_POOL_SIZE增加为10MB时，全局资源分配也会改变为下列新值：

gcs_resources 2553 2553 19351 19351 gcs_shadows 1279 1279 19351 19351

规则是，MAX_UTILIZATION (MU)接近LIMIT_VALUE (LV)并且长时间将常量保持为这个值时，就考虑增加SGA。

Oracle也在内存中保持几个全局区，它们与Oracle紧密相关。分配大小是这些区的常量，而它们也包含在参数SHARED_POOL_SIZE中。例如，下面的查询显示专门为RAC环境保持的内存区：

SELECT *

FROM v$sgastat where name like 'g%';

POOL NAME BYTES ----------- -------------------------- ---------- shared pool ges enqueue cur. usage pe 16 shared pool ges deadlock xid hash tab 11036 shared pool ges recovery domain table 108 shared pool ges process hash table 9504 shared pool gcs res hash bucket 65536 shared pool gcs close obj 4104 shared pool ges lmd process descripto 2684 shared pool gcs scan queue array 216 shared pool ges process array 281600 shared pool gcs resources 7379392 shared pool grplut_kfgsg 256 shared pool generic process shared st 448 shared pool ges enqueue max. usage pe 16 shared pool ges reserved msg buffers 27860 shared pool gcs mastership buckets 4608 shared pool ges scan queue array 108 shared pool groups_kfgbsg 4096 shared pool gcs shadows 5241536 shared pool gcs resource freelist dyn 32

shared pool gcs shadow locks dyn seg 32 shared pool ges resource hash seq tab 16384 shared pool gcs I/O statistics struct 32 shared pool ges deadlock xid freelist 7040 shared pool gcs resource freelist arr 272 shared pool ges regular msg buffers 609004 shared pool gcs opaque in 4028 shared pool grptab_kfgsg 3592 shared pool ges enqueues 3870184 shared pool ges res mastership bucket 3072 shared pool ges resource hash table 442368 shared pool ges ipc instance maps 384 shared pool ges big msg buffers 3979396 shared pool gcs res latch table 15360 shared pool gcs affinity 4108 shared pool ges resource 3105300 shared pool gcs shadow locks freelist 272 shared pool ges enqueue multiple free 400 shared pool ges lms process descripto 5368 shared pool ges shared global area 22724 shared pool gcs commit sga state 67596 41 rows selected.

11.1.8 使用企业管理器网格控制调整RAC

Oracle企业管理器网格控制、AWR报表和STATSPACK报表都是确定互连延迟良好的信息来源。最好的RAC调整工具是Oracle企业管理器网格控制。虽然在第3章已经详细讨论过它，但这里互连部分也值得研究。要查找集群的数据库(或RAC/网格数据库)，我们必须进入目标/所有目标(Targets/All Targets)屏幕，再单击集群数据库查看。本示例中，单击“ioug”集群数据库显示该集群数据库的监控信息(如图11-2所示)。该屏幕显示有全部6个实例。有一些CPU(约25%)正在被使用，还有不到20个活动会话。

图11-2 “ioug”6个实例集群数据库的性能信息

该页面的一个非常重要的部分是诊断小结(Diagnostic Summary)部分，它在本示例中显示有4个互连查找。

技巧：

使用企业管理器网格控制查找互连问题。

在同一个屏幕的底部，可以看到集群数据库的一些最有用的链接和信息，如图11-3所示，其中包括所有与集群数据库相关的实例。这里还显示了6个实例(从ioug_ioug1到ioug_

ioug6)，这样就很容易通过单击实例来查看各个实例的信息。

图11-3 “ioug”6个实例集群数据库的性能信息(底部)

单击某个实例(本示例中是ioug_ioug1)，就会显示该实例的主要信息屏幕，如图11-4所示。在图11-4的右上角还有一个下拉菜单，它让您能够快速切换到另一个数据库实例。

图11-4 “ioug1”实例的性能信息

数据库性能标签

单击性能标签会显示该集群的详细图表和一个主屏，它可以用来调整互连。图11-5显示了该屏幕的上半部分。单击单个图表会显示给定性能度量更详细的图表。移动到屏幕中间会显示其他图表。

技巧：

OEM内的数据库或集群性能屏幕是查找系统中性能问题的最快方法。

图11-5 集群数据库性能

图11-6显示了其他许多性能链接。这些链接包括数据库锁定、顶级会话(Top Session)、顶级客户(Top Consumer)、集群缓存一致(Cluster Cache Conherence)和顶级段(Top Segment)。每个链接都可用来研究具体问题。

单击图11-5中所示的Cluster Host Load Average图表，就会显示该图的更大版本，列出的每个节点都有颜色。在图11-7所示的示例中，该图表显示了ioug集群中的4个实例(在4个物理节点上)。实例是ioug3、ioug4、ioug5和ioug6，实例占据的物理节点是atlmdi3、atlmdi4、atlmdi5和atlmdi7。

单击图11-5中的第2个图表会显示互连问题。全局缓存数据块访问延迟和传输与从一个实例向另一个实例发送数据块有关。单击集群数据库性能(Cluster Database Performance)屏幕(如图11-8所示)上的集群缓存一致(Cluster Cache Coherency)链接也会显示这个屏幕。在图11-8中，数据块传输的数量在上午11:10急剧增加。所有访问延迟超过20毫秒的数据块都需要进一步调查。修复这个问题涉及调整导致大量数据块读取或传输的查询，获得更快的互连，排除放慢传输的所有锁定(附属于数据块的一个实例)或使用公共(而不是私有)互连。

图11-6 集群数据库其他性能链接

图11-7 集群数据库性能加载平均值

图11-8 集群缓存一致性

在图11-5中的第3个图表中，活动会话图表显示了大量集群等待。单击图表右边的Cluster链接(但是在实例级别)，就会显示所有集群等待的详细图表，如图11-9所示。我们可以看到显示时许多与该图表相关的全局缓存(gc)类型的等待。在图表下方，我们可以看到正在运行的实际Top SQL查询以及运行这些查询的用户的顶级会话(Top Session)。屏幕只显示了集群等待的Top SQL和顶级会话。这是一个彩色屏幕，用不同颜色显示每个等待，以便让调整变得更加直观。

技巧：

可以研究企业管理器上的特定全局缓存等待事件。

单击图表右边gc current block busy等待上的链接，就会立即转换为该等待的柱状图，通过它查看这些等待是许多短等待还是较少的长等待。这里有些等待很短(1~2毫秒)，有些等待较长(32毫秒及以上)，如图11-10中的柱状图所示。

注意：

第5章更详细讨论了使用企业管理器网格控制的方法，那里的图也比这里多。第5

章还介绍了查找导致问题的特定SQL语句的方法，以及使用企业管理器网格控制调

整特性调整它们的方法。

图11-9 活动会话等待——集群

图11-10 gc current block busy等待的等待事件柱状图本文内容搜集于互联网，如有侵犯你的权利，请来信告知。

本站只提供部分章节试读，版权为作者和出版社所有，请购买正版书籍。看过此文的读者还看过：

目录 -《Oracle Database10g 性能调整与优化》

前言 -《Oracle Database10g 性能调整与优化》作者简介 -《Oracle Database10g 性能调整与优化》宣传语 -《Oracle Database10g 性能调整与优化》来自全球的赞誉

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文