Ask Maclean

Oracle RAC 性能指标参考

本文的第二部分涵盖了常用的观点描述，等待事件，init.ora中的参数和跟踪事件。 RAC统计资料的完整列表，并在等待V $视图中使用的事件，可以在Oracle文件在线公众RAC性能组文件夹中的子文件夹RAC10g中找到。

 

https://www.askmac.cn/archives/oracle-rac-性能指标参考.html

 

1会话和系统事件统计

当它需要一些时间来获得，因为总的路径长度和等待时间的请求的资源，流程睡眠，以避免纺纱的时间不定周期。一旦该过程决定等待，通常是通过调用某种形式的kslwait（）函数，它唤醒任何指定一个定时器值期满（“超时”）或当它发生时正在等待该事件并且处理过帐后。

 

等待事件记录，并在汇总意见:

  • V$SESSION_EVENT
  • V$SYSTEM_EVENT
  • V$SESSION_WAIT
  • V$ACTIVE_SESSION_HISTORY
  • V$SESSION_WAIT_HISTORY

 

 

其中前两个是等待时间，超时聚合和等待的次数为特定事件而其余允许实时等待会话，包括最近的事件的历史等待的监测。

 

个别事件由他们的名字和他们承担的参数，例如脱颖而出对于大多数的全局高速缓存（GC）的等待事件，这些参数包括文件编号，块号，块级和接入方式处置，如举行，并要求模式。

 

调试响应时间的性能问题时提出，并聚集在上述观点的事件等待时间是非常有用的。请注意，时间等是累积的，并具有最高得分事件不一定是一个问题。但是，如果可用的CPU电源不能刷爆，或一个应用程序的响应时间过高，顶端等待事件提供有价值的性能诊断。

 

 

1.1介绍全局缓存事件在10g中

在数据块被跨分布式高速缓存共享用于读取和写入一个多实例的数据库系统，远程高速缓存存取将消耗显著CPU和等待时间。事件的特定组跟踪的等待时间缓存到缓存的传输。

 

通常，会话等待本地高速缓存未命中后的电流或CR缓冲器的请求的完成，并且数据块的到达或由全球缓存服务访问的授予完成等待。

 

在Oracle9i中，等待事件的用户可读描述是在接入模式的改变来表示（如全局缓存空至x）。然而，关键的是要注意的一个事实，即大多数块请求可具有各种的结果，这取决于应用程序的数据访问特性和全局共享工作集。因此，流程等当前或CR请求既可以接收块或将被授予全球的访问权限。有些请求甚至可能导致失败，这样一想就知道是多少时间浪费在他们身上。

 

所有这些事件都等待在缓存层和由前台进程。某些后台进程（LGWR，DBWR，LMD和LMS）将永远不会等待任何全局高速缓存事件。事件提供参数P1，P2和P3，其中

  • P1表示文件编号，
  • P2上的块数，
  • P3被主要用于携带该块类和为当前块保持并要求全局访问模式，而对于CR块，只有块类设置。

在当前块请求的情况下，表示P3字节的最显著字节包含所请求的模式并保持，所述至少显著字节包含块类的模式。 P3可以用下面的SQL语句进行解码：

 

select decode(trunc(bitand(&&p3,16777215)/65535),

0, ‘Null’, 1, ‘Share’, 2, ‘Exclusive’, 3,’Recovery’) MODE_FROM,

decode(trunc(&p3/16777216),

0, ‘Null’, 1, ‘Share’, 2, ‘Exclusive’, 3,’Recovery’) MODE_TO,

decode(bitand(&p3,65535),

1, ‘Data’, 4, ‘Seg Header’, 6,’Freelist’, 7,’Ext map’,

8,’1st lvl bmb’, 9,’2nd lvl bmb’, 10,’3rd lvl bmb’,

14,’Pre-warm’,

decode(trunc(bitand(&p3,65535)/15),

0,’Other’,

decode(mod(&p3,2),0,’Undo block’,’Undo Header’))) CLASS

from dual

/

如果块的请求是一个CR缓冲，然后只类被使用，因此，有可能区分，导致一个当前块的CR请求。

 

由参数提供的信息可以使用V $ SESSION_WAIT V $ ACTIVE_SESSION_HISTORY，V $ SESSION_WAIT_HISTORY和会议与活动跟踪10046更详细的面向会话的监控非常有用的工具。

在10g中，该系统的统计数据，动态性能视图和会话等待事件的几个变化，以提供更快，更清晰的诊断进行的。等待事件模型，以便允许适当的介绍和高速缓存合并请求的结果分级得到延长。

 

为了实现这一点：

 

  • 占位符的链接地址信息和事件的概念被创造和内核服务层新功能的支持，
  • 每个缓存融合信息返回给请求者携带GCS性能提示往返排位赛期间的主要处理时间
  • 用户可读的事件名称已更改为准确反映高速缓存融合消息传递架构
  • 添加更具体的普通等待事件

 

为了方便钻和更快的问题隔离，

 

  • 引入包含等待GC事件时间的总和集群等待类
  • 一个集群等待时间列被添加到V $ SQLAREA
  • 视图V$ INSTANCE_CACHE_TRANSFER（V $ INSTANCE_CACHE_TRANSFER”），即通过与GCS性能提示，块类和高速缓存融合请求的完成相关的建立是为了分类和在多个维度，表征高速缓存融合活动实例

得到了加强•段统计数据包括全球忙碌的缓冲区。

 

综上所述，修改和添加到系统统计信息，会话等待事件和动态性能视图提高诊断能力由

 

  • 代表真正的高速缓存融合用户招致的开销
  • 确定SQL高等待时间进行远程数据访问
  • 包括块传输数据块类
  • 传递其循不同层次和阶段的要求GCS性能的提示。

 

为了提高效率和理由，以避免系统统计和会话事件的信息内容重叠，几个系统的统计数据被删除。这些统计数据将在一个特殊的部分上市。

 

 

1.2事件的技术概述等待模式在10g中

 

 

等待事件的命名在10g中约定已经从基于并发到一个消息传递或基于缓存融合范式改变。在最常见的情况下，命名包括

 

  • 标识符GC
  • 缓冲区类型（电流/ CR）
  • 完成消息的类型（块/批）
  • 性能提示（移位#of网络跃/忙/拥堵）

 

为了包括事件名称的完成状态和GCS性能提示，修正事件的概念实现的。可以使用一个叫占位更普遍的等待事件，同时要求在飞行和固定到一个真实的事件当它完成。在完成时间，已知是否接收一个块或授权消息。在完成处理程序中，GCS提示进行评估和等待时间，数量和超时都归结到一个特定的事件。因此没有重复计算时，会出现修正程序也将复位占位符。在内核服务层的新功能被设计出来以处理来自占位交换机完成事件，即kslwt_fxup（）

 

因此，一个占位符事件仅代表是在请求一个块时已知的信息，即缓冲模式，举办了接入方式和请求的访问模式。接入模式转变不是名称的一部分，但组合中的P3。占位符事件在性质短暂的存在，直到一个请求已完成。

 

应该明确的是普通单片等待事件都在使用适当的地方，也就是当一个人不感兴趣的请求的实际结果

在块和grant标题1.2.1 GCS性能提示

 

为了识别处理gc的请求时花费的主要时间，GCS提示被传递与每个块或授权消息。它们是被运到请求者的真实或伪造缓冲报头的一部分，而在2位被实施。KCL和KJB层提供基于其可能会延迟请求处理过程中显著情况下，这些提示。例如，日志同步，块或多个网络跃点的管理延迟可以支配接收块的时间。

 

足够的信息进行维护和传来传去，这样缓存下方排队延迟和阻塞条件可占。由此产生的GCS暗示在缓存及以下用于限定在等待事件所花费的实时性和区分以下情况

 

  • 消息路径长度或消息跃点，即接收到的块是否是一个双向或三向消息的结果
  • 延误，由于在韧皮LMS中，使一个块“忙”处理发现的特殊条件下，例如日志同步，块推迟，未决写
  • 它是由LMS处理回升之前，内部队列请求花费的时间。

 

在内部，GCS提示被定义为

 

  • KCL_WAIT_2HOP,
  • KCL_WAIT_3HOP,
  • KCL_WAIT_LMS,
  • KCL_WAIT_BUSY

https://www.askmac.cn/archives/oracle-rac-性能指标参考.html ‎

在10g中，对事件和统计命名全局缓存中的所有引用都被简称为GC和convenienc用于构建事件，如GC[current/ CR]块[23]-way，GC[current/ CR]块[忙/拥挤]等下表中总结了报考条件时，提示用于：

 

GCS提示说明

KCL_WAIT_2HOP•#Instances=2：块/补助，后两跳获得

  • #Instances>2块/赠款从主发送或主是局部的，持有人发送

KCL_WAIT_3HOP•#Instances>2：请求者，硕士及持有人在不同的情况下，因此该消息的路径长度requestor->大师 – >持有人>请求者

KCL_WAIT_BUSY BAST当前块的过程中：

  • 日志块同步（〜5-10ms）
  • 块具有本地服务员（延迟：30毫秒〜）
  • 独家访问被阻止（多的读者）
  • 阻止正处于复苏
  • 块被驱逐
  • 正在进行克隆写
  • 从SHR/ PI缓冲拆分失败，没有可用的缓冲区（S韧皮）

 

在CR处理：

  • 日志块同步

KCL_WAIT_LMS LMS队列时间，即通过等待它已由ksxp递送到LMS处理之后要被处理的请求所花费的时间是>1毫秒

表5：GCS提示

 

表5：GCS提示

 

在平原，解释方面，提示特征

 

  • 消息往返和处理时间不平凡的延误2路和3路的消息
  • 引起争的处理主要延迟（“忙”）
  • 引起内部排队时，即当LMS无法与消息到达率跟上或LMS必须与其他进程的CPU竞争的处理显着延迟。

 

和基于其上的事件可以因此通过快速诊断解释相关联。

 

注意，对于特征为“忙”（KCL_WAIT_BUSY）或“拥挤”（KCL_WAIT_LMS）的消息，但事实上，它是一个2-或3-方式一跳的结果不考虑和是无关紧要的，因为服务延迟韧皮加工过程中产生的将是占主导地位的，因为应当从上面介绍的表格清晰

 

1.3 GC事件的说明

在以下章节中，个体GC等待事件进行说明。我们提供了一个简短的说明，引用动态性能视图或走线等统计数据，包括和一些诊断解释，适用情况。此外，假定读者基本上熟悉缓存融合协议和消息处理流程。

 

对于意见和痕迹GC事件的可视性，请参考第二部分，章节“1.4能见度事件”。

 

除非另有说明

 

P1：文件＃

P2：块＃

P3：模式要求|模式举行|块级

 

的符号来表示在低于所使用的请求的不同阶段所花的时间是：

 

T（S）=花费的时间由请求者发送请求，主要是CPU周期

T（R）=花费的时间由请求者接收请求，主要是CPU周期

M =时间发送一个小的消息（<200字节）的物理网络上

M =时间发送的物理网络上的数据块（DB_BLOCK_SIZE）

Ma=处理时间，包括发送，接收和处理，主要是CPU周期

Himm =时间立即处理BAST在持有人的实例，主要是CPU周期

Hbusy =时间为BAST处理，它包括一个上下文切换，IO，大多经过

m（S< – >Ma）=请求和大师之间的小消息

M（Ma< – > H）=大师和持有人之间的小消息

ns=共享持有人数量

 

1.3.1 GC current/ CR请求

 

这些等待事件有关只有在为CR或当前缓冲区一个GC请求正在进行。他们充当占位符，直到请求完成。

 

1.3.2 GC[current CR][23]-way

 

请求当前或CR块和后2或3的网络跳接收。请求被立即处理，即它不是忙或拥挤。

 

请求往返时间可以受以下因素影响延迟：

 

2路：

T（S）+ M + Himm+ M + T（R）

 

3路：

T（S）+ M +Ma+ Himm+ M + T（R）

 

诊断：这些等待时间通常是受影响最严重

 

  • 网络传输速度和带宽
  • IPC协议的代码路径长度
  • 系统负载：CPU利用率， #of流程，运行队列长度

 

 

如果这些事件消耗了大量的时间，额外的检查应包括

 

  • 对当前GC和GC CR块平均潜伏期
  • 网络带宽饱和
  • 专用互连配置
  • 插座发送和接收缓冲区大小
  • 运行队列长度和系统CPU利用率

 

高等待时间的应用程序对这些事件的特点是

 

  • 几个热点，没有竞争
  • 频繁的读/写访问
  • 可以读取大量撤消头/撤消块

 

和调整将包括

 

  • 系统和负载调优，以减少延迟
  • SQL和架构调整，以尽量减少IO和远程高速缓存引用

 

1.3.3 GC [current/ CR]阻止忙

 

请求当前或CR块和接收的，但不是由LMS，因为这延迟韧皮加工过程中发送发现一些特殊的条件（参见第二部分立即发送，章节“1.2.1 GCS表现在Block和准许消息提示头“）。

 

的往返时间可以由下面延迟（主要的延迟被高亮显示）的影响：

 

2路：

T（S）+ M + Hbusy + M + T（R）

 

3路：

T（S）+ M +Ma+ Hbusy + M + T（R）

 

诊断：这些等待时间通常是由占主导地位

 

  • 块冲洗时间（日志文件同步）或延迟时间为当前块
  • 块冲洗时间（日志文件同步）的CR转移

 

服务节点和提示KCL_WAIT_BUSY上会被设置。

 

增加的等待时间为这些事件是严格指示高并发和块的争夺。它可以通过增加的IO时间和总体系统的负载，例如可加剧过多的进程。

 

要认识到，主要的时间没有在网络传输或发送花费和接收的IPC处理，但在BAST处理在服务情况下，它是重要的。

 

如果这些事件消耗了大量的时间，额外的检查应包括

 

  • V $ INSTANCE_CACHE_TRANSFER识别显著繁忙的电流或CR块实例做出贡献
  • 对其他实例当前和CR块刷新平均潜伏期
  • 平均针时间对其他实例
  • 登录其他实例文件同步时间，LGWR IO性能
  • 在其他情况下，DBWR性能

 

高等待时间的应用程序对这些事件的特点是

 

  • 热点和争论在同一区块
  • 并发更新到相同的块（例如，表设计成一个队列）
  • 在高利率的主键单调递增到插入索引

 

和调整将集中在

 

  • 最小化LGWR IO等待时间，更大尺寸的IO
  • 给LGWR到CPU的快速访问，如果负载较高
  • 通过使用稀疏块避免争，序列号范围或散列分区索引。

 

1.3.4 GC [Current/ CR] grant 2-way

 

 

请求当前或CR块，并收到了确认消息。这笔赠款给予没有任何显著的延迟。它意味着该块的主站不是本地节点和所要求的块没有在任何其他实例缓存。该模块可在其他地方在兼容模式下进行缓存。

 

的往返时间可以受以下因素影响延迟：

 

T（S）+ 2×M +Ma+ T（R）

 

如果该块不在其本地高速缓冲存储器，一个电流或CR准许之后，将在请求实例读取一个盘;当前请求，用户转换S-> X中是没有被多个读者共享块的副本，也可以等待此事件。

 

诊断：这些等待时间通常是由占主导地位

 

  • 网络传输速度和带宽
  • 上下文切换的开销
  • 系统负载

 

如果这些事件消耗了大量的时间，额外的检查应包括

 

  • 网络带宽饱和
  • 专用互连配置
  • 运行队列长度和CPU利用率

 

高等待时间的应用程序的特点是

 

  • 很少的缓存到缓存传输
  • 更高的IO速率

 

和调整应重点

 

  • SQL和访问计划优化（参见调整建议为1.3.2 GC [电流/ CR] [23] -way）
  • 缓冲区缓存调整。

 

1.3.5 GC current grant busy                                                   

 

请求当前块，并收到了确认消息。繁忙的暗示意味着请求被阻止，因为其他人在它前面或无法立即处理。

 

当电流缓冲由多个实例共享时的电流繁忙授予最可能的情况，并请求一个独占访问，例如发对其进行修改。在这种情况下，所有的人共享数据访问必须首先释放块可被授予的独占访问之前。

 

 

在上述情况下，往返时间可以受以下因素影响延迟：

 

T（S）+ 2 * M（S < – >Ma）+ 2 * M（Ma< – > H）*nS+Ma+ T（R）

 

它变得清晰，这些方案的消息交换是相当复杂的，涉及许多旅行和上下文切换。

 

诊断：这些等待时间通常是由占主导地位

 

  • 网络传输速度和带宽
  • 块的共享当前份数
  • 上下文切换延迟
  • 系统负载

 

如果这些事件消耗了大量的时间，额外的检查应包括

 

  • 网络带宽饱和
  • 专用互连配置
  • 运行队列长度和CPU利用率

 

具有高等待时间此事件的应用程序的调整应侧重于SQL和对象的系统调整和鉴定。如上所述，当在不同的实例的多个阅读器共享相同的块时发生了一个忙碌当前准许的最可能的情况下，和进行独占访问被请求时，即在一个S与多个非本地S持有者X转换。这些方案可能在多节点集群在空间管理和索引块分割是主要的发生。

1.3.6 gc [current/cr] block/grant congested

 

请求当前或CR块，并收到了块或授权消息。拥挤的暗示意味着该请求在内部队列中花费超过1毫秒的IPC层传递的消息后，和LMS把它捡起来了。排队可能会影响在主或持有者请求的延迟。地方选区服务器代码将通过提示KCL_WAIT_LMS。

 

诊断：这些等待时间通常是由原因，如主导

 

  • LMS实施往往较高优先级的进程中断
  • 后台进程的CPU时间段太短
  • LMS超载，不能与请求到达率跟上
  • 系统的总负荷或内存不足（分页，交换）

 

如果这些事件消耗了大量的时间，额外的检查应包括

 

  • CPU利用率和运行队列长度
  • LMS的过程中CPU使用率
  • 操作系统内存统计信息包括虚拟内存的统计数据（如分页）

 

调整应该完全集中于系统优化和负载减少

 

1.3.7 gc cr failure

 

请求一个CA CR块，并收到了故障状态或其他一些特殊事件，如发生丢失块。本次活动有时伴有占位事件的多个超时。失败的原因可能是

 

  • 丢失块
  • 校验和错误
  • CR前身读取错误
  • 无效格式或块无效SCN

 

诊断应包括：

 

  • 10046水平8痕迹
  • 107087级的痕迹
  • GC块丢失统计
  • 统计的Netstat

 

的原因可以是多方面的，但最常见的丢失块和校验和错误，并可能由下列原因造成

 

  • 故障的网络硬件
  • 交换机丢包
  • 数据包重组失败
  • 通信缓冲区溢出
  • 网络固件或驱动程序

 

当观察套接字缓冲器溢出，UDP的增加接收套接字缓冲区大小和关于所允许的最大套接字缓冲区大小的参数指示及解决问题。 256K的值通常是足够的。在其他情况下，更新到适配器固件和驱动程序的最新版本一般应考虑。

 

1.3.8 gc current retry

请求当前块，并收到了故障状态或其他一些特殊事件，如发生丢失块。类似GC CR失败。其原因可能包括：

 

  • 丢失块
  • 校验和错误
  • 重构
  • 下变频期间收到BAST
  • 无效的格式

 

诊断应该是类似的GC CR失败。

 

1.3.9 gc current/cr multi block request

 

较高的层试图连续或不连续的块的读取和通过块地址的一个矢量到GCS层。对于连续块的请求，试图向多个请求组合成一个消息以节省CPU。缓存将等待所有请求完成。它可能会收到赠款或块。由于对DMA缓冲区在OSD的限制，只有16个连续的块可以通过一个多嵌段请求被接收。

 

一个连续的CR请求通常是由全表扫描或索引全扫描引起的。对于目前的街区，空间管理层设置了多块请求时与相邻的DBA的newing块。

 

正常情况下，没有大的性能问题多嵌段读取，除非块丢失。这种病症的症状是

 

  • 严重的性能下降
  • 每秒失去了多块GC
  • 超时的等待事件，其次是GC CR故障或CR请求重试

 

诊断应该寻找10046 8级踪迹的文件。

 

如果丢失块引起性能的劣化，则原因通常在OS层是并可能需要相同的诊断和修复如上所述用于GC CR衰竭和gc的当前重试。

 

高等待时间的应用程序对这些事件的特点是

 

  • SQL数据的连续扫描（全表扫描）
  • 大容量数据的插入。

 

和调整应侧重于SQL和段空间管理的优化。

 

1.3.10 gc buffer busy

对于一些应用程序的工作组，在本地和远程系统上的用户可能会更频繁访问一定范围比其他块地址。如果块的访问之间的时间（即“到达间隔时间”）变得小于该块在存储器固定的时间，然后将含有该块缓冲据说变得繁忙，因此感兴趣的用户可能必须等待它要取消固定。

 

如果这样的数据或索引块已被读入从磁盘或另一个实例高速缓冲存储器中，销的时间可能与它需要来服务块请求的时间成比例地增加。总之，关系可以概括为

 

销时间=（时间阅读块入高速缓存）+（时间修改/进程缓冲区）

闲时间=（平均销时间）*（等待我前面有兴趣的用户数）

 

在集群数据库环境中，有三种被全局地忙碌缓冲器相关等待，即，有一个挂起的IPC请求块并为哪些用户在那里等待发生实例排队的。他们的共同点是，

 

  • 在同一实例的用户已经开始了远程操作在同一资源而请求尚未完成或已被另一个节点请求块和块没有被本地实例发布了新的本地接入是何时
  • 等待时间可以通过网络延迟和慢服务时间在服务器而恶化，即如果在缓冲器中的全局操作不能完成足够快
  • 多个服务员可以排队具有未决的全局操作，请求者以及在保持器侧相同的块。

 

无论如何，试图针的缓冲区全球忙，用户将不得不等待，直到该块已经到来，在队列的头服务员已经发布了它，否则他将不得不等待，直到远程用户已经放弃缓冲区，它是ping通回到这个实例。换句话说，访问一个远程读开始的时间之间，直到它完成将排队和等待gc的缓冲器忙碌取得的缓冲器。

 

时间越长传输缓冲区（日志同步会增加延迟），和并发的程度越大（例如，用户在完成短事务，争夺在SMP机器热块），较高的将是等待时间平均等待。它通常是严重的争用和热点的迹象，不得不通过减少到块的并发访问进行调整;罕见的数据块，但状态表或频繁更新小数据集（会话日志）可以甚至在这种情况下，提示自己高争用。

 

在大多数情况下，等待时间为全局忙碌缓冲器可以通过减少并发在热块和/或使得频繁阻塞资源非抢占-能的用户，提高并发进程的优先次序和降低，并且响应时间提高从而使时间关键流程，通过更快的关键部分。

 

为GC缓冲区忙等待时，可以在同一个实例用户尝试读取远程块，并请求尚未完成，或者在该块被释放，因为它是由另一个实例请求发生。该转换模式可以通过查看P3被识别，在较高位，其中将有

 

  • 1 =收购
  • 2 =释放

 

1.4能见度事件

 

占位符和修正事件之间的区别变化，使他们能够被看的方式。而普通的事件在所有相关意见提出，占位事件是短暂的，而且直到请求完成才相关，并因此每一个积极捕捉信息等视图的一部分。经修正事件传达的更多具体信息可访问后的事实和历史的角度。然而，在10g中，如会话历史记录和活动会话历史新观点添加差异化的表现：

 

 

 

 

  Placeholder Fixup Ordinary
V$SESSION_WAIT Yes No Yes
V$ACTIVE_SESSION_HISTORY Yes No Yes
V$SESSION_WAIT_HISTORY No Yes Yes
10046 level 8, SQL tracing No Yes Yes

Table 6: Visibility of events

1.5  Oracle9i和10g的事件映射

 

下面的表格关联最9i中使用与10g中的GC等待事件来促进过渡全局缓存等待事件。请注意，GC等待事件已经变得更加具体，即注重成果和与GCS提示超载：

 

Oracle9i event Oracle 10g event
Global cache null to x

Global cache null to s

 gc current block 2-way

gc current block 3-way

gc current block busy

gc current block congested

 
Global cache open x gc current block 2-way

gc current block 3-way

gc current block busy

gc current block congested

gc current grant 2-way

gc current multiblock request

 
Global cache s to x gc current grant 2-way

 
Global cache cr request gc cr block 2-way

gc cr block 2-way

gc cr block busy

gc cr block congested

gc cr grant 2-way

gc cr multiblock request

 
Global cache busy

Buffer busy global cache

Buffer busy global cr

 gc buffer busy

Table 7: Mapping of events

 

 

1.6 其他重要等待

 

1.6.1 cr request retry

 

当一个请求CR块不侧信道消息之前到达，该块被认为是失落和缓冲区高速缓存层等待重试前，此事件（参见2.2.3 GC块丢失）。本质上，该事件是一个睡眠定时器。

 

1.6.2 Enqueue

 

正如前面指出的，排队等待不RAC具体的，但被启用的RAC当涉及全局锁操作。最让排队，全球的请求是同步的，即前台进程将等待他们。集群处理中的任何延迟都会影响阻塞时间，并导致车队如果是侍应生等资源的持有人。最常见的，对于这个事件发生等待类型的入队

 

  • TX：交易排队，用于事务划分和跟踪
  • TM：表或分区排队，大多用于hared模式以保护表定义DML操作过程中
  • HW：高水位标记排队，收购作为屏障同步块newing操作
  • SQ：顺序排队，用于序列递增Oracle序列号

 

在上述所有的情况下，该等待是同步的，并且可以构成严重序列分。

 

TX

事务排队，（TX）用于识别数据库事务。它们提供的并发控制，当用户参与

 

  • 等待一个事务提交或者被清理
  • 等待服务的交易保护指数分裂
  • 在块等待空间变得可用
  • 等待其他用户锁定的行

 

如果有响应时间的问题和TX排队，招致较高累积等待时间，一个鉴别诊断与上述的假设被表明。

 

在10g中，排队等待事件指定资源名称，例如TX排队，和用于等待一个原因，例如“索引块分裂”，从而使排队的诊断等待更容易。

 

HW

的高水位标记（HW）排队所使用的空间管理层，并且可以表征如下：

 

  • 一个屏障保护段高水位标记的“撞了”;高水位线之下，段标题或位图块被收购，以及新的块格式化，为插入新空间
  • 它一直保持到新块已被格式化;新的块以独占模式，这可能需要一个消息发送，使已知的GCS资源收购
  • 为HW排队，等待往往与高发生全局缓存开点¯x等待的（9i中）相关或GC当前拨款2路（10G）

 

一般来说，经常堵塞newing和高水位标记的运动可能会导致更长的延迟插入和增加更多的CPU开销。

 

因此，在此数据结构争用应该由使用的减少：

 

  • 更大的块大小，以适应更多的数据，并减少对新块的需求（缺点：当块被更新可能更争）
  • 空闲列表组，预分配盘（缺点：全表扫描）

 

内核优化了，以减少发送的消息的数量作出回Oracle9i及由相邻块收集请求的装置和分批远程实例发送它们收到的块的“newing”。此外，在HWM的运动的频率是由自动预分配大扩展，同时保持开销大分配低减小。

 

一般而言，表和索引的自动段空间管理优于由于良好的平均性能和更容易管理列表组

 

1.6.3 Library Cache Lock

 

 

在许多应用中执行SQL的单位，如游标，触发器，包 – 其中一个很好的例子是Oracle E-Business Suite的 – 大量的时间，可以花在等待库高速缓存锁，主要是对表和过程。内部类型这样的库高速缓存锁为“LB”。当时间等待库高速缓存锁是总事件等待时间相当大的比重，性能计数器可以在V $ LIBRARYCACHE查询各种空间和类型的收购，如不慎入眼，销和无效的，为了获得更详细的天寒LB锁。

 

请参考第一部分，章节“2.2等待库高速缓存锁”为图书馆的缓存问题的讨论和第二部分，第一章“2.3全局队列服务统计”全球锁统计信息的更详细的介绍。

 

 

1.6.4 DFS lock handle

 

一个DFS锁柄事件可以被等待在特殊情况下，RAC集群如当跨实例调用频繁或当其完成需要的时间显著量。一个典型的例子是，当表被丢弃或截断重用或范围的检查点发出。

 

通常情况下，这应该是很少发生，但有可能成为某些DSS和DW工作量显著。欲了解更多信息和案例研究，请参见“DFS锁手柄等待”，在“性能和Oracle 9i实时应用集群（RAC）在HP ES45 Alpha服务器在PeopleSoft EPM基准的可扩展性”，可从公众RAC表演团，在OracleFiles（文件perf9iRACEPM.zip）文件夹中。

 

 

1.7 Background Processes Only

 

有些RAC相关等待事件陷入“空转”的等待，即该类别的等待，当会话的过程中没有任何的工作要做。较知名的空闲事件是“RDBMS IPC消息”，“SMON定时器”或“SQL *网络，等待来自客户端的消息”。他们没有在Statspack的前5个等待事件出现，并没有什么实际意义，预计在LMD或丢失LMS职位或服务时间延迟的调试。

 

1.7.1 gcs remote message

 

当没有GCS请求，在处理队列或者在其接收队列排队LMS，学习管理系统将转入休眠状态，并等待，直到它被张贴或直到等待超时。超时值是自10毫秒9.2。在繁忙的系统中，时间的百分比花费在等待相对于快照间隔持续时间的动作是较小的，因为LMS进程将总是有工作要做。

 

1.7.2 ges remote message

 

LMD只处理传入的GES消息。当有对LMD没有消息，它会去休眠，直到被唤醒或直到出了等待时间。这类似于上述的LMS的行为。

 

2  V$ SYSSTAT和V $ SESSTAT

在下面的段落中，最相关的系统和会话统计表征上多个群集节点运行的工作量将被讨论。实例统计从实例的开始收集，即它们是累积的。在内部，会话统计由回调，这样对系统性能的会议的影响，可以持久保存会话注销后卷起系统的统计数据。使用基于V $ SYSSTAT系统统计允许基于平均值的数据库活动的表征。它是许多指标和比率在不同的工具和方法，如AWR，Statspack的，和OEM等。为了深入到单个会话或会话组使用的基础上，V $ SESSTAT是有用的，当重要的会话ID对显示器是已知的。如果应用程序在V $ SESSION的模块和操作列填充其实用性增强。对于一个向下钻取到特定的SQL语句，V $ SESSTAT可以用V $ SESSION或V $ SQLAREA加入。总之，相关的连接是：

 

  • V $ SESSION和V $ SESSTAT使用SID列的加入，与有趣的过滤器列，如程序，模块，动作，VALUE
  • V $ SESSION，V $ SQLAREA与V $ SESSTAT通过SID的加盟，SQL_ADDRESS和地址

 

RAC的相关统计数据可以分为

 

  • 全局缓存服务的统计数据（例如GC接收到的CR块，GC CR块接收时间等）
  • 全局排队服务统计（例如全球排队获取等）
  • 所发送消息统计（GCS发送消息和GES消息发送）

 

正如其名称所示，全局高速缓存的统计数据是在缓存层收集，即在处理集群中的实例间的请求和缓存一致性的代码。它们被增值时请求完成，并且在定时统计的情况下，请求的开始时间被保持在保持对象的全局状态的结构（例如，一个锁定元件），即定时统计基本上积累的往返时间的请求。

 

全球队列服务统计信息维护使用的通用代码期望数据块同步访问所有数据库资源的API中。此API是从由高速缓冲存储器中所使用的明显不同。由于历史原因，许多客户层保持自己的统计信息和重复计算的一定量的操作后，例如对于统计“排队等待”和“入队”，也有计算全球排队获取和全局排队发行。排队和全局锁等待某些功能或层的映射是困难的，如果不是不可能的，并且通常的无关联性。对于有关全球排队，性能调试，它是更有益的是指由一个特定的代码层填充事件等待统计和观点（例如行锁，库高速缓存锁定，V $ ROWCACHE，V $ LIBRARYCACHE等）

 

最后，消息统计在缓冲区高速缓存GCS消息，并为GES消息全局队列服务API下面的高速缓存融合API层收集。发送的消息的数量是在群集通信消耗的工作的一个重要指标，通常可以用引起的集群处理和消息传递的CPU开销相关。

 

2.1 Global Cache Service Statistics

 

如高速缓存块与全部高速缓存融合操作的任何统计数据服务，并获得可以很容易识别，因为它们包含前缀“GC” 。他们中许多人是成对出现的，计数器和定时统计，并分为请求端和服务器端的统计信息。请注意，定时统计数据是累积和厘秒表示。

 

全局高速缓存服务系统统计对应于等待事件的统计，其中该事件统计代表请求者的处置时，它必须等待一个块或一个消息，并且系统统计记录请求的结果。下表映射事件取决于块的全局状态及其结果：

 

Request Block held X in another instance Block held S in another instance Block not held in another instance
Gc cr request Block transfer

(gc cr blocks received )

 Block transfer, if master=holder

(gc current blocks received )

 Permission granted
gc current request Block transfer

(gc current blocks received)

 Block transfer

(gc current blocks received )

 Permission granted

 
gc current request Block transfer

(gc current blocks received )

 Block transfer, if master=holder

(gc current blocks received )

 Permission granted

 
gc current request   Permission granted

 

 Permission granted

 
gc current request Block transfer

(gc current blocks received )

 Block transfer

(gc current blocks received )

 Permission granted

 
gc current request Block transfer

(gc current blocks received )

 Block transfer, if master=holder

(gc current blocks received)

 Permission granted

 

Table 8: Wait events and their outcomes
全局高速缓存系统的统计数据显示在括号中。它已经指出，修正事件详细解释在请求完成时间的请求的结果。

 

 

2.1.1 Global Cache Fusion Block Transfers: Requestor

 

 

最全局高速缓存操作启动时逻辑读取，即任何类的一个数据库块的访问未能找到在本地缓存缓冲副本。从磁盘读取的块之前，试图找到它在另一种情况下的高速缓冲存储器。 （即立刻）来处理的GCS发出请求，这可能会被转发到另一个实例或在本地。如果该块是存在于另一个实例，无论是与排他或共享访问权限，该块的版本可以出货，否则所请求的访问权限授予和块从磁盘读出。该请求可以开始作为一个一致的或当前读取的结果。 如果一个进程，试图访问一个全球管理数据块时，需要发送一条消息，该消息将被直接发送到LMS过程在远程实例。如果请求者节点不是资源的主人或保持器，并需要被发送的消息，将有2或3路由，直到请求完成，这取决于集群中节点的数目和资源主人的位置和阻止持有人，分别。在许多情况下，请求能立即完成，而没有发送信息和等待完成的请求。

 

gc current blocks received

 
计数器是由前台或后台进程递增时对当前块或在一个当前块的全局高速缓存CR请求的结果的修改的请求。在接收的块，完成处理器递增的统计。

 

相关统计（服务器端）：

  •    gc current blocks served

 

相关等待事件：

  • 所有全局高速缓存等待这可能导致接收当前块的事件，例如 gc current block[23] 或者gc  current block[busy|congested]

为了辨识对象，服务实例和SQL导致集群等待事件，查询

  • V$INSTANCE_CACHE_TRANSFER
  • V$SEGMENT_STATISTICS
  • V$SQLAREA

和他们的相等的全局视图

 

gc current block receive time

该统计表示当前块请求累积端至端经过时间或延迟。单位为厘秒。每个单独的请求从点定时时提出的请求，直到它完成。请求的开始时间被存储在表示高速缓存的数据块的状态的全局高速缓存结构。个人计时可以通过打开事件10708，7级被追踪（参见第二部分，章节“6.8 KCL跟踪（事件10708）”）。对平均请求时间的确定，该比率

 

  • 10 * gc current block receive time / gc current blocks received

 

产生以毫秒为单位的请求的平均往返时间。这种计算是在Statspack报告的缓存融合统计部分中使用，并且如

  • Avg global cache current block receive time (ms):

平均可能会产生误导。实际分配可能不正常和主要取决于争用。如果应用程序的响应时间进行优化和全局高速缓存当前块的等待和接收时间是占主导地位，直方图数据应使用V $ CURRENT_BLOCK_SERVER进行分析;请参考第一部分，章节“1.3 RAC操作的典型延迟”和第II部分，章节“3.4 V $ CR_BLOCK_SERVER”更多关于这个话题。相关的统计信息（服务器侧，可以指示在接收的时间的效果）：

  • gc current block pin time
  • gc current block flush time
  • gc current block send time
  • Current Block Server Histogram (第二部分, 章节r “5 V$CURRENT_BLOCK_SERVER”)

 

如果pin和flush times对其他实例有显著影响，，则事件

  •  gc current block busy

 

将在最高其他实例时间的等待事件下

 

相关等待事件：

  • 所有可能导致接受当前块的全局缓存等待事件,例如 gc current block[23]-way或者

gc current block[busy|congested]

 

gc cr blocks received

 

 

当一个块的一致读版本搜索未能找到与所需的数据的快照的本地缓冲器此计数器是在前台或后台进程递增。这也意味着，现行版本的特定块没有被本地缓存。因此，试图从远程实例得到该块。所述保持器可以船舶或者CR或当前版本的块时，接收机将其复制作为CR缓冲器。块可以与其他实例独占访问权被缓存，如果它是最近修改那里，或具有共享的访问权限。 在某些情况下，一个完整的块CR版本不能生产和不完整副本发送由于在CR拷贝建筑物可能涉及太多工作，诸如读取数据，或从磁盘或从另一高速缓存（“轻重量规则复原块“）。在后一种情况下，请求将给出与可能被在服务器端铺开并恢复CR块创建他自己的所有的变化，这可能涉及开销回滚和清洗和远程回滚段头读取块版本，部分所述“2.1 CR请求和缓冲区等待远程还原段头”。 为了确定哪种类型的CR请求都频繁地进行和结果由CR块服务器返回，视图V $ CR_BLOCK_SERVER进行采样;请参考第二部分，以供参考章节“3.4 V $ CR_BLOCK_SERVER”。 相关统计数据（服务器端）和相关的等待事件：

 

  • gc cr blocks served (system and segment statistics)
  • V$CR_BLOCK_SERVER
  • gc cr block [23]-way, gc cr block busy/congested

 

在集群环境中如果所有的或者一些实例读出最近修改的数据或者从另一个需要读出频繁修改的回滚段，对于undo heads和undo blocks所有的CR请求可能达到50%。  它被辨认去辨析流畅读和修改的表和索引

  • V$SEGMENT_STATISTICS
  • V$SYSSTAT
  • V$SQLAREA

和确定多数送达的CR块是否为数据或还原段的帮助

  • V$CR_BLOCK_SERVER (refer to Part II, chapter “3.4 V$CR_BLOCK_SERVER”)
  • V$INSTANCE_CACHE_TRANSFER

理解应用程序的参数文件

 

在集群中共享数据的并发读写活动是一种常见的活动，一般情况下不会造成性能问题。这取决于服务要求非常多。在某些情况下，需要的100毫秒或更少的响应时间和对于群延迟的公差是有限的。在其他情况下， CPU消耗将被降低以实现最佳的吞吐量。 通常，优化SQL计划和架构，实现良好的本地高速缓存的命中效率，并最大限度地减少I / O将成为性能优化一个成功的策略时，全局缓存CR请求造成性能问题。

 

gc cr block receive time

 
该统计表示一个请求的累积结束到端经过时间或延迟。单位为厘秒。每个单独的请求从点定时时提出的请求，直到它完成。请求的开始时间被存储在表示高速缓存数据块的集群范围的状态的全局高速缓存结构。个人计时可以通过打开事件10708跟踪（请参考第二部分，章节“ 6.8 KCL跟踪（事件10708 ）”）。

 

  • 10 * gc current block receive time / gc current blocks received

产生以毫秒为单位的请求的平均往返时间。这种计算是在Statspack报告的缓存融合统计部分中使用，并且如

  • Avg global cache current block receive time (ms):

通常情况下， CR的要求不应该被阻止，他们的等待时间几乎完全被处理和信息时间限制的。

 

相关统计数据（服务器端）：

  • gc cr block flush time
  • gc cr block build time
  • gc cr block send time

 

相关等待事件：

·         所有全局高速缓存等待这可能导致接收当前块的事件，例如

. gc current block [23]-way or gc current block [busy|congested]

 

2.1.2 Global Cache Fusion Block Transfers: Server

 

当试图减少花费远程高速缓存访问时间，其考虑到其中一个或多个实例中，供应的大部分块的考虑是很重要的。还应当指出的是，pin的总和，冲洗和发送时间为块投放构成它的服务时间。如果该服务时间是高，更详细的统计可以被用来确定一个可能的性能问题。平均pin的总和，冲洗和发送时间可被计算为平均的时间来处理一个当前块的请求。 在服务器侧的处理可以显著影响整体时间为全局高速缓存访问，其中第一眼可通过比较平均处理进行评估和平均接收时间。 随着有关新等待事件的章节所述，处理时间因争用或负载增加服务器的BAST可以通过分析GC等待事件，造成忙等待的情况下，被诊断列于V $ INSTANCE_CACHE_TRANSFER

 

gc current blocks served

 

该统计表示由本实例提供当前块的请求的计数。全局高速缓存服务器进程（例如LMS0，LMS1等）处理的融合BAST（=阻断异步系统陷阱，该通知机制来释放由全球缓存服务中使用的块），并发送一个数据块作为结果，当保持它。一个当前块的服务时间可能会受 •延迟块运送（如果清除块，它是由30ms的延迟或任何为_GC_DEFER_TIME指定被运前，该请求也将有链接到缓冲区头部，以便快速事件推迟本地处理完成） •冲洗等待重做到磁盘发生 •完成块发送操作单独的统计可用于监控的处理时间为当前块。如果高往返时间（请参考GC当前块接收时间）遇到，这些时间应该进行检查。     单独的统计可用于监控的处理时间为当前块。如果高往返时间（请参考GC当前块接收时间）遇到，这些时间应该进行检查。 相关统计数据： •当前块服务器柱状图（指第二部分，章节“3.5 V $ CURRENT_BLOCK_SERVER”） 相关的统计：

 

Posted

in

by

mac

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *