Oracle备份与恢复
本节中，您应该能够：
Oracle提供了多重功能，可让您从数据库的错误中恢复，其中包含了硬件故障与用户错误。在本节中，您将学会如何实行备份和还原策略，在硬件故障时保护数据库。此外，您还会学到如何使用闪回功能来恢复用户错误。
本文的第二部分涵盖了常用的观点描述，等待事件，init.ora中的参数和跟踪事件。 RAC统计资料的完整列表，并在等待V $视图中使用的事件，可以在Oracle文件在线公众RAC性能组文件夹中的子文件夹RAC10g中找到。
1会话和系统事件统计
当它需要一些时间来获得，因为总的路径长度和等待时间的请求的资源，流程睡眠，以避免纺纱的时间不定周期。一旦该过程决定等待，通常是通过调用某种形式的kslwait（）函数，它唤醒任何指定一个定时器值期满（“超时”）或当它发生时正在等待该事件并且处理过帐后。
等待事件记录，并在汇总意见:
其中前两个是等待时间，超时聚合和等待的次数为特定事件而其余允许实时等待会话，包括最近的事件的历史等待的监测。
个别事件由他们的名字和他们承担的参数，例如脱颖而出对于大多数的全局高速缓存（GC）的等待事件，这些参数包括文件编号，块号，块级和接入方式处置，如举行，并要求模式。
调试响应时间的性能问题时提出，并聚集在上述观点的事件等待时间是非常有用的。请注意，时间等是累积的，并具有最高得分事件不一定是一个问题。但是，如果可用的CPU电源不能刷爆，或一个应用程序的响应时间过高，顶端等待事件提供有价值的性能诊断。
1.1介绍全局缓存事件在10g中
在数据块被跨分布式高速缓存共享用于读取和写入一个多实例的数据库系统，远程高速缓存存取将消耗显著CPU和等待时间。事件的特定组跟踪的等待时间缓存到缓存的传输。
通常，会话等待本地高速缓存未命中后的电流或CR缓冲器的请求的完成，并且数据块的到达或由全球缓存服务访问的授予完成等待。
在Oracle9i中，等待事件的用户可读描述是在接入模式的改变来表示（如全局缓存空至x）。然而，关键的是要注意的一个事实，即大多数块请求可具有各种的结果，这取决于应用程序的数据访问特性和全局共享工作集。因此，流程等当前或CR请求既可以接收块或将被授予全球的访问权限。有些请求甚至可能导致失败，这样一想就知道是多少时间浪费在他们身上。
所有这些事件都等待在缓存层和由前台进程。某些后台进程（LGWR，DBWR，LMD和LMS）将永远不会等待任何全局高速缓存事件。事件提供参数P1，P2和P3，其中
在当前块请求的情况下，表示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中，该系统的统计数据，动态性能视图和会话等待事件的几个变化，以提供更快，更清晰的诊断进行的。等待事件模型，以便允许适当的介绍和高速缓存合并请求的结果分级得到延长。
为了实现这一点：
为了方便钻和更快的问题隔离，
得到了加强•段统计数据包括全球忙碌的缓冲区。
综上所述，修改和添加到系统统计信息，会话等待事件和动态性能视图提高诊断能力由
为了提高效率和理由，以避免系统统计和会话事件的信息内容重叠，几个系统的统计数据被删除。这些统计数据将在一个特殊的部分上市。
1.2事件的技术概述等待模式在10g中
等待事件的命名在10g中约定已经从基于并发到一个消息传递或基于缓存融合范式改变。在最常见的情况下，命名包括
为了包括事件名称的完成状态和GCS性能提示，修正事件的概念实现的。可以使用一个叫占位更普遍的等待事件，同时要求在飞行和固定到一个真实的事件当它完成。在完成时间，已知是否接收一个块或授权消息。在完成处理程序中，GCS提示进行评估和等待时间，数量和超时都归结到一个特定的事件。因此没有重复计算时，会出现修正程序也将复位占位符。在内核服务层的新功能被设计出来以处理来自占位交换机完成事件，即kslwt_fxup（）
因此，一个占位符事件仅代表是在请求一个块时已知的信息，即缓冲模式，举办了接入方式和请求的访问模式。接入模式转变不是名称的一部分，但组合中的P3。占位符事件在性质短暂的存在，直到一个请求已完成。
应该明确的是普通单片等待事件都在使用适当的地方，也就是当一个人不感兴趣的请求的实际结果
在块和grant标题1.2.1 GCS性能提示
为了识别处理gc的请求时花费的主要时间，GCS提示被传递与每个块或授权消息。它们是被运到请求者的真实或伪造缓冲报头的一部分，而在2位被实施。KCL和KJB层提供基于其可能会延迟请求处理过程中显著情况下，这些提示。例如，日志同步，块或多个网络跃点的管理延迟可以支配接收块的时间。
足够的信息进行维护和传来传去，这样缓存下方排队延迟和阻塞条件可占。由此产生的GCS暗示在缓存及以下用于限定在等待事件所花费的实时性和区分以下情况
在内部，GCS提示被定义为
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：块/补助，后两跳获得
KCL_WAIT_3HOP•#Instances>2：请求者，硕士及持有人在不同的情况下，因此该消息的路径长度requestor->大师 – >持有人>请求者
KCL_WAIT_BUSY BAST当前块的过程中：
在CR处理：
KCL_WAIT_LMS LMS队列时间，即通过等待它已由ksxp递送到LMS处理之后要被处理的请求所花费的时间是>1毫秒
表5：GCS提示
表5：GCS提示
在平原，解释方面，提示特征
和基于其上的事件可以因此通过快速诊断解释相关联。
注意，对于特征为“忙”（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）
诊断：这些等待时间通常是受影响最严重
如果这些事件消耗了大量的时间，额外的检查应包括
高等待时间的应用程序对这些事件的特点是
和调整将包括
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）
诊断：这些等待时间通常是由占主导地位
服务节点和提示KCL_WAIT_BUSY上会被设置。
增加的等待时间为这些事件是严格指示高并发和块的争夺。它可以通过增加的IO时间和总体系统的负载，例如可加剧过多的进程。
要认识到，主要的时间没有在网络传输或发送花费和接收的IPC处理，但在BAST处理在服务情况下，它是重要的。
如果这些事件消耗了大量的时间，额外的检查应包括
高等待时间的应用程序对这些事件的特点是
和调整将集中在
1.3.4 GC [Current/ CR] grant 2-way
请求当前或CR块，并收到了确认消息。这笔赠款给予没有任何显著的延迟。它意味着该块的主站不是本地节点和所要求的块没有在任何其他实例缓存。该模块可在其他地方在兼容模式下进行缓存。
的往返时间可以受以下因素影响延迟：
T（S）+ 2×M +Ma+ T（R）
如果该块不在其本地高速缓冲存储器，一个电流或CR准许之后，将在请求实例读取一个盘;当前请求，用户转换S-> X中是没有被多个读者共享块的副本，也可以等待此事件。
诊断：这些等待时间通常是由占主导地位
如果这些事件消耗了大量的时间，额外的检查应包括
高等待时间的应用程序的特点是
和调整应重点
1.3.5 GC current grant busy
请求当前块，并收到了确认消息。繁忙的暗示意味着请求被阻止，因为其他人在它前面或无法立即处理。
当电流缓冲由多个实例共享时的电流繁忙授予最可能的情况，并请求一个独占访问，例如发对其进行修改。在这种情况下，所有的人共享数据访问必须首先释放块可被授予的独占访问之前。
在上述情况下，往返时间可以受以下因素影响延迟：
T（S）+ 2 * M（S < – >Ma）+ 2 * M（Ma< – > H）*nS+Ma+ T（R）
它变得清晰，这些方案的消息交换是相当复杂的，涉及许多旅行和上下文切换。
诊断：这些等待时间通常是由占主导地位
如果这些事件消耗了大量的时间，额外的检查应包括
具有高等待时间此事件的应用程序的调整应侧重于SQL和对象的系统调整和鉴定。如上所述，当在不同的实例的多个阅读器共享相同的块时发生了一个忙碌当前准许的最可能的情况下，和进行独占访问被请求时，即在一个S与多个非本地S持有者X转换。这些方案可能在多节点集群在空间管理和索引块分割是主要的发生。
请求当前或CR块，并收到了块或授权消息。拥挤的暗示意味着该请求在内部队列中花费超过1毫秒的IPC层传递的消息后，和LMS把它捡起来了。排队可能会影响在主或持有者请求的延迟。地方选区服务器代码将通过提示KCL_WAIT_LMS。
诊断：这些等待时间通常是由原因，如主导
如果这些事件消耗了大量的时间，额外的检查应包括
调整应该完全集中于系统优化和负载减少
请求一个CA CR块，并收到了故障状态或其他一些特殊事件，如发生丢失块。本次活动有时伴有占位事件的多个超时。失败的原因可能是
诊断应包括：
的原因可以是多方面的，但最常见的丢失块和校验和错误，并可能由下列原因造成
当观察套接字缓冲器溢出，UDP的增加接收套接字缓冲区大小和关于所允许的最大套接字缓冲区大小的参数指示及解决问题。 256K的值通常是足够的。在其他情况下，更新到适配器固件和驱动程序的最新版本一般应考虑。
请求当前块，并收到了故障状态或其他一些特殊事件，如发生丢失块。类似GC CR失败。其原因可能包括：
诊断应该是类似的GC CR失败。
较高的层试图连续或不连续的块的读取和通过块地址的一个矢量到GCS层。对于连续块的请求，试图向多个请求组合成一个消息以节省CPU。缓存将等待所有请求完成。它可能会收到赠款或块。由于对DMA缓冲区在OSD的限制，只有16个连续的块可以通过一个多嵌段请求被接收。
一个连续的CR请求通常是由全表扫描或索引全扫描引起的。对于目前的街区，空间管理层设置了多块请求时与相邻的DBA的newing块。
正常情况下，没有大的性能问题多嵌段读取，除非块丢失。这种病症的症状是
诊断应该寻找10046 8级踪迹的文件。
如果丢失块引起性能的劣化，则原因通常在OS层是并可能需要相同的诊断和修复如上所述用于GC CR衰竭和gc的当前重试。
高等待时间的应用程序对这些事件的特点是
和调整应侧重于SQL和段空间管理的优化。
对于一些应用程序的工作组，在本地和远程系统上的用户可能会更频繁访问一定范围比其他块地址。如果块的访问之间的时间（即“到达间隔时间”）变得小于该块在存储器固定的时间，然后将含有该块缓冲据说变得繁忙，因此感兴趣的用户可能必须等待它要取消固定。
如果这样的数据或索引块已被读入从磁盘或另一个实例高速缓冲存储器中，销的时间可能与它需要来服务块请求的时间成比例地增加。总之，关系可以概括为
销时间=（时间阅读块入高速缓存）+（时间修改/进程缓冲区）
闲时间=（平均销时间）*（等待我前面有兴趣的用户数）
在集群数据库环境中，有三种被全局地忙碌缓冲器相关等待，即，有一个挂起的IPC请求块并为哪些用户在那里等待发生实例排队的。他们的共同点是，
无论如何，试图针的缓冲区全球忙，用户将不得不等待，直到该块已经到来，在队列的头服务员已经发布了它，否则他将不得不等待，直到远程用户已经放弃缓冲区，它是ping通回到这个实例。换句话说，访问一个远程读开始的时间之间，直到它完成将排队和等待gc的缓冲器忙碌取得的缓冲器。
时间越长传输缓冲区（日志同步会增加延迟），和并发的程度越大（例如，用户在完成短事务，争夺在SMP机器热块），较高的将是等待时间平均等待。它通常是严重的争用和热点的迹象，不得不通过减少到块的并发访问进行调整;罕见的数据块，但状态表或频繁更新小数据集（会话日志）可以甚至在这种情况下，提示自己高争用。
在大多数情况下，等待时间为全局忙碌缓冲器可以通过减少并发在热块和/或使得频繁阻塞资源非抢占-能的用户，提高并发进程的优先次序和降低，并且响应时间提高从而使时间关键流程，通过更快的关键部分。
为GC缓冲区忙等待时，可以在同一个实例用户尝试读取远程块，并请求尚未完成，或者在该块被释放，因为它是由另一个实例请求发生。该转换模式可以通过查看P3被识别，在较高位，其中将有
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 |
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 |
1.6 其他重要等待
当一个请求CR块不侧信道消息之前到达，该块被认为是失落和缓冲区高速缓存层等待重试前，此事件（参见2.2.3 GC块丢失）。本质上，该事件是一个睡眠定时器。
正如前面指出的，排队等待不RAC具体的，但被启用的RAC当涉及全局锁操作。最让排队，全球的请求是同步的，即前台进程将等待他们。集群处理中的任何延迟都会影响阻塞时间，并导致车队如果是侍应生等资源的持有人。最常见的，对于这个事件发生等待类型的入队
在上述所有的情况下，该等待是同步的，并且可以构成严重序列分。
TX
事务排队，（TX）用于识别数据库事务。它们提供的并发控制，当用户参与
如果有响应时间的问题和TX排队，招致较高累积等待时间，一个鉴别诊断与上述的假设被表明。
在10g中，排队等待事件指定资源名称，例如TX排队，和用于等待一个原因，例如“索引块分裂”，从而使排队的诊断等待更容易。
HW
的高水位标记（HW）排队所使用的空间管理层，并且可以表征如下：
一般来说，经常堵塞newing和高水位标记的运动可能会导致更长的延迟插入和增加更多的CPU开销。
因此，在此数据结构争用应该由使用的减少：
内核优化了，以减少发送的消息的数量作出回Oracle9i及由相邻块收集请求的装置和分批远程实例发送它们收到的块的“newing”。此外，在HWM的运动的频率是由自动预分配大扩展，同时保持开销大分配低减小。
一般而言，表和索引的自动段空间管理优于由于良好的平均性能和更容易管理列表组
在许多应用中执行SQL的单位，如游标，触发器，包 – 其中一个很好的例子是Oracle E-Business Suite的 – 大量的时间，可以花在等待库高速缓存锁，主要是对表和过程。内部类型这样的库高速缓存锁为“LB”。当时间等待库高速缓存锁是总事件等待时间相当大的比重，性能计数器可以在V $ LIBRARYCACHE查询各种空间和类型的收购，如不慎入眼，销和无效的，为了获得更详细的天寒LB锁。
请参考第一部分，章节“2.2等待库高速缓存锁”为图书馆的缓存问题的讨论和第二部分，第一章“2.3全局队列服务统计”全球锁统计信息的更详细的介绍。
一个DFS锁柄事件可以被等待在特殊情况下，RAC集群如当跨实例调用频繁或当其完成需要的时间显著量。一个典型的例子是，当表被丢弃或截断重用或范围的检查点发出。
通常情况下，这应该是很少发生，但有可能成为某些DSS和DW工作量显著。欲了解更多信息和案例研究，请参见“DFS锁手柄等待”，在“性能和Oracle 9i实时应用集群（RAC）在HP ES45 Alpha服务器在PeopleSoft EPM基准的可扩展性”，可从公众RAC表演团，在OracleFiles（文件perf9iRACEPM.zip）文件夹中。
有些RAC相关等待事件陷入“空转”的等待，即该类别的等待，当会话的过程中没有任何的工作要做。较知名的空闲事件是“RDBMS IPC消息”，“SMON定时器”或“SQL *网络，等待来自客户端的消息”。他们没有在Statspack的前5个等待事件出现，并没有什么实际意义，预计在LMD或丢失LMS职位或服务时间延迟的调试。
当没有GCS请求，在处理队列或者在其接收队列排队LMS，学习管理系统将转入休眠状态，并等待，直到它被张贴或直到等待超时。超时值是自10毫秒9.2。在繁忙的系统中，时间的百分比花费在等待相对于快照间隔持续时间的动作是较小的，因为LMS进程将总是有工作要做。
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加入。总之，相关的连接是：
RAC的相关统计数据可以分为
正如其名称所示，全局高速缓存的统计数据是在缓存层收集，即在处理集群中的实例间的请求和缓存一致性的代码。它们被增值时请求完成，并且在定时统计的情况下，请求的开始时间被保持在保持对象的全局状态的结构（例如，一个锁定元件），即定时统计基本上积累的往返时间的请求。
全球队列服务统计信息维护使用的通用代码期望数据块同步访问所有数据库资源的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
全局高速缓存系统的统计数据显示在括号中。它已经指出，修正事件详细解释在请求完成时间的请求的结果。
最全局高速缓存操作启动时逻辑读取，即任何类的一个数据库块的访问未能找到在本地缓存缓冲副本。从磁盘读取的块之前，试图找到它在另一种情况下的高速缓冲存储器。 （即立刻）来处理的GCS发出请求，这可能会被转发到另一个实例或在本地。如果该块是存在于另一个实例，无论是与排他或共享访问权限，该块的版本可以出货，否则所请求的访问权限授予和块从磁盘读出。该请求可以开始作为一个一致的或当前读取的结果。 如果一个进程，试图访问一个全球管理数据块时，需要发送一条消息，该消息将被直接发送到LMS过程在远程实例。如果请求者节点不是资源的主人或保持器，并需要被发送的消息，将有2或3路由，直到请求完成，这取决于集群中节点的数目和资源主人的位置和阻止持有人，分别。在许多情况下，请求能立即完成，而没有发送信息和等待完成的请求。
计数器是由前台或后台进程递增时对当前块或在一个当前块的全局高速缓存CR请求的结果的修改的请求。在接收的块，完成处理器递增的统计。
相关统计（服务器端）：
相关等待事件：
为了辨识对象，服务实例和SQL导致集群等待事件，查询
和他们的相等的全局视图
该统计表示当前块请求累积端至端经过时间或延迟。单位为厘秒。每个单独的请求从点定时时提出的请求，直到它完成。请求的开始时间被存储在表示高速缓存的数据块的状态的全局高速缓存结构。个人计时可以通过打开事件10708，7级被追踪（参见第二部分，章节“6.8 KCL跟踪（事件10708）”）。对平均请求时间的确定，该比率
产生以毫秒为单位的请求的平均往返时间。这种计算是在Statspack报告的缓存融合统计部分中使用，并且如
平均可能会产生误导。实际分配可能不正常和主要取决于争用。如果应用程序的响应时间进行优化和全局高速缓存当前块的等待和接收时间是占主导地位，直方图数据应使用V $ CURRENT_BLOCK_SERVER进行分析;请参考第一部分，章节“1.3 RAC操作的典型延迟”和第II部分，章节“3.4 V $ CR_BLOCK_SERVER”更多关于这个话题。相关的统计信息（服务器侧，可以指示在接收的时间的效果）：
如果pin和flush times对其他实例有显著影响，，则事件
将在最高其他实例时间的等待事件下
相关等待事件：
gc current block[busy|congested]
当一个块的一致读版本搜索未能找到与所需的数据的快照的本地缓冲器此计数器是在前台或后台进程递增。这也意味着，现行版本的特定块没有被本地缓存。因此，试图从远程实例得到该块。所述保持器可以船舶或者CR或当前版本的块时，接收机将其复制作为CR缓冲器。块可以与其他实例独占访问权被缓存，如果它是最近修改那里，或具有共享的访问权限。 在某些情况下，一个完整的块CR版本不能生产和不完整副本发送由于在CR拷贝建筑物可能涉及太多工作，诸如读取数据，或从磁盘或从另一高速缓存（“轻重量规则复原块“）。在后一种情况下，请求将给出与可能被在服务器端铺开并恢复CR块创建他自己的所有的变化，这可能涉及开销回滚和清洗和远程回滚段头读取块版本，部分所述“2.1 CR请求和缓冲区等待远程还原段头”。 为了确定哪种类型的CR请求都频繁地进行和结果由CR块服务器返回，视图V $ CR_BLOCK_SERVER进行采样;请参考第二部分，以供参考章节“3.4 V $ CR_BLOCK_SERVER”。 相关统计数据（服务器端）和相关的等待事件：
在集群环境中如果所有的或者一些实例读出最近修改的数据或者从另一个需要读出频繁修改的回滚段，对于undo heads和undo blocks所有的CR请求可能达到50%。 它被辨认去辨析流畅读和修改的表和索引
和确定多数送达的CR块是否为数据或还原段的帮助
理解应用程序的参数文件
在集群中共享数据的并发读写活动是一种常见的活动，一般情况下不会造成性能问题。这取决于服务要求非常多。在某些情况下，需要的100毫秒或更少的响应时间和对于群延迟的公差是有限的。在其他情况下， CPU消耗将被降低以实现最佳的吞吐量。 通常，优化SQL计划和架构，实现良好的本地高速缓存的命中效率，并最大限度地减少I / O将成为性能优化一个成功的策略时，全局缓存CR请求造成性能问题。
该统计表示一个请求的累积结束到端经过时间或延迟。单位为厘秒。每个单独的请求从点定时时提出的请求，直到它完成。请求的开始时间被存储在表示高速缓存数据块的集群范围的状态的全局高速缓存结构。个人计时可以通过打开事件10708跟踪（请参考第二部分，章节“ 6.8 KCL跟踪（事件10708 ）”）。
产生以毫秒为单位的请求的平均往返时间。这种计算是在Statspack报告的缓存融合统计部分中使用，并且如
通常情况下， CR的要求不应该被阻止，他们的等待时间几乎完全被处理和信息时间限制的。
相关统计数据（服务器端）：
相关等待事件：
· 所有全局高速缓存等待这可能导致接收当前块的事件，例如
. gc current block [23]-way or gc current block [busy|congested]
当试图减少花费远程高速缓存访问时间，其考虑到其中一个或多个实例中，供应的大部分块的考虑是很重要的。还应当指出的是，pin的总和，冲洗和发送时间为块投放构成它的服务时间。如果该服务时间是高，更详细的统计可以被用来确定一个可能的性能问题。平均pin的总和，冲洗和发送时间可被计算为平均的时间来处理一个当前块的请求。 在服务器侧的处理可以显著影响整体时间为全局高速缓存访问，其中第一眼可通过比较平均处理进行评估和平均接收时间。 随着有关新等待事件的章节所述，处理时间因争用或负载增加服务器的BAST可以通过分析GC等待事件，造成忙等待的情况下，被诊断列于V $ INSTANCE_CACHE_TRANSFER
该统计表示由本实例提供当前块的请求的计数。全局高速缓存服务器进程（例如LMS0，LMS1等）处理的融合BAST（=阻断异步系统陷阱，该通知机制来释放由全球缓存服务中使用的块），并发送一个数据块作为结果，当保持它。一个当前块的服务时间可能会受 •延迟块运送（如果清除块，它是由30ms的延迟或任何为_GC_DEFER_TIME指定被运前，该请求也将有链接到缓冲区头部，以便快速事件推迟本地处理完成） •冲洗等待重做到磁盘发生 •完成块发送操作单独的统计可用于监控的处理时间为当前块。如果高往返时间（请参考GC当前块接收时间）遇到，这些时间应该进行检查。 单独的统计可用于监控的处理时间为当前块。如果高往返时间（请参考GC当前块接收时间）遇到，这些时间应该进行检查。 相关统计数据： •当前块服务器柱状图（指第二部分，章节“3.5 V $ CURRENT_BLOCK_SERVER”） 相关的统计：
这部分主要讨论操作系统具体的调优和配置相关的问题, 例如使用用户模式的IPC和其他相关操作系统的配置问题。(askmac.cn)
无论IPC协议是否使用, 一个私有网络仅用于RAC和CSS/CRS,也就是这个连接不会用于其他通信， 例如DATA Guard实例的归档日志。在10g中，RAC和CRS的私有网络通信信息存储在OCR。RAC和CRS总是使用相同的私有IP地址。你需要确保信息通信和数据库传输确实使用私有连接，而不是错误的使用公共网络。
如果你不确定经由UDP正用于RAC相关通信的IP地址/NFC, 在SQL*Plus中运行:
select INST_ID,PUB_KSXPIA,PICKED_KSXPIA,NAME_KSXPIA,IP_KSXPIA
from x$ksxpia;
INST_ID PUB_KSXPIA PICKED_KSX NAME_ IP_KSXPIA
———- ———- ———- —– —————-
1 N OCR eth3 140.87.150.21
这个视图将显示哪个IP地址和接口被实例使用，同时显示从哪儿获得信息（OCR，OSD或者CI） 。
另一种比较老的方法是运行
SQL> oradebug setmypid
SQL> oradebug ipc
SQL> oradebug tracefile_name
USER_DUMP_DEST中被写入跟踪文件的信息将显示被使用的IP地址信息；如果是用户模式IPC协议，跟踪文件不会显示IP地址因为可能不是通过IP 传输。
SSKGXPT 0xd8158fc flags SSKGXPT_READPENDING info for network 0
socket no 7 IP 140.87.150.21 UDP 58031
sflags SSKGXPT_UP
为了鉴别用于CRS/CSS的IP地址，运行“ocrdump /tmp/bla” 命令并在转储文件定位”SYSTEM.css.node_numbers.node<n>.privatename”.
自从连接信息存储在OCR中之后，10g不再需要设置cluster_interconnects参数。尽管这个参数支持指定接口间的负载平衡，但是不提供故障转移功能，如果一个接口失效，会当作全部失效并踢出实例。
你仍然可以使用cluster_interconnects 如果是一个IP 地址, 举例来说. 解决网络选择的问题或者出于测试目的对特殊实例使用指定的NIC。
上文提到的，我们不建议在客户环境中使用cluster_interconnects来负载均衡。另外，CRS也不支持负载均衡或者故障转移功能。因此，操作系统供应商应该提供一个负载均衡和故障转移的解决方案。我们不知道NIC 配对/结合/中继测试内部是如何执行的，因此没有配置指南或类似的东西。
就目前为止的这些故障转移和负载均衡解决方案来看，基本上都是预故障转移解决方案和故障转移&负载均衡解决方案，后者是首选之一。底层技术由操作系统供应商Cisco授权, 它可以有不同的名字：HP的Autoport aggregation, IBM的Etherchannel, SUN的Trunking 等等。这些解决方案提供一个逻辑IP给最终用户，他们可以指定RAC和CRS的私有连接信息在安装/DBCA过程中。
在过去，使用IPC协议而不是UDP或者TCP，前者的低延迟是首选它的原因。但这都是过去的事儿了， 事实表明使用HP的HMP 或者SUN的 RSM IPC协议有着一长串的问题，因此我们不再使用这些IPC协议和硬件技术。HP的 RDG (原Compaq Tru64) 运行良好, 推荐我们使用。
因此，通常和首选的建议是使用UDP千兆以太网，HP/UX上的HMP和Solaris上的RSM不鼓励使用。
另一种推荐的网络设置是使用一个交换机即使是2个节点的环境。尽管使用交叉电缆代替交换机比较便宜, 一套多余的交换机可以确保更高的可用性.
为了获得重大的性能提升使用IP基础协议，强烈推荐使用巨型帧。然而, 需要主机网卡和交换机支持9K-frame尺寸。 一个大型尺寸的以太网帧避免了包的分片和重组并且相应的内核CPU开销比更小的信息少。
在主机上, 巨型帧设置：
ifconfig <adapter> mtu 9000
e.g. ifconfig eth2 mtu 9000
这里有两种方法检测和确认9K-framesize是否被使用。例如，运行“ifconfig <adapter>” 在主机上会显示MTU:9000. 接下来的命令也适用于9K-framesize已经被设置。运行 “ping” 和 “traceroute”,通过包大小增加，可以探查MTU的大小。运行 “tracepath”, 它跟踪目的地的路径并沿着路径报告MTU。
例如:
$ ping –s <packet size> –M do <host>[1]
举例来说
$ ping –s 8972 –M do 10.1.1.5, 应该成功并返回:
PING 10.1.1.5 (10.1.1.5) from 10.1.1.4 : 8972(9000) bytes of data.
8980 bytes from 10.1.1.5: icmp_seq=0 ttl=255 time=455 usec
$ ping –s 8973 –M do 10.1.1.5, 应该失败并返回:
PING 10.1.1.5 (10.1.1.5) from 10.1.1.4 : 8973(9001) bytes of data.
ping: sendto: Message too long
$ traceroute <host> <packet size>
举例来说
$ traceroute 10.1.1.5 9000, 应该成功并返回:
traceroute to 10.1.1.5 (10.1.1.5), 30 hops max, 9000 byte packets
1 hprr-5_san (10.1.1.5) 0.335 ms 0.282 ms 0.275 ms
$ traceroute 10.1.1.5 9001, 应该失败并返回:
traceroute to 10.1.1.5 (10.1.1.5), 30 hops max, 9000 byte packets
traceroute: sendto: Message too long
1 traceroute: wrote 10.1.1.5 9000 chars, ret=-1
$ tracepath <host>
举例来说
$ tracepath 10.1.1.5, should report pmtu 9000 along the path and return:
1: [LOCALHOST] pmtu 9000
1: hprr-5_san (10.1.1.5) 0.325ms reached
Resume: pmtu 9000 hops 1 back 1
注意正确的IP地址应该由上面的查询提供，例如，如果私有网络设置MTU 9000，那么私有网络必用来代替公共IP地址。
注意实例可能启动失败如果网络的一个组件不支持大型尺寸的帧。虽然使用不规则的MTU尺寸仍然可以发送和接收大小小于1500 bytes，但是大的数据包交换还是会挂起或者失败。
我们知道’spray’ 工具可以帮助鉴别网络性能问题是由于一个糟糕的网卡还是一个配置错误的网卡。. ‘spray’ 发送大量的宝（包的数量和大小可以通过命令行参数定于）。如果有大量的包丢失，你应该检查网络配置。 ‘spray’工具可以在Solaris 和 HP/UX.上使用。
我们强烈建议在所有集群节点设置网络时间协议（NTP）, 甚至是你在安装RAC之前。这个服务将同步所有节点的时间，并且促进分析基于时间戳的跟踪信息。此外，可能出现一些问题在版本10.2.0.1, 远程复制会出现警告如果远程的节点时间时间提前. 注意调整时间大于15分钟会引起实例被踢出。 强烈建关闭所有实例在时间日期调整之前。.
下面部分提供了指定平台的配置和练习：
因为数据库通常放在裸设备上，防止操作系统不支持集群文件系统强烈建议安装异步I/O设备(asyncdsk) ，创建设备 /dev/async , 并配置内核参数MAX_ASYNC_PORTS 为同时打开的asyncdsk 端口的最大数量，也就是说 MAX_ASYNC_PORTS 限制同时使用/dev/async 的进程的最大数量。作为参考,设置这个参数为参数文件中的PROCESSES+后台进程的数量的和。后台进程在实例启动时会打开/dev/async 两次. 如果达到MAX_ASYNC_PORTS的值,后面的进程会使用同步I/O。
UDP/IPC 也可以用于像HyperFabric 的硬件. HMP 协议不鼓励使用。.
RDG是Oracle10g默认的IPC协议除了在HP Tru64 Unix 上的RAC环境之外。RDG已经专门的设计和优化来消除通常协议（像TCP和UDP）的性能方面的限制。
RDG相关的系统参数使用下面的命令查询：
# /sbin/sysconfig -q rdg
最重要的参数设置成：
| 参数 | 参数值 |
| rdg_max_auto_msg_wires | 必须设置成0。 |
| max_objs | 应设置成至少 <Oracle 进程数量 * 5> 至多为10240或 <Oracle 进程数量 * 70>.
比如: 5120 |
| msg_size | 需要设置成至少<db_block_size>,但是我们建议设置成32768, 因为我们支持每个表空间有不同的数据块大小。 |
| max_async_req | 至少设置成100但256+可能提供更好的性能。 |
| max_sessions | 应该设置成最少< Oracle 进程数量 + 20>。
比如： 500 |
如果因为一些原因UDP必须被取代， 下面的命令展示如何启用/禁用不同的IPC协议。
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk rac_on ioracle
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk rac_on ipc_udp ioracle
alert.log 会指明使用什么协议：
cluster interconnect IPC version:Oracle RDG
IPC Vendor 1 proto 2 Version 1.0
或者
cluster interconnect IPC version:Oracle UDP/IP
IPC Vendor 1 proto 2 Version 1.0
在5.1或者更高版本的系统中, Tru64 支持 CFS 在集群系统中. CFS 是在AdvFS之上, 所以它继承了许多非集群系统的特点。CFS 也支持并发的直接I/O模式为RAC所用。
除了为了得到时间统计（包括RAC统计值）而设置init.ora参数STATISTICS_LEVEL为TYPICAL (默认)之外, /dev/timedev 设备需要创建在聚群的每个节点（如果节点不存在这设备）
# mknod /dev/timedev c 15 0
# chmod ugo+r /dev/timedev (or chmod 644 /dev/timedev)
使用/dev/timedev 也可以避免因为Tru64上的NTP问题导致的实例被踢出的潜在威胁 。
注意:
从Tru64 UNIX V5.1开始, 一个叫做/dev/sysdev0的系统文件可以提供上述功能. 此外, 从Oracle for Tru64 UNIX 9.2.0.4开始, sltrg OSD 被修改打开/dev/sysdev0文件如果 /dev/timedev是无效的话。因此，/dev/timedev不再是必须要创建的设备文件了。
Tru64 UNIX V5.1 或更高版本, 进程指定参数AIO_TASK_MAX_NUM 应该设置成8193。DBWR I/O 操作的最大默认值是8192, 除非另外指定隐藏参数_DB_WRITER_MAX_WRITES。如果你没有设置这个操作系统参数至少为8193，Oracle性能会减少并且可能发生I/O错误。8193这个值是需要的，因为操作系统储备一个AIO请求为自己本身。
注意：
在崩溃恢复和实例恢复中, 我们提交64K异步恢复读。因此，为了更好的恢复性能，我们推荐设置AIO_TASK_MAX_NUM 至少8193.
Tru64 UNIX V5.1A PK6 或更高 和 Tru64 UNIX V5.1B PK2 或 更低, 你必须编辑接下来的/etc/sysconfigtab中的参数:
vfs: fifo_do_adaptive = 0
vm: new_wire_method = 0
vm: vm_bigpg_enabled = 0 (这是默认的)
Tru64 UNIX V5.1B PK4 或者更高的版本, 你必须在/etc/sysconfigtab编辑下列参数：
vfs: fifo_do_adaptive = 0
vm: new_wire_method = 1 (这是默认的)
vm: vm_bigpg_enabled = 0
NEW_WIRE_METHOD = 1 已经认证了上面的操作系统版本和补丁包。
注意：
客户不应该运行Oracle在Tru64 UNIX V5.1B PK3上。同时, 设置FIFO_DO_ADAPTIVE = 0 改善bequeath连接的性能，因为它禁用通过管道批处理数据。最后, 如果NEW_WIRE_METHOD 没有设置成1在上面指定的操作系统版本, AIO 性能会显著下降。实际性能下降50%使用NEW_WIRE_METHOD = 0在Tru64 UNIX V5.1B PK4 或更高版本。
参考Part I, 部分“13 SCN propagation”.
从Oracle在Tru64 UNIX 9.2.0.5以来, _SPIN_COUNT的默认值开始增长按照下面：
640 * < CPU的数量> Wildfire类型系统
320 * < CPU的数量> Marvel 类型系统
512 * < CPU的数量> 所有其他的系统
高于正常闩的休眠和等待时间可能是由于_SPIN_COUNT设置太低。
我们推荐使用UDP通过千兆以太网在Solaris系统上。在过去使用UDP通过SCI网络表现出性能问题并且不支持也不推荐即使是Sun公司。
参考 Part I, 章节 “2.7 gc cr multi block request timeouts and slow performance” 关于UDP缓冲区大小
截至今天AIX 不支持用户模式IPC协议，所以只能选UDP 。这路有一些命令显示和修改UDP发送和接收缓冲区设置：
no -a
no -o udp_sendspace=65536
no -o udp_recvspace=262144
将这些添加到/etc/rc.net确保参数生效在每个重启后。Oracle将信任配置并不再内部调整UDP缓冲区大小。如果udp_sendspace 设置太低, 实例将启动失败并报错“ORA-27301: OS failure message: Message too long”。如果你想设置TCP或UDP相关参数(*_sendspace, *_recvspace) 大于64K, 这些需要参数rfc1323设置成1，举例来说
rfc1323=1
tcp_sendspace=262144
tcp_recvspace=262144
udp_sendspace=65536
udp_recvspace=262144
Oracle10g 支持 UDP IPC 和 TCP IPC. 我们推荐只使用UDP IPC。
为了最好的连接性能，需要增加UDP相关参数, 因为定义的默认值和最大值会禁止SKGXP 进一步增加：
$ /sbin/sysctl net.core.rmem_max
net.core.rmem_max = 131071
$ /sbin/sysctl net.core.wmem_max
net.core.wmem_max = 131071
$ /sbin/sysctl net.core.rmem_default
net.core.rmem_default = 65535
$ /sbin/sysctl net.core.wmem_default
net.core.wmem_default = 65535
推荐这些参数至少 256k:
# sysctl -w net.core.rmem_max=262144
# sysctl -w net.core.wmem_max=262144
# sysctl -w net.core.rmem_default=262144
# sysctl -w net.core.wmem_default=262144
在某些情况下, 例如DB_BLOCK_SIZE>=8k 和 DB_FILE_MULTIBLOCK_READ_COUNT=16, 需要增加参数到 512k。
Redhat 2.1 AS 和更高版本支持操作系统核心异步I/O 在文件系统和裸设备上。内部测试发现在使用异步I/O时， I/O吞吐量巨大增加. 更多关于启动/禁用异步 I/O, 请参考WebIV Note 205259.1.
默认情况下，Oracle10gR1 禁用异步I/O。然而，由于一个bug, 异步 I/O在10.1.0.2将不会启用即使异步 I/O 选项如下 (make -f ins_rdbms.mk async_on).
直到10.1.0.3,变通方案是使用下面命令:
$ make PL_ORALIBS=-laio -f ins_rdbms.mk async_on
对于更大的数据库,需要记住至今为止,RedHat Linux只支持255原始设备。
更多关于linux上的oracle信息可以从linux_us@oracle.com 和 oracle-list@redhat.com (https://listman.redhat.com/mailman/listinfo/oracle-list) 获取。
OS/390或VMS与RAC相关的认证和其他信息，访问rac.us.oracle.com 或 WebIV.
[1] In order to use Ping to verify the MTU sizes, “-M do” must be used to prohibit fragmentation. Otherwise, no matter the value of <packet size>, Ping always succeeds.
本文固定链接：https://www.askmac.cn/archives/hadoop-cluster-installation.html
此文是官方文档翻译，原文链接：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/ClusterSetup.html
这个文档描述了如何安装和配置hadoop集群，从小范围节点拓展到上千个节点。要玩hadoop,你先要再单机上安装上它（参考单机安装hadoop）
安装一个hadoop集群，通常是在集群内所有集群上解压软件，或者根据你的操作系统通过包系统来安装。重点是在于分配硬件的功能。
通常在集群中一个集群被指定为NameNode，另外一个集群作为资源管理器，唯一地。这些都是主要的机器。其他的服务（例如WEB app 代理服务器和 mapreduce 任务历史服务器）通常根据负载，运行在专有的硬件模块上或共享基础。
其余的在集群中的机器，充当数据节点（DataNode）和节点管理者(NodeManager)。这些都是从属的。
Hadoop的Java配置是由两种类型的重要配置文件驱动：
此外，你可以通过设置etc/hadoop/hadoop-env.sh etc/hadoop/yarn-env.sh特定参数的值来控制hadoop查找bin/ 路径下的脚本。
HDFS（分布式系统）守护进程是 nameNode，SecondaryNameNode和DataNode。YARN守护进程是ResourceManager, NodeManager,和 WebAppProxy。如果Mapreduce被使用，那么 mapreduce 任务历史服务器也被运行。对于大型设施，这些通常是在单独的机器上运行。
本文永久地址https://www.askmac.cn/archives/rac-awr-statistics.html
Global Cache Load Profile
| Per Second | Per Transaction | |
| Global Cache blocks received: | 12.06 | 2.23 |
| Global Cache blocks served: | 8.18 | 1.51 |
| GCS/GES messages received: | 391.19 | 72.37 |
| GCS/GES messages sent: | 368.76 | 68.22 |
| DBWR Fusion writes: | 0.10 | 0.02 |
| Estd Interconnect traffic (KB) | 310.31 |
| 指标 | 指标说明 |
| Global Cache blocks received | 通过硬件连接收到远程实例的数据块的数量。发生在一个进程请求一致性读一个数据块不是在本地缓存中。Oracle发送一个请求到另外的实例。一旦缓冲区收到，这个统计值就会增加。这个统计值是另两个统计值的和：Global Cache blocks received = gc current blocks received + gc cr blocks received |
| Global Cache blocks served | 通过硬件连接发送到远程实例的数据块的数量。这个统计值是另外两个统计值的和：Global Cache blocks served = gc current blocks served + gc cr blocks served |
| GCS/GES messages received | 通过硬件连接收到远程实例的消息的数量。这个统计值通常代表RAC服务引起的开销。这个统计值是另外两个统计值的和：GCS/GES messages received = gcs msgs received + ges msgs received |
| GCS/GES messages sent | 通过硬件连接发送到远程实例的消息的数量。这个统计值通常代表RAC服务引起的开销。这个统计值是另外两个统计值的和：GCS/GES messages sent = gcs messages sent + ges messages sent |
| DBWR Fusion writes | 这个统计值显示融合写入的次数。在RAC中，单实例Oracle数据库，数据块只被写入磁盘因为数据过期，缓冲替换或者发生检查点。当一个数据块在缓存中被替换因为数据过期或发生检查点但在另外的实例没有写入磁盘，Global Cache Service会请求实例将数据块写入磁盘。因此融合写入不包括在第一个实例中的额外写入磁盘。大量的融合写入表明一个持续的问题。实例产生的融合写入请求占总的写入请求的比率用于性能分析。高比率表明DB cache大小不合适或者检查点效率低。 |
| Estd Interconnect traffic (KB) | 连接传输的KB大小。计算公式如下：Estd Interconnect traffic (KB) = ((‘gc cr blocks received’+ ‘gc current blocks received’ + ‘gc cr blocks
served’+ ‘gc current blocks served’) * Block size) + ((‘gcs messages sent’ + ‘ges messages sent’ + ‘gcs msgs received’+ ‘gcs msgs received’)*200)/1024/Elapsed Time |
Global Cache Efficiency Percentages (Target local+remote 100%)
| Buffer access – local cache %: | 91.05 |
| Buffer access – remote cache %: | 0.03 |
| Buffer access – disk %: | 8.92 |
| 指标 | 指标说明 |
| Buffer access – local cache % | 数据块从本地缓存命中占会话总的数据库请求次数的比例。在OLTP应用中最希望的是尽可能维持这个比率较高，因为这是最低成本和最快速的获得数据库数据块的方法。计算公式：Local Cache Buffer Access Ratio = 1 – ( physical reads cache + Global Cache blocks received ) / Logical Reads |
| Buffer access – remote cache % | 数据块从远程实例缓存命中占会话总的数据块请求的比例。在OLTP应用中这个比率和Buffer access – local cache的和应该尽可能的高因为这两种方法访问数据库数据块是最快速最低成本的。这个比率的计算方法：Remote Cache Buffer Access Ratio = Global Cache blocks received / Logical Reads |
| Buffer access – disk % | 从磁盘上读数据块到缓存占会话总的数据块请求次数的比例。在OLTP应用中希望维持这个比例低因为物理读是最慢的访问数据库数据块的方式。这个比率计算方法：
1 – physical reads cache / Logical Reads |
Global Cache and Enqueue Services – Workload Characteristics
| Avg global enqueue get time (ms): | 0.0 |
| Avg global cache cr block receive time (ms): | 0.3 |
| Avg global cache current block receive time (ms): | 0.2 |
| Avg global cache cr block build time (ms): | 0.0 |
| Avg global cache cr block send time (ms): | 0.0 |
| Global cache log flushes for cr blocks served %: | 1.2 |
| Avg global cache cr block flush time (ms): | 1.8 |
| Avg global cache current block pin time (ms): | 1,021.7 |
| Avg global cache current block send time (ms): | 0.0 |
| Global cache log flushes for current blocks served %: | 6.9 |
| Avg global cache current block flush time (ms): | 0.9 |
本文永久地址https://www.askmac.cn/archives/rac-awr-statistics.html
| 指标 | 指标说明 |
| Avg global enqueue get time (ms) | 通过interconnect发送消息，为争夺资源开启一个新的全局队列或者对已经开启的队列转换访问模式所花费的时间。如果大于20ms，你的系统可能会出现超时。 |
| Avg global cache cr block receive time (ms) | 从请求实例发送消息到mastering instance（2-way get）和一些到holding instance (3-way get)花费的时间。这个时间包括在holding instance生成数据块一致性读映像的时间。CR数据块获取耗费的时间不应该大于15ms。 |
| Avg global cache current block receive time (ms) | 从请求实例发送消息到mastering instance（2-way get）和一些到holding instance (3-way get)花费的时间。这个时间包括holding instance日志刷新花费的时间。Current Block获取耗费的时间不大于30ms |
| Avg global cache cr block build time (ms) | CR数据块创建耗费的时间 |
| Avg global cache cr block send time (ms) | CR数据块发送耗费的时间 |
| Global cache log flushes for cr blocks served % | 需要日志刷新的CR数据块占总的需要服务的CR数据块的比例。 |
| Avg global cache cr block flush time (ms) | CR数据块刷新耗费的时间 |
| Avg global cache current block pin time (ms) | Current数据块pin耗费的时间 |
| Avg global cache current block send time (ms) | Current数据块发送耗费的时间 |
| Global cache log flushes for current blocks served % | 需要日志刷新的Current数据块占总的需要服务的Current数据块的比例 |
| Avg global cache current block flush time (ms) | Current数据块刷新耗费的时间 |
Global Cache and Enqueue Services – Messaging Statistics
| Avg message sent queue time (ms): | 2,367.6 |
| Avg message sent queue time on ksxp (ms): | 0.1 |
| Avg message received queue time (ms): | 0.3 |
| Avg GCS message process time (ms): | 0.0 |
| Avg GES message process time (ms): | 0.0 |
| % of direct sent messages: | 54.00 |
| % of indirect sent messages: | 44.96 |
| % of flow controlled messages: | 1.03 |
| 指标 | 指标说明 |
| Avg message sent queue time (ms) | 一条信息进入队列到发送它的时间 |
| Avg message sent queue time on ksxp (ms) | 对端收到该信息并返回ACK的时间，这个指标很重要，直接反应了网络延迟，一般小于1ms |
| Avg message received queue time (ms) | 一条信息进入队列到收到它的时间 |
| Avg GCS message process time (ms) | |
| Avg GES message process time (ms) | |
| % of direct sent messages | 直接发送信息占的比率 |
| % of indirect sent messages | 间接发送信息占的比率，一般是排序或大的信息，流控制也可能引起 |
| % of flow controlled messages | 流控制信息占的比率，流控制最常见的原因是网络状况不佳， % of flow
controlled messages应当小于1% |
Wait Event Histogram
| % of Waits | |||||||||
| Event | Total Waits | <1ms | <2ms | <4ms | <8ms | <16ms | <32ms | <=1s | >1s |
| ADR block file read | 208 | 38.0 | 3.4 | 44.7 | 13.9 | ||||
| ADR block file write | 40 | 100.0 | |||||||
| ADR file lock | 48 | 100.0 | |||||||
| ARCH wait for archivelog lock | 3 | 100.0 | |||||||
| ASM file metadata operation | 12.8K | 99.7 | .1 | .0 | .0 | .0 | .2 | .0 | |
| Backup: MML write backup piece | 310.5K | 7.6 | .1 | .1 | 1.3 | 10.4 | 30.2 | 50.2 | .0 |
| CGS wait for IPC msg | 141.7K | 100.0 | |||||||
| CSS initialization | 34 | 50.0 | 47.1 | 2.9 | |||||
| CSS operation: action | 110 | 48.2 | 20.9 | 28.2 | 2.7 | ||||
| CSS operation: query | 102 | 88.2 | 3.9 | 7.8 | |||||
| DFS lock handle | 6607 | 93.9 | .5 | .2 | .0 | .0 | 5.3 | .0 | |
| Disk file operations I/O | 1474 | 100.0 | |||||||
| IPC send completion sync | 21.9K | 99.5 | .1 | .1 | .1 | .0 | .2 | ||
| KJC: Wait for msg sends to complete | 13 | 100.0 | |||||||
| LGWR wait for redo copy | 16.3K | 100.0 | .0 | ||||||
| Log archive I/O | 3 | 33.3 | 66.7 | ||||||
| PX Deq: Signal ACK EXT | 2256 | 99.8 | .1 | .1 | |||||
| PX Deq: Signal ACK RSG | 2124 | 99.9 | .1 | .0 | |||||
| PX Deq: Slave Session Stats | 7997 | 94.6 | .9 | .9 | 2.5 | .8 | .4 | ||
| PX Deq: Table Q qref | 2355 | 99.9 | .1 | ||||||
| PX Deq: reap credit | 1215.7K | 100.0 | .0 | .0 | |||||
| PX qref latch | 1366 | 100.0 | |||||||
| Parameter File I/O | 194 | 94.8 | 1.0 | 1.0 | 1.0 | 1.5 | .5 | ||
Wait Event Histogram：等待时间直方图
Event：等待事件名字
Total Waits：该等待事件在快照时间内等待的次数
%of Waits < 1ms ：小于1ms的等待次数
%of Waits < 2ms ：小于2ms的等待次数
%of Waits < 4ms ：小于4ms的等待次数
%of Waits < 8ms ：小于8ms的等待次数
%of Waits < 16ms ：小于16ms的等待次数
%of Waits < 32ms ：小于32ms的等待次数
%of Waits < =1s ：小于等于1s的等待次数
%of Waits > 1s ：大于1s的等待次数
Parent Latch Statistics
| Latch Name | Get Requests | Misses | Sleeps | Spin & Sleeps 1->3+ |
| Real-time plan statistics latch | 77,840 | 136 | 20 | 116/0/0/0 |
| active checkpoint queue latch | 321,023 | 20,528 | 77 | 20451/0/0/0 |
| active service list | 339,641 | 546 | 132 | 424/0/0/0 |
| call allocation | 328,283 | 550 | 148 | 440/0/0/0 |
| enqueues | 1,503,525 | 217 | 14 | 203/0/0/0 |
| ksuosstats global area | 2,605 | 1 | 1 | 0/0/0/0 |
| messages | 2,608,863 | 141,380 | 29 | 141351/0/0/0 |
| name-service request queue | 155,047 | 43 | 15 | 28/0/0/0 |
| qmn task queue latch | 2,368 | 90 | 78 | 12/0/0/0 |
| query server process | 268 | 30 | 30 | 0/0/0/0 |
| redo writing | 910,703 | 11,623 | 50 | 11573/0/0/0 |
| resmgr:free threads list | 14,454 | 190 | 4 | 186/0/0/0 |
| space background task latch | 11,209 | 15 | 7 | 8/0/0/0 |
Latch Name：闩名称
Get Requests：申请获得父闩的次数
本文永久地址https://www.askmac.cn/archives/rac-awr-statistics.html
Child Latch Statistics
| Latch Name | Child Num | Get Requests | Misses | Sleeps | Spin & Sleeps 1->3+ |
| KJC message pool free list | 1 | 96,136 | 82 | 20 | 62/0/0/0 |
| Lsod array latch | 10 | 2,222 | 153 | 118 | 58/0/0/0 |
| Lsod array latch | 13 | 2,151 | 43 | 14 | 29/0/0/0 |
| Lsod array latch | 4 | 2,066 | 154 | 124 | 59/0/0/0 |
| Lsod array latch | 5 | 1,988 | 105 | 44 | 63/0/0/0 |
| Lsod array latch | 9 | 1,734 | 95 | 32 | 64/0/0/0 |
| Lsod array latch | 2 | 1,707 | 88 | 38 | 55/0/0/0 |
| Lsod array latch | 11 | 1,695 | 88 | 32 | 57/0/0/0 |
| Lsod array latch | 6 | 1,680 | 158 | 126 | 64/0/0/0 |
| Lsod array latch | 12 | 1,657 | 155 | 111 | 65/0/0/0 |
| Lsod array latch | 7 | 1,640 | 90 | 34 | 59/0/0/0 |
| Lsod array latch | 1 | 1,627 | 169 | 153 | 46/0/0/0 |
| Lsod array latch | 3 | 1,555 | 87 | 36 | 54/0/0/0 |
| Lsod array latch | 8 | 1,487 | 127 | 88 | 57/0/0/0 |
| cache buffers chains | 47418 | 354,313 | 391 | 4 | 387/0/0/0 |
| cache buffers chains | 8031 | 337,135 | 250 | 8 | 242/0/0/0 |
| cache buffers chains | 78358 | 305,022 | 528 | 9 | 519/0/0/0 |
| cache buffers chains | 6927 | 241,808 | 129 | 4 | 125/0/0/0 |
Latch Name：闩名称
Child Num：
Get Requests：
Misses：
Sleeps：
Spin&Sleeps 1->3+：
| Cache | GES Requests | GES Conflicts | GES Releases |
| dc_awr_control | 11 | 5 | 0 |
| dc_global_oids | 5 | 0 | 0 |
| dc_histogram_defs | 215 | 1 | 707 |
| dc_objects | 90 | 9 | 0 |
| dc_segments | 79 | 10 | 73 |
| dc_sequences | 35,738 | 37 | 0 |
| dc_table_scns | 6 | 0 | 0 |
| dc_tablespace_quotas | 907 | 77 | 0 |
| dc_users | 10 | 0 | 0 |
| outstanding_alerts | 576 | 288 | 0 |
Cache：字典缓存类名
GES Requests：
GES Conflicts：
GES Releases：
Library Cache Activity (RAC)
| Namespace | GES Lock Requests | GES Pin Requests | GES Pin Releases | GES Inval Requests | GES Invali- dations |
| ACCOUNT_STATUS | 242 | 0 | 0 | 0 | 0 |
| BODY | 0 | 1,530,013 | 1,530,013 | 0 | 0 |
| CLUSTER | 74 | 74 | 74 | 0 | 0 |
| DBLINK | 246 | 0 | 0 | 0 | 0 |
| EDITION | 311 | 311 | 311 | 0 | 0 |
| HINTSET OBJECT | 186 | 186 | 186 | 0 | 0 |
| INDEX | 152,360 | 152,360 | 152,360 | 0 | 0 |
| QUEUE | 223 | 9,717 | 9,717 | 0 | 0 |
| SCHEMA | 255 | 0 | 0 | 0 | 0 |
| SUBSCRIPTION | 0 | 26 | 26 | 0 | 0 |
| TABLE/PROCEDURE | 275,215 | 3,023,083 | 3,023,083 | 0 | 0 |
| TRIGGER | 0 | 384,493 | 384,493 | 0 | 0 |
Namespace：library cache 的命名空间
GES Lock Requests：
GES Pin Requests：
GES Inval Requests：
GES Invali-dations：
Interconnect Ping Latency Stats
| Target Instance | 500B Ping Count | Avg Latency 500B msg | Stddev 500B msg | 8K Ping Count | Avg Latency 8K msg | Stddev 8K msg |
| 1 | 1,138 | 0.20 | 0.03 | 1,138 | 0.20 | 0.03 |
| 2 | 1,138 | 0.17 | 0.04 | 1,138 | 0.20 | 0.05 |
| 3 | 1,138 | 0.19 | 0.22 | 1,138 | 0.23 | 0.22 |
| 4 | 1,138 | 0.18 | 0.04 | 1,138 | 0.21 | 0.04 |
Target Instance：目标实例
500B Ping Count：
Avg Latency 500B msg：
Stddev 500B msg：
8K Ping Count：
Avg Latency 8K msg：
Stddev 8K msg：
Interconnect Throughput by Client
| Used By | Send Mbytes/sec | Receive Mbytes/sec |
| Global Cache | 0.10 | 0.20 |
| Parallel Query | 0.02 | 0.06 |
| DB Locks | 0.09 | 0.09 |
| DB Streams | 0.00 | 0.00 |
| Other | 0.02 | 0.01 |
Used By：主要消费者
Send Mbytes/sec：发送Mb/每秒
Receive Mbytes/sec：接收Mb/每秒
Interconnect Device Statistics
| Device Name | IP Address | Public | Source | Send Mbytes/sec | Send Errors | Send Dropped | Send Buffer Overrun | Send Carrier Lost | Receive Mbytes/sec | Receive Errors | Receive Dropped | Receive Buffer Overrun | Receive Frame Errors |
| bondib0 | 192.168.10.8 | NO | cluster_interconnects parameter | 0.00 | 0 | 0 | 0 | 0 | 0.00 | 0 | 0 | 0 |
Device Name：设备名称
IP Address：IP地址
Public：是否为公用网络
Source：来源
Send Mbytes/sec：发送MB/每秒
Send Errors：发送错误
Send Dropped：
Send Buffer Overrun：
Send Carrier Lost：
Receive Mbytes/sec：
Receive Errors：
Receive Dropped：
Receive Buffer Overrun：
Receive Frame Errors：
Dynamic Remastering Stats
| Name | Total | per Remaster Op | Begin Snap | End Snap |
| remaster ops | 29 | 1.00 | ||
| remastered objects | 40 | 1.38 | ||
| replayed locks received | 1,990 | 68.62 | ||
| replayed locks sent | 877 | 30.24 | ||
| resources cleaned | 0 | 0.00 | ||
| remaster time (s) | 5.0 | 0.17 | ||
| quiesce time (s) | 1.7 | 0.06 | ||
| freeze time (s) | 0.6 | 0.02 | ||
| cleanup time (s) | 0.7 | 0.02 | ||
| replay time (s) | 0.2 | 0.01 | ||
| fixwrite time (s) | 1.3 | 0.04 | ||
| sync time (s) | 0.5 | 0.02 | ||
| affinity objects | 365 | 367 |
Name：
Total：
Per Remaster Op：
Begin Snap：
End Snap：
本文地址：https://www.askmac.cn/archives/mysql-client-involve.html
MySQL客户端程序通过命令行调用，如使用Windows命令行窗口或Linux Shell Teminal。当你调用了客户端程序，你可以在程序命令后指定命令项来控制其行为。命令项可以设置在配置项文件中。一些命令项可用于告知客户端如何连接MySQL Server，其它一些则告知程序如何执行相应操作。
本节中例子都使用mysql程序，不过一般在mysql程序上可用的原则上对其它命令行客户端程序也可用。
为了了解MySQL程序所支持的命令项，可以通过调用 --help项。如，了解如何使用mysql程序:
shell> mysql --help
查看程序当前版本，可以使用 --version项。如当前mysql客户端程序版本为：
虽然说没有必要要求客户端运行程序的版本和服务端保持一致。多数情况下，高版本或低版本的客户端程序都能够成功连接到服务端。不过，不同版本可能会由于一些bug而导致问题，因此最好使用匹配兼容的版本。
通过本节，您应该能够：
方案(Schema)是数据库对象的集合。一个Schema由一位数据库使用者所拥有，并且名称与该用户相同。Schema对象是直接参照数据库数据的逻辑结构，而其所包含的结构有表、视图及索引等。
注意: 表空间与Schema之间并无关系。同一Schema中的对象，可以位于不同的表空间，而一个表空间可以保存来自不同Schema的对象。
您可以使用SQL或Oracle Enterprise Manager(EM)来建立和操作Schema对象。当您使用Enterprise Manager时，EM会为您产生基础SQL。
Oracle数据库11g ocm认证大师考试信息
测试号： 11GOCM
相关认证： Oracle Database 11g Administrator Certified Master
测试产品版本：11g
测试所需时间：2天
考试注册
考试准备
OCM考试并不包含任何必须的参加的课程。你需要为此次认证进行有计划的实践演练或确保就认证中的考点任务已经具备相应的在职经验。由于Oracle大学提供的课程不会涵盖所有考试的考点，因此你需要做一个综合全面的考前准备。
其他资源及信息
考试提供：
考试注意
