引言：
本篇文章主要介绍Oracle数据库的数据字典、数据字典是Oracle数据库后台具有只读参考表和视图中最重要的部分，包括动态性能视 图，他们是一些会在Oracle处于打开状态时不断更新的特殊视图，数据字典对于DBA来讲非常重要，站在数据仓库角度，它就类似数据仓 库的元数据管理，想想平时我们做用户，模式对象，存储结构，某个特定数据需求检索，想想用户审计相关信息，想想row cache lock等 待事件，在想想每次发出ddl语句是不是都需要检索数据字典，本章我们不聊用户访问数据字典的概述和介绍，类似DBA_ ,USER_,ALL_这 些基础的概念知识，我们主要聊的是数据字典如何定位和帮助优化数据库的方法论。
日常生产环境，在数据库的初始配置之后，定期监视和调优实例对于消除任何潜在的性能瓶颈非常重要。本章讨论的重点就是使用 Oracle v$ 动态视图的调优过程。
本次公众号文章分享问题重点和方向：
☺实例优化步骤 。
☺解释Oracle数据库统计信息 。
☺等待事件统计。
实例优化步骤和方法论：
下面是Oracle performance方法中的主要步骤，例如调优:
☆定义问题：从客户现场获得关于性能问题范围和问题反馈
☆检查主机系统和Oracle数据库统计信息：
1.在获得一组完整的操作系统、数据库和应用程序统计信息之后，检查数据以寻找性能 问题的任何证据。
2.考虑常见性能错误的列表，以查看收集的数据是否表明这些错误导致了问题。
3.使用收集到的性能数据构建系 统上发生问题的概念模型。这里其实我推荐大家了解思维导图，对于无论学习哪种技术都尤为重要，思维导图，思维导图，思维导图，重要的事情说三遍。
☆实施和度量变更：提出要进行的更改和实现更改的预期结果。然后，实现更改并度量应用程序性能 。
☆确定是否满足步骤1中定义的性能目标。如果没有，那么重复步骤2和步骤3，直到达到性能目标。
定义问题：
☆在尝试实现解决方案之前，必须对调优工作的目的和问题的性质有一个相对清晰的思路和了解。没有这种理解，就几乎不可能实现有 效的更改。在此阶段收集的数据有助于确定下一步要采取的措施以及要检查哪些证据。
☆性能数据收集：
1.确定绩效目标：可接受绩效的衡量标准是什么?每小时或每秒有多少事务响应时间将满足所需的性能水平?
2.确定问题的范围：例如，整个实例是否很慢?它是特定的应用程序、特定的操作，还是单个用户?，DBA思路应该放在某个具体 的session上还是需要全局考虑，是特定sql问题，还是某个等待事件导致？
3.确定问题发生的时间：性能问题只在业务高峰时段出现吗?还是某个固定业务时间?还是阶段性时快时慢？
4.识别任何更改：确定自性能可接受以来发生了哪些变化。这可能会迅速缩小潜在的原因。例如，操作系统软件、硬件、应用程 序软件或Oracle数据库版本是否已经升级?系统中加载了更多的数据，还是数据量或用户数量增加了，或者某个变更sql上线，或者业务激 增导致的各种问题。
检查主机操作系统：
☆查看数据库服务器和数据库实例上的负载。考虑操作系统、I/O子系统和网络统计信息，因为检查这些领域有助于确定哪些可能值得 进一步研究的方向。在多层系统中，还要检查应用服务器中间层主机。检查主机硬件通常可以很好地显示系统中的瓶颈。这决定了哪些 Oracle数据库性能数据可以用于交叉引用和进一步诊断。
☆CPU使用率：如果有大量的空闲CPU，那么可能会出现I/O、应用程序或数据库瓶颈。注意，等待I/O应该被视为空闲CPU。如果 CPU使用率很高，则确定是否有效地使用了CPU。大部分CPU使用情况是由少数使用高CPU的程序造成的，还是由均匀分布的工作 负载消耗CPU ?如果有少量高使用率的程序使用CPU，那么可以查看程序来确定原因。检查某些进程是否单独使用一个CPU的全部 功率。根据进程的不同，这可能表明可以通过划分或并行化进程活动来处理CPU或进程绑定的工作负载。
☆常见的情况：如果少数Oracle进程消耗了大部分CPU资源，那么使用SQL_TRACE和TKPROF来标识SQL或PL/SQL语句，以查看 是否可以调优特定的查询或PL/SQL程序单元。例如，如果SELECT语句的执行涉及缓存中数据的多次读取(逻辑读取)，可以通过更 好的SQL优化来避免，那么它可能是cpu密集型语句，然后我们来看动态性能视图在cpu层面的问题定位：
☆V$SYSSTAT显示所有会话的Oracle数据库CPU使用情况。此会话统计数据所使用的CPU显示了所有会话所使用的聚合CPU。解 析时间cpu统计数据显示用于解析的总cpu时间 。
☆V$SESSTAT显示每个会话的Oracle数据库CPU使用情况。使用此视图可以确定哪个会话使用的CPU最多。
☆V$RSRC_CONSUMER_GROUP显示Oracle数据库资源管理器运行时每个使用者组的CPU利用率统计信息。
☆解释CPU统计数据：认识到CPU时间和实时时间是不同的。对于8个CPU，对于任何给定的实时分钟，都有8分钟的CPU时间可 用。在Windows和UNIX上，这可以是用户时间，也可以是系统时间(Windows上的特权模式)。因此，系统上所有进程(线程)所使 用的平均CPU时间在每一分钟的实时时间间隔中可能大于一分钟。
☆在任何给定的业务时刻，我们都知道Oracle数据库在系统上使用了多少时间。因此，如果有8分钟可用，而Oracle数据库使用了 其中的4分钟，那么就知道Oracle使用了所有CPU时间的50%。如果我们的业务流程没有消耗这些时间，那么其他一些流程会消耗 这些时间。确定正在使用CPU时间的进程，找出原因，然后尝试优化它们。
☆如果CPU使用率均匀地分布在许多Oracle服务器进程上，需要检查V$SYS_TIME_MODEL视图，以帮助准确理解大部分时间都花 在了哪里。
确定I O问题
☆过度活跃的I/O系统可以通过磁盘队列长度大于2或磁盘服务时间超过20-30ms来证明。如果I/O系统过于活跃，那么检查可能受益于 在更多磁盘上分布I/O的潜在热点情况。还要确定是否可以通过降低使用这些资源的程序的资源需求来减少负载。如果I/O问题是由Oracle 数据库引起的，那么可以开始进行I/O调优。如果Oracle数据库不使用可用的I/O资源，则标识正在使用的进程
☆检查V$SYSTEM_EVENT中的Oracle等待事件数据，看看上面的等待事件是否与I/O相关。与I/O相关的事件包括 db file sequential read, db file scattered read, db filesingle write, db file parallel write, and log file parallel write。这些都是针对 数据文件和日志文件执行的与I/O对应的事件。如果这些等待事件中有任何一个对应于高平均时间，那么就需要调查I/O争用。
☆将主机I/O系统数据与AWR中的I/O部分交叉引用分析，以识别热数据文件和表空间。还可以将操作系统报告的I/O时间与Oracle 数据库报告的时间进行比较，看看它们是否一致。
☆I/O问题也可以通过与非I/O相关的等待事件表现出来。例如，很难在缓冲区缓存中找到空闲缓冲区，或者日志刷新到磁盘的等待 时间过长，也可能是I/O问题的症状。在研究是否应该重新配置I/O系统之前，先确定是否可以减少I/O系统上的负载。
☆为了减少Oracle数据库引起的I/O负载，使用以下视图检查数据库发出的所有I/O调用所收集的I/O统计信息比较有帮助同志们：
1.V$IOSTAT_CONSUMER_GROUP：V$IOSTAT_CONSUMER_GROUP视图捕获消费组的I/O统计信息。如果启用了Oracle数据 库资源管理器，那么将捕获当前启用资源计划的所有使用者组的I/O统计信息 2.V $ IOSTAT_FILE：V$IOSTAT_FILE视图捕获正在或已经被访问的数据库文件的I/O统计信息。SMALL_SYNC_READ_LATENCY 列显示单个块同步读取的延迟(以毫秒为单位)，它直接转换为客户机在转移到下一个操作之前需要等待的时间。这定义了基于当前负载的 存储子系统的响应能力。如果关键数据文件有很高的延迟，我们可能需要考虑重新定位这些文件，以改善它们的服务时间。要计算延迟统 计信息，可以使用timed_statistics。
3.V $ IOSTAT_FUNCTION：V$IOSTAT_FUNCTION视图捕获数据库函数(如LGWR和DBWR)的I/O统计信息。
☆I/O可以由具有不同功能的各种Oracle进程发出。顶级数据库函数在V$IOSTAT_FUNCTION视图中分类。在出现I/O函数冲突的情 况下，I/O被放在具有较低FUNCTION_ID的bucket中。例如，如果XDB从缓冲区缓存发出I/O，则I/O将被分类为XDB I/O，因为它 具有较低的FUNCTION_ID值。任何未分类的函数都放在other bucket中。可以通过查询V$IOSTAT_FUNCTION视图来显示 FUNCTION_ID层次结构。
☆这些V$IOSTAT视图包含用于单个和多个块读写操作的I/O统计信息。单个块操作是小于或等于128 kb的小型I/Os。多块操作是大 于128 kb的大型I/Os。对于这些操作，我们收集了以下统计数据即可：会话sid,总等待时间(以毫秒为单位,执行的等待数(对于使用者 组和函数),每个操作的请求数,读取单个和多个块字节的数目,写入的单个和多个块字节的数目。
等待事件：
☆等待事件是由服务器进程或线程递增的统计信息，表示它必须等待事件完成后才能继续处理。等待事件数据揭示了可能影响性能的各 种问题的症状，例如latch contention, buffer contention, and I/O contention。请一定要记住，这些只是问题的症状，都是表象，而不是真正的原因：
☆等待事件被分组到class中。等待事件类包括：Administrative, Application, Cluster, Commit, Concurrency, Configuration, Idle, Network, Other, Scheduler, System I/O, and User I/O. 为了最小化用户响应时间，需要减少服务器进程等待事件完成所花费的时间。不是所有的等待事件都有相同的等待时间。因此，更重要的 是检查等待时间最长的事件，而不是等待出现次数较多的事件。通常，至少在监视性能时，最好将动态参数TIMED_STATISTICS设置为 true。本文中对该参数不做详细介绍。
☆包含等待事件统计信息的动态性能视图，可以查询这些动态性能视图以获得等待事件统计信息。
☆V $ACTIVE_SESSION_HISTORY：V$ACTIVE_SESSION_HISTORY视图显示活动数据库会话活动，每秒取样一次。
☆V SESS_TIME_MODEL和V $SYS_TIME_MODEL：V$SESS_TIME_MODEL和V$SYS_TIME_MODEL视图包含时间模型统计信 息，包括数据库调用花费的总时间DB time。
☆V $ SESSION_WAIT:V$SESSION_WAIT视图显示关于每个会话的当前或最后一次等待的信息(例如等待ID、类和时间) V$SESSION视图显示关于每个当前会话的信息，并包含与V$SESSION_WAIT视图中发现的相同的等待统计信息。如果适用,这种 观点也包含详细信息会话正在等待的对象(例如对象编号、块号、文件编号,和行号),阻止会话负责当前的等待(如阻止会话ID,状态,和 类型),和等待的时间。
☆V$SESSION_EVENT：V$SESSION_EVENT视图提供了会话启动以来一直等待的所有事件的摘要 V$ SESSION_WAIT_CLASS：V$SESSION_WAIT_CLASS视图提供每个会话在每个等待事件类中花费的等待次数和时间 。
☆V$ SESSION_WAIT_HISTORY：V$SESSION_WAIT_HISTORY视图显示关于每个活动会话的最近10个等待事件的信息(例如事件 类型和等待时间)。
☆V$ SYSTEM_EVENT：V$SYSTEM_EVENT视图提供了实例启动以来等待的所有事件的摘要。
☆V$ EVENT_HISTOGRAM：V$EVENT_HISTOGRAM视图显示一个直方图，其中显示了基于事件的等待数量、最大等待和总等待 时间。 ☆V$ FILE_HISTOGRAM：V$FILE_HISTOGRAM视图显示每个文件在单块读取期间等待的时间的直方图。
☆V$ SYSTEM_WAIT_CLASS：V$SYSTEM_WAIT_CLASS视图提供实例范围内的等待次数和在每个等待事件类中花费的时间总数。
☆在执行响应性性能调优时，研究等待事件和相关的计时数据。针对它们列出的时间最长的事件通常是性能瓶颈的排查重点。例如，通过查看V$SYSTEM_EVENT，可能会注意到许多缓冲区繁忙等待。可能是许多进程正在插入到同一个块中，它们必须相互等 待才能插入。解决方案可以是对所讨论的对象使用自动段空间管理或分区。
☆每当Oracle进程等待某些东西时，它都会使用一组预定义的等待事件记录等待。这些等待事件分组在等待类中。Idle wait类将进程在没有工作要做并等待执行更多工作时等待的所有事件分组。非空闲事件表示等待资源或操作完成所花费的非生产时间。
关注等待事件的链信息：
☆buffer busy waits:属于：buffer cache/DBWR范畴，可能原因：取决于缓冲区类型。例如，索引块的等待可能由基于升序序列 的主键引起，在发生问题时可以检查V$SESSION，以确定争用块的类型。
☆free buffer waits:属于：buffer cache/DBWR I/O范畴，可能原因：dbwr写入性能过慢，或者buffer cache设置过小导致，使 用操作系统统计信息检查写入时间。检查缓冲区缓存统计数据，以确定缓存太小 。
☆db file scatered read:属于：I/O or SQL语句范畴，可能原因：I/O子系统问题或者慢sql引起，比如全表扫描，V$SQLAREA， 看看是否有SQL语句执行许多磁盘读取。交叉检查I/O系统和V$FILESTAT的低读取时间。
☆db file sequential read:属于：I/O or SQL语句范畴，可能原因：I/O子系统问题或者慢sql引起，比如索引全扫描，索引范围扫 描，行迁移，行链接，V$SQLAREA，看看是否有SQL语句执行许多磁盘读取。交叉检查I/O系统和V$FILESTAT的低读取时间。
☆enqueue locks wait class:属于：locks类型，首先要定义队列的类型，可以通过v$enqueue_stat检索。
☆library cache latch waits:属于：latch争用范畴，可能原因：sql解析期间或者共享游标期间，检查V$SQLAREA，看看是否有解 析调用相对较多的SQL语句或子游标较多的SQL语句(列VERSION_COUNT)。检查V$SYSSTAT中的解析统计信息及其对应的每秒速 率 。
☆log buffer space:属于：log buffer I/O范畴：可能原因：I/O子系统问题或者log buffer过小导致，检查V$SYSSTAT中的统计 重做缓冲区分配重试。检查存放在线重做日志的磁盘，以查看资源争用情况。
总结： 本篇文章为第一篇开篇，所以理论知识可能过于枯燥乏味，后期文章会陆续进行不同等待事件，包括如何结合AWR来分析等待事件的 文章，敬请期待！欢迎入群！
