AWR报告详细分析

合集下载

OracleAwr报告_awr报告解读_基础简要信息

OracleAwr报告_awr报告解读_基础简要信息导出关于awr报告的导出，上⼀篇博客已经进⾏过讲述了。

博客链接地址：这⾥就不再赘述。

各个字段的含义 awr报告的HTML报告，可以在⽹页上直接打开。

这⾥，按照每⼀部分介绍下awr报告的各个字段。

1.报告基本信息这⼀部分，是报告的⼀些基本信息。

分别包括：上⾯部分，数据库物理环境相关信息。

第⼀⾏，DB Name 数据库名（数据库名是存储在控制⽂件中，代表数据库所有物理⽂件的总称）。

DB Id 数据库id（数据库的dbid可能在数据库⽂件恢复中需要⽤到，查询数据库DB Id的sql语句为：select dbId from v$database;）。

Instance 实例名（实例名（sid），写数据库地址的时候，192.168.*.*:1521/orcl 这⾥的orcl就是实例名）初始实例编号（暂时不知道⼲什么⽤的，欢迎指导）。

Startup Time 数据库启动时间（本次导出awr报告对应时段的数据库启动时间）。

Release 数据库版本（不同的版本awr报告不全⼀样，这⾥是11.2版本的数据库）。

RAC real application cluster 数据库⾃⼰的集群系统（分布式数据库，安装设置好集群后，从集群的任何⼀个节点数据库都可以同步到其他节点，这⾥没有开启）第⼆⾏，HostName 服务器名（oracle所在服务器的名称，链接的时候需要验证的⼀个信息）。

Platform 操作系统（orale的安装环境，什么系统，多少位）。

CPUs（服务器多少颗cpu）。

Cores（服务器⼏核）。

Sockets （主板上CPU插槽个数）Memory (GB) 内存⼤⼩。

下⾯部分，快照信息。

snap id 快照id snap time快照时间session会话Cursors/Session游标/ 会话begin Snap(起始快照)end snap （终⽌快照）elapsed: (跨度)DB TIme（请求时间）其中，快照起始/终⽌时间和起始/终⽌Id是创建awr报告的时候⾃⼰选的。

最详尽的AWR报告详细分析

AWR报告详细分析AWR 是 Oracle 10g 版本推出的新特性，全称叫Automatic Workload Repository-自动负载信息库, AWR 是通过对比两次快，照(snapshot)收集到的统计信息，来生成报表数据，生成的报表包括多个部分。

WORKLOAD REPOSITORY report forDB Name DB Id Instance Inst num Release RAC HostICCI 1314098396 ICCI1 1 10.2.0.3.0 YES HPGICCI1Snap Id Snap Time Sessions Cursors/SessionBegin Snap: 2678 25-Dec-08 14:04:50 24 1.5End Snap: 2680 25-Dec-08 15:23:37 26 1.5Elapsed: 78.79 (mins)DB Time: 11.05 (mins)Elapsed 时间，说明数据库比较空闲。

db time= cpu time + wait time（不包含空闲等待）（非后台进程）说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间DB time = cpu time + all of nonidle wait event time在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利用率只有大约2%（1.4/79）。

说明系统压力非常小。

列出下面这两个来做解释：Report A:Snap Id Snap Time Sessions Curs/Sess--------- ------------------- -------- ---------Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1End Snap: 4612 24-Jul-08 23:00:25 17 1.7Elapsed: 59.51 (mins)DB Time: 466.37 (mins)Report B:Snap Id Snap Time Sessions Curs/Sess--------- ------------------- -------- ---------Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6End Snap: 3102 13-Nov-07 22:00:15 40 16.4Elapsed: 59.63 (mins)DB Time: 19.49 (mins)服务器是AIX的系统，4个双核cpu,共8个核:/sbin> bindprocessor -qThe available processors are: 0 1 2 3 4 5 6 7先说Report A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time 为466.37分钟，则：cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)也就是说cpu有466.37/480*100% 花费在处理Oracle的操作上，这还不包括后台进程看Report B，总共约60分钟，cpu有19.49/480*100% 花费在处理Oracle的操作上很显然，2中服务器的平均负载很低。

最详尽的AWR报告详细分析

最详尽的AWR报告详细分析AWR报告是Oracle数据库性能分析的重要工具之一，通过分析AWR 报告，可以深入了解数据库的性能状况，找出潜在的性能问题，并进行相应的优化。

AWR报告的分析可以从以下几个方面展开：1.数据库整体性能分析：从报告的概览部分可以看到数据库的整体负载情况，包括数据库的总体活动情况、平均负载、各个SQL语句的执行情况等。

通过分析这些指标，可以了解数据库在特定时间段内的性能表现。

2.高负载SQL分析：在SQL执行统计部分可以看到数据库中执行次数最多、响应时间最长的SQL语句。

对于这些高负载的SQL语句，可以结合AWR报告中的其他部分，如锁等待、I/O统计等，进一步分析其性能瓶颈所在，并优化相应的SQL语句。

3.数据库操作的瓶颈分析：AWR报告中提供了详细的数据库操作统计信息，包括CPU消耗、物理读写、逻辑读写等。

通过分析这些指标，可以找出数据库操作的瓶颈所在，如频繁的物理读写、高CPU消耗等，并通过优化解决相应的问题。

4.内存和I/O调优分析：AWR报告中提供了数据库缓冲区、PGA、SGA 等内存相关的统计信息，以及磁盘I/O统计信息。

通过分析这些指标，可以确定数据库是否存在内存不足或磁盘I/O过高的问题，并通过调整相应的配置参数进行优化。

5.统计信息和索引优化分析：AWR报告中可以看到数据库的统计信息和索引相关的指标，如表和索引的统计信息、索引扫描情况等。

通过分析这些指标，可以找出缺失统计信息或无效索引的问题，并及时进行更新和优化。

6.并发和锁等待分析：AWR报告中提供了数据库的并发操作和锁等待信息。

通过分析这些指标，可以找出数据库中的并发问题和锁等待的瓶颈所在，并通过调整相关的事务隔离级别、锁粒度等进行优化。

除了AWR报告本身的分析，还可以结合数据库的实际情况和应用需求，进行进一步的优化和调整。

总之，通过详细分析AWR报告，可以全面了解数据库的性能状况，找出潜在的性能问题，并进行相应的优化和改进。

awr分析报告详解

awr分析报告详解AWR分析报告（Automatic Workload Repository）是Oracle数据库提供的一个强大的性能分析工具，可以帮助用户深入了解数据库的性能瓶颈、资源利用情况和应用程序行为。

本文将对AWR分析报告的内容进行详解，帮助读者更好地理解和应用AWR分析报告。

一、概述AWR分析报告是由Oracle数据库自动收集和生成的，以图表和表格形式展示数据库性能数据的报告。

它主要分为以下几个部分：Snapshots Summary、Top 5 Timed Events、SQL Statistics、Wait Events 等。

1. Snapshots SummarySnapshots Summary部分展示了在指定时间范围内的数据库快照信息，包括快照的起始时间、终止时间、快照之间的时间间隔等。

通过该部分，我们可以了解快照的基本信息，为后续的分析提供基础。

2. Top 5 Timed EventsTop 5 Timed Events部分显示了数据库中花费时间最长的前五个事件。

这些事件可能包括CPU消耗、IO等待、锁等待等。

通过分析这些事件，可以找到数据库的性能瓶颈所在，并进行相应的优化。

3. SQL StatisticsSQL Statistics部分提供了数据库中执行时间最长的SQL语句信息。

它包括了每个SQL语句的执行次数、平均执行时间、逻辑读、物理读等指标。

通过分析这些指标，可以找出执行时间最长的SQL语句和索引缺失等问题，并进行性能优化。

4. Wait EventsWait Events部分展示了数据库中发生的等待事件。

它包括等待事件的类型、等待时间占比等指标。

通过分析等待事件，可以发现数据库中存在的资源争用和瓶颈，并进行适当的调整和优化。

二、AWR分析报告的应用方法AWR分析报告提供了丰富的数据库性能数据，但如何进行分析和应用是关键。

下面将介绍几种常用的分析方法：1. 性能瓶颈分析通过分析Top 5 Timed Events和Wait Events，可以找到数据库中的性能瓶颈所在。

ORACLEAWR报告详细分析

ORACLEAWR报告详细分析ORACLE AWR（Automatic Workload Repository）报告是ORACLE数据库的性能诊断和优化工具之一、它采集并保存了数据库实例的性能指标数据，例如CPU利用率、内存利用率、I/O活动等。

在实际工作中，分析AWR报告可以帮助我们了解数据库实例的性能瓶颈，并提供相应的优化建议。

AWR报告通常包含多个部分，包括实例活动统计、系统事件统计、SQL统计、I/O统计、SGA统计等。

下面将详细分析AWR报告的各个部分，并提供相应的优化建议。

1.实例活动统计：实例活动统计提供了数据库实例整体的活动情况，包括CPU利用率、用户连接数、用户等待等。

通过分析这些数据，可以判断数据库实例是否存在性能瓶颈，并从中找出问题的原因。

优化建议：-如果CPU利用率较高，可能是由于SQL语句执行效率低导致的，可以通过优化SQL语句来减少CPU负载。

-如果用户等待较多，可能是由于一些资源的瓶颈导致的，可以通过增加相应资源的容量来提高性能。

2.系统事件统计：系统事件统计列出了数据库实例中发生的各种事件的次数和等待时间。

通过分析这些数据，可以判断数据库实例中是否存在事件等待较高的情况，以及可能导致事件等待的原因。

优化建议：-如果一些事件的等待时间较高，可以通过增加相应资源的容量或者调整相关参数来减少等待时间。

-如果类事件的总等待时间较高，可能需要对相关资源进行优化或者增加容量。

3.SQL统计：SQL统计列出了数据库中执行次数较高的SQL语句的统计信息，包括执行次数、平均执行时间、Buffer gets、Disk reads等。

通过分析这些数据，可以找出执行效率较低的SQL语句，并进行优化。

优化建议：-对于执行时间较长的SQL语句，可以通过重写或者调整查询计划来提高执行效率。

-对于频繁执行的SQL语句，可以通过增加缓存或者优化索引来减少IO操作。

4.I/O统计：I/O统计提供了数据库实例中各种I/O活动的统计信息，包括每个表空间的读写次数、平均读写时间等。

ORACLE性能AWR报告的使用和分析

ORACLE性能AWR报告的使用和分析Oracle性能AWR报告（Automatic Workload Repository）是Oracle 数据库提供的一个强大的性能诊断工具，可以帮助管理员识别和解决数据库性能问题。

AWR报告收集和保存数据库的性能指标和统计信息，以便在需要时进行分析和比较。

本文将介绍AWR报告的使用和分析过程，包括如何收集AWR报告、AWR报告的内容和结构、及如何分析AWR报告。

一、收集AWR报告AWR报告只能在Oracle数据库中收集，首先需要启用AWR功能。

在Oracle数据库中，AWR功能默认是开启的。

你可以使用以下命令查看AWR 功能是否已经开启：```SELECT name FROM v$statname WHERE name LIKE '%AWR%';```如果显示了AWR相关的统计项，则表示AWR功能已经启用。

要收集AWR报告，需要按照以下步骤操作：1. 连接到数据库，在SQLPlus或类似的工具中执行以下命令，以开启AWR快照：```EXECDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(;```2.执行一段时间（建议至少30分钟）的正常工作负载。

3.再次执行以下命令，以关闭AWR快照：```EXECDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(;```4.通过以下命令查看AWR报告的快照ID：```SELECT snap_id FROM dba_hist_snapshot ORDER BY snap_id;```5.选择要分析的快照ID，使用以下命令生成AWR报告：``````根据提示输入快照ID和报告类型（HTML或文本），即可生成AWR报告。

二、AWR报告的内容和结构AWR报告提供了丰富的性能指标和统计信息，以帮助诊断数据库性能瓶颈。

AWR报告通常包括以下几个部分：1.报告概述：包含报告生成的时间、数据库版本、报告周期等信息，并提供了一个整体的性能评估。

如何高效的分析AWR报告

如何⾼效的分析AWR报告AWR报告分析1.1 看CPU的负载情况DBTime:表⽰CPU花费在处理Oralce⾮空闲等待和运算上的时间DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queueElapsed：表⽰本AWR报告由多久的快照间隔⽣成的负载情况：DBTime / Elapsed * CPUs 这个⽐值越⼩说明DB负载压⼒越⼩1.2看事务的繁忙程度、软硬解析Load Profile 主要⽤来显⽰当前系统的⼀些指⽰性能的总体参数，部分介绍如下列Per Second：平均每秒列Per Transaction：平均每个事务如图，平均每秒的事务数Transactions是75，⾮常⼩，说明系统压⼒⾮常⼩，⼀般来说Transactions不超过200都是正常的，或者200左右都是正常的，超过1000就是⾮常繁忙了，再看看平均每秒的⽇志尺⼨是4位数的，平均每个事务的⽇志尺⼨是5位数的，说明了系统访问不是很频繁，⽽单个业务是⽐较复杂的，如果反过来，平均每秒⽇志尺⼨⽐平均每秒事务⽇志尺⼨⼤很多，说明系统访问很频繁，⽽业务⽐较简单，不需要响应很久Redo Size ：⽤来显⽰平均每秒的⽇志⼤⼩和平均每个事务的⽇志⼤⼩，有时候可以结合 Transactions 每秒事务数，分析当前事务的繁忙程度。

Parses：解析次数，包括软解析 + 硬解析，软解析优化得不好⼏乎等于每秒SQL执⾏次数，即执⾏解析⽐1:1。

理想状态是解析⼀次到处运⾏。

Hard Parses：硬解析次数，最好⼩于每秒20次，否则就要考虑优化相关SQL。

Transactions: 事务数量1.3 看命中率指标efficiency percentages是⼀些命中率指标。

Buffer Hint、Library Hint等表⽰SGA(System global area)的命中率；Buffer Nowait : Buffer Nowait的这个值⼀般需要⼤于99%** 否则可能存在争⽤，可以在后⾯等待事件中进⼀步确认。

ORACLEAWR报告详细分析

ORACLEAWR报告详细分析Oracle AWR（Automatic Workload Repository）报告是Oracle数据库提供的一个性能分析工具，用于识别数据库的瓶颈和优化潜力。

通过分析AWR报告，数据库管理员可以获取关于数据库实例的详细性能信息，并采取相应的措施来改进数据库性能。

AWR报告提供了广泛的性能指标和统计数据，其中包括数据库负载、SQL语句的执行情况、系统活动、资源使用和等待事件等。

在分析AWR报告时，可以根据以下几个方面进行详细分析：1.数据库负载分析：AWR报告中的数据库负载信息可以帮助我们了解数据库的整体负载情况。

这包括CPU利用率、物理和逻辑读写次数、用户、系统和I/O等待时间等。

通过检查这些指标，我们可以找到数据库的瓶颈，并采取相应的优化措施，如增加CPU资源、调整I/O配置等。

2.SQL语句执行情况分析：AWR报告中提供了SQL语句执行情况的详细信息，包括每个SQL语句的执行次数、平均执行时间、等待时间等。

通过分析这些信息，我们可以确定哪些SQL语句是数据库性能的瓶颈，并对其进行优化。

我们可以检查执行时间最长的SQL语句，优化其执行计划、创建索引、重新编写SQL语句等以提高其性能。

3.系统活动和资源使用情况分析：AWR报告中还提供了系统活动和资源使用情况的详细信息，如CPU使用率、内存使用、磁盘和网络I/O等。

通过分析这些指标，我们可以了解数据库实例的整体状态和资源使用情况，并对其进行调优。

例如，通过检查高CPU利用率的时间段，我们可以找出可能导致性能下降的原因，如长时间运行的SQL语句、重复执行的作业等。

4.等待事件分析：AWR报告中提供了等待事件的详细统计数据，包括等待事件的数量、平均等待时间和等待时间百分比等。

等待事件是数据库性能问题的一个重要指标，它表示数据库在处理请求时等待的时间。

通过分析等待事件，我们可以找出哪些事件导致了性能问题，并采取相应的措施来解决这些问题，如调整等待事件的阈值、优化数据库配置等。

awr报告分析

awr报告分析AWR 报告分析概述：AWR（Automatic Workload Repository）报告是 Oracle 数据库中重要的性能分析工具之一。

它通过自动收集数据库运行时的性能信息，为DBA（数据库管理员）提供了深入分析数据库的能力。

本文将从不同角度分析 AWR 报告的使用和优化。

AWR 报告的生成：AWR 报告的生成分为两个步骤：一是在数据库中收集运行性能信息，二是生成 AWR 报告。

AWR 报告可以基于数据库的快照和数据存储结构进行生成。

通过在不同时间间隔内生成数据库的快照，AWR 可以提供关于数据库性能变化的信息。

AWR 报告的数据分析：1. 数据库性能指标分析AWR 报告中的数据库性能指标包括 CPU 使用率、内存使用率、磁盘和 I/O 使用率等。

通过分析这些指标，我们可以了解数据库的资源利用情况，并针对性地进行性能优化。

例如，我们可以根据 AWR 报告中的 CPU 使用率指标，判断数据库是否存在 CPU 瓶颈。

如果 CPU 使用率持续高于 80%，可能需要调整应用程序或增加服务器的 CPU 资源来提高数据库性能。

2. SQL 语句分析AWR 报告能够提供 SQL 语句的执行情况，包括每个 SQL 语句的执行次数、执行时间和等待时间等。

通过分析 SQL 语句的执行情况，我们可以发现慢查询、高等待和高消耗的 SQL，从而对数据库进行性能优化。

举个例子，我们可以根据 AWR 报告中的 SQL 语句执行次数和执行时间来确定哪些 SQL 语句是消耗数据库资源最多的。

然后，我们可以对这些消耗较大的 SQL 进行优化，例如添加索引、重写查询语句或修改数据模型。

3. 等待事件分析AWR 报告中的等待事件列举了数据库中各种等待事件的发生次数和等待时间。

通过分析等待事件，我们可以了解数据库中存在的瓶颈和资源竞争情况。

举个例子，我们可以根据 AWR 报告中的等待事件找出数据库中发生频率较高的等待事件，如 I/O 等待、锁等待或网络等待。

awr报告分析

awr报告分析AWR（Automatic Workload Repository）报告是Oracle数据库的统计和性能诊断工具，它提供了详细的数据库性能信息和指导。

在分析AWR报告时，可以关注以下几个方面：1. Load Profile：显示了数据库的负载情况，包括每秒事务数量、平均读/写IO等。

通过观察负载情况可以了解数据库的工作量和性能瓶颈。

2. Instance Efficiency Percentages：通过检查这些百分比，可以获得数据库实例的效率。

其中包括库缓冲命中率、共享池命中率、PGA命中率等。

3. Top 5 Timed Events：显示了数据库中消耗时间最长的前5个事件。

根据这些事件的耗时情况，可以判断数据库的性能瓶颈所在。

4. SQL Statistics：提供了数据库中执行时间最长的SQL语句，以及它们的执行计划信息。

可以通过分析和优化这些SQL语句来提高数据库的性能。

5. Wait Events：显示了数据库中的等待事件，包括等待的类型和等待的数量。

通过了解这些等待事件，可以发现和解决数据库的瓶颈问题。

6. Memory Statistics：展示了数据库中各种内存组件的使用情况，包括Buffer Cache、Shared Pool、PGA等。

通过了解内存的使用情况，可以调整内存参数以提高性能。

7. IO Profile：提供了数据库的IO性能指标，包括平均读/写时间、平均等待时间等。

通过分析这些指标，可以发现IO瓶颈和调整IO参数。

通过对AWR报告的分析，可以定位和解决数据库的性能问题，提高数据库的运行效率。

AWR分析报告解析

AWR分析报告解析AWR（Automatic Workload Repository）是Oracle数据库自带的一项性能诊断工具，可以收集数据库实例的性能数据并生成详细的报告。

AWR分析报告是针对数据库实例进行性能分析的重要依据，通过分析AWR 报告可以找出数据库的瓶颈，诊断性能问题，并提出相应的优化建议。

1.概述部分：该部分主要对数据库实例进行整体概述，包括数据库版本、实例名称、快照开始和结束时间等信息，通过该部分可以了解数据库的基本情况。

2. Load Profile部分：该部分主要展示数据库在快照期间的负载情况，包括每秒事务数、每秒用户数、每秒SQL语句执行数等。

通过该部分可以了解数据库的负载情况，判断数据库是否存在负载过重的情况。

3. Instance Efficiency Percentages部分：该部分主要展示数据库实例的各项效率指标，如Buffer Cache命中率、Library Cache命中率、Dictionary Cache命中率等。

通过该部分可以了解数据库的缓存使用状况，判断数据库在数据缓存和SQL代码重用方面的效率。

4. Top 5 Timed Events部分：该部分主要展示数据库实例在快照期间消耗时间最长的5个事件，如CPU消耗、物理读取、逻辑读取等。

通过该部分可以了解数据库实例的性能瓶颈所在，确定需要优化的方向。

5. SQL Statistics部分：该部分主要展示在快照期间执行时间最长的SQL语句，包括每个SQL语句的执行次数、平均执行时间、总消耗的CPU时间等。

通过该部分可以找出执行时间较长的SQL语句，进一步分析优化的可能性。

6. Tuning Summary部分：该部分主要展示数据库实例在快照期间的性能提升提示和建议。

通过该部分可以了解数据库实例的问题以及相应的解决方法和建议。

在解析AWR分析报告时，需要综合考虑各个部分的内容，辨认出可能存在的性能问题和瓶颈，并针对性地进行优化。

AWR报告详细分析

AWR报告详细分析AWR（Automatic Workload Repository）报告是Oracle数据库性能分析的重要工具，通过分析AWR报告可以了解数据库的整体性能情况，找出数据库性能瓶颈，并进行优化。

1.概要信息：报告中会显示数据库的基本信息，包括数据库名称、版本、启动时间、快照时间范围等。

2.数据库活动指标：报告会显示数据库的关键性能指标，如平均每秒提交次数、平均每秒用户调用次数、平均每秒物理读次数等。

通过分析这些指标，可以了解数据库的整体负载状况。

3. Load Profiles：报告中会显示不同时间段的数据库负载情况，包括物理读写情况、用户调用情况、并发会话情况等。

通过分析这些信息，可以了解数据库的繁忙时段和空闲时段，为系统调整提供依据。

4. Top 5 Timed Events：报告会列出消耗时间最长的前五个事件，包括CPU消耗、IO消耗等。

通过分析这些事件，可以找出潜在的性能瓶颈，并进行针对性的调优。

5.SQL统计信息：报告会列出运行时间最长的SQL语句，包括执行次数、平均消耗时间、IO消耗等。

通过分析这些SQL语句，可以找出执行效率低下的语句，并进行优化。

6. Instance Efficiency Percentages：报告会显示数据库实例的效率百分比，包括Buffer Cache命中率、Redo Log缓存命中率、Library Cache命中率等。

通过分析这些百分比，可以评估数据库的性能和效率，并进行相应的调整。

除了以上几个部分外，AWR报告还包含其他一些信息，如系统配置信息、事件等待统计信息等。

在分析AWR报告时，需要关注以下几个方面：1. 整体性能分析：可以通过查看数据库活动指标和Load Profiles 来评估数据库的整体性能，了解数据库的负载情况和系统繁忙时段。

2. 事件分析：可以通过查看Top 5 Timed Events来找出消耗时间最长的事件，如CPU消耗事件、IO消耗事件等。

awr报告分析

awr报告分析AWR（Adaptive Wide Range）报告是一种用于分析和优化无线电频率的工具。

它可以对无线电系统中的各种参数进行监测和测试，并生成详细的分析报告，以帮助工程师们了解无线电系统的性能以及可能的改进方法。

在AWR报告中，主要包含以下内容：系统结构、电路图、仿真结果、性能评估和建议等。

在进行AWR分析之前，一般需要明确系统的需求和目标，然后根据这些要求进行电路设计和仿真。

接下来，我将从AWR报告的几个主要方面进行详细介绍。

首先，系统结构是AWR报告的重要组成部分之一。

它描述了整个无线电系统的组成和连接方式。

通常，系统结构包括天线、射频信号源、放大器、滤波器、Mixer和控制电路等。

通过清晰地展示无线电系统的结构，工程师可以更好地了解每个组件的作用和相互连接方式。

其次，电路图是AWR报告的关键内容之一。

电路图以图形的方式显示了所有组件的连接关系和信号流动路径。

通过电路图，工程师可以精确地了解电路中各个元件的参数、电阻、电容和电感值等。

这些参数对于优化无线电系统的性能至关重要。

第三，仿真结果是AWR报告中的重要组成部分。

通过对无线电系统进行仿真和分析，可以评估系统的性能和瓶颈。

仿真可以模拟各种工况，并显示系统在不同工况下的响应和特性。

如此一来，工程师们可以根据仿真结果进行系统参数的优化和调整，以达到更好的性能。

其次，性能评估是AWR报告不可或缺的一环。

在AWR报告中，工程师将会根据仿真结果以及实际测试数据对无线电系统进行性能评估。

评估内容通常包括信号的幅度、频率响应、带宽、失真度、噪声及声音的清晰度等指标。

通过性能评估，可以更直观地了解系统是否能够满足需求，并提供改进的方向。

最后，AWR报告通常会给出一些建议和改进方案。

根据性能评估和分析结果，工程师们可以提出一些优化和改进无线电系统性能的建议。

例如，调整电路中的参数、更换部件或增加滤波器等。

这些建议和方案将有助于提高无线电系统的性能和稳定性。

最详尽的AWR报告详细分析

Elapsed 时间，说明数据库比拟空闲。

db time= cpu time + wait time〔不包含空闲等待〕〔非后台进程〕说白了就是db time就是记录的效劳器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间DB time = cpu time + all of nonidle wait event time在79分钟里〔其间收集了3次快照数据〕，数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU〔4个物理CPU〕，平均每个CPU耗时1.4分钟，CPU 利用率只有大约2%〔1.4/79〕。

说明系统压力非常小。

列出下面这两个来做解释：Report A:Snap Id Snap Time Sessions Curs/Sess--------- ------------------- -------- ---------Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1End Snap: 4612 24-Jul-08 23:00:25 17 1.7Elapsed: 59.51 (mins)DB Time: 466.37 (mins)Report B:Snap Id Snap Time Sessions Curs/Sess--------- ------------------- -------- ---------Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6End Snap: 3102 13-Nov-07 22:00:15 40 16.4Elapsed: 59.63 (mins)DB Time: 19.49 (mins)效劳器是AIX的系统，4个双核cpu,共8个核:/sbin> bindprocessor -qThe available processors are: 0 1 2 3 4 5 6 7先说Report A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time 为466.37分钟，那么：cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上，这还不包括后台进程看Report B，总共约60分钟，cpu有 19.49/480*100% 花费在处理Oracle的操作上很显然，2中效劳器的平均负载很低。

awr分析报告详解

Awr -Oracle10g新特性—工作量自动收集-性能调优当数据库发生了性能问题时，如何去定位？比较常用的方法是采用一个既定的模式：解决诸如“是不是同一问题的再现？”、“是否在某一特殊时间段发生？”、“两个问题之间是否存在联系？”等问题，这样通常能得到一个比较好的诊断结果。

作为一个DBA，你可能使用一个第三方或者自己开发的工具来收集数据库运行期间的精细统计数据，并从中得到性能度量数据。

你需要将这些发生问题时的度量数据与当前数据进行比较。

重现以前的时间能使现在的问题变得明朗。

因此，持续的收集相关统计数据对于性能分析来说十分重要。

在某些情况下，在解决收集统计数据这方面的问题上有自己内置的工具——statspack。

尽管在某些情况下的作用非常大，但它缺乏解决性能问题所必须的健壮性。

提供了一个标志性的改进特性：自动工作量存储（Automatic Workload Repository AWR）。

AWR是随着数据库一起被安装的，它不仅能收集统计数据，还能从统计数据中分析出度量数据。

通过运行$ORACLE_HOME/rdbms/admin目录下的awrrpt.sql脚本可以生产AWR从统计和度量数据中分析报告。

这个分析报告最能体现出AWR 的性能分析能力。

这个脚本看起来很像statspack，它会列出所有可用的AWR快照并要求输入两个特定的快照编号作为一个间隔段。

它能产生两种类型的输出：文本格式（除了AWR统计信息外和statspack报告基本类似）和默认的格式（通过超连接等方式来提供一个友好的界面）。

下面来运行以下这个脚本，对它产生的分析报告及AWR的性能分析能力做一个认识。

AWR的使用首先来了解一下AWR是如何设计的，并了解一下它的构造。

基本上来说，AWR应该是一个Oracle用来收集性能相关统计数据并从中得出性能度量数据来追踪潜在问题的内置工具。

和statspack不一样，AWR的快照信息是由一个新的后台进程MMON及其线程来每隔一个小时自动收集的。

awr报告详细分析

AWR报告详细分析AWR（Automatic Workload Repository）报告是Oracle数据库系统提供的一项性能分析工具，它能够收集并保存数据库实例的运行信息。

通过对AWR报告进行详细的分析，可以帮助我们了解数据库的性能瓶颈，并进行相应的优化。

本文将以Step by Step的思路，介绍如何对AWR报告进行详细分析。

第一步：选择AWR报告在Oracle数据库中，我们可以使用以下命令生成AWR报告：SELECT*FROM TABLE(dbms_workload_repository.awr_report_html(<dbid>, <inst_num>, <begin_snap>, <end_snap>));在命令中，dbid是数据库的标识号，inst_num是实例的编号，begin_snap和end_snap是要分析的快照点的编号。

第二步：报告概览打开AWR报告后，我们首先需要查看报告的概览部分。

概览部分包含了数据库的一些基本信息，例如数据库版本、实例名、快照点范围等。

我们可以从概览中了解到数据库运行的时间范围和快照点的频率，这对后续分析非常有帮助。

第三步：负载分析在AWR报告的负载分析部分，我们可以看到数据库的整体负载情况。

其中包含了实例的活动会话数、平均每秒事务数、平均每秒用户提交数等指标。

通过对这些指标的分析，我们可以了解到数据库的整体负载情况，进而判断是否存在性能瓶颈。

第四步：Top SQL分析AWR报告的Top SQL分析部分列出了数据库中消耗资源最多的SQL语句。

通过分析这些SQL语句，我们可以找出执行时间最长、消耗CPU最多、IO操作最频繁的SQL语句，并进行相应的优化。

在分析时，我们可以根据执行时间、CPU使用率和IO操作等指标进行排序，找出影响数据库性能的关键SQL语句。

第五步：等待事件分析等待事件是指数据库中的会话在执行过程中因为等待某种资源而暂停执行的状态。

AWRReport关键参数详细分析

AWRReport关键参数详细分析WORKLOAD REPOSITORY report forDB Name DB Id Instance InstnumStartupTimeRelease RACCALLDB1251068085calldb1107-Dec-1221:1211.2.0.3.0YESHost Name Platform CPUs Cores Sockets Memory(GB)calldb01AIX-Based Systems(64-bit)12832250.25 SnapIdSnap Time Sessions Cursors/SessionBeginSnap:50108-Dec-12 19:09:55608 1.9 EndSnap:50208-Dec-12 19:27:13711 1.9 Elapsed:17.29 (mins)DB Time:66.19 (mins)前台session话费在数据库调⽤上的时间，反映⽤户的负载，包括cpu时间、io time、⾮空闲等待时间Sessions：开始有608个会话，结束有711个会话Elapsed：采样时间DB Time：因为多cpu，最⼤可提供Elapsed*CPU_num的运⾏时间。

AAS：Avg Active Session=DB Time/Elapsed time，如果 <1 ,说明负载很低，>1000基本系统hang住了Report SummaryCache SizesBegin EndBuffer Cache:73,728M73,728M Std Block Size:8KShared Pool Size:16,384M16,384M Log Buffer:334,848Kbuffer cache：所有缓冲池⼤⼩之和，不仅default池如果begin和end之间的变化较⼤，可以查看期间内存的抖动：Load Profile （系统负载情况）Per Second PerTransactionPerExecPerCallDB Time(s): 3.80.60.080.04DB CPU(s):0.00.00.000.00 Redo size:36,052.5（b）5,279.3Logical reads:块数*次数1,411.1206.6Block changes:229.333.6Physical reads:0.00.0Physical writes:7.4 1.1Physical writes:7.4 1.1User calls:103.715.2Parses:(分析sql的次数)4.40.6Hard parses:(硬解析次数)0.00.0W/A MB processed:0.10.0Logons:0.20.0Executes:49.17.2Rollbacks: 3.40.5Transactions: 6.8可以通过Redo size推断每天产⽣的⽇志量，并推断⽇志⼤⼩是否合理（每⼩时⽇志=36k*60*60，看⽇志⼤⼩推断多久切换⼀次，看是否合理）transactions在不同⽇期中，正常应该差不多如果某天逻辑读206.6增⼤很多，可以怀疑是否某个索引失效、sql的执⾏计划错误Instance Efficiency Percentages (Target 100%) 命中率指标Buffer Nowait %:反映热快冲突98.15Redo NoWait %:是否存在redo等待100.00Buffer Hit %:100.00In-memory Sort %:100.00 Library Hit %:99.87Soft Parse %:99.56 Execute to Parse %:91.16Latch Hit %:99.28Parse CPU to Parse Elapsd %:29.92% Non-Parse CPU:CPU⽤来解析sql的时间5%95.48PARSE CPU TO PARESE ELAPSD%表⽰在整个PARSE所占⽤的时间的中,真正的CPU时间⽐.PARSE CPU TO PARESE ELAPSD=100*(PARSE CPU/PARESE ELAPSD).我们知道PARSE ELAPSD=PARSE CPU+等待.⼀般这个值越低,表⽰解析等待越严重.%NON-PARSE CPU.表⽰在整个DB　CPU中⾮PARSE CPU所占⽤的百份⽐,越⾼表⽰解析越少,⽤于执⾏查询的CPU越多.该值过⼩表⽰解析过多.EXECUTE TO PARSE%表⽰PARSE/EXECUTE的百份⽐.该参数是语句执⾏和分析了多少次的度量.有可能为负数,说明效率极低，这个Parse包括软解析Shared Pool Statistics 共享池状态Begin EndMemory Usage %:共享池使⽤率，100%并不能说明共享池不⾜，分配就是要⽤的37.7237.79% SQL with executions>1:97.2897.50% Memory for SQL w/exec>1:重⽤的sql使⽤的内存95.2995.40Top 5 Timed Foreground EventsEvent Waits Time(s)Avg wait (ms)% DB time Wait Classenq: TX - allocate ITL entry2,7333,325121783.73Configurationenq: TX - index contention5,97924942 6.26Concurrencybuffer busy waits11,16913912 3.50Concurrencygc buffer busy acquire10,779949 2.35Clustergc buffer busy release4,0888521 2.14Clustersequential read某天突然降低，有可能系统出现瓶颈Host CPU (CPUs: 128 Cores: 32 Sockets: )Load AverageBegin Load AverageEnd%User%System%WIO%Idle0.980.830.20.30.099.5 Instance CPU%Total CPU %BusyCPU%DB time waiting for CPU (ResourceManager)0.111.30.0Memory StatisticsBegin End Host Mem (MB):256,256.0256,256.0 SGA use (MB):97,865.197,865.1 PGA use (MB):1,216.51,418.5 % Host Mem used for SGA+PGA:38.6738.74RAC StatisticsBegin End Number of Instances:22Global Cache Load Profile （全局缓冲区负载，只有rac才有）Per SecondPer TransactionGlobal Cache blocks received:接收到全局缓冲块35.91 5.26 Global Cache blocks served:发送出38.13 5.58 GCS/GES messages received:GCS消息接收1k算很低65.449.58 GCS/GES messages sent:消息发送63.879.35 DBWR Fusion writes:其他节点要求写操作0.490.07 Estd Interconnect traffic (KB)内⽹卡通讯量，40M/s算⾮常⾼，重点关注，80M/S是极限，少的系统可能不到1M617.61Global Cache Efficiency Percentages (Target local+remote 100%) Buffer access - local cache %:本地缓冲区获得数据，印证了上⾯消息量很⼩97.45 Buffer access - remote cache %:远程缓冲区获得数据 2.54 Buffer access - disk %:磁盘读取0.00 Global Cache and Enqueue Services - Workload Characteristics全局缓冲和全局锁Avg global enqueue get time (ms):⼀个global cache获取时间1~20ms正常54.0 Avg global cache cr block receive time (ms):⼀个CR块从发起请求到收到的时间，超过12ms有问题0.1 Avg global cache current block receive time (ms): 1.6 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 %: 2.1 Avg global cache cr block flush time (ms):0.5 Avg global cache current block pin time (ms): 1.4 Avg global cache current block send time (ms):0.0Avg global cache current block flush time (ms):0.5 Global Cache and Enqueue Services - Messaging Statistics消息统计数据Avg message sent queue time (ms):⾮直接传输的消息，在队0.0列中的等待时间，0.1ms左右Avg message sent queue time on ksxp (ms):ipc层⾯发送⼀个0.2消息到ack回应，应⼩于1msAvg message received queue time (ms):消息进⼊队列到开始处0.0理的时间，0.1ms左右Avg GCS message process time (ms):处理⼀个buffer相关的0.0 gcs时间，应⼩于0.5msAvg GES message process time (ms):处理⼀个锁消息的时间，0.0应⼩于0.5ms% of direct sent messages:直接发送消息86.84 % of indirect sent messages:通过代理发送消息13.04 % of flow controlled messages:流控消息0.12如果某天消息处理特别慢，可以看看是否消息量特别多Cluster Interconnectif IP/Public/Source at End snap is different a '*' is displayedBegin EndInterface IP Address Pub Source IP Pub Srcen9169.254.185.73NMain ReportMore RAC StatisticsWait Events StatisticsTime Model Statistics（时间模型）Total time in database user-calls (DB Time): 3971.2sStatistics including the word "background" measure background process time, and so do not contribute to the DB time statistic Ordered by % or DB time desc, Statistic nameStatistic Name Time (s)% of DB Timesql execute elapsed time3,911.7798.50DB CPU24.540.62parse time elapsed：sql解析时间 3.800.10connection management call elapsed time0.810.02PL/SQL execution elapsed time0.600.01hard parse (sharing criteria) elapsed time0.050.00hard parse elapsed time0.050.00repeated bind elapsed time0.000.00DB time3,971.17background elapsed time70.31background cpu time46.36Operating System Statistics*TIME statistic values are diffed. All others display actual values. End Value is displayed if differentordered by statistic type (CPU Use, Virtual Memory, Hardware Config), NameStatistic Value End ValueAVG_BUSY_TIME440AVG_IDLE_TIME103,307AVG_IOWAIT_TIME2AVG_SYS_TIME243AVG_USER_TIME140BUSY_TIME62,659IDLE_TIME13,230,065IOWAIT_TIME2,057SYS_TIME37,834USER_TIME24,825LOAD11OS_CPU_WAIT_TIME92,900VM_IN_BYTES20,480VM_OUT_BYTES121,802,752PHYSICAL_MEMORY_BYTES268,703,891,456NUM_CPU_CORES32NUM_LCPUS128NUM_VCPUS32GLOBAL_RECEIVE_SIZE_MAX1,310,720GLOBAL_SEND_SIZE_MAX1,310,720TCP_RECEIVE_SIZE_DEFAULT16,384TCP_RECEIVE_SIZE_MAX9,223,372,036,854,775,807TCP_RECEIVE_SIZE_MIN4,096TCP_SEND_SIZE_DEFAULT16,384TCP_SEND_SIZE_MAX9,223,372,036,854,775,807TCP_SEND_SIZE_MIN4,096Operating System Statistics - DetailSnap Time Load%busy%user%sys%idle%iowait08-Dec 19:09:550.9808-Dec 19:27:130.830.470.190.2899.530.02Foreground Wait Classs - second, ms - millisecond - 1000th of a secondordered by wait time desc, waits desc%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0Captured Time accounts for 99.8% of Total DB time 3,971.17 (s)Total FG Wait Time: 3,939.48 (s) DB CPU time: 24.54 (s)Wait Class Waits%Time -outs Total Wait Time (s)Avg wait (ms)%DB timeConfiguration2,974513,325111883.73Concurrency24,7780390169.82Cluster52,60502144 5.39DB CPU250.62Other10,61748710.18Commit7,1760300.07User I/O1,2680000.01Network65,9510000.01System I/O1560000.00Application000.00Foreground Wait Events（等待事件明细）s - second, ms - millisecond - 1000th of a secondOnly events with Total Wait Time (s) >= .001 are shownordered by wait time desc, waits desc (idle events last)%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0Event Waits%Time -outs Total Wait Time (s)Avg wait (ms)Waits /txn% DB time enq: TX - allocate ITL entry2,733553,32512170.3983.73 enq: TX - index contention5,9790249420.84 6.26 buffer busy waits11,169013912 1.58 3.50 gc buffer busy acquire10,7790949 1.52 2.35 gc buffer busy release4,088085210.58 2.14 gc current block busy5,33002650.750.66 latch: ges resource hash list4,1010410.580.11 gc cr block 2-way18,416030 2.600.08gc current block 2-way11,980030 1.690.07log file sync7,176030 1.010.07latch free6800230.100.05gc current grant busy8820220.120.04latch: cache buffers chains6,4570200.910.04gc current split1460160.020.02reliable message1003570.000.01library cache: mutex X6030000.090.01Disk file operations I/O1,1980000.170.01gc cr block busy3930010.060.01enq: HW - contention2410010.030.01enq: US - contention860020.010.01SQL*Net message to client65,2960009.220.00gc cr multi block request3130010.040.00row cache lock5560000.080.00enq: TA - contention170060.000.00wait list latch free830010.010.00gc current multi block request800010.010.00enq: TX - contention18896000.030.00read by other session热快冲突610010.010.00buffer deadlock4,65499000.660.00control file sequential read1560000.020.00gc current grant 2-way1410000.020.00SQL*Net message from dblink740000.010.00DFS lock handle6441000.010.00enq: TS - contention590000.010.00rdbms ipc reply2750000.040.00enq: FB - contention330000.000.00SQL*Net more data to client5070000.070.00db file sequential read90010.000.00gc current retry350000.000.00IPC send completion sync280000.000.00enq: JQ - contention8100000.000.00gc current block congested130000.000.00lock deadlock retry207100000.030.00cursor: pin S wait on X20010.000.00enq: PS - contention70000.000.00gc cr block congested80000.000.00PX Deq: Slave Session Stats90000.000.00KJC: Wait for msg sends to complete110000.000.00enq: WF - contention50000.000.00SQL*Net message from client65,1970634,60397349.20jobq slave wait1,2001006005000.17PX Deq: Execution Msg360000.01Background Wait Eventsordered by wait time desc, waits desc (idle events last)Only events with Total Wait Time (s) >= .001 are shown%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0Event Waits%Time -outs Total Wait Time (s)Avg wait (ms)Waits /txn% bg time Streams AQ: qmn coordinator waiting for slave to start21001156410.0016.05 os thread startup2903940.00 3.88log file parallel write10,343030 1.46 3.86 gcs log flush sync4,1970200.59 2.20 control file sequential read3,0290100.43 1.18 db file parallel write2,5320100.36 1.04 DFS lock handle81799000.120.22 control file parallel write4810000.070.19 enq: CO - master slave det346100000.050.19 ASM file metadata operation3090000.040.16 CSS operation: data query510020.010.13 latch free330020.000.12 enq: WF - contention170040.000.10 CGS wait for IPC msg9,38910000 1.330.09 CSS initialization200170.000.05 ksxr poll remote instances2,933100000.410.04 row cache process5,6830000.800.04 gc current block 2-way1070000.020.03 reliable message810000.010.03 gc cr block 2-way820000.010.03 row cache lock450000.010.02 CSS group membership query170010.000.02 enq: CF - contention34100000.000.02 row cache cleanup4,1250000.580.01 db file sequential read10080.000.01 gc current grant busy350000.000.01 Disk file operations I/O280000.000.01 CSS operation: action20030.000.01 LGWR wait for redo copy1840000.030.01 PX Deq: reap credit492100000.070.01 libcache interrupt action by LCK3,1470000.440.00 enq: PS - contention850000.000.00 gc current block busy30010.000.00 db file async I/O submit2,5320000.360.00 latch: cache buffers chains330000.000.00 rdbms ipc message40,8405339,711972 5.76gcs remote message534,648896,2181275.46Space Manager: slave idle wait611922,93548040.09wait for unread message on broadcast channel2,0771002,07610000.29DIAG idle wait72,458822,0512810.23 Streams AQ: qmn slave idle wait7241,858258080.01class slave wait11401,615141680.02smon timer8131,0441305530.00 Streams AQ: waiting for time management or cleanup tasks97741,044107590.01pmon timer363941,03828600.05ges remote message14,605611,03771 2.06PX Idle Wait901,0371152080.00GCR sleep2071001,03550000.03ASM background timer20701,03449960.03PING343241,03330120.05 Streams AQ: qmn coordinator idle wait74461,027138750.01 dispatcher timer171001,020600010.00shared server idle wait341001,020300000.00SQL*Net message from client3720000.05KSV master wait65695000.09PX Deq: Join ACK60010.00Wait Event HistogramUnits for Total Waits column: K is 1000, M is 1000000, G is 1000000000% of Waits: value of .0 indicates value was <.05%; value of null is truly 0% of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024msOrdered by Event (idle events last)% of WaitsEvent Total Waits<1ms<2ms<4ms<8ms<16ms<32ms<=1s>1s ASM file metadata operation31099.7.3 CGS wait for IPC msg9389100.0CSS group membership query1764.735.3CSS initialization250.050.0 CSS operation: action2100.0CSS operation: data query5196.1 3.9CSS operation: query23100.0DFS lock handle88199.9.1Disk file operations I/O122790.18.5 1.5IPC send completion sync32100.0KJC: Wait for msg sends to complete11100.0LGWR wait for redo copy184100.0PX Deq: Signal ACK EXT6100.0PX Deq: Signal ACK RSG6100.0PX Deq: Slave Session Stats15100.0PX Deq: reap credit560100.0SQL*Net message from dblink7495.9 2.7 1.4SQL*Net message to client65.5K100.0SQL*Net message to dblink74100.0SQL*Net more data to client507100.0Streams AQ: qmn coordinator waiting for slave to start2100.0 asynch descriptor resize154100.0buffer busy waits11.2K35.0 5.1 5.87.818.318.29.7 buffer deadlock4632100.0control file parallel write482100.0control file sequential read315399.9.0.1cursor: mutex X1100.0cursor: pin S wait on X2100.0db file async I/O submit2532100.0db file parallel write2532100.0db file sequential read425.050.025.0direct path write1100.0enq: CF - contention34100.0enq: CO - master slave det34698.8 1.2enq: CR - block range reuse ckpt1100.0enq: DR - contention1100.0enq: FB - contention31100.0enq: HW - contention24468.925.0 2.9 3.3enq: JQ - contention8100.0enq: JS - job run lock - synchronize1100.0enq: MW - contention1100.0enq: PS - contention15100.0enq: TA - contention2119.0 4.89.552.414.3enq: TD - KTF dump entries1100.0enq: TK - Auto Task Serialization2100.0enq: TM - contention3100.0enq: TS - contention59100.0enq: TX - allocate ITL entry2732.5.051.847.6 enq: TX - contention18994.7 3.7 1.1.5enq: TX - index contention59628.3 5.0 5.97.611.115.746.4 enq: US - contention8650.012.820.98.17.0 1.2enq: WF - contention2290.9 4.5 4.5gc buffer busy acquire10.8K38.4 6.48.410.921.78.4 5.7gc buffer busy release408524.2 6.7 6.57.418.015.921.2gc cr block 2-way18.5K99.9.1.0gc cr block busy39999.0 1.0gc cr block congested8100.0gc cr grant 2-way1100.0gc cr multi block request31391.78.3gc current block 2-way12.1K99.8.2.0gc current block busy533649.37.57.3 6.425.2 3.3 1.1gc current block congested13100.0gc current grant 2-way146100.0gc current grant busy93388.0 1.4 1.1 1.8 4.7 1.8 1.2gc current grant congested1100.0gc current multi block request7891.0 3.8 1.3 3.8gc current retry35100.0gc current split14656.2 1.4 4.1 6.817.811.6 2.1gcs log flush sync420899.4.3.1.0.1.0global enqueue expand wait2100.0ksxr poll remote instances2949100.0latch free71421.116.227.335.3latch: active service list4100.0latch: cache buffers chains648996.6 3.3.1latch: call allocation2100.0latch: enqueue hash chains15100.0latch: gc element17100.0latch: ges resource hash list410757.527.315.2latch: row cache objects4100.0latch: shared pool2100.0libcache interrupt action by LCK3163100.0library cache lock3100.0library cache pin3100.0library cache: mutex X60395.4 4.6lock deadlock retry207100.0lock escalate retry2100.0log file parallel write10.4K99.9.1.0.0.0log file sync717398.6 1.3.0.0os thread startup29100.0 rdbms ipc reply27599.6.4read by other session6175.4 3.321.3reliable message8298.8 1.2row cache cleanup4151100.0row cache lock60797.7 1.5.3.2.3row cache process5725100.0wait list latch free8291.58.5ASM background timer208100.0GCR sleep207100.0 KSV master wait65699.8.2 PING34376.123.9 PX Deq: Execute Reply6100.0PX Deq: Execution Msg3694.4 5.6PX Deq: Join ACK666.733.3PX Deq: Parse Reply666.733.3PX Idle Wait922.277.8 SQL*Net message from client65.6K52.49.7 4.2 6.3 3.3 2.08.213.9 Space Manager: slave idle wait623.6 2.796.6 Streams AQ: RAC qmn coordinator idle wait77100.0Streams AQ: qmn coordinator idle wait7451.448.6 Streams AQ: qmn slave idle wait72 1.498.6 Streams AQ: waiting for time management or cleanup tasks9724.737.138.1 class slave wait11139.629.730.6 dispatcher timer17100.0 gcs remote message534.4K 4.3 1.9 1.9 2.166.223.6ges remote message14.6K24.7 2.3 1.6 1.2 1.8 2.565.9jobq slave wait1200100.0 pmon timer363 1.4.3.3 2.595.6 rdbms ipc message40.9K24.9 2.5 3.0 5.0 2.8 2.234.425.3 shared server idle wait34100.0 smon timer1233.366.7 wait for unread message on broadcast channel2075.0100.0Wait Event Histogram Detail (64 msec to 2 sec)Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000Units for % of Total Waits: ms is milliseconds s is 1024 milliseconds (approximately 1 second)% of Total Waits: total waits for all wait classes, including Idle% of Total Waits: value of .0 indicates value was <.05%; value of null is truly 0Ordered by Event (only non-idle events are displayed)% of Total WaitsEvent Waits 64ms to 2s<32ms<64ms<1/8s<1/4s<1/2s<1s<2s>=2sASM file metadata operation199.7.3CSS initialization150.050.0buffer busy waits108790.37.5 2.1.1enq: TX - allocate ITL entry2674.5.2.8 2.3 4.644.046.0 1.6enq: TX - index contention276653.622.319.2 4.8enq: WF - contention195.5 4.5gc buffer busy acquire61894.3 3.6 2.1gc buffer busy release86678.812.97.2 1.1gc current block busy5898.9 1.0.1.0gc current grant busy1198.8 1.1.1gc current split397.9 1.4.7log file parallel write1100.0.0os thread startup29100.0reliable message198.8 1.2Wait Event Histogram Detail (4 sec to 2 min)Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000minutes)% of Total Waits: total waits for all wait classes, including Idle% of Total Waits: value of .0 indicates value was <.05%; value of null is truly 0Ordered by Event (only non-idle events are displayed)% of Total WaitsEvent Waits 4s to 2m<2s<4s<8s<16s<32s< 1m< 2m>=2m Streams AQ: qmn coordinator waiting for slave to start2100.0enq: TX - allocate ITL entry4398.4 1.6Wait Event Histogram Detail (4 min to 1 hr)No data exists for this section of the report.Service Statistics 多个应⽤使⽤不同的serviceordered by DB TimeService Name DB Time (s)DB CPU (s)Physical Reads (K)Logical Reads (K)calldb3,9692301,426SYS$USERS2105SYS$BACKGROUND00033calldbXDB0000Service Wait Class Stats每个service在各个wait class上的等待情况Wait Class info for services in the Service Statistics section.Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network Time Waited (Wt Time) in secondsService Name User I/OTotal Wts User I/O WtTimeConcurcyTotal WtsConcurcy WtTimeAdmin TotalWtsAdmin WtTimeNetworkTotal WtsNetwork WtTimecalldb124902477039000659490 SYS$USERS190800020 SYS$BACKGROUND300325430000SQL StatisticsSQL ordered by Elapsed TimeResources reported for PL/SQL code includes the resources used by all SQL statements called by the code.%Total - Elapsed Time as a percentage of Total DB time%CPU - CPU Time as a percentage of Elapsed Time%IO - User I/O Time as a percentage of Elapsed Time Captured SQL account for 1.0% of Total DB Time (s): 3,971 Captured PL/SQL account for 0.0% of Total DB Time (s): 3,971Elapsed Time(s)Executions Elapsed Time per Exec(s)%Total%CPU%IO SQLIdSQL Module SQL Text31.297,0220.000.79 4.040.01JDBC ThinClientINSERT INTO S_WKST_ORG_EXT(AP...1.6600.0445.970.68PL/SQLDeveloperselect dbms_workload_reposito...1.637,0150.000.0445.930.00JDBC ThinClientupdate S_ATTACH_INFO setAPP_N...1.324,6510.000.0347.190.00JDBC ThinClientselect * from (select _no...1.014,6500.000.0341.470.00JDBC ThinClientselect * from (select _no...0.65170.040.0239.270.01JDBC ThinClientupdate S_95598_WKST setHANDLE...0.613380.000.0259.960.00PL/SQLDeveloperselect value from v$sesstat wh...0.2330.080.0142.870.00JDBC ThinClientselect t2.* from (select t1.*,...0.221690.000.0145.610.00PL/SQLDeveloperselect t.app_no, t.handle_stat...0.228730.000.0145.930.00JDBC ThinClientupdate S_COMM_REC setHANDLE_I...SQL ordered by CPU TimeResources reported for PL/SQL code includes the resources used by all SQL statements called by the code.%Total - CPU Time as a percentage of Total DB CPU%CPU - CPU Time as a percentage of Elapsed Time%IO - User I/O Time as a percentage of Elapsed TimeCaptured SQL account for 24.8% of Total CPU Time (s): 25Captured PL/SQL account for 0.1% of Total CPU Time (s): 25CPU Time(s)Executions CPU per Exec(s)%Total Elapsed Time(s)%CPU%IO SQLIdSQL Module SQL Text1.277,0220.00 5.1631.29 4.040.01JDBC ThinClientINSERT INTOS_WKST_ORG_EXT (AP...0.760 3.11 1.6645.970.68PL/SQLDeveloperselect dbms_workload_reposito...0.757,0150.00 3.05 1.6345.930.00JDBC ThinClientupdate S_ATTACH_INFO setAPP_N...0.624,6510.00 2.54 1.3247.190.00JDBC ThinClientselect * from (select _no...0.424,6500.00 1.70 1.0141.470.00JDBC ThinClientselect * from (select _no...0.373380.00 1.500.6159.960.00PL/SQLDeveloperselect value from v$sesstat wh...0.26170.02 1.040.6539.270.01JDBC ThinClientupdate S_95598_WKST setHANDLE...0.1310.130.510.1966.140.00insert into wrh$_system_event ...0.1210.120.510.1965.010.00insert into wrh$_bg_event_summ...0.114,9640.000.460.2057.790.00JDBC ThinClientSELECT 1 FROM DUALResources reported for PL/SQL code includes the resources used by all SQL statements called by the code. %Total - User I/O Time as a percentage of Total User I/O Wait time%CPU - CPU Time as a percentage of Elapsed Time%IO - User I/O Time as a percentage of Elapsed TimeCaptured SQL account for 27.9% of Total User I/O Wait Time (s): 0Captured PL/SQL account for 0.0% of Total User I/O Wait Time (s): 0User I/O Time(s)Executions UIO per Exec(s)%Total Elapsed Time(s)%CPU%IO SQLIdSQL Module SQL Text0.061240.0018.690.1954.4533.34JDBC ThinClientinsert into sys.aud$( sessioni...0.010 3.29 1.6645.970.68PL/SQLDeveloperselect dbms_workload_reposito...0.0140.00 2.360.017.7786.83select q_name, state, delay, e...0.007,0220.00 1.3231.29 4.040.01JDBC ThinClientINSERT INTOS_WKST_ORG_EXT (AP...0.00640.00 1.210.1557.88 2.72select us#, status$, user#, ts...0.00590.000.590.0245.7512.96select count(*) from undo$0.0010.000.340.0545.02 2.20JDBC ThinClientSELECT ORG_NO, CALL_DEPT,SUM(...0.0010.000.080.0830.960.35INSERT /*+ APPEND LEADING(@"SE...0.00170.000.020.6539.270.01JDBC ThinClientupdate S_95598_WKST setHANDLE...0.001420.000.010.0439.410.10select /*+ rule */ name, file#...SQL ordered by GetsResources reported for PL/SQL code includes the resources used by all SQL statements called by the code.%Total - Buffer Gets as a percentage of Total Buffer Gets%CPU - CPU Time as a percentage of Elapsed Time%IO - User I/O Time as a percentage of Elapsed TimeTotal Buffer Gets: 1,463,934Captured SQL account for 21.0% of TotalBuffer Gets Executions Gets perExec%Total Elapsed Time(s)%CPU%IO SQLIdSQL Module SQL Text118,8307,02216.928.1231.2940JDBC ThinClientINSERT INTO S_WKST_ORG_EXT(AP...41,8447,015 5.96 2.86 1.6345.90JDBC ThinClientupdate S_ATTACH_INFO setAPP_N...27,9004,651 6.00 1.91 1.3247.20JDBC ThinClientselect * from (select _no...27,8584,650 5.99 1.90 1.0141.50JDBC ThinClientselect * from (select _no...25,93464405.22 1.770.1557.9 2.7select us#, status$, user#, ts...15,64716992.59 1.070.2245.60PL/SQLDeveloperselect t.app_no, t.handle_stat...11,25817662.240.770.6539.30JDBC ThinClientupdate S_95598_WKST setHANDLE...5,226871 6.000.360.1848.20JDBC ThinClientupdate S_ATTACH_INFO setHANDL...5,12600.35 1.6646.7PL/SQLDeveloperselect dbms_workload_reposito...4,88414,884.000.330.0741.80JDBC ThinClientbegin pkg_bs_ywjk_job.p_stat_s...SQL ordered by Reads%CPU - CPU Time as a percentage of Elapsed Time %IO - User I/O Time as a percentage of Elapsed Time Total Disk Reads: 4Captured SQL account for 50.0% of TotalPhysical ReadsExecutions Reads perExec%Total Elapsed Time(s)%CPU%IO SQLIdSQL Module SQL Text140.2525.000.017.7786.83select q_name, state, delay, e... 1025.00 1.6645.970.68PL/SQLDeveloperselect dbms_workload_reposito... 04,6500.000.00 1.0141.470.00JDBC ThinClientselect * from (select _no... 0180.000.000.0061.400.00JDBC ThinClientselectS_95598_WKST_RELA.RELA_... 01270.000.000.0548.140.00select privilege# from sysauth... 01410.000.000.0944.430.03update seg$ set type#=:4, bloc... 000.000.0062.000.00insert into sys.col_usage$ (ob... 01240.000.000.0548.330.00selectSYS_CONTEXT('USERENV', ... 010.000.000.0060.660.00delete from dependency$ where...05740.000.000.0632.460.00JDBC ThinClientselect app_no, seat_emp_no,em...SQL ordered by Physical Reads (UnOptimized)UnOptimized Read Reqs = Physical Read Reqts - Optimized Read Reqs%Opt - Optimized Reads as percentage of SQL Read Requests%Total - UnOptimized Read Reqs as a percentage of Total UnOptimized Read Reqs Total Physical Read Requests: 4Captured SQL account for 8.6E+03% of TotalTotal UnOptimized Read Requests: 4Captured SQL account for 8.6E+03% of TotalTotal Optimized Read Requests: 1Captured SQL account for 0.0% of TotalUnOptimized Read Reqs Physical ReadReqsExecutions UnOptimized Reqsper Exec%Opt%Total SQLIdSQLModuleSQL Text34134100.008525.00PL/SQLDeveloperselect dbms_workload_reposito...1140.250.0025.00select q_name, state, delay, e...004,6500.000.00JDBC ThinClientselect * from (select _no...00180.000.00JDBC ThinClientselectS_95598_WKST_RELA.RELA_...001270.000.00select privilege# from sysauth... 001410.000.00update seg$ set type#=:4, bloc... 0000.00insert into sys.col_usage$ (ob...001240.000.00selectSYS_CONTEXT('USERENV', ...0010.000.00delete from dependency$ where ...005740.000.00JDBC ThinClientselect app_no, seat_emp_no,em...SQL ordered by Executions%CPU - CPU Time as a percentage of Elapsed Time%IO - User I/O Time as a percentage of Elapsed TimeCaptured SQL account for 67.0% of TotalExecutions RowsProcessed Rows perExecElapsed Time(s)%CPU%IO SQLIdSQL Module SQL Text7,0227,022 1.0031.2940JDBC ThinClientINSERT INTO S_WKST_ORG_EXT(AP...7,01500.00 1.6345.90JDBC ThinClientupdate S_ATTACH_INFO setAPP_N...4,9644,964 1.000.2057.80JDBC ThinClientSELECT 1 FROM DUAL4,65100.00 1.3247.20JDBC ThinClientselect * from (select _no...4,65000.00 1.0141.50JDBC ThinClientselect * from (select _no...87300.000.2245.90JDBC ThinClientupdate S_COMM_REC setHANDLE_I...87100.000.1848.20JDBC ThinClientupdate S_ATTACH_INFO setHANDL...639651 1.020.08510select file# from file$ where ...57400.000.0632.50JDBC ThinClientselect app_no, seat_emp_no, em...4862100.430.0454.90select /*+ connect_by_filterin...SQL ordered by Parse CallsTotal Parse Calls: 4,508Captured SQL account for 67.9% of TotalParse Calls Executions% Total Parses SQL Id SQL Module SQL Text2354,651 5.21JDBC Thin Client select * from (select _no...2344,650 5.19JDBC Thin Client select * from (select _no...2347,015 5.19JDBC Thin Client update S_ATTACH_INFO set APP_N...2347,022 5.19JDBC Thin Client INSERT INTO S_WKST_ORG_EXT (AP...225871 4.99JDBC Thin Client update S_ATTACH_INFO set HANDL...225873 4.99JDBC Thin Client update S_COMM_REC set HANDLE_I...205639 4.55select file# from file$ where ...127127 2.82select privilege# from sysauth...127486 2.82select /*+ connect_by_filterin...124124 2.75select SYS_CONTEXT('USERENV', ...124124 2.75select value$ from props$ wher...124124 2.75JDBC Thin Client insert into sys.aud$( sessioni...124124 2.75select decode(failover_method,...1244,964 2.75JDBC Thin Client SELECT 1 FROM DUAL59141 1.31update seg$ set type#=:4, bloc...5959 1.31select us# from undo$ where st...55142 1.22select /*+ rule */ name, file#...5465 1.20select type#, blocks, extents,...5164 1.13select us#, status$, user#, ts...50118 1.11update undo$ set name=:2, file...5059 1.11select count(*) from undo$SQL ordered by Sharable MemoryOnly Statements with Sharable Memory greater than 1048576 are displayedSharable Mem (b)Executions% Total SQL Module SQL Text。

ORACLEAWR报告详细分析

ORACLEAWR报告详细分析ORACLE AWR（Automatic Workload Repository）报告是ORACLE数据库中的性能监控工具，用于收集和存储数据库工作负载的信息。

AWR报告提供了关于数据库性能的详细分析，可以用于识别性能瓶颈和优化查询。

AWR报告包含了大量的信息，包括系统配置、会话统计、等待事件、SQL查询和索引统计等。

下面将详细分析AWR报告的各个重要部分。

1.系统配置：AWR报告的第一部分包含了数据库的系统配置信息，如数据库版本、操作系统版本、CPU配置、内存配置等。

这些信息对于了解系统的硬件和操作系统环境非常有帮助。

2.数据库实例性能指标：AWR报告提供了一系列的性能指标，如数据库的并发会话数、平均等待时间、平均响应时间、平均I/O请求等。

通过分析这些指标，可以了解数据库的整体性能状况。

3.会话统计信息：AWR报告中的会话统计信息可以帮助识别出高负载会话和频繁使用资源的会话。

这些统计信息包括会话的执行次数、等待事件、CPU使用率等。

通过分析这些信息，可以找出影响数据库性能的会话，并作出相应的优化措施。

4.等待事件统计：等待事件统计信息显示了数据库中各种等待事件的频率和等待时间。

这些等待事件可能包括锁等待、I/O等待、CPU等待等。

通过分析等待事件统计信息，可以找到数据库中的性能瓶颈，并对其进行优化。

5.SQL统计信息：AWR报告提供了数据库中最频繁执行的SQL查询语句的统计信息。

这些统计信息包括SQL执行的次数、平均响应时间、I/O请求等。

通过分析这些统计信息，可以找出执行效率低下的SQL语句，并进行优化调整。

6.索引统计信息：AWR报告中的索引统计信息显示了数据库中索引的使用情况和效率。

这些统计信息包括索引的扫描次数、索引的存储空间利用率、索引的磁盘I/O等。

通过分析索引统计信息，可以确定是否需要调整索引的使用方式或者对索引进行优化。

总结起来，AWR报告通过收集和分析数据库的各种统计信息，为数据库管理员和开发人员提供了深入分析数据库性能的工具。

AWR分析报告解析

AWR分析报告解析定义：awr报告是oracle 10g下提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，通过这个报告，我们就可以了解一个系统的整个运行情况，这就像一个人全面的体检报告。

一、如何分析：在看awr报告的时候，我们并不需要知道所有性能指标的含义，就可以判断出问题的所在，这些性能指标其实代表了oracle内部实现，对oracle理解的越深，在看awr报告的时候，对数据库性能的判断也会越准确在看性能指标的时候，心里先要明白，数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的（ps：我们先假设这个三个地方都没有物理上的故障），当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能是解析sql语句，也可能是过滤太多的数据，到不一定是和io或内存有关系了。

当我们把一条sql送到数据库去执行的时候，我们要知道，什么时候用到cpu，什么时候用到内存，什么时候用到io ？1. cpu：解析sql语句，尝试多个执行计划，最后生成一个数据库认为是比较好的执行计划，不一定是最优的，因为关联表太多的时候，数据库并不会穷举所有的执行计划，这会消耗太多的时间，oracle怎么就知道这条数据时你要，另一个就不是你要的呢，这是需要cpu来过滤的。

2. 内存：sql语句和执行计划都需要在内存保留一段时间，还有取到的数据，根据lru算法也会尽量在内存中保留，在执行sql语句过程中，各种表之间的连接，排序等操作也要占用内存3. io：如果需要的数据在内存中没有，则需要到磁盘中去取，就会用到物理io了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，也需要用到临时表空间，也就用到物理io了。

这里有一点说明的是，虽然oracle占用了8G的内存，但pga一般只占8G 的20%，对于专用服务器模式，每次执行sql语句，表数据的运算等操作，都在pga中进行的，也就是说只能用1.6G左右的内存，如果多个用户都执行多表关联，而且表数据又多，再加上关联不当的话，内存就成为瓶颈了，所有优化sql很重要的一点就是，减少逻辑读和物理读二、如何生成awr报告：1：登陆对应的数据库服务器2：找到oracle磁盘空间（d:oracle\product\10.2.0\db_1\RDBMS\Admin) 3：执行cmd-cd d:回车4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回车5：sqlplus 用户名/密码@服务连接名(例：sqlpluscarmot_esz_1/carmot@igrp)6：执行@awrrpt.sql 回车第一步输入类型：html第二步输入天数：天数自定义（如1，代表当天，如果2，代表今天和昨天。