6、session和system 统计

    使用基于V$SYSSTAT的系统统计使得基于平均的Database描述成为可能。它是很多通过各种工具和方法获得Database的度量和比率的基础，例如AWR、statspack和Database control。

    为了进一步对sessions进行深化的了解，V$SESSTAT视图是非常有用的。此外，如果使用了MODULE、ACTION模式的统计，将更有效。

    V$SEGMENT_STATISTICS对于RAC环境也非常重要，因为它跟踪了CR的数量以及object当前获得的blocks

    RAC相关的统计可以被分为以下几组：

    *  Global cache service 统计：gc cr blocks received, gc cr block recevie time等

    *  Global Enqueue service 统计：global enqueue gets等

    *  messages发送的统计：gcs messages sent和ges messages sent

    可以通过查询V$ENQUEUE_STATISTICS确定哪个队列对Database service时间和最终的响应时间有最大的影响。

    V$INSTANCE_CACHE_TRANSFER显示了每个block类中有多少current和CR blocks从Instance中接受，包括多少传输引起延迟。

    7、RAC tuning的tips

    首先，在RAC环境中，必须先利用传统的调节技术对每个Instance进行调节，此外，下面的内容也很重要：

    *  尽量避免较长的全表扫描来缩小GCS的请求。由Global CR请求引起的开支主要是因为当所查询的结果在本地cache中不存在，先尝试在其他cache中尝试找到相应数据。

    *  自动段空间管理可以给table blocks提供Instance 关联（affinity）

    *  增加sequences的caches改善Instance关联的通过sequences获得索引关键字的值的性能。

    *  当把range或是list类型的partitioning和data-dependent routing相结合，可以有效的提高性能。

    *  hash partitioning可有效降低buffer busy的冲突，使得buffer访问分布格局松散，可以使buffers用于更多的并发访问。

    *  在RAC中，library cache和row cache操作都是全局协调的。所以过度的解析意味着额外的互联传输。当packages或是procedure需要被重新编译时，需要以排他模式获得library cache locks。

    *  因为transaction locks 是全局协调的，在RAC中，也应的到特殊的对待。例如使用tables代替Oracle sequences产生唯一numbers是不推荐的，可能引起严重的冲突，即使是在single Instance系统中。

    *  选择性不好的indexes不会提高查询性能，反而会降低DML操作的性能。在RAC环境中，unselective index blocks可能导致Instance间的冲突，增加cache对indexes传输的的频度。

    8、index block冲突的思考

    由于index多数是单调递增的，往往造成热块争用的问题；而且对于大量的insert操作，可能引起频繁的splits；所有leaf block的访问都是通过root block的。所以index可能造成性能的降低。对此：

    *  全局索引hash partitioning

    *  增加sequence cache，如果必要的话

    9、undo block 考虑

    当index blocks包含了从多个Instances发起的事务被频繁的读，过度的undo block传输和undo buffers的争用经常会发生。当一个select语句需要读取一个block，该block正被一个active的事务使用，就不得不用undo来重建一个CR版本。如果block所在的active 事务属于不只一个Instance，则需要结合本地和远程undo information用于一致读，依据被多个Instances修改的index blocks的数量和transaction的并发，undo block的传输可能成为瓶颈。

    这多发生在频繁读取近期插入的数据但提交不频繁的应用中。对此应：

    *  使用shorter transaction从而降低这样的可能性：从cache中获得的index block含有未提交的data，从而降低访问undo information用于一致读的可能

    *  增加sequence cache size，从而减少需要进行远程undo 信息组合的需求。

    10、高水位线的考虑

    数据的insert操作是业务领域的主要功能，新的blocks需要频繁的分配给segment。如果data的insert操作比率较高，如果没有找到空闲空间时，需要申请新的blocks。这需要获得相应的high-water mark（HWM）队列。

    因此，最为普遍的状况为：

    *  较高比率的队列等待时间 enq: HW – contention

    *  较高比率的等待时间对于 gc current grant events

    前者是HWM队列序列化的结果，后者是由于当前访问新的data blocks是需要对新的blocks进行操作。在RAC环境中，这个空间管理操作的时间长短是与获得HW队列和获得所有新的blocks的Global locks所用的时间成比例的。这个时间在普通环境中比较小，因为在访问新的blocks时是不存在任何冲突的。然而，这种冲突可能会出现在有大量data load的业务需求中。对此，建议在本地管理及自动空间管理segments中定义一致的较大的extent size，从而适当解决相应的问题。

    11、automatic workload repository

    1）overview

    AWR是Oracle Database 10g提供的基础服务工具，用于收集、维护和应用统计信息来检测问题并进行自我的调节。

    AWR主要由两部分组成：

    *  一个在内存的统计收集设施，由Oracle Database 10g使用并收集统计信息。这些统计被存储在内存中，可以通过动态性能视图查看到（V$）

    *  AWR snapshots 代表了设备的持久部分。可以通过data dictionary视图和Database control来访问。

    处于以下几个原因，统计需要保存在永久的设备中：

    *  统计需要用于激活Instance crashes

    *  一些分析需要历史数据作为基线的比较

    *  内存的溢出：当由于内存不足，旧的统计数据需要被新的统计数据替换时，可以将旧的统计数据存储在磁盘上以备后用

    统计的内存版本由新的后台进程manageability monitor（MMON）定期的传输的disk上。通过AWR，Oracle Database提供了自动捕获历史统计data的方法，无需DBA干涉。

    2）AWR tables

    AWR包括两类表：

    *  元数据表：用于控制、处理、描述AWR 表。例如，Oracle Database 使用元数据表来确定何时执行snapshots，并将什么数据捕获到disk上。此外，元数据包含了snapshots_id和相应通讯时间之间的映射。

    *  历史统计表：存储了Oracle Database的历史统计信息。每个snapshots就是在特定时间点捕获的内存中的Database 统计数据。
AWR表的names都有 一个WRx$前缀，其中x指明了tables的种类：
    
    *  WRM$ 表存储了AWR中的元数据

    *  WRH$表中存储了历史数据和snapshots

    可以是使用字典视图来查询AWR数据。在AWR中任何相关的历史信息有DBA_HIST_的前缀

    AWR使用分区用于有效的查询和数据的清理。snapshots tables是按照以下分类组织的：file 统计、一般系统统计、并发统计、Instance调节统计、SQL 统计、segment 统计、 undo 统计、time-model 统计、恢复统计和RAC统计。

    3）在RAC中的AWR snapshots

    在RAC环境中，每个AWR snapshot是从所有的活动的Instances获得data的。从每个活动的Instances获得的每个snapshot数据集合是大致来自相同的时间点的。此外，每个Instance的数据是单独存储的，是以Instance的标识符来区分的。例如，buffer_busy_wait统计显示了在每个Instance上buffer waits的次数。AWR不会存储cluster中的合计数据。换句话说，data是存放在各自的Instance上的。

    由AWR产生的统计snapshots可以用于评估、产生报告显示data 摘要。

    12、statspack 和AWR

    可以通过手工的对statspack操作获得历史统计数据。但是将statspack获得的数据迁移到AWR中是不支持的，也不存在为其创建的视图

    13、Automatic Database diagnosis monitor

    默认下，Database每隔60分钟，会自动的从SGA中捕获相应的统计信息，并将其以snapshots的形式存储在AWR中。这些snapshots被存储在disk上，和statspack snapshots是一致的，但比statspack的信息更精确。此外，ADDM是通过在每个Database Instance中的新的MMON进程自动运行相应的计划，来主动找到问题的所在。每次获得一个snapshot。ADDM会被触发执行一个与上一个snapshots进行阶段一致性比较的操作。

    每个ADDM分析被存储在AWR中（WRI$表）也可通过EM访问。

    1）ADDM问题分类

    ADDM使用树形结构代表所有可能需要调节的问题。该tree是基于新的等待和时间统计模式的。树根代表的是Database当前的症状。