tp钱包官方正版|awr
作者： tp钱包官方正版
2024-03-07 17:10:01
AWR 报告深度解读：AWR的原理和基本功能 - 墨天轮
AWR 报告深度解读：AWR的原理和基本功能 - 墨天轮
排行 数据库百科 核心案例 行业报告 月度解读 大事记 产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
数说
活动
大会
学习 课程中心 推荐优质内容、热门课程学习路径 预设学习计划、达成学习目标知识图谱 综合了解技术体系知识点课程库 快速筛选、搜索相关课程视频学习 专业视频分享技术知识电子文档 快速搜索阅览技术文档文档
问答
工具 SQLRUN 在线数据库即时SQL运行平台数据库在线实训平台 实操环境、开箱即用、一键连接AWR分析 上传AWR报告，查看分析结果SQL格式化 快速格式化绝大多数SQL语句SQL审核 审核编写规范，提升执行效率PLSQL解密 解密超4000字符的PL/SQL语句OraC函数 查询Oracle C 函数的详细描述智能助手小墨 关于数据库相关的问题，您都可以问我 数据库百科核心案例行业报告月度解读大事记产业图谱我的订单
登录后可立即获得以下权益 免费培训课程 收藏优质文章 疑难问题解答 下载专业文档 签到免费抽奖 提升成长等级 立即登录 登录 注册 登录 注册 首页资讯数说活动大会课程文档排行问答我的订单 15 微信扫码 复制链接 新浪微博 分享数说 采集到收藏夹 分享到数说 首页 /
AWR 报告深度解读：AWR的原理和基本功能 AWR 报告深度解读：AWR的原理和基本功能 原创 eygle 2019-08-28 12999 为了系统化的梳理 AWR 的知识体系，我们整理了一个系列文章，希望从原理、使用到 AWR 报告的解读，给读者展示全面的 AWR 知识体系，本文是这个系列文章的开篇。自动负载信息库（Automatic Workload Repository，AWR）是在Oracle
10g中被引入的，缺省地被安装到Oracle10g数据库中，用于收集关于该特定数据库的操作统计信息和其他统计信息。Oracle以固定的时间间隔（默认为每小时一次）为其所有重要统计信息和负载信息执行一次快照，并将这些快照存储在AWR中。这些信息在AWR中保留给定的时间（默认为一周），然后被清除。执行快照的频率及其保持时间都可以自定义，以满足不同环境的独特需要。AWR的采样间隔及信息保留等信息可以通过dba_hist_wr_control视图查询得到：SQL> select * from dba_hist_wr_control;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- -------------------- ------------------------------ ----------
3965153484 +00000 01:00:00.0 +00007 00:00:00.0 DEFAULTAWR的采样工作由后台进程MMON每60分钟执行一次，ASH信息同样会被采样写出到AWR负载库。虽然ASHbuffers被设计为保留1小时的信息，但是很多时候这个内存是不足够的，当ASH
buffers写满之后，另外一个后台进程MMNL将会主动将ASH信息写出。由于数据量巨大，把所有的ASH数据写到磁盘上是不可接受的。一般是在写到磁盘的时候过滤这个数据，写出的数据占采样数据的10%，写出时通过direct-path
insert完成，尽量减少日志生成，从而最小化数据库性能影响。通过下图，可以直观地理解ASH与AWR的关系。 ASH与AWR的关系AWR的行为受到数据库另外一个重要初始化参数STATISTICS_LEVEL的影响，该参数有以下3个可选值。· BASIC：设置为BASIC时，AWR的统计信息收集和所有自我调整的特性都被关闭。· TYPICAL：设置为TYPICAL时，数据库收集部分统计信息，这些信息为典型的数据库监控需要，是数据库的缺省设置。· ALL：所有可能的统计信息都被收集。AWR的采样设置可以通过Oracle 10g新增加的一个系统包dbms_workload_repository来完成，这个Package中的过程MODIFY_SNAPSHOT_SETTINGS可以用于修改AWR的缺省采样设置：PROCEDURE MODIFY_SNAPSHOT_SETTINGSArgument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
RETENTION NUMBER IN DEFAULT
INTERVAL NUMBER IN DEFAULT
TOPNSQL NUMBER IN DEFAULT
DBID NUMBER IN DEFAULTASH信息的写出比例受一个隐含参数控制：SQL> @GetHparDes.sql
Enter value for par: filter_ratio
old 6: AND x.ksppinm LIKE '%&par%'
new 6: AND x.ksppinm LIKE '%filter_ratio%'
NAME VALUE DESCRIB
------------------------------ ---------- ------------------------------------------------
_ash_disk_filter_ratio 10 Ratio of the number of in-memory samples to the
number of samples actually written to disk写出到AWR负载库的ASH信息记录在AWR的基础表wrh$active_session_hist中，wrh$active_session_hist是一个分区表，Oracle会自动进行数据清理。wrh$active_session_hist记录的这些历史信息可以通过dba_hist_active_sess_history视图进行聚合查询，通过简化后的下图来看一下Oracle以session为起点的一系列用以追踪和诊断的数据库对象。 一系列用以追踪和诊断的数据库对象简单总结一下：· V$SESSION代表数据库活动的开始，是为源起；· V$SESSION_WAIT视图用以实时记录活动session的等待情况，是当前信息；· V$SESSION_WAIT_HISTORY是对V$SESSION_WAIT的简单增强，记录活动SESSION的最近10次等待；· V$ACTIVE_SESSION_HISTORY是ASH的核心，用以记录活动session的历史等待信息，每秒采样一次，这部分内容记录在内存中，期望值是记录一个小时的内容；· WRH$_ACTIVE_SESSION_HISTORY是V$ACTIVE_SESSION_HISTORY在AWR的存储地，V$ACTIVE_SESSION_HISTORY中记录的信息会被定期（每小时一次）的刷新到负载库中，并缺省保留一个星期用于分析。· DBA_HIST_ACTIVE_SESS_HISTORY视图是WRH$_ACTIVE_SESSION_HISTORY视图和其他几个视图的联合展现，通常通过这个视图进行历史数据的访问。可以看到，关于session信息的记录，Oracle从不同的粒度进行了增强，目的只有一个，那就是全面真实地记录、监控和反映数据库的运行状况。AWR记录的信息还远不止于此，通过系统的自动采样，AWR可以收集数据库运行的各方面统计信息及等待等重要数据，提供给数据库诊断分析使用。当然AWR的信息需要独立存储，在Oracle 10g中，新增的SYSAUX表空间是这类信息的存储地：SQL> select OCCUPANT_NAME,OCCUPANT_DESC,SCHEMA_NAME,SPACE_USAGE_KBYTES/1024 "MB"
2 from V$SYSAUX_OCCUPANTS WHERE OCCUPANT_NAME LIKE '%AWR%'
3 /
OCCUPANT_NAME OCCUPANT_DESC SCHEMA_NAME MB
------------ ---------------------------------------------- ---------- -----
SM/AWR Server Manageability - Automatic Workload Repository SYS 250.875在Oracle
10g之前的版本中，类似的功能是由Statspack实现，但是Statspack需要由用户自行安装调度，并且其收集的信息十分有限。我们一直提到的session历史信息Statspack就是无法提供的。AWR大大强化了这部分信息，由于AWR收集的信息十分完备，所以经常被称为“数据库的数据仓库”。AWR信息的修改缺省的，数据库每小时采样一次AWR数据，保留7天，这些定义是可以被修改的。DBA可以通过DBMS_WORKLOAD_REPOSITORY包来控制AWR的行为。通过如下执行可以手工创建AWR采样点，在进行测试时，在测试前后进行手工采样可以帮助我们获得完善的测试性能数据：SQL> exec dbms_workload_repository.create_snapshot();
PL/SQL procedure successfully completed.创建的采样点，可以通过DBA_HIST_SNAPSHOT视图来查询。除了手工创建采样点之外，数据库也允许我们手工删除采样点，这可以通过DBMS_WORKLOAD_REPOSITORY 包中的DROP_SNAPSHOT_RANGE过程来实现，该过程需要一个采样范围输入，然后删除指定范围内的AWR采样信息：SQL> select snap_id from DBA_HIST_SNAPSHOT where rownum < 6;
SNAP_ID
----------
3860
3886
3887
3888
3889
SQL> exec dbms_workload_repository.drop_snapshot_range(low_snap_id=>3860,high_snap_id=>3889);
PL/SQL procedure successfully completed.
SQL> select snap_id from DBA_HIST_SNAPSHOT where rownum < 6;
SNAP_ID
----------
3890
3891
3892
3893
3894通过MODIFY_SNAPSHOT_SETTINGS 过程，还可以调整包括快照采样频率、快照保存时间、以及捕获的SQL 数量等信息。MODIFY_SNAPSHOT_SETTINGS 主要包含三个输入参数：PROCEDURE MODIFY_SNAPSHOT_SETTINGS Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
RETENTION NUMBER IN DEFAULT
INTERVAL NUMBER IN DEFAULT
TOPNSQL NUMBER IN DEFAULT
DBID NUMBER IN DEFAULT其含义分别如下：· Retention：设置快照保存的时间，单位是分钟，最小值为1 天，最大值为100年。如果该参数值设置为0 ，则表示永久保留快照信息。· Interval：设置快照的收集频率，以分钟为单位，最小值为10 分钟，最大值为1 年。如果设置该参数值为0，就表示禁用AWR 特性。· Topnsql：有两种方式指定该参数，如果给定值为NUMBER，则其含义为收集比较占用资源的SQL
数量，最小值为30，最大不超过100000000，这个设置会覆盖系统的statistics/flush
级别设置；如果这个参数设置为VARCHAR2，则允许的定义有： DEFAULT, MAXIMUM, N，这里的N同样指采样的Top
SQL数量，DEFAULT参数受statistics level 影响，在TYPICAL设置下，采样Top 30，在ALL设置下采样Top
100 ，如果定义MAXIMUM 将引起系统采样和捕获所有的SQL。如，修改采样间隔：SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>120);
PL/SQL procedure successfully completed.
SQL> select * from dba_hist_wr_control;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------------ -------------------- ----------
2310943069 +00000 02:00:00.0 +00007 00:00:00.0 DEFAULT同时修改采样间隔为30分钟，保留周期15天（时间以分钟计算）：SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>15*24*60);
PL/SQL procedure successfully completed.AWR报告的生成根据AWR记录的数据，我们可以通过报告来展现这些信息。报告可以通过运行脚本生成类似statspack report的AWR报告，也可以通过Package直接输出。脚本位于$ORACLE_HOME/rdbms/admin/awrrpt.sql，报表可以通过两种形式输出：TEXT和HTML。用脚本生成AWR报告的过程与生成Statspack报告非常类似，需要以sys用户执行这个脚本，执行过程需要选择报表类型、天数（用来决定显示那几天内的snapshot）、begin_snap、end_snap以及报表名称等5个参数。如果不想手工输入参数，可以修改$ORACLE_HOME/rdbms/admin/awrrpti.sql文件，把需要用到的5个变量设置好，在执行过程中就不必再输入了，修改过的awrrpti.sql脚本可以用于自动生成报表。以下是一个报告生成的简单示范过程，首先Oracle会要求我们指定报告类型：SQL> @?/rdbms/admin/awrrpt
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
3243092624 SMSBOSS 1 smsboss
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: text
Type Specified: text定义文件格式之后，数据库会要求输入报告包含采样的时间段：Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 3243092624 1 SMSBOSS smsboss db480-6
Using 3243092624 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing
specifying a number lists all completed snapshots.
Enter value for num_days: 2如果定义为2天之内，则2天之内的采样都会被列出供用户选择：Listing the last 2 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
smsboss SMSBOSS 10735 15 Mar 2007 00:01 1
10736 15 Mar 2007 01:00 1
10737 15 Mar 2007 02:00 1
10738 15 Mar 2007 03:00 1
。。。。。。。。。。
10750 15 Mar 2007 15:00 1
10751 15 Mar 2007 16:00 1
10752 15 Mar 2007 17:00 1
10753 15 Mar 2007 18:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 10735
Begin Snapshot Id specified: 10735
Enter value for end_snap: 10750
End Snapshot Id specified: 10750完成类似问题的回答后，报告生成。awrrpt.sql脚本实际上是调用DBMS_WORKLOAD_REPOSITORY包来生成报表，这个包中主要有两个函数用于生成报表：DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT用于生成TEXT格式报表；DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML用于生成HTML格式报表。例如，以下命令将和之前的定义等价：select * from
table(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT(3243092624,1,10735,10756));AWR比较报告的生成除了常规的AWR报告，Oracle还支持生成AWR比较报告，该报告可以对两个时段进行比较，生成详细的对比报告，提供比较分析，非常有助于问题的发现和解决。生成对比报告，可以调用$ORACLE_HOME/rdbms/admin/awrddrpt.sql脚本实现，在OEM中可以更直观的看到这个过程，下图在操作中选择“比较时段”： 图：选择比较时段，生成比较报告按照提示操作，选择两个时段，即可生成一个比较报告： 图：比较报告的两个时段生成的比较报告可以清晰的看到不同日期数据库的性能对比，以下报告显示，第一个时段DB Time为43.8分钟，第二个时段数据库的DB Time高达885.31分钟，同样是一个小时，数据库的性能存在巨大的差异： 在负载概要部分，更详细的对比显示，两个时段的Logical Reads有显著的不同，进一步分析SQL列表，就可以找到引起过高逻辑读的SQL语句： 在数据库性能调整前后，生成对比报告，是显示调整效果的最佳手段之一。Baseline - 基线在创建数据库比较报告时，通常选择两个时段的采样进行比较，而如果我们能够创建基于正常运行的数据库快照，在发生性能问题时，就可以将异常与正常情况进行比较，获得差异对比信息。基线-BaseLine说的就是这个含义。创建Baseline
时，需要指定一个采样范围，指点范围中的快照会被保存下来，不会因为过期而被删除，创建Baseline 可以使用CREATE_BASELINE
过程，执行该过程时分别指定开始和结束的snap_id，然后为该baseline 定义一个名称即可，例如：1 SQL> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id =>3890,
3 end_snap_id => 3894,
4 baseline_name => 'baseline01');
5 END;
6 /
PL/SQL procedure successfully completed.
SQL> col baseline_name for a30
SQL> select dbid,baseline_name,start_snap_id,end_snap_id from dba_hist_baseline;
DBID BASELINE_NAME START_SNAP_ID END_SNAP_ID
---------- ------------------------------ ------------- -----------
2310943069 baseline01 3890 3894使用DROP_BASELINE 过程删除Baseline信息，删除时可以通过cascade 参数选择是否将其关联的Snapshots 级联进行删除，下例选择了级联删除，例如：SQL> BEGIN
2 DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name =>'baseline01',cascade => true);
3 END;
4 /
PL/SQL procedure successfully completed.有了基线之后，AWR报告之间的对比就会更加明确和有效。AWR报告的分析报告和Statspack的报告极为类似，不过Oracle 10g增加了很多新的内容，我们对新的内容进行一点简单介绍。首先报告在Top 5 Timed Events后面增加了时间模型部分，根据前面对Statspack的分析可以知道，实际上等待时间也是依据时间模型来建立的，在Oracle 10g中，时间模型被独立出来并进一步细化：Time Model Statistics DB/Inst: SMSBOSS/smsboss Snaps: 10735-10756
-> Total time in database user-calls (DB Time): 24514.6s
-> Statistics 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 name
Statistic Name Time (s) % of DB Time
------------------------------------------ ------------------ ------------
sql execute elapsed time 24,813.6 101.2
DB CPU 12,885.3 52.6
PL/SQL execution elapsed time 362.3 1.5
parse time elapsed 61.0 .2
connection management call elapsed time 38.9 .2
hard parse elapsed time 19.9 .1
hard parse (sharing criteria) elapsed time 4.3 .0
sequence load elapsed time 2.0 .0
PL/SQL compilation elapsed time 1.2 .0
failed parse elapsed time 0.2 .0
repeated bind elapsed time 0.1 .0
hard parse (bind mismatch) elapsed time 0.1 .0
DB time 24,514.6 N/A
background elapsed time 3,050.2 N/A
background cpu time 664.4 N/A
-------------------------------------------------------------等待事件通过分类之后，可以被快速汇总，从而显示数据库瓶颈消耗在哪一类资源上：Wait Class DB/Inst: SMSBOSS/smsboss Snaps: 10735-10756
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc
Avg
%Time Total Wait wait Waits
Wait Class Waits -outs Time (s) (ms) /txn
-------------------- ---------------- ------ ---------------- ------- ---------
User I/O 2,435,546 .0 6,996 3 1.4
System I/O 786,339 .0 2,398 3 0.4
Configuration 1,800 37.3 217 121 0.0
Commit 13,264 .0 124 9 0.0
Network 828,998 .0 80 0 0.5
Concurrency 1,092 .0 74 68 0.0
Other 85,958 .0 10 0 0.0
Application 8,484 .0 9 1 0.0
-------------------------------------------------------------对于这个数据库，显然主要的等待都消耗在IO上，那么调整SQL、优化IO实际上应该是优化这个系统的主要目标。更进一步地，Oracle将操作系统的统计信息也收集计算进来，这部分信息非常重要（以前的Statspack中是不包含这部分信息的），包括了CPU的繁忙程度、IO等待情况、内存总量、CPU数量等信息，这些信息对于评价数据库的并发性能、事务处理能力等都非常重要：Operating System Statistics DB/Inst: SMSBOSS/smsboss Snaps: 10735-10756
Statistic Total
-------------------------------- --------------------
AVG_BUSY_TIME 627,108
AVG_IDLE_TIME 6,927,000
AVG_IOWAIT_TIME 291,066
AVG_SYS_TIME 155,566
AVG_USER_TIME 470,269
BUSY_TIME 1,256,735
IDLE_TIME 13,856,519
IOWAIT_TIME 584,638
SYS_TIME 313,671
USER_TIME 943,064
LOAD 0
OS_CPU_WAIT_TIME 106,200
RSRC_MGR_CPU_WAIT_TIME 0
VM_IN_BYTES 57,344
VM_OUT_BYTES 0
PHYSICAL_MEMORY_BYTES 4,165,320,704
NUM_CPUS 2
-------------------------------------------------------------在AWR报告的SQL部分，则增加了SQL ordered by Elapsed Time和SQL ordered by CPU Time部分，通过这两部分内容，Oracle将最耗时的SQL抓取了出来，那么现在AWR对SQL的采样已经包括了一下内容。· SQL ordered by CPU Time · SQL ordered by Elapsed Time · SQL ordered by Executions · SQL ordered by Gets · SQL ordered by Parse Calls · SQL ordered by Reads · SQL ordered by Sharable Memory · SQL ordered by Version Count 可以说在Oracle
10g中，Oracle对SQL的采样已经相当完备了。从Oracle 11gR2开始，在SQL采样部分还包括了SQL ordered by
User I/O Wait Time和SQL ordered by Physical Reads
(UnOptimized)部分，对I/O资源的使用做出了进一步的评估，从SQL ordered by User I/O Wait
Time部分我们可以清晰的看到哪些SQL消耗了更高的I/O等待，对于协助诊断分析数据库具有极大的参考意义。下图是这一新增量度的范例： 更为有趣的是，如果我们将Oracle 10g的AWR数据导入到Oracle 11gR2中，就能够在生成AWR报告中利用这一新特性。通过EM生成AWR报告通过Oracle 10g基于Web方式的强大EM功能，我们可以很容易地进行AWR报告的创建查看以及分析等操作。如下图所示，在EM管理选项中有一项称为“自动工作量资料档案库”，这就是配置和管理AWR信息的地方。 EM管理选项单击该链接，可以进入编辑管理页面，如图10-11所示，在这里可以根据需要调整快照的保留时间和收集间隔等信息。 自动工作量资料档案库编辑页面如果要查看和管理快照，可以单击快照具体数值中的链接，进入详细页面，该详细页面会列出系统中记录的采样点，首先选择一个快照作为AWR报告的起始点，然后在下拉菜单中选择“查看报告”，单击“开始”按钮，如下图所示。查看报告下一步进入选择结束采样点页面，如下图所示。 选择结束快照单击“确定”按钮，数据库即开始生成AWR报告，如下图所示。 正在创建报告此后生成的报告和通过脚本生成的报告内容是一致的，不过是通过Web形式展现出来（当然也可以转存为本地HTML格式的报告），如下图所示。 生成的AWR报告AWR数据的导出导入在进行采样数据分析时，经常涉及到跨数据库的迁移，对于Statspack的采样数据，可以通过spuexp.sql脚本，按照用户模式进行导出。而AWR的数据相对复杂，不能通过简单的用户模式导出，但是Oracle提供了两个脚本：awrextr.sql 脚本用于导出；awrload.sql 用户AWR数据的加载；而加载后的数据可以通过awrddrpi.sql来生成报告。也是非常方便高效的。查看这两个脚本，可以看到其中主要调用了dbms_swrf_internal 包来完成数据的卸载和加载工作。awrextr.sql的核心内容如下：begin
/* call PL/SQL routine to extract the data */
dbms_swrf_internal.set_awr_dbid(-2);
dbms_swrf_internal.awr_extract(dmpfile => :dmpfile,
dmpdir => :dmpdir,
bid => :bid,
eid => :eid,
dbid => :dbid);
dbms_swrf_internal.clear_awr_dbid;
end;
/dbms_swrf_internal.awr_extract过程通过指定相关参数（包括导出文件名、Directory路径名、开始snapid、结束的snapid，dbid）来实现数据转储。awrload.sql的核心内容如下：begin
/* call PL/SQL routine to load the data into the staging schema */
dbms_swrf_internal.set_awr_dbid(-2);
dbms_swrf_internal.awr_load(schname => :schname,
dmpfile => :dmpfile,
dmpdir => :dmpdir);
dbms_swrf_internal.clear_awr_dbid;
end;
/
begin
/* call PL/SQL routine to move the data into AWR */
dbms_swrf_internal.set_awr_dbid(-2);
dbms_swrf_internal.move_to_awr(schname => :schname);
dbms_swrf_internal.clear_awr_dbid;
end;
/这个脚本通过dbms_swrf_internal.awr_load过程向数据库加载数据，其中需要定义一个临时的Schema名称，加载完成之后，再通过dbms_swrf_internal.move_to_awr将数据从临时Schema转移到正式Schema中。了解这两个脚本的核心内容之后，其使用就一目了然了。awrextr.sql 脚本非常易用，以下是一个测试输出：[oracle@dbrac1 admin]$ sqlplus "/ as sysdba" @?/rdbms/admin/awrextr.sql
SQL*Plus: Release 10.2.0.4.0 - Production on Sun Aug 1 23:39:37 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer: This SQL/Plus script should only be called under
the guidance of Oracle Support.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~执行的说明注释部分：~~~~~~~~~~~~~
AWR EXTRACT
~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ This script will extract the AWR data for a range of snapshots ~
~ into a dump file. The script will prompt users for the ~
~ following information: ~
~ (1) database id ~
~ (2) snapshot range to extract ~
~ (3) name of directory object ~
~ (4) name of dump file ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Databases in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id DB Name Host
------------ ------------ ------------
* 3368702614 NAPDB dbrac1
* 3368702614 NAPDB dbrac2
The default database id is the local one: '3368702614'. To use this
database id, press
Enter value for dbid:
Using 3368702614 for Database ID
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing
specifying a number lists all completed snapshots.
Enter value for num_days:列举快照信息：Listing all Completed Snapshots
DB Name Snap Id Snap Started
------------ --------- ------------------
NAPDB 22492 01 Aug 2010 10:00
22493 01 Aug 2010 11:00
22494 01 Aug 2010 12:00
22495 01 Aug 2010 13:00
22496 01 Aug 2010 14:00
22497 01 Aug 2010 15:00
22498 01 Aug 2010 16:00
22499 01 Aug 2010 17:00
22500 01 Aug 2010 18:00
22501 01 Aug 2010 19:00
22502 01 Aug 2010 20:00
22503 01 Aug 2010 21:00
22504 01 Aug 2010 22:00
22505 01 Aug 2010 23:00定义需要导出的快照范围： Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 22338
Begin Snapshot Id specified: 22338
Enter value for end_snap: 22505
End Snapshot Id specified: 22505定义DataPUMP需要的路径：Specify the Directory Name
~~~~~~~~~~~~~~~~~~~~~~~~~~
Directory Name Directory Path
------------------------------ -------------------------------------------------
ADMIN_DIR /opt/oracle/product/10.2.0/db/md/admin
DUMP /opt/oracle/backup/
WORK_DIR /opt/oracle/product/10.2.0/db/work
Choose a Directory Name from the above list (case-sensitive).
Enter value for directory_name: DUMP
Using the dump directory: DUMP定义导出文件的名称：Specify the Name of the Extract Dump File
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The prefix for the default dump file name is awrdat_22338_22505.
To use this name, press
an alternative.
Enter value for file_name:
Using the dump file prefix: awrdat_22338_22505
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| The AWR extract dump file will be located
| in the following directory/file:
| /opt/oracle/backup/
| awrdat_22338_22505.dmp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~完成所有条件定义之后，AWR开始Extract数据，抽取数据的实质是通过一个Query条件来限制访问的数据： | *** AWR Extract Started ...
|
| This operation will take a few moments. The
| progress of the AWR extract operation can be
| monitored in the following directory/file:
| /opt/oracle/backup/
| awrdat_22338_22505.log
|
WHERE (dbid, snap_id) IN (SELECT dbid, snap_id FROM SYS.WRM$_SNAPSHOT WHERE DBID = 3368702614 AND SNAP_ID >=
22338 AND SNAP_ID <= 22505 AND STATUS = 0 AND BL_MOVED = 1)
Table List String Length: 2212
('WRM$_WR_CONTROL', 'WRM$_DATABASE_INSTANCE', 'WRM$_SNAPSHOT', ....'WRH$_ACTIVE_SESSION_HISTORY_BL')
Starting "SYS"."SYS_EXPORT_TABLE_01":
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 125.4 MB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/COMMENT
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
. . exported "SYS"."WRH$_SQL_PLAN" 1.425 MB 3969 rows
. . exported "SYS"."WRH$_WAITCLASSMETRIC_HISTORY" 5.969 MB 88231 rows
......................
. . exported "SYS"."WRR$_FILTERS" 0 KB 0 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/opt/oracle/backup/awrdat_22338_22505.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 23:41:54完成数据抽取后，我们就可以获得一个转储的导出文件。比如将生产库的采样数据导入测试库，就可以比较两者或多者之间的性能差异或变化，是非常有效的采样数据利用手段。将导出文件转移到目标数据库或性能分析数据库，可以通过执行awrload.sql导入到数据库中。在导入之前，首先创建一个目录指向包含导出文件的路径，如：SQL> create or replace directory eygle as 'E:\AWRData';
Directory created.然后调用awrload.sql脚本执行导入：SQL> @?/rdbms/admin/awrload
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer: This SQL/Plus script should only be called under
the guidance of Oracle Support.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
AWR LOAD
~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ This script will load the AWR data from a dump file. The ~
~ script will prompt users for the following information: ~
~ (1) name of directory object ~
~ (2) name of dump file ~
~ (3) staging schema name to load AWR data into ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Specify the Directory Name
~~~~~~~~~~~~~~~~~~~~~~~~~~
Directory Name Directory Path
------------------------------ -------------------------------------------------
DATA_PUMP_DIR D:\oracle\admin\enmo\dpdump\
EYGLE E:\AWRData
ORACLE_OCM_CONFIG_DIR D:\oracle\10.2.0\ccr\state
Choose a Directory Name from the list above (case-sensitive).
Enter value for directory_name: EYGLE
Using the dump directory: EYGLE首先列出的是目录名，选择我们之前建好，指向包含导出文件的路径。然后需要导入的文件名称，注意输入文件名不需要包含后缀，否则会报错：Specify the Name of the Dump File to Load
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please specify the prefix of the dump file (.dmp) to load:
Enter value for file_name: awrdat_46145_46197
Loading from the file name: awrdat_46145_46197.dmp然后有一个关键步骤是创建一个中间转换Schema，缺省的名称是AWR_STAGE，这个选择缺省即可，转换完成之后会自动删除：Staging Schema to Load AWR Snapshot Data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The next step is to create the staging schema
where the AWR snapshot data will be loaded.
After loading the data into the staging schema,the data will be transferred into the AWR tables in the SYS schema.
The default staging schema name is AWR_STAGE.To use this name, press
Enter value for schema_name:
Using the staging schema name: AWR_STAGE
Choose the Default tablespace for the AWR_STAGE user
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choose the AWR_STAGE users's default tablespace. This is thetablespace in which the AWR data will be staged.
TABLESPACE_NAME CONTENTS DEFAULT TABLESPACE
------------------------------ --------- ------------------
EYGLE PERMANENT
SYSAUX PERMANENT *
USERS PERMANENT
Pressing
Enter value for default_tablespace:
Using tablespace SYSAUX as the default tablespace for the AWR_STAGE
Choose the Temporary tablespace for the AWR_STAGE user
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choose the AWR_STAGE user's temporary tablespace.
TABLESPACE_NAME CONTENTS DEFAULT TEMP TABLESPACE
------------------------------ --------- -----------------------
TEMP TEMPORARY *
Pressing
tablespace (identified by *) being used.
Enter value for temporary_tablespace:
Using tablespace TEMP as the temporary tablespace for AWR_STAGE在选择了缺省表空间及临时表空间之后，创建用户和导入的进程自动开始：... Creating AWR_STAGE user
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Loading the AWR data from the following
| directory/file:
| E:\AWRData
| awrdat_46145_46197.dmp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| *** AWR Load Started ...
|
| This operation will take a few moments. The
| progress of the AWR load operation can be
| monitored in the following directory/file:
| E:\ AWRData
| awrdat_46145_46197.log导入的基本原则是和原来的数据不产生冲突，所以大量的判断子句被加入进来：WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_SERVICE_STAT)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_SERVICE_STAT_BL)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_SYSMETRIC_HISTORY)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_FILEMETRIC_HISTORY)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_WAITCLASSMETRIC_HISTORY)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_TABLESPACE_STAT)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_TABLESPACE_STAT_BL)
WHERE (DBID, SNAP_ID) NOT IN (SELECT DBID, SNAP_ID FROM AWR_STAGE.WRH$_LOG)最后Oracle通过INSERT APPEND的方式向SYS对象追加数据，然后删除临时用户，完成导入工作：INSERT /*+ APPEND */ INTO SYS.WRM$_SNAP_ERROR (SNAP_ID, DBID, INSTANCE_NUMBER, TABLE_NAME, ERROR_NUMBER)
SELECT SNAP_ID, DBID, INSTANCE_NUMBER, TABLE_NAME, ERROR_NUMBER FROM AWR_STAGE.WRM$_SNAP_ERROR WHERE (DBID,
SNAP_ID, INSTANCE_NUMBER, TABLE_NAME) NOT
IN (SELECT DBID, SNAP_ID, INSTANCE_NUMBER, TABLE_NAME FROM SYS.WRM$_SNAP_ERROR)
UPDATE SYS.WRM$_SNAPSHOT s1 SET status = 0, error_count = (SELECT count(*) FROM SYS.wrm$_snap_error s2 WHERE
s1.dbid = s2.dbid AND s1.snap_id = s2.snap_id AND s1.instance_number = s2.instance_number) WHERE status
1 AND BITAND(snap_flag, 2) != 0
AND (dbid, snap_id) IN (SELECT dbid, snap_id FROM AWR_STAGE.WRM$_SNAPSHOT)
Finished MOVE_TO_AWR procedure
... Dropping AWR_STAGE user
End of AWR Load注意：以上这个过程在Oracle
10.2.0.4及10.2.0.5中存在问题，数据导入非常缓慢，几百M的文件导入可能就需要数个小时的时间，在11g中及10.2.0.4之前的版本中不存在这个问题。10g的AWR数据可以导入到11g的数据库中，以下是一个导入范例：SQL> create or replace directory dadi as 'E:\AWRStat';
SQL> @?/rdbms/admin/awrload
~~~~~~~~~~
Specify the Directory Name
~~~~~~~~~~~~~~~~~~~~~~~~~~
Directory Name Directory Path
------------------------------ -------------------------------------------------
DADI E:\AWRStat
DATA_PUMP_DIR D:\oracle\admin\eyglee\dpdump\
Choose a Directory Name from the list above (case-sensitive).
Enter value for directory_name: DADI
Using the dump directory: DADI
Enter value for file_name: awrdat_49018_50602
Loading from the file name: awrdat_49018_50602.dmp
Enter value for schema_name:
Using the staging schema name: AWR_STAGE
TABLESPACE_NAME CONTENTS DEFAULT TABLESPACE
------------------------------ --------- ------------------
SYSAUX PERMANENT *
USERS PERMANENT
Enter value for default_tablespace:
Using tablespace SYSAUX as the default tablespace for the AWR_STAGE
Choose the Temporary tablespace for the AWR_STAGE user~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choose the AWR_STAGE user's temporary tablespace.
TABLESPACE_NAME CONTENTS DEFAULT TEMP TABLESPACE
------------------------------ --------- -----------------------
TEMP TEMPORARY *
Pressing
tablespace (identified by *) being used.
Enter value for temporary_tablespace:
Using tablespace TEMP as the temporary tablespace for AWR_STAGE
... Creating AWR_STAGE user
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Loading the AWR data from the following
| directory/file:
| E:\AWRStat
| awrdat_49018_50602.dmp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| *** AWR Load Started ...
|
| This operation will take a few moments. The
| progress of the AWR load operation can be
| monitored in the following directory/file:
| E:\AWRStat
| awrdat_49018_50602.log
|
... Dropping AWR_STAGE user
End of AWR Load导入的AWR数据，同样可以生成AWR报告，通过调用awrrpti.sql脚本即可，这个脚本会要求输入DBID和实例号，定义导入数据库相应的信息即可生成相应的报告。SQL> @?/rdbms/admin/awrrpti
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type:
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
3944144691 1 CCICDB ccicdb ccicdbsrv5
* 572103006 1 ENMO enmo EYGLEE
Enter value for dbid: 3944144691
Using 3944144691 for database Id
Enter value for inst_num: 1
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing
specifying a number lists all completed snapshots.
Enter value for num_days: 2
Listing the last 2 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
ccicdb CCICDB 46421 19 Oct 2010 00:00 1
46422 19 Oct 2010 00:15 1
46423 19 Oct 2010 00:30 1
46424 19 Oct 2010 00:45 1对于RAC集群环境，也可以通过调用awrrpti.sql脚本，按照不同的实例号来生成不同实例的AWR报告。如果希望了解AWR数据的存储和分布情况，可以调用awrinfo.sql来生成关于AWR数据的报告，根据报告里的snap_id分布情况，你可以选择通过手工来删除一定范围的采样数据：SQL> select min(snap_id), max(snap_id)
2 from dba_hist_snapshot
3 where dbid = 3944144691;
MIN(SNAP_ID) MAX(SNAP_ID)
------------ ------------
45189 47802
SQL> exec dbms_workload_repository.drop_snapshot_range(45189, 47802, 3944144691)
PL/SQL procedure successfully completed.
SQL> select * from dba_hist_snapshot where dbid = 3944144691;
no rows selected这个操作很快可以完成，如果检查数据字典可以发现，Oracle仅仅修改了对应SNAPSHOT的状态，而并没有真正删除快照（在11gR2最新的版本中，会执行直接删除操作）：SQL> select dbid, status, count(*)
2 from wrm$_snapshot
3 group by dbid, status;
DBID STATUS COUNT(*)
-------------- ---------------- --------------------
3812548755 0 89
96312462 0 50
3944144691 2 2614检查DBA_HIST_SNAPSHOT视图可以发现，这个视图的定义是只显示STATUS为0的记录：SQL> select text
2 from dba_views
3 where view_name = 'DBA_HIST_SNAPSHOT';
TEXT
--------------------------------------------------------------------------------
select snap_id, dbid, instance_number, startup_time,
begin_interval_time, end_interval_time,
flush_elapsed, snap_level, error_count
from WRM$_SNAPSHOT
where status = 0如果需要彻底清除某个实例的AWR数据，可以通如下命令指定DBID，则该数据库的所有采样都将被清除：SQL> exec dbms_swrf_internal.unregister_database(3944144691)
PL/SQL procedure successfully completed.多数据库实例的对比报告在RAC环境中，数据库的采样报告包含了两个实例的采样数据，可以通过awrddrpi.sql来生成两个实例的性能对比报告。当向数据库导入了其他实例的AWR信息之后，也可以使用这个脚本来生成不同实例的对比报告，诸如对生产环境和测试环境的比对，都可以通过类似这样的操作来实现。以下是awrddrpi.sql调用过程的一个简要列举：SQL> @?/rdbms/admin/awrddrpi
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Enter value for report_type:html
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
3944144691 1 CCICDB ccicdb ccicdbsrv5
* 572103006 1 ENMO enmo EYGLEE
Database Id and Instance Number for the First Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for dbid: 3944144691
Enter value for inst_num: 1
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for num_days: 1
Listing the last day's Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
ccicdb CCICDB 46421 19 Oct 2010 00:00 1
46422 19 Oct 2010 00:15 1
46423 19 Oct 2010 00:30 1
46424 19 Oct 2010 00:45 1
46425 19 Oct 2010 01:00 1
Specify the First Pair of Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 46421
Enter value for end_snap: 46422
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
3944144691 1 CCICDB ccicdb ccicdbsrv5
* 572103006 1 ENMO enmo EYGLEE
Database Id and Instance Number for the Second Pair of Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for dbid2: 572103006
Enter value for inst_num2: 1
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for num_days2: 1
Listing the last day's Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
enmo ENMO 111 02 Nov 2010 14:26 1
112 02 Nov 2010 14:27 1
113 02 Nov 2010 15:00 1
Specify the Second Pair of Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap2:AWR报告的实现AWR的本质是通过定时采样，收集数据库的性能数据，然后通过报表进行直观展现，以下摘录一些生成报表的SQL，可以据此了解一下Oracle AWR的内部展现机制。在使用awrrpt.sql生成报告时，会调用awrrpti.sql脚本，该脚本的主要部分为： select output from table(dbms_workload_repository. &fn_name( :dbid,:inst_num,:bid,:eid,:rpt_options )); 这里的fn_name是根据用户输入的选项来选择调用AWR_REPORT_HTML或AWR_REPORT_TEXT函数。 AWR_REPORT_HTML函数的内容如下，其主要内容是调用了另外一个过程DBMS_SWRF_REPORT_INTERNAL：
FUNCTION AWR_REPORT_HTML(L_DBID IN NUMBER,
L_INST_NUM IN NUMBER,
L_BID IN NUMBER,
L_EID IN NUMBER,
L_OPTIONS IN NUMBER DEFAULT 0)
RETURN AWRRPT_HTML_TYPE_TABLE PIPELINED
IS
I NUMBER;
ARR DBMS_SWRF_REPORT_INTERNAL.OUTPUT_TABLE;
BEGIN
ARR := DBMS_SWRF_REPORT_INTERNAL.AWR_REPORT_MAIN(L_DBID, L_INST_NUM, L_BID, L_EID,
L_OPTIONS, DBMS_SWRF_REPORT_INTERNAL.TRUE_I);
FOR I IN ARR.FIRST..ARR.LAST LOOP
PIPE ROW(AWRRPT_HTML_TYPE(SUBSTR(ARR(I), 1,
DBMS_SWRF_REPORT_INTERNAL.HTML_REPORT_LINESIZE)));
END LOOP;
DBMS_SWRF_REPORT_INTERNAL.REPORT_CLEANUP();
END AWR_REPORT_HTML; 这里的AWR_REPORT_MAIN是最重要的一个函数： FUNCTION AWR_REPORT_MAIN(L_DBID IN NUMBER,
L_INST_NUM IN NUMBER,
L_BID IN NUMBER,
L_EID IN NUMBER,
L_OPTIONS IN NUMBER DEFAULT OPT_NULL,
TO_HTML IN BINARY_INTEGER DEFAULT TRUE_I)
RETURN OUTPUT_TABLE;该函数的主要内容如下，：FUNCTION AWR_REPORT_MAIN(L_DBID IN NUMBER,
L_INST_NUM IN NUMBER,
L_BID IN NUMBER,
L_EID IN NUMBER,
L_OPTIONS IN NUMBER DEFAULT OPT_NULL,
TO_HTML IN BINARY_INTEGER DEFAULT TRUE_I)
RETURN OUTPUT_TABLE --返回一个输出表内容
IS
BEGIN
REPORT_CLEANUP();
CHECK_PARAMETERS(L_DBID,L_INST_NUM,L_BID,L_EID);
SET_THRESHOLD;
REPORT_INIT(L_DBID, L_INST_NUM, L_BID, L_EID, RPT_STATS, RPT_PARAMS, RPT_TIME_VALS); --报表初始化
IF (TO_HTML = TRUE_I) THEN
BEGIN_REPORT_TAGS('AWR Report');
END IF;
REPORT_SUMMARY(L_DBID, L_INST_NUM,
L_BID, L_EID, L_OPTIONS, TO_HTML, FALSE_I); --生成报表概要
DISPLAY_SUBTREES_OF(MAIN_REPT, TO_HTML, L_OPTIONS, L_DBID,
L_INST_NUM, L_BID, L_EID); --生成报表其他部分
DISPLAY_SUBTREES_OF(RAC_REPT, TO_HTML, L_OPTIONS, L_DBID,
L_INST_NUM, L_BID, L_EID); --生成报表的RAC部分信息
APPEND_ROW(END_REPORT);
IF (TO_HTML = TRUE_I) THEN
END_REPORT_TAGS();
END IF;
RETURN RPT_ROWS;
END AWR_REPORT_MAIN;接下来数据库就会在主要的过程中调用各种SQL生成报表的各部分内容，如以下就是展现等待事件的查询： SELECT EVENT, WAITS, TIME,
DECODE(WAITS, NULL, TO_NUMBER(NULL),
0, TO_NUMBER(NULL),
TIME/WAITS*1000) AVGWT,
PCTWTT, WAIT_CLASS
FROM (SELECT EVENT, WAITS, TIME, PCTWTT, WAIT_CLASS
FROM (SELECT E.EVENT_NAME EVENT,
E.TOTAL_WAITS - NVL(B.TOTAL_WAITS,0) WAITS,
(E.TIME_WAITED_MICRO -
NVL(B.TIME_WAITED_MICRO,0)) / 1000000 TIME,
100 * (E.TIME_WAITED_MICRO -
NVL(B.TIME_WAITED_MICRO,0)) /
RPT_STATS(STAT_DBTIME) PCTWTT,
E.WAIT_CLASS WAIT_CLASS
FROM DBA_HIST_SYSTEM_EVENT B,
DBA_HIST_SYSTEM_EVENT E
WHERE B.SNAP_ID(+) = L_BID
AND E.SNAP_ID = L_EID
AND B.DBID(+) = L_DBID
AND E.DBID = L_DBID
AND B.INSTANCE_NUMBER(+) = L_INST_NUM
AND E.INSTANCE_NUMBER = L_INST_NUM
AND B.EVENT_ID(+) = E.EVENT_ID
AND E.TOTAL_WAITS > NVL(B.TOTAL_WAITS,0)
AND E.WAIT_CLASS != 'Idle'
UNION ALL
SELECT 'CPU time' EVENT,
TO_NUMBER(NULL) WAITS,
RPT_STATS(STAT_CPU_TIME)/1000000 TIME,
100 * RPT_STATS(STAT_CPU_TIME) /
RPT_STATS(STAT_DBTIME) PCTWTT,
NULL WAIT_CLASS
FROM DUAL
WHERE RPT_STATS(STAT_CPU_TIME) > 0)
ORDER BY TIME DESC, WAITS DESC)
WHERE ROWNUM <= TOP_N_EVENTS;各类SQL不再过多介绍，了解了AWR的展现原理，我们就可以灵活的去分析各种AWR数据，获得更有价值的信息。 oracle 最后修改时间：2019-08-29 09:41:25 「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」 关注作者 赞赏 【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。 文章被以下合辑收录 AWR 知识体系（共25篇） 为了系统化的梳理 AWR 的知识体系，我们整理了一个系列文章，希望从原理、使用到 AWR 报告的解读，给读者展示全面的 AWR 知识体系， 收藏合辑 采集到收藏夹 评论 领墨值 有奖问卷 意见反馈 客服小墨
WHAT——什么是AWR？ - 知乎
WHAT——什么是AWR？ - 知乎切换模式写文章登录/注册WHAT——什么是AWR？无谓互联网将成为赖以生存的现实！现在我们稍微详细地了解一下刚才所说内容。1. ash占用的内存大小ASH的采集信息保存在内存中，在旧的信息被采样到AWR中后，可被新采集的信息覆盖，重启oracle后该信息被清除。分配给ASH的内存大小可以查询到：SQL> select pool, name, bytes/1024/1024 From v$sgastat where name like '%ASH %';POOL NAME BYTES/1024/1024------------- ------------- ---------------shared pool ASH buffers 22. AWR更正为了便于描述和理解，在第一部分中，我们说AWR就是保存ASH中的信息。其实，AWR记录的信息不仅是ASH，还可以收集到数据库运行的各方面统计信息和等待信息，用以诊断分析。AWR的采样方式是，以固定的时间间隔为其所有重要的统计信息和负载信息执行一次采样，并将采样信息保存在AWR中。可以这样说：ASH中的信息被保存到了AWR中的视图wrh$_active_session_history中。ASH是AWR的真子集。3. mmon进程与mmnl进程快照由一个称为 MMON 的新的后台进程（及其从进程）以及MMNL后台进程自动地每隔固定时间采样一次。我们先来看一下10g的概念指南中对这两个新增加的后台进程的介绍：* MMON进程负责执行多种和管理相关（manageability-related）的后台任务，例如： * 当某个测量值（metrics）超过了预设的限定值（threshold value）后提交警告 * 创建新的 MMON 隶属进程（MMON slave process）来进行快照（snapshot） * 捕获最近修改过的 SQL 对象的统计信息* MMNL进程负责执行轻量级的且频率较高的和可管理性相关的后台任务，例如捕获会话历史信息，测量值计算等。AWR的采样工作由MMON进程每个1小时执行一次，ASH信息同样会被采样写出到AWR负载库中。虽然ASH buffer被设计为保留1小时的信息，但很多时候这个内存是不够的，当ASH buffer写满后，另外一个后台进程MMNL将会主动将ASH信息写出。4. SYSAUX表空间这些采样数据都存储在SYSAUX表空间中，并且以WRM$_* 和 WRH$_*的格式命名。前一种类型存储元数据信息（如检查的数据库和采集的快照），后一种类型保存实际采集的统计数据。SQL> select table_name from dba_tables where table_name like 'WRM$%';TABLE_NAME-----------------------WRM$_WR_CONTROLWRM$_SNAP_ERRORWRM$_SNAPSHOTWRM$_DATABASE_INSTANCEWRM$_BASELINE当SYSAUX表空间满后，AWR将自动覆盖掉旧的信息，并在警告日志中记录一条相关信息：ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_3533490838_1522 by 128 in tablespace SYSAUX5. 采样频率和保留时间可以通过查询视图dba_hist_wr_control或（wrm$_wr_control）来查询AWR的采样频率和保留时间。默认为每1小时采样一次，采样信息保留时间为7天。SQL> select * from dba_hist_wr_control;DBID SNAP_INTERVAL RETENTION TOPNSQL---- ------------- ----------- ----------1148 +00000 00:1 +00007 00:0 DEFAULTSQL> select DBID, SNAP_INTERVAL, SNAPINT_NUM, RETENTION from wrm$_wr_control; DBID SNAP_INTERVAL SNAPINT_NUM RETENTION---------- ------------------ ----------- --------------------1160732652 +00000 01:00:00.0 3600 +00007 00:00:00.06. 采样数据量由于数据量巨大，把所有ASH数据写到磁盘上是不可接受的。一般是在写到磁盘的时候过滤这个数据，写出的数据占采样数据的10%，写出时通过direct-path insert完成，尽量减少日志生成，从而最小化数据库性能的影响。7. 初始化参数statistics_levelAWR的行为受到参数STATISTICS_LEVEL的影响。这个参数有三个值：* BASIC：awr统计的计算和衍生值关闭.只收集少量的数据库统计信息.* TYPICAL：默认值．只有部分的统计收集.他们代表需要的典型监控oracle数据库的行为.* ALL : 所有可能的统计都被捕捉. 并且有操作系统的一些信息.这个级别的捕捉应该在很少的情况下,比如你要更多的sql诊断信息的时候才使用.发布于 2019-07-22 14:59Oracle 数据库赞同添加评论分享喜欢收藏申请
且听AWR之父解读AWR报告 - 墨天轮
且听AWR之父解读AWR报告 - 墨天轮
排行 数据库百科 核心案例 行业报告 月度解读 大事记 产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
数说
活动
大会
学习 课程中心 推荐优质内容、热门课程学习路径 预设学习计划、达成学习目标知识图谱 综合了解技术体系知识点课程库 快速筛选、搜索相关课程视频学习 专业视频分享技术知识电子文档 快速搜索阅览技术文档文档
问答
工具 SQLRUN 在线数据库即时SQL运行平台数据库在线实训平台 实操环境、开箱即用、一键连接AWR分析 上传AWR报告，查看分析结果SQL格式化 快速格式化绝大多数SQL语句SQL审核 审核编写规范，提升执行效率PLSQL解密 解密超4000字符的PL/SQL语句OraC函数 查询Oracle C 函数的详细描述智能助手小墨 关于数据库相关的问题，您都可以问我 数据库百科核心案例行业报告月度解读大事记产业图谱我的订单
登录后可立即获得以下权益 免费培训课程 收藏优质文章 疑难问题解答 下载专业文档 签到免费抽奖 提升成长等级 立即登录 登录 注册 登录 注册 首页资讯数说活动大会课程文档排行问答我的订单 2 微信扫码 复制链接 新浪微博 分享数说 采集到收藏夹 分享到数说 首页 /
且听AWR之父解读AWR报告 且听AWR之父解读AWR报告 孙雪 2017-10-12 2027
AWR报告是数据库性能评估和优化的重要参考，将数据库的问题已量化的形式展现出来，给DBA带来了很多便利。然而AWR中的内容是非常多的，如何才能以最佳的方式解读AWR报告，最高效地找出数据库的性能问题所在呢？在刚刚过去的OOW2017大会上，AWR之父Graham 做了一个主题分享，名为“AWR Analysis for Admins, Developers and Architects” 运维、开发及架构师都应该一读的AWR报告分析。演讲ppt已在oow官网公开，接下来我们简单解读一下分享的主要内容。希望对大家有所帮助和借鉴。注：原ppt可以关注数据和云（OraNews）回复关键字2017oow 获取。以下是对该ppt的解读真实环境下，性能问题的根源有以下几种：1、数据库没有按照预期设计的目的被使用2、应用的架构或代码设计不佳3、数据库中存在一些不良的算法可能会引发问题对于大部分人来说，都会讲优化的目标集中在一些小细节上，比如某一条SQL的性能比较差，shared pool的某一组件设置不合理等等。对于这些细节的调整，一般会带来小幅度的性能提升，而大部分人则满足于此。RWP团队一直追求千倍以上极致的性能提升，对于他们来说，每一个性能问题，都应该找到根源，从最有效的角度解决问题，而不是满足于小幅度的性能提升。在他们的工作当中，一般性能优化会涉及到以下几个方面的处理：代码的改写，应用的逻辑修改，保证被正常地使用，bug的修复等。通过多个维度的调整和修改，最终实现系统性能千倍的提升。发现数据库性能问题的方法很多，而不只是简单地看wait event 和 top SQL。事实上，我们需要的很多数据都可以从AWR报告中获取，同时，我们也需要了解系统架构的设计方式、实现原理。在我们的经验中，很多性能问题都是架构设计不合理或者应用代码的逻辑问题导致的。接下来我们分享如何通过AWR的解读来定位问题，在AWR报告中应该关注哪些重要的信息，有效地利用报告中的数据，从而发挥AWR的真正价值。首先看AWR报告的头部。要关注的部分如图中黄色标记所示。首先我们看到系统中有4个socket，总共32核，CPUs显示为64，应该是开了超线程。session值很高，在采样时间内还不断增长。猜测：可能是会话泄露或者是连接风暴。知识点补充会话泄露：当应用程序断开连接而数据库中对应的会话还处于活动状态的时候，就会发生会话泄露。对于应用来说，就意味着程序的丢失。一般都是由于应用程序的异常导致的，在数据库中没有正常地执行commit或者rollback的时候失去了与数据库的联系。在session本身很高的时候，每个session中的cursor值也从8增加到了26。这说明会话中游标耗尽，猜测：可能存在游标泄露的问题。再看详细负载信息DBtime达到260，就意味着同一时间的活动会话数量达到260，DB CPUs大于系统CPU核数（32）。Logons 为10.5，每秒有10+的会话登录，这个值是非常高的，在正常情况下，一般系统可能在1左右。这说明系统存在异常，再次推测可能是会话泄露或连接风暴等原因，与前面的信息相符。60%的用户事务在做回滚。（图中写40%应该是误写，40%的事务是做提交）这也是不正常的。接下来我们来看数据库的一些参数的设置。我们看到数据库中块的大小是非默认块16k。同时将cursor_sharing设置为Force。知识点补充cursor_sharing 参数有 exact和Force两个选项，force 选项指的是优化器会将所有的文本值用系统生成的绑定变量替换，如果在使用绑定变量之后SQL语句一样的话，优化器就会使用同样的执行计划。在一般情况下不建议将参数设置为Force。这很可能会引发SQL注入的风险，对于SQL中的函数来说，在一些直接使用文本而非绑定变量更优的情况下，如果使用系统生成的绑定变量，可能会对执行计划产生负面的影响。因此系统一般建议设置为EXACT，只有在特殊情况下才设置为Force。详情请参考官网（http://docs.oracle.com/database/122/TGSQL/improving-rwp-cursor-sharing.htm#TGSQL-GUID-6C3AFFA0-21DD-41BC-8DEE-5FC9A58B0954）DB_file_multiblock_read_count 默认值对应于可以高效执行且与平台相关的最大I O大小 。此处与系统CPUs核数相等，说明IO没有问题。 open_cursors 参数指定一个会话一次最多可以打开的游标的数量，默认值为50.现在设置为2000，这是很高的，说明系统存在异常。而从db_recovery_file_dest参数的设置是哪个，我们看到存储类型为ASM，ASM是支持异步IO的，在支持异步IO 的情况下，open_cursor达到2000也是不正常的。DB_Writer_processes的默认值为1或者CPU_count/8,取较大者。此时设置为12，比默认值大，应该是手动调整过。前面的信息判断，系统应该是2个节点的RAC，processes推荐值为 50*2+50=150. 此时达到5500，而sessions默认值为processes*1.5+22=8272，图中的值应该也是手动调整过。 而调整的原因，推测是8272也不够用。这是很不正常的。接下来是等待事件的分析。看到系统大部分处于等待。以下是对于具体的top SQL的分析描述。因此，综合上述的信息，推测系统可能是出现会话泄露和游标泄露的问题。对于会话泄露，一般是由于应用的异常导致，不能直接通过数据库层面的分析得出结论也不能单纯从数据库的层面解决。以上，针对一份具体的AWR报告，我们看到哪些问题是最需要我们关注的，是能够帮助我们最有效地分析出系统的问题所在的。希望对大家有借鉴意义。资源下载关注本微信（OraNews）回复关键字获取2017OOW，Oracle OpenWorld最新资料；INTERNALS,Oracle RAC精品原版PPT;2017DTCC, 2017数据库大会PPT；DBALife,"DBA的一天"精品海报大图；122ARCH,Oracle 12cR2体系结构海报；DBA01，《Oracle DBA手记》第一本下载；YunHe，“云和恩墨大讲堂”案例文档下载；
oracle 文章转载自孙雪，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。 文章被以下合辑收录 AWR 知识体系（共25篇） 为了系统化的梳理 AWR 的知识体系，我们整理了一个系列文章，希望从原理、使用到 AWR 报告的解读，给读者展示全面的 AWR 知识体系， 收藏合辑 采集到收藏夹 评论 领墨值 有奖问卷 意见反馈 客服小墨
一文对比RF和微波仿真软件ADS vs. AWR - 知乎
一文对比RF和微波仿真软件ADS vs. AWR - 知乎切换模式写文章登录/注册一文对比RF和微波仿真软件ADS vs. AWR李叶背景介绍ADS：由Keysight Technologies（前身为Agilent Technologies）开发，适用于多个电路和系统设计领域，包括射频（RF）、微波、高速数字电路的信号完整性等。由于产品历史更长，目前ADS的应用更为广泛。AWR：由National Instruments（AWR现被Cadence从NI收购）开发，AWR设计工具专注于射频和微波电路设计（无论是芯片、电路板还是系统级）。Cadence收购AWR以后，首先将AWR的AXIEM紧密集成到Cadence Virtuoso平台。Cadence的传统是硅芯片设计，而AWR在与RF/微波设计有关的专门分析和模型，尤其是GaAs和GaN III-V半导体方面拥有更多的经验。功能对比在PCB 电路方面，Microwave Office能够解决的问题，与ADS是十分相似的，相似之处就是就是在电路原理仿真上设计放大器、混频器、震荡器 等单个器件，以及收发机、频率源等模块等。但二者在有些方面仍然有一些区 别，例如AWR软件相对ADS小很多，但功能一点也不少，而且用户界面更友好，更容易上手、效率更高。下面的表格是二者在功能上的比较。 序号比较项目ADSAWR1线性分析ADS提供广泛的线性分析工具，包括S参数、Y参数、Z参数分析等。能够准确预测线性电路的频率响应、传输和反射特性。ADS还支持多端口网络的分析，以及通过数据拟合等方式获得元件参数。AWR同样提供线性分析工具，如S参数、Y参数等。专注于射频和微波领域的应用，AWR的线性分析针对这些特定应用进行了优化。AWR在器件建模和传输线分析方面具有丰富的经验，支持特定的射频器件模型。2非线性分析ADS以其强大的非线性分析功能而闻名，支持多种非线性模型，如MOS、BJT、GaN等。它能够进行谐波平衡分析，以模拟非线性电路如混频器、振荡器和功率放大器。ADS的非线性分析可用于预测高功率工作状态下的电路性能。AWR同样支持非线性分析，主要专注于射频和微波电路的非线性仿真。针对高频电路的特定需求，AWR在非线性分析方面提供了专门的工具和模型，如功率放大器模型和谐波平衡仿真。3电磁仿真分析电磁仿真引擎：ADS内置了Momentum电磁仿真引擎，可以进行三维电磁场分析。它能够对微带线、传输线、微波元器件等进行高精度的电磁仿真。元器件建模：ADS支持元器件级别的电磁建模，例如微带线、耦合器、滤波器等。电磁-电路联合仿真：ADS具有电磁-电路联合仿真能力，允许工程师在电磁仿真的基础上进行电路仿真，以更好地分析整体系统性能。电磁仿真引擎：AWR使用了AXIEM电磁仿真引擎，也是一种强大的三维电磁场仿真工具。它可以分析微带线、传输线、高频器件等的电磁行为。射频器件模型：AWR提供丰富的射频器件模型，以便工程师可以在电磁仿真中准确建模射频器件的特性。布局优化：AWR强调布局优化，可以帮助工程师在电磁仿真的基础上优化布局，以最大程度地提高电路性能。4软件构架模块化设计：ADS采用了模块化的设计方法，将不同的功能分解为各种模块，例如线性仿真、非线性仿真、电磁仿真等。这种模块化的设计使得用户可以根据需要选择特定的功能，从而减少了不必要的复杂性。平行处理能力：ADS支持多核处理和分布式计算，能够在多个处理器上同时运行仿真任务，提高仿真效率。图形用户界面：ADS的界面较为直观，易于学习和使用。它提供了直观的工具栏、绘图工具和分析选项，使用户能够方便地进行设计、仿真和分析。集成设计环境：AWR提供了一个集成的设计环境，可以在同一个平台上进行电路设计、版图设计、电磁仿真等。这种集成性可以帮助用户更快速地从设计到仿真到制造。器件库和模型：AWR在设计环境中提供了丰富的器件库和模型，用户可以在设计中直接使用这些模型，从而减少了手动建模的工作。自动化流程：AWR强调自动化设计流程，通过设计向导和自动化脚本，用户可以更容易地进行各种分析和优化。电磁设计和仿真：AWR将电磁仿真作为其核心特点之一，提供了与电磁仿真引擎AXIEM的紧密集成，使得用户可以在同一个环境中进行电磁仿真和电路设计。5调谐优化与生产分析功能ADS提供了强大的参数扫描和优化工具，使工程师能够对设计参数进行范围扫描，寻找最佳性能的设计。ADS支持多种优化算法，如遗传算法、逐步优化等，可以根据设计需求选择合适的优化方法。AWR同样提供参数扫描和优化工具，允许工程师在设计空间中搜索最佳解决方案。AWR的优化功能可以在电路性能、电磁特性等方面进行优化，适用于射频和微波设计。6软件仿真速度ADS的仿真速度可能会受到复杂模型和分析方法的影响。在复杂的电路或系统级仿真中，仿真速度可能会有所降低。使用多核处理器和分布式计算，ADS可以提高仿真效率，加速仿真任务的完成。AWR的仿真速度可能受到电磁仿真引擎的复杂性影响。电磁场分析可能会较为耗时。AWR也支持多核处理和分布式计算，以提高仿真效率。7开放性开放性接口：ADS提供了多种开放性接口，例如Python脚本、MATLAB连接以及其自己的高级脚本语言。这使得用户可以编写脚本来自动化任务、自定义流程和与外部环境集成。自定义组件：ADS允许用户创建自定义的元器件模型、电路拓扑和脚本。这使得用户可以根据需要将自己的功能集成到ADS中。开放性接口：AWR同样提供Python脚本接口，用于自动化任务和与外部环境集成。此外，AWR也支持MATLAB连接，使得用户可以利用MATLAB的分析和处理能力。自定义组件：AWR允许用户创建自定义的射频器件模型、电路布局和脚本，以满足特定需求。8可用基本电路模 型数量213种367种9易用性图形用户界面（GUI）：ADS的界面通常被认为是直观和易于使用的。它提供了丰富的工具栏、选项面板和绘图工具，使得用户能够快速创建和编辑电路。自动化设计流程：ADS具有自动化设计流程的能力，用户可以通过向导式设计或批处理脚本来执行一系列操作。这有助于简化复杂任务的处理。教育和支持资源：Keysight提供了大量的教程、培训材料和社区支持，帮助用户学习和掌握软件的使用。一体化设计环境：AWR强调一体化的设计环境，使得用户可以在同一个平台上进行电路设计、仿真和版图设计。这有助于减少在不同工具之间切换的复杂性。自动化和向导：AWR提供了自动化的设计流程和向导，可以帮助用户更轻松地完成一系列任务，特别是在电磁仿真和电路布局方面。用户体验：AWR的用户界面被认为是相对简洁和用户友好的。它的工具栏和选项也使得用户可以快速访问常用功能。10射频预算分析模块化设计和优化：ADS的模块化设计使得用户可以将电路分解为各个模块，并在每个模块中进行预算分析。然后可以使用优化工具对每个模块的性能进行优化，以满足整体系统的规格和要求。直流至射频分析：ADS支持从直流到射频的多种分析技术，包括直流电路分析、频域分析、时域分析以及谐波平衡分析。这使得用户可以考虑信号在各个频段的传输和转换。射频器件库和模型：ADS拥有广泛的射频器件库和模型，可以用于建模传输线、滤波器、放大器等射频模块。一体化设计环境：AWR提供了一体化的设计环境，使得用户可以在同一个平台上进行电路设计、仿真和电磁仿真。这可以帮助用户更全面地进行射频预算分析。射频器件建模和仿真：AWR专注于射频和微波设计，提供了丰富的射频器件建模和仿真功能。用户可以使用这些工具来进行增益、损耗、噪声等方面的分析。电磁仿真和分析：由于AWR强调电磁仿真，因此用户可以在电磁分析中考虑传输线、耦合器等组件的电磁行为。11Layout不支持与电路图同步更新电路图与Layout同步更新12是否支持电路抽取技术否是13电路与系统协同仿真支持，速度较慢。支持，速度快。ADS不得不说的的两大缺点第一、相比AWR的版图设计也就是 Layout功能， ADS的Layout功能单一，且需要借助第三方的工具才能较好完成3D Layout，如下图：ADS的3D Layout效果图左下角为其平面Layout ，右下角为 ADS 最新收购XFDTD 软件代码后推出的EMDS 三维仿真软件内的建模。与AWR最大的不同是ADS的电路原理图Schematic与Layout处于不同的数据库，一旦Layout较为复杂，同步的时间就会非常长，而且很容易出错。而AWR本身的Layout以及电路原理图Schematic就是一个数据库，从根本上避免了这个问题。第二、ADS 2008的发布介绍中提到了，ADS 2008推出了新的2D多层透3视Layout和3D Layout的技术，注意观察其3D Layout，以及之前没有3D Layout的对比情况，如以下这两幅图：ADS 2008的2D与3D效果图对比要知道，类似这样的2D以及3D Layout，AWR早在 2000年发布的Microwave Office 版本中就推出了，比ADS领先了七八年。问题的关键在于，ADS的Layout信息很难反馈到电路原理图Schematic 中来。相比AWR操作的便利性，以及以测试量为驱动的直接的仿真设置， ADS则需要工程师设置一大堆参数才能进行仿真。如下图中ADS 2008提供的简便设置：ADS 2008的“简单”设置图示对比AWR的设置，才知道什么是“简单”：AWR的相同电路图的简单设置与效果造成差异的根本原因是AWR的软件构架是统一的，软件本身的数据链接是动态的，可以允许单纯的使用测试量来驱动仿真引擎，而ADS的软件构架是分立的，必须在电路原理图中就要对仿真求解器进行设置。换句话说，使用ADS的工程师必须对ADS所使用的各个仿真求解器都非常了解，才能很好的测试。通信系统仿真套件的对比AWR和ADS两种软件工具都有复杂包络、时域的、同步的、行为级的、数据驱动的仿真工具来针对不同的系统仿真。区别在于：第一、射频链路仿真的建模与控制： ADS的Ptolemy Simulation需要不同类型之间的模型的转换 – Timed to Complex– Complex to Timed– Complex to Rectangular– Complex to Timed IQ– Floating Point to Timed– … ADS 需要控制模块来控制仿真 – Data Flow下是在这两个软件中完成相同功能和测试量的射频系统模拟仿真： – Circuit Envelope– ….但AWR 的VSS不需要多重的转换模块或者控制模块来使得仿真运行。以下是在这两个软件中完成相同功能和测试量的射频系统模拟仿真：ADS 需要用户自己设置接收机的参数对比下图，一个 VSS的探针就可以解决这两个 Ptolemy测试控制模块解决的问题。同时，VSS 也不需要像 Ptolemy那样进行烦琐的数据类型转换。AWR 的VSS 设置快捷方便第二、射频链路仿真的测试设置：VSS 使用测试点和一个直观的用户界面来进行测量，例如，VSS 测量信道功率和ACPR 的方法，在diagram中加入VSA，打开ACPR 测量窗口，如下图：VSS 的ACPR 测量窗口可见VSS 的方法相当直观，即使过了一个月以后再打开diagram，也能够根据窗口中的说明很快进入状态。 而ADS Ptolemy Simulation必须使用表达式（等式）来进行测量： – acpr_x( )– cdf ( )– channel_power( )– …而ADS 的方法则要求多重接收器，需要一个节点来使得多种不同的测试量、许多的表达式来写入并创造变量。举例说明ADS 测量信道功率和ACPR 的方法： – 在diagram 中加入频谱分析仪 – 运行仿真 – 使用post processing expressions– channel_power ( )– Channel_power = channel_power_vr(voltage, resistance, mainCh, winType,winConst)– acpr_vr expression– ACPRvals = acpr_vr(voltage, resistance, mainCh, lowerAdjCh, upperAdjCh,winType, winConst)由于需要自定义vector 变量，因此进行测量的难度比较大。假如在一个月后再次打开diagram，用户毕竟也是人而不是机器人，很可能已经忘记了vector 的定义是什么。 第三、射频链路与电路的协同仿真Co-simulation： VSS 和Ptolemy 均可以进行和电路的协同仿真，VSS 基于统一数据库，调谐的速度非常快，仅需一步。把电路设计图拖到VSS 中，不需要控制或者转换模块，也不需要网表。AWR可直接将Microwave Office的电路设计图拖入VSS中而ADS Ptolemy ，本身是由伯克利大学的DSP 工程师研发的，在研发时并没有考虑与电路协同的仿真，所以后来用了与其他软件结合的方法来完成电路协同仿真，这就导致了调谐速度极慢且需要购买多种软件License 的问题， Ptolemy 的电路协同仿真解决方案流程如下图：ADS Ptolemy系统在仿真之前有很多需要预先设置的步骤第四、硬件在环测试所支持的硬件测试设备：通过 Test Wave 模块，VSS 可以与业界绝大多数设备相连接，如 Agilent、 HP、Rohde & Schwarz、Anritsu，但 ADS 目前只支持 Agilent 和 HP 的设备。AWR发展历史AWR 由 Hughes 的微波设计师 Joe Pekarek 于 1994 年创立，当时，他对市面上的 RF 设计软件感到非常失望。通过一项由 Hughes 赞助的博士计划，Joe 开发了一个早期版本，该版本最终成为 AWR 软件的一部分，也是其论文的一部分。之后，他与同事共同创立了 AWR。这家新公司及其旗舰产品 Microwave Office® 为业界带来了耳目一新的转变，提供了直观的用户界面、集成的原理图捕获/Layout功能，以及创新的设计辅助工具——实时调试功能。在持续增长的同时，公司于 2011 年被 National Instruments 收购，后者也一直致力于将业务专长扩展到 RF/无线领域。之后，National Instruments 和 Cadence 开始携手制定策略，专注于应对迅速发展的 5G 通信、物联网和航空航天行业带来的技术挑战。National Instruments 与 Cadence 紧密合作，于 2018 年将 AWR 的 AXIEM®软件集成到了 Cadence 的 Virtuoso® RF 环境中。现在AWR公司已经被Cadence从NI公司收购，属于Cadence系统级产品线中重要的RF和微波设计解决方案。AWR简介AWR 产品组合作为一个集成的界面在 AWR Design Environment 平台内运行，用于设计输入（原理图/layout）、分析（系统/电路/EM）、优化、良率分析和结果绘图。公司的旗舰产品 Microwave Office 是一款 RF 电路模拟器，用于开发前端组件，例如功率放大器、低噪声放大器、滤波器、混频器等。AXIEM 是矩量法 (method-of-moments ，即MoM) 3D 平面电磁分析工具，用于表征（S 参数）无源结构和 RF 互连。AXIEM 现已集成到 Microwave Office 和 Virtuoso RF软件 中。Visual System Simulator™ (VSS) 工具则使用基于行为模型的 RF 和 DSP 模块来支持通信/雷达系统级开发。VSS 支持许多系统分析（预算、ACPR 和 EVM、级联噪声、IP3、频谱）、组件规格/验证和架构设计。凭借符合标准的库和测试平台，VSS 可以用于测试 5G 信号激励的设备。还有其他一些更专业的工具，例如 AntSyn™，可用于天线综合和优化、5G/雷达库等。发布于 2023-09-07 15:35・IP 属地上海仿真仿真模拟赞同 1添加评论分享喜欢收藏申请
Oracle AWR性能分析报告深度解读 - 知乎
Oracle AWR性能分析报告深度解读 - 知乎首发于分布式系统切换模式写文章登录/注册Oracle AWR性能分析报告深度解读bluesky软件架构师，从事分布式数据库，云计算等方向研发转自：Oracle中的AWR，全称为Automatic Workload Repository，自动负载信息库。它收集关于特定数据库的操作统计信息和其他统计信息，Oracle以固定的时间间隔(默认为1个小时)为其所有重要的统计信息和负载信息执行一次快照，并将快照存放入AWR中。这些信息在AWR中保留指定的时间(默认为1周)，然后执行删除。执行快照的频率和保持时间都是可以自定义的。AWR的引入，为我们分析数据库提供了非常好的便利条件(这方面MySQL就相差了太多)。曾经有这样的一个比喻——“一个系统，就像是一个黑暗的大房间，系统收集的统计信息，就如同放置在房间不同位置的蜡烛，用于照亮这个黑暗大房间。Oracle，恰到好处地放置了足够的蜡烛(AWR)，房间中只有极少的烛光未覆盖之处，性能瓶颈就容易定位。而对于蜡烛较少或是没有蜡烛的系统，性能优化就如同黑暗中的舞者。”那如何解读AWR的数据呢？Oracle本身提供了一些报告，方便进行查看、分析。下面就针对最为常见的一种报告——《AWR数据库报告》进行说明。希望通过这篇文章，能方便大家更好地利用AWR，方便进行分析工作。一、MAIN1Database Information2Snapshot Information(1)Sessions表示采集实例连接的会话数。这个数可以帮助我们了解数据库的并发用户数大概的情况。这个数值对于我们判断数据库的类型有帮助。(2)Cursors/session每个会话平均打开的游标数。(3)Elapsed通过Elapsed/DB Time比较，反映出数据库的繁忙程度。如果DB Time>>Elapsed，则说明数据库很忙。(4)DB Time表示用户操作花费的时间，包括CPU时间和等待事件。通常同时这个数值判读数据库的负载情况。具体含义db time = cpu time + wait time(不包含空闲等待)(非后台进程)*db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间。对应于V$SESSION的elapsed_time字段累积。"合集数据"需要注意的是AWR是一个数据合集。比如在1分钟之内，1个用户等待了30秒钟，那么10个用户等待事件就是300秒。CPU时间也是一样，在1分钟之内，1个CPU处理30秒钟，那么4个CPU就是120秒。这些时间都是以累积的方式记录在AWR当中的。示例DB CPU——这是一个用于衡量CPU的使用率的重要指标。假设系统有N个CPU，那么如果CPU全忙的话，一秒钟内的DB CPU就是N秒。除了利用CPU进行计算外，数据库还会利用其它计算资源，如网络、硬盘、内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有M个session在运行，同一时刻有的session可能在利用CPU，有的session可能在访问硬盘，那么在一秒钟内，所有session的时间加起来就可以表征系统在这一秒内的繁忙程度。一般的，这个和的最大值应该为M。这其实就是Oracle提供的另一个重要指标:DB time，它用以衡量前端进程所消耗的总时间。对除CPU以后的计算资源的访问，Oracle用等待事件进行描述。同样地，和CPU可分为前台消耗CPU和后台消耗CPU一样，等待事件也可以分为前台等待事件和后台等待事件。DB Time一般的应该等于"DB CPU + 前台等待事件所消耗时间"的总和。等待时间通过v$system_event视图进行统计，DB Time和DB CPU则是通过同一个视图，即v$sys_time_model进行统计。--"Load Profile"中关于DB Time的描述*这个系统的CPU个数是8，因此我们可以知道前台进程用了系统CPU的7.1/8=88.75%。DB Time/s为11.7，可以看出这个系统是CPU非常繁忙的。里面CPU占了7.1，则其它前台等待事件占了11.7 – 7.1 = 4.6 Wait Time/s。DB Time 占 DB CPU的比重: 7.1/11.7= 60.68%--"Top 5 Timed Events"中关于DB CPU的描述按照CPU/等待事件占DB Time的比例大小，这里列出了Top 5。如果一个工作负载是CPU繁忙型的话，那么在这里应该可以看到 DB CPU的影子。*注意到，我们刚刚已经算出了DB CPU 的%DB time，60%。其它的external table read、direct path write、PX Deq: read credit、PX Deq: Slave Session Stats这些就是占比重40的等待事件里的Top 4了。--"Top 5 Timed Foreground Events"的局限性再研究下这个Top 5 Timed Foreground Events，如果先不看Load Profile，是不能计算出一个CPU-Bound的工作负载。要知道系统CPU的繁忙程序，还要知道这个AWR所基于两个snapshot的时间间隔，还要知道系统CPU的个数。要不系统可以是一个很IDLE的系统呢。记住CPU利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。这个Top 5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用insert append的方式写入磁盘，同时，主要时间耗费在CPU的运算上。--解读"DB Time" > "DB CPU" + "前台等待事件所消耗时间" ——进程排队时间上面提到，DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计：DB CPU = 6474.65DB TIME = 10711.2FG Wait Time = 1182.63明显的，DB CPU + FG Wait Time < DB Time，只占了71.5%*其它的28.5%被消耗到哪里去了呢?这里其实又隐含着一个Oracle如何计算DB CPU和DB Time的问题。当CPU很忙时，如果系统里存在着很多进程，就会发生进程排队等待CPU的现象。在这样，DB TIME是把进程排队等待CPU的时间算在内的，而DB CPU是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time的一个重要原因。如果一个系统CPU不忙，这这两者应该就比较接近了。不要忘了在这个例子中，这是一个CPU非常繁忙的系统，而71.5%就是一个信号，它提示着这个系统可能是一个CPU-Bound的系统。二、Report Summary1Cache Sizes这部分列出AWR在性能采集开始和结束的时候，数据缓冲池(buffer cache)和共享池(shared pool)的大小。通过对比前后的变化，可以了解系统内存消耗的变化。2Load Profile这两部分是数据库资源负载的一个明细列表，分隔成每秒钟的资源负载和每个事务的资源负载。Redo size每秒(每个事务)产生的日志大小(单位字节)Logical reads每秒(每个事务)产生的逻辑读(单位是block)。在很多系统里select执行次数要远远大于transaction次数。这种情况下，可以参考Logical reads/Executes。在良好的oltp环境下，这个应该不会超过50，一般只有10左右。如果这个值很大，说明有些语句需要优化。Block Changes每秒(每个事务)改变的数据块数。Physical reads每秒(每个事务)产生的物理读(单位是block)。一般物理读都会伴随逻辑读，除非直接读取这种方式，不经过cache。Physical writes 每秒(每个事务)产生的物理写(单位是block)。User calls每秒(每个事务)用户调用次数。User calls/Executes基本上代表了每个语句的请求次数，Executes越接近User calls越好。Parses每秒(每个事务)产生的解析(或分析)的次数，包括软解析和硬解析，但是不包括快速软解析。软解析每秒超过300次意味着你的"应用程序"效率不高，没有使用soft soft parse，调整session_cursor_cache。Hard parses每秒(每个事务)产生的硬解析次数。每秒超过100次，就可能说明你绑定使用的不好。Sorts每秒(每个事务)排序次数。Logons每秒(每个事务)登录数据库次数。Executes每秒(每个事务)SQL语句执行次数。包括了用户执行的SQL语句与系统执行的SQL语句，表示一个系统SQL语句的繁忙程度。Transactions每秒的事务数。表示一个系统的事务繁忙程度。目前已知的最繁忙的系统为淘宝的在线交易系统，这个值达到了1000。% Blocks changed per Read表示逻辑读用于只读而不是修改的块的比例。如果有很多PLSQL，那么就会比较高。Rollback per transaction %看回滚率是不是很高，因为回滚很耗资源。Recursive Call %递归调用SQL的比例，在PL/SQL上执行的SQL称为递归的SQL。3Instance Efficiency Percentages (Target 100%)这个部分是内存效率的统计信息。对于OLTP系统而言，这些值都应该尽可能地接近100%。对于OLAP系统而言，意义不太大。因为在OLAP系统中，大查询的速度才是对性能影响的最大因素。Buffer Nowait %非等待方式获取数据块的百分比。这个值偏小，说明发生SQL访问数据块时数据块正在被别的会话读入内存，需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。Buffer Nowait<99%说明，有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。Redo NoWait %非等待方式获取redo数据百分比。Buffer Hit %数据缓冲命中率，表示了数据块在数据缓冲区中的命中率。Buffer Hit<95%，可能是要加db_cache_size，但是大量的非选择的索引也会造成该值很高(大量的db file sequential read)。In-memory Sort %数据块在内存中排序的百分比。总排序中包括内存排序和磁盘排序。当内存中排序空间不足时，使用临时表空间进行排序，这个是内存排序对总排序的百分比。过低说明有大量排序在临时表空间进行。在oltp环境下，最好是100%。如果太小，可以调整PGA参数。Library Hit %共享池中SQL解析的命中率。Library Hit<95%，要考虑加大共享池，绑定变量，修改cursor_sharing等。Soft Parse %软解析占总解析数的百分比。可以近似当作sql在共享区的命中率。这个数值偏低，说明系统中有些SQL没有重用，最优可能的原因就是没有使用绑定变量。<95%：需要考虑到绑定<80%：那么就可能sql基本没有被重用Execute to Parse %执行次数对分析次数的百分比。如果该值偏小，说明解析(硬解析和软解析)的比例过大，快速软解析比例小。根据实际情况，可以适当调整参数session_cursor_cache，以提高会话中sql执行的命中率。round(100*(1-:prse/:exe),2) 即(Execute次数 - Parse次数)/Execute次数 x 100%prse = select value from v$sysstat where name = 'parse count (total)';exe = select value from v$sysstat where name = 'execute count';没绑定的话导致不能重用也是一个原因，当然sharedpool太小也有可能，单纯的加session_cached_cursors也不是根治的办法，不同的sql还是不能重用，还要解析。即使是soft parse 也会被统计入 parse count,所以这个指标并不能反应出fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析) 几种解析的比例。只有在pl/sql的类似循环这种程序中使用使用变量才能避免大量parse，所以这个指标跟是否使用bind并没有必然联系增加session_cached_cursors 是为了在大量parse的情况下把soft转化为fast soft而节约资源。Latch Hit %latch的命中率。其值低是因为shared_pool_size过大或没有使用绑定变量导致硬解析过多。要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。Parse CPU to Parse Elapsd %解析总时间中消耗CPU的时间百分比。即:100*(parse time cpu / parse time elapsed)解析实际运行事件/(解析实际运行时间+解析中等待资源时间)，越高越好。% Non-Parse CPUCPU非分析时间在整个CPU时间的百分比。100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd %查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。4Shared Pool StatisticsMemory Usage %共享池内存使用率。应该稳定在70%-90%间，太小浪费内存，太大则内存不足。% SQL with executions>1执行次数大于1的SQL比率。若太小可能是没有使用绑定变量。% Memory for SQL w/exec>1执行次数大于1的SQL消耗内存/所有SQL消耗的内存(即memory for sql with execution > 1)。5Top 5 Timed Events三、RAC Statistics这一部分只在有RAC环境下才会出现，是一些全局内存中数据发送、接收方面的性能指标，还有一些全局锁的信息。除非这个数据库在运行正常是设定了一个基线作为参照，否则很难从这部分数据中直接看出性能问题。经验Oracle公司经验，下面GCS和GES各项指标中，凡是与时间相关的指标，只要GCS指标低于10ms，GES指标低于15ms，则一般表示节点间通讯效率正常。但是，即便时间指标正常，也不表示应用本身或应用在RAC部署中没有问题。1Global Cache Load Profile2Global Cache Efficiency Percentages (Target local+remote 100%)3Global Cache and Enqueue Services - Workload Characteristics4Global Cache and Enqueue Services - Messaging Statistics5Global Cache Transfer Stats*如果CR的%Busy很大，说明节点间存在大量的块争用。四、Wait Events Statistics1Time Model Statistics这部分信息列出了各种操作占用的数据库时间比例。parse time elapsed/hard parse elapsed time通过这两个指标的对比，可以看出硬解析占整个的比例。如果很高，就说明存在大量硬解析。% Not-Parse CPU花费在非解析上CPU消耗占整个CPU消耗的比例。反之，则可以看出解析占用情况。如果很高，也可以反映出解析过多(进一步可以看看是否是硬解析过多)。示例 - 计算CPU消耗Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds再除以总的 BUSY_TIME + IDLE_TIME% Total CPU = 1341.8/1941.76 = 69.1%，这刚好与上面Report的值相吻合。其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。这里 5.3/8 = 66.25 %比69.1%稍小，说明DB在后台也消耗了大约3%的CPU。2Wait Class这一部分是等待的类型。可以看出那类等待占用的时间最长。3Wait Events这一部分是整个实例等待事件的明细，它包含了TOP 5等待事件的信息。%Time-outs: 超时百分比（超时依据不太清楚?）4Background Wait Events这一部分是实例后台进程的等待事件。如果我们怀疑那个后台进程(比如DBWR)无法及时响应，可以在这里确认一下是否有后台进程等待时间过长的事件存在。5Operating System Statistics(1)背景知识如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。而细分起来，CPU可能指的是：OS级的User%, Sys%, Idle%DB所占OS CPU资源的Busy%DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU(2)11g如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然：OS级的%User为75.4，%Sys为2.8，%Idle为21.2，所以%Busy应该是78.8。DB占了OS CPU资源的69.1，%Busy CPU则可以通过上面的数据得到:%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和报告的87.7相吻合。(3)10g如果是10g，则需要手工对Report里的一些数据进行计算了。Host CPU的结果来源于DBA_HIST_OSSTAT，AWR报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是厘秒-也就是1/100秒)。解读输出%User = USER_TIME/(BUSY_TIME+IDLE_TIME)*100 = 146355/(152946+41230)*100 = 75.37%Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100ELAPSED_TIME这里已经隐含着这个AWR报告所捕捉的两个snapshot之间的时间长短了。有下面的公式。正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT推算出：ELAPSED_TIME = (152946+41230)/8/100 = 242.72 seconds //这是正确的。时间统计视图v$sys_time_model至于DB对CPU的利用情况，这就涉及到10g新引入的一个关于时间统计的视图 - v$sys_time_model。简单而言，Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括：1) background elapsed time 2) background cpu time 3) RMAN cpu time (backup/restore)1) DB time 2) DB CPU 2) connection management call elapsed time 2) sequence load elapsed time 2) sql execute elapsed time 2) parse time elapsed 3) hard parse elapsed time 4) hard parse (sharing criteria) elapsed time 5) hard parse (bind mismatch) elapsed time 3) failed parse elapsed time 4) failed parse (out of shared memory) elapsed time 2) PL/SQL execution elapsed time 2) inbound PL/SQL rpc elapsed time 2) PL/SQL compilation elapsed time 2) Java execution elapsed time 2) repeated bind elapsed time我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。这两个值在AWR里面也有记录。五、SQL Statistics1SQL ordered by Elapsed Time这一部分是按照SQL执行时间从长到短的排序。Elapsed Time(S)SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait TimeCPU Time(s)为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。ExecutionsSQL语句在监控范围内的执行次数总计。如果Executions=0，则说明语句没有正常完成，被中间停止，需要关注。Elap per Exec(s)执行一次SQL的平均时间。单位时间为秒。% Total DB Time为SQL的Elapsed Time时间占数据库总时间的百分比。SQL IDSQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。SQL Module显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。SQL Text简单的SQL提示，详细的需要点击SQL ID。分析说明如果看到SQL语句执行时间很长，而CPU时间很少，则说明SQL在I/O操作时(包括逻辑I/O和物理I/O)消耗较多。可以结合前面I/O方面的报告以及相关等待事件，进一步分析是否是I/O存在问题。当然SQL的等待时间主要发生在I/O操作方面，不能说明系统就存在I/O瓶颈，只能说SQL有大量的I/O操作。如果SQL语句执行次数很多，需要关注一些对应表的记录变化。如果变化不大，需要从前面考虑是否大多数操作都进行了Rollback，导致大量的无用功。2SQL ordered by CPU Time记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。这部分是SQL消耗的CPU时间从高到底的排序。CPU Time (s)SQL消耗的CPU时间。Elapsed Time (s)SQL执行时间。ExecutionsSQL执行次数。CPU per Exec (s)每次执行消耗CPU时间。% Total DB TimeSQL执行时间占总共DB time的百分比。3SQL ordered by Gets这部分列出SQL获取的内存数据块的数量，按照由大到小的顺序排序。buffer get其实就是逻辑读或一致性读。在sql 10046里面，也叫query read。表示一个语句在执行期间的逻辑IO，单位是块。在报告中，该数值是一个累计值。Buffer Get=执行次数 * 每次的buffer get。记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。Buffer GetsSQL执行获得的内存数据块数量。ExecutionsSQL执行次数。Gets per Exec每次执行获得的内存数据块数量。%Total占总数的百分比。CPU Time (s)消耗的CPU时间。Elapsed Time (s)SQL执行时间。筛选SQL的标准因为statspack/awr列出的是总体的top buffer，它们关心的是总体的性能指标，而不是把重心放在只执行一次的语句上。为了防止过大，采用了以下原则。如果有sql没有使用绑定变量，执行非常差但是由于没有绑定，因此系统人为是不同的sql。有可能不会被列入到这个列表中。大于阀值buffer_gets_th的数值，这是sql执行缓冲区获取的数量(默认10000)。小于define top_n_sql=65的数值。4SQL ordered by Reads这部分列出了SQL执行物理读的信息，按照从高到低的顺序排序。记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。Physical ReadsSQL物理读的次数。ExecutionsSQL执行次数。Reads per ExecSQL每次执行产生的物理读。%Total占整个物理读的百分比。CPU Time (s)SQL执行消耗的CPU时间。Elapsed Time (s)SQL的执行时间。5SQL ordered by Executions这部分列出了SQL执行次数的信息，按照从大到小的顺序排列。如果是OLTP系统的话，这部分比较有用。因此SQL执行频率非常大，SQL的执行次数会对性能有比较大的影响。OLAP系统因为SQL重复执行的频率很低，因此意义不大。ExecutionsSQL的执行次数。Rows ProcessedSQL处理的记录数。Rows per ExecSQL每次执行处理的记录数。CPU per Exec (s)每次执行消耗的CPU时间。Elap per Exec (s)每次执行的时长。6SQL ordered by Parse Calls这部分列出了SQL按分析次(软解析)数的信息，按照从高到底的顺序排列。这部分对OLTP系统比较重要，这里列出的总分析次数并没有区分是硬分析还是软分析。但是即使是软分析，次数多了，也是需要关注的。这样会消耗很多内存资源，引起latch的等待，降低系统的性能。软分析过多需要检查应用上是否有频繁的游标打开、关闭操作。Parse CallsSQL分析的次数。ExecutionsSQL执行的次数。% Total Parses占整个分析次数的百分比。7SQL ordered by Sharable Memory记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)占用library cache的大小。单位是byte。8SQL ordered by Version Count这部分列出了SQL多版本的信息。记录了SQL的打开子游标的TOP SQL。一个SQL产生多版本的原因有很多，可以查询视图v$sql_sahred_cursor视图了解具体原因。对于OLTP系统，这部分值得关注，了解SQL被重用的情况。Version CountSQL的版本数。ExecutionsSQL的执行次数。9SQL ordered by Cluster Wait Time记录了集群的等待时间的TOP SQL。这部分只在RAC环境中存在，列出了实例之间共享内存数据时发生的等待。在RAC环境下，几个实例之间需要有一种锁的机制来保证数据块版本的一致性，这就出现了一类新的等待事件，发生在RAC实例之间的数据访问等待。对于RAC结构，还是采用业务分隔方式较好。这样某个业务固定使用某个实例，它访问的内存块就会固定地存在某个实例的内存中，这样降低了实例之间的GC等待事件。此外，如果RAC结构采用负载均衡模式，这样每个实例都会被各种应用的会话连接，大量的数据块需要在各个实例的内存中被拷贝和锁定，会加剧GC等待事件。Cluster Wait Time (s)集群等待时长。CWT % of Elapsd Time集群操作等待时长占总时长的百分比。Elapsed Time(s)SQL执行总时长。10Complete List of SQL Text这部分是上面各部分涉及的SQL的完整文本。六、Instance Activity Statistics1Instance Activity Stats这部分是实例的信息统计，项目非常多。对于RAC架构的数据库，需要分析每个实例的AWR报告，才能对整体性能做出客观的评价。CPU used by this session这个指标用来上面在当前的性能采集区间里面，Oracle消耗的CPU单位。一个CPU单位是1/100秒。从这个指标可以看出CPU的负载情况。案例 - 分析系统CPU繁忙程度在TOP5等待事件里，找到"CPU time"，可以看到系统消耗CPU的时间为26469秒。在实例统计部分，可以看到整个过程消耗了1813626个CPU单位。每秒钟消耗21个CPU单位，对应实际的时间就是0.21秒。也就是每秒钟CPU的处理时间为0.21秒。系统内CPU个数为8。每秒钟每个CPU消耗是21/8=2.6(个CPU单位)。在一秒钟内，每个CPU处理时间就是2.6/100=0.026秒。*总体来看，当前数据库每秒钟每个CPU处理时间才0.026秒，远远算不上高负荷。数据库CPU资源很丰富，远没有出现瓶颈。七、IO Stats1Tablespace IO Stats表空间的I/O性能统计。Reads发生了多少次物理读。Av Reads/s每秒钟物理读的次数。Av Rd(ms)平均一次物理读的时间(毫秒)。一个高相应的磁盘的响应时间应当在10ms以内，最好不要超过20ms；如果达到了100ms，应用基本就开始出现严重问题甚至不能正常运行。Av Blks/Rd每次读多少个数据块。Writes发生了多少次写。Av Writes/s每秒钟写的次数。 Buffer Waits获取内存数据块等待的次数。Av Buf Wt(ms)获取内存数据块平均等待时间。2File IO Stats文件级别的I/O统计。八、Advisory Statistics顾问信息。这块提供了多种顾问程序，提出在不同情况下的模拟情况。包括databuffer、pga、shared pool、sga、stream pool、java pool等的情况。1Buffer Pool AdvisoryBuffer pool的大小建议。Size for Est (M)Oracle估算Buffer pool的大小。Size Factor估算值与实际值的比例。如果0.9就表示估算值是实际值的0.9倍。1.0表示buffer pool的实际大小。Buffers for Estimate估算的Buffer的大小(数量)。Est Phys Read Factor估算的物理读的影响因子，是估算物理读和实际物理读的一个比例。1.0表示实际的物理读。Estimated Physical Reads估计的物理读次数。2PGA Memory AdvisoryPGA的大小建议。PGA Target Est (MB)PGA的估算大小。Size Factr影响因子，作用和buffer pool advisory中相同。W/A MB ProcessedOracle为了产生影响估算处理的数据量。Estd Extra W/A MB Read/ Written to Disk处理数据中需要物理读写的数据量。Estd PGA Cache Hit %估算的PGA命中率。Estd PGA Overalloc Count需要在估算的PGA大小下额外分配内存的个数。3Shared Pool Advisory建议器通过设置不同的共享池大小，来获取相应的性能指标值。Shared Pool Size(M)估算的共享池大小。SP Size Factr共享池大小的影响因子。Est LC Size (M)估算的库高速缓存占用的大小。Est LC Mem Obj高速缓存中的对象数。Est LC Time Saved (s)需要额外将对象读入共享池的时间。Est LC Time Saved Factr对象读入共享池时间的影响因子。表示每一个模拟的shared pool大小对重新将对象读入共享池的影响情况。当这个值的变化很小或不变的时候，增加shared pool的大小就意义不大。Est LC Load Time (s)分析所花费的时间。Est LC Load Time Factr分析花费时间的影响因子。Est LC Mem Obj Hits内存中对象被发现的次数。4SGA Target Advisory建议器对SGA整体的性能的一个建议。SGA Target Size (M)估算的SGA大小。SGA Size FactorSGA大小的影响因子。Est DB Time (s)估算的SGA大小计算出的DB Time。Est Physical Reads物理读的次数。九、Latch Statistics1Latch ActivityGet Requests/Pct Get Miss/Avg Slps /Miss表示愿意等待类型的latch的统计信息。NoWait Requests/Pct NoWait Miss表示不愿意等待类型的latch的统计信息。Pct Misses比例最好接近0。十、Segment Statistics1Segments by Logical Reads段的逻辑读情况。2Segments by Physical Reads段的物理读情况。3Segments by Buffer Busy Waits从这部分可以发现那些对象访问频繁。Buffer Busy Waits事件通常由于某些数据块太过频繁的访问，导致热点块的产生。4Segments by Row Lock WaitsAWR报告Segment Statistics部分的Segments by Row Lock Waits，非常容易引起误解，它包含的不仅仅是事务的行级锁等待，还包括了索引分裂的等待。之前我一直抱怨为什么v$segment_statistics中没有统计段级别的索引分裂计数，原来ORACLE已经实现了。但是统计进这个指标中，你觉得合适吗？十一、其他问题SQL运行周期对报告的影响对SQL语句来讲，只有当它执行完毕之后，它的相关信息才会被Oracle所记录(比如：CPU时间、SQL执行时长等)。当时当某个SQL终止于做AWR报告选取的2个快照间隔时间之后，那么它的信息就不能被这个AWR报告反映出来。尽管它在采样周期里面的运行，也消耗了很多资源。也就是说某个区间的性能报告并不能精确地反映出在这个采样周期中资源的消耗情况。因为有些在这个区间运行的SQL可能结束于这个时间周期之后，也可能有一些SQL在这个周期开始之前就已经运行了很久，恰好结束于这个采样周期。这些因素都导致了采样周期里面的数据并不绝对是这个时间段发生的所有数据库操作的资源使用的数据。发布于 2021-04-01 14:51数据库MySQL甲骨文 (Oracle)赞同 252 条评论分享喜欢收藏申请转载文章被以下专栏收录分布式系统分布式数据库、分布式存储、分布式架构、
AWR基本介绍 20220306 - 知乎
AWR基本介绍 20220306 - 知乎切换模式写文章登录/注册AWR基本介绍 20220306野生动物ZALE90产品AWR的射频/微波设计产品套件包含系统仿真工具(Visual System Simulator™), 电路仿真工具(Microwave Office® 和 Analog Office®)和电磁分析工具(AXIEM® 和 Analyst™)。为了扩展这些设计环境的功能，AWR向射频/微波设计者提供了AWR Connected™ 等更完整、更有效率的解决方案。Visual System SimulatorMicrowave Office(AXIEM Analyst公司介绍Advancing the wireless revolutionAWR公司是全球射频/微波电子设计自动化(EDA)工具的领先供应商与行业领跑者，其EDA产品广泛用于手机，卫星通信系统和其他无线通信电子产品的设计与仿真。应用AWR产品进行设计，工程师可以快速开发出高技术含量，稳定可靠的新产品，大幅提高设计效率，降低成本。AWR的总部位于美国加州，在全球各地均设有研发、销售、培训中心和经销渠道。AWR在亚太区的上海、东京、首尔成立了直接进行销售和技术支持的办公室。全球超过700家公司应用AWR的产品，几乎涵盖了全部的射频/微波电子器件和系统的生产商。AWR公司软件主要为射频集成电路（RFIC）,多芯片组件（MCM），含有高频无线电路及系统的印刷电路板(PCB)及光电市场所应用。AWR公司提供了一套完整的EDA软件解决方案，真正简化了产品的概念，仿真到生产的整个流程。AWR公司也就产品，库的建立和设计方法提供咨询服务。AWR公司不断对产品进行优化与创新，其具有革命性、前瞻性的产品架构和开放式软件平台，也充分展现了公司在射频、微波和毫米波设计应用领域的专业技术与多年的经验积累，它将电子设计自动化的效率提高到一个前所未有的高度，奠定了它在EDA软件市场上的领先位置。Cadence收购AWR(射频仿真软件Microwave Office)加速5G创新 加利福尼亚州圣何塞，2019年12月3日——楷登电子（美国Cadence公司，Nasdaq：CDNS）与National Instruments Corporation（美国国家仪器公司，Nasdaq：NATI）今日共同宣布，就Cadence意向收购AWR Corporation达成最终协议。AWR Corporation是National Instruments（NI，美国国家仪器公司）的全资子公司。AWR是高频RF EDA软件技术的领先供应商，其专业的射频人才团队也将在收购完成后加入Cadence。同时，Cadence与NI达成战略合作协议，深化合作，推动通信领域的电子系统创新。AWR软件可以助力微波和射频工程师为复杂的高频RF应用设计无线产品。该技术适用于通信、航天和国防、半导体、计算机及消费电子领域，可帮助客户加速系统设计和产品开发周期，大大缩短从概念到生产的时间。“客户在设计高速增长的5G/无线应用的通信和雷达芯片、模组及系统时，面临越来越大的产品上市周期压力。打造差异化产品的同时缩短设计周期，需要设计、仿真和分析环境的无缝集成，” Cadence公司总裁 Anirudh Devgan博士表示。“AWR的人才和技术将帮助Cadence开发更优化和更紧密集成的RF设计解决方案，从而加速系统创新，继续推动我们公司“智能系统设计”战略的执行。”传统的RF/微波设计流程极易出错，造成生产力下降和性能损失，是设计师面临的巨大挑战。AWR® 设计环境将与Cadence® Allegro® PCB 设计工具和业界领先的Virtuoso® 及 Spectre® 平台无缝集成，从而帮助客户实现RF集成电路（IC）的卓越设计。通常，电磁和热分析工具的设置和使用非常困难，给设计师带来了很多挑战。为了解决这一问题，Cadence也同时集成了包括Clarity™ 3D 解算器，Celsius™ 热解算器和Sigrity™ PowerSI® 技术在内的Cadence系统分析工具。“RF/微波/毫米波应用需要业界领先的解决方案，才能实现设计首次通过，确保最优设计性能，”AWR公司总经理 Joseph E.pekarek表示。“加入Cadence后，我们将充分发挥Virtuoso和Allegro两大设计工具平台的核心优势，与AWR设计环境平台无缝集成，为复杂IC、封装和电路板交付最完整的解决方案。”AWR技术与Cadence计算软件集成后的工作流程将与NI LabVIEW和PXI等模块化仪器系统及半导体数据平台紧密结合，构成全新的战略联盟合作。如需了解更多Cadence和NI战略联盟的相关内容，请访 ni.com/nati/news。按照最终协议条款规定，Cadence将在收购交割时支付约1.6亿美元，约110名AWR员工将加入Cadence。本次收购预计在2020年第一季度完成，且应满足包括监管机构批准在内的其它通例成交前提。20220306发布于 2022-03-06 21:25实时计算软件过程改进数据处理软件赞同 1添加评论分享喜欢收藏申请
软件介绍 - AWR中文网站 - 微波射频网
- AWR中文网站 - 微波射频网 微波射频网 资讯 专题 技术文库 视频课堂 下载 电子商务 招聘 活动 图书 博客 社区 百科 工具 周刊 进入AWR官方网站AWR中国区：021-50509800 首页 新闻与活动 产品与应用 技术资源 视频教程 社区交流 联系及注册试用 关于AWR更多 AWR公司是全球射频/微波电子设计自动化(EDA)工具的领先供应商与行业领跑者。通常被用于设计移动电话, 智能手机, 基站收发器, 卫星通信系统和国防系统中的电子战和雷达通信防御系统中至关重要的射频与微波器件的设计。 工程师也常用AWR软件设计具有WiFi和蓝牙功能的等其他上百种应用无线技术的产品。AWR的总部位于美国加州... 查看更多>> 分类目录 软件介绍 解决方案 成功案列 推荐内容 热点内容 1 AWR公司简介、发展历史、主 AWR公司是全球射频/微波电子设计自动化(... AWR CONNECTED - Antenna Magus射频和 AWR 射频印刷电路板（PCB）解决方案 联系方式及试用注册申请 AWR 完整的、综合化的射频系统设计解决方案 南京爱立信熊猫通信公司使用AWR软件，使得L AWR 单片微波集成电路（MMIC）解决方案 AWR白皮书阐述了用电磁仿真进行VHF不平衡变 软件介绍 ANALYST - 三维有限元电磁分析软件 Analyst™是一款功能强大的、并行的三维有限元（FEM）电磁仿真和分析工具，它无缝的集成到AWR设计环境中。它允许您通过一次鼠标点击实现从电路概念到全三维电磁验证的整个过程。 发布时间：2013-06-04 AWR CONNECTED - ZUKEN 为PCB布局验证的射频微波设计 AWR Connected™ – Zuken提供了将射频微波设计流程从Zuken的 CR-8000 PCB平台转移到AWRMicrowave Office®/AXIEM® 设计环境进行布局后的电路设计和EM验证。 发布时间：2013-06-04 AWR CONNECTED - CAPESYM 射频/微波电路设计和高功率MMIC的热分析工具 AWR Connected™ for CapeSym’s SYMMIC：为MMIC设计者提供了双向接口，用以将AWR的Microwave Office®的设计导入到CapeSym的 SYMMIC 软件中进行热分析。 发布时间：2013-06-04 AWR CONNECTED - Antenna Magus射频和微波天线自动设计 AWR Connected™ – 与AWR射频/微波设计软件的无缝整合，大大提高了天线设计的效率。Antenna Magus向用户提供了包含多种不同特性天线的数据库，可将天线导入到AWR软件进行EM的... 发布时间：2013-06-04 本频道由专注微波、射频、无线等电磁波技术的垂直网站 [微波射频网] 负责运营维护 Copyright © 2007-2020 Retey Media Inc. All Rights Reserved. 版权所有 粤ICP备11063816快速熟悉 Oracle AWR 报告解读 - Cocowool - 博客园
快速熟悉 Oracle AWR 报告解读 - Cocowool - 博客园
会员
周边
新闻
博问
AI培训
云市场
所有博客
当前博客
我的博客
我的园子
账号设置
简洁模式 ...
退出登录
注册
登录
小狼的世界
不积跬步，无以至千里、不积细流，无以成江海
博客园
首页
联系
订阅
管理
快速熟悉 Oracle AWR 报告解读
目录AWR报告简介AWR报告结构基本信息Report SummaryMain ReportRAC statisticsWait Event Statistics参考资料
本文面向没有太多 Oracle 基础知识，但是需要通过 AWR 报告来分析数据库性能或排查问题人员，通过对 AWR 报告的简介，了解其包含的主要信息，然后对一些能够帮助我们分析定位问题的章节做一点稍微详细的介绍。通过阅读本文，期望使读者能够快速抓住阅读 AWR 报告的重点，为分析判断数据库性能是否有问题提供帮助。
本文示例报告基于 Oracle 11.2.0.3.0 版本生成。
AWR报告简介
AWR是Oracle 10g版本推出的特性，全称叫做 Automatic Workload Repository 全自动负载信息库 。Oracle启动后，会有后台进程定时采集并保存系统快照信息，也可以手工创建快照。AWR通过对比两个时间点的快照信息，生成该时间段的AWR报告，帮助DBA或开发人员了解 Oracle 数据库的运行情况。Oracle 还提供了 ASH、ADDM等工具，本文不进行探讨。
AWR报告结构
AWR报告基本分为四部分：
基本信息部分，包括了DB实例、主机的信息以及报告采集时间段的信息。
Main Report部分，第一部分Report Summary被单独放在了基本信息后面，其他的信息则放在整个报告较后的位置，个人觉得最重要的部分是SQL Statistcs。
RAC statistics部分，包括RAC相关的统计信息。
Wait Event Statistics部分。
基本信息
报告一开始部分为基本信息，显示了DB实例、主机信息。DB Time 指标可以用来判断数据库是否繁忙，如果 Elapsed 时间乘以CPU个数小于DB Time 表示数据库比较繁忙。
Report Summary
Report Summary 分为8个部分，最主要的是 Load Profile。
Load Profile 主要用来显示当前系统的一些指示性能的总体参数，部分介绍如下：
Redo Size ：用来显示平均每秒的日志大小和平均每个事务的日志大小，有时候可以结合 Transactions 每秒事务数，分析当前事务的繁忙程度。
Logical Read：逻辑读耗CPU，主频和CPU核数都很重要，逻辑读高则DB CPU往往高，也往往可以看到 latch: cache buffer chains 等待。
Physical Read：物理读消耗IO读，体现在IOPS和吞吐量等不同纬度上。但减少物理读可能意味着消耗更多CPU。
Parses：解析次数，包括软解析 + 硬解析，软解析优化得不好几乎等于每秒SQL执行次数， 即执行解析比1:1。理想状态是解析一次到处运行。
Hard Parses：硬解析次数，最好少于没秒20次。
注意 Load Profile 中的指标提供了 Per second 和 Per transaction 两个维度。Per second 主要是把快照抓到的值除以两个快照之间的秒数。这是我们用来判断性能的主要维度。Per transaction 是基于事务的维度，主要是把快照抓到的值除以两个快照之间的事务数。
Instance Efficiency Percentages 是一些命中率指标。Buffer Hit、Library Hit 等表示SGA ( System global area )的命中率。Soft Parse 指标表示共享池的软解析率，如果小于90%，就说明存在未绑定变量的情况。这些指标应当尽可能接近100%，如果过低一定是发生了性能问题。
Buffer Nowait ** 表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%**。否则可能存在争用，可以在后面的等待事件中进一步确认。
Buffer Hit 表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。数据块在数据缓冲区中的命中率，通常应在95%以上。
Redo NoWait 表示在Log 缓冲区获得Buffer的未等待比例。如果太低可考虑增加Log Buffer。当redo buffer达到1M时就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。当前，一般设置为2M的redo buffer，对于内存总量来说，应该不是一个太大的值。
Library Hit 表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在Oracle立即执行语句；如果不存在Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的Library Hit Ratio会导致过多的解析，增加CPU消耗，降低性能。如果Library Hit Ratio低于90%，可能需要调大Shared pool区。
Latch Hit：Latch是一种保护内存结构的锁，可以认为是Server进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。
Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。如果这个值比较小，表示解析消耗的CPU时间过多。
Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA(10g)。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。
Soft Parse：软解析的百分比(Softs/Softs+Hards)，近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。
Main Report
Report Summary 在上面一节已经说过，不再赘述。
SQL Statistics 从 11 个维度对SQL进行排序并给出了Top SQL的详细内容，可以点击查看具体的SQL内容，进一步分析调优方案。
SQL ordered by Elapsed Time。记录了执行总和时间的 TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。
SQL ordered by CPU Time。记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。
SQL ordered by Gets。记录了执行占总 buffer gets (逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。
SQL ordered by Reads。记录了执行占总磁盘物理读(物理IO)的TOP SQL。
SQL ordered by Executions。记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。
SQL ordered by Parse Calls。记录了SQL的软解析次数的TOP SQL。
SQL ordered by Sharable Memory。记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。
SQL ordered by Version Count。记录了SQL的打开子游标的TOP SQL。
SQL ordered by Cluster Wait Time。记录了集群的等待时间的TOP SQL。
Top 10 Foreground Events by Total Wait Time，等待事件是衡量数据库优化情况的重要指标，通过观察Event和%DB time两列就可以直观看出当前数据库的主要等待事件。
RAC statistics
这一部分涉及RAC运行的相关统计信息，对于初学者来说不太常用，本文暂不赘述。
Wait Event Statistics
其中 Time Model Statistics 几个有用的指标解释如下：
parse time elapsed 与 hard parse elapsed time 需要结合起来看解析是否是主要矛盾，若是则重点是软解析还是硬解析。
sequence load elapsed time 序列争用
PL/SQL compilation elapsed time PL/SQL对象编译的耗时
connection management call elapsed time 数据库连接建立和断开的耗时
failed parse elapsed time 解析失败的耗时
参考资料
oracle11G AWR使用及分析
等待事件：db file scattered read(离散读）
【深度长文】循序渐进解读Oracle AWR性能分析报告
Oracle AWR报告生成和性能分析
Oracle AWR报告指标全解析
posted @
2020-11-18 19:03
Cocowool
阅读(4615)
评论(0)
编辑
收藏
举报
会员力量，点亮园子希望
刷新页面返回顶部
公告
Copyright © 2024 Cocowool
Powered by .NET 8.0 on Kubernetes
Oracle AWR报告生成和性能分析 - smileNicky - 博客园
Oracle AWR报告生成和性能分析 - smileNicky - 博客园
会员
周边
新闻
博问
AI培训
云市场
所有博客
当前博客
我的博客
我的园子
账号设置
简洁模式 ...
退出登录
注册
登录
SmileNicky的博客
Email : nickypm@foxmail.com
Blog：https://smilenicky.blog.csdn.net
博客园
首页
新随笔
联系
订阅
管理
Oracle AWR报告生成和性能分析
目录一、AWE报告生成步骤1.1 工具选择1.2 自动创建快照1.3 手工创建快照1.4 生成AWR报告二、AWR报告分析2.1 AWR之DB Time2.2 AWR之load_profile2.3 AWR之efficiency percentages2.4 AWR之top 10 events
一、AWE报告生成步骤
对于SQL调优，局部SQL，我们可以直接使用执行计划等直接调优，而对于整个系统来说？这时候就可以用Oracle系统自带的报告对系统进行整体分析了，Oracle提供好几种性能分析的报告，比如AWR、ASH、ADDM等等
这篇博客主要介绍AWR
AWR全称Automatic Workload Repository，自动负载信息库，是Oracle 10g版本后推出的一种性能收集和分析工具，提供了一个时间段内整个系统的报表数据。通过AWR报告，可以分析指定的时间段内数据库系统的性能。
1.1 工具选择
对于Oracle数据库可以使用sqlplus或者plsql developer客户端软件
sqlplus 使用
可以使用sqlplus工具登录
进入数据库
sqlplus / as sysdba
查看用户
show parameter db_name
用登录之后才可以使用
plsql developer使用
plsql developer也可以使用，登录之后，选择文件(File)->新建(New)->命令窗口(Command Window)
1.2 自动创建快照
开始压测后执行
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
可以通过dba_hist_wr_control查看当前的配置情况，当前awr为每1小时做一次数据快照，保留时间为8天。
select * from dba_hist_wr_control;
修改配置，每隔30分钟收集一次，保存1天
execute dbms_workload_repository.modify_snapshot_settings(interval=>30,retention=>14000);
关闭AWR自动收集
SQL>exec dbms_workload_repository.modify_snapshot_settings (interval=>0,retention=>24*60);
注：10g默认是自动开启awr信息收集的，会对系统有一定的影响（很小）；如果要关闭awr信息收集，只需设置interval参数为0即可。但interval设0后，AWR报告无法生成。
1.3 手工创建快照
除了自动创建快照，也可以手工创建快照
select dbms_workload_repository.create_snapshot() from dual;
1.4 生成AWR报告
在sqlplus或者plsql使用命令，${ORACLE_HOME}是Oracle的安装路径
@/${ORACLE_HOME}/.../RDBMS/ADMIN/awrrpt.sql
例如我的命令为：
@D:/oracle/product/11.1.0/db_1/RDBMS/ADMIN/awrrpt.sql
sqlplus登录的可以使用
@?/rdbms/admin/awrrpt/awrrpt.sql
@?/rdbms/admin/awrrpt; 本实例AWR包括：
@?/rdbms/admin/awrrpti; RAC中选择实例号
@?/rdbms/admin/awrddrpt; AWR 比对报告
@?/RDBMS/admin/awrgrpt; RAC全局AWR报告
执行命令之后，会提示你输入一些参数
(1) Enter value of report_type
意思是生成报告的格式有两种，html和txt，这里选择html
(2) Enter value of num_days
收集几天的报告信息，数字，可以输入1
(3) Enter value of begin_snap
输入开始快照id，要根据日志打印的快照id范围来填
例如我实验时候，日志打印的快照id范围为：6727 ~6745
Listing the last day's Completed Snapshots
INST_NAME DB_NAME SNAP_ID SNAPDAT LV
------------ ------------ -------- ------------------ --
orcl ORCL 6727 17 4月 2019 00:00 1
orcl ORCL 6728 17 4月 2019 01:00 1
orcl ORCL 6729 17 4月 2019 02:00 1
orcl ORCL 6730 17 4月 2019 03:00 1
orcl ORCL 6731 17 4月 2019 04:00 1
orcl ORCL 6732 17 4月 2019 05:00 1
orcl ORCL 6733 17 4月 2019 06:00 1
orcl ORCL 6734 17 4月 2019 07:00 1
orcl ORCL 6735 17 4月 2019 08:00 1
orcl ORCL 6736 17 4月 2019 09:00 1
orcl ORCL 6737 17 4月 2019 10:00 1
orcl ORCL 6738 17 4月 2019 11:00 1
orcl ORCL 6739 17 4月 2019 12:00 1
orcl ORCL 6740 17 4月 2019 13:00 1
orcl ORCL 6741 17 4月 2019 14:00 1
orcl ORCL 6742 17 4月 2019 14:13 1
orcl ORCL 6743 17 4月 2019 14:15 1
orcl OANET 6744 17 4月 2019 14:16 1
orcl OANET 6745 17 4月 2019 14:40 1
所以我随意填写：6743
(4) Enter value of end_snap
输入结束快照id，要根据日志打印的快照id范围来填，所以我随意填写：6745
SQL> @D:/oracle/product/11.1.0/db_1/RDBMS/ADMIN/awrrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DBID DB_NAME INST_ INST_NAME
---------- ------------ ----- ------------
4279242421 ORCL 1 orcl
rpt_options
---------
0
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Type Specified: html
Cannot SET TRIMSPOOL
Cannot SET UNDERLINE
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DBBID INSTT DBB_NAME INSTT_NAME HOST
------------ ----- ------------ ------------ ------------
* 4279242421 1 ORCL ORCL zwdb
Using 4279242421 for database Id
Using 1 for instance number
dbid
---------
4279242421
inst_num
---------
1
inst_num
---------
1
dbid
---------
4279242421
max_snap_time
---------
17/04/2019
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing
specifying a number lists all completed snapshots.
Listing the last day's Completed Snapshots
INST_NAME DB_NAME SNAP_ID SNAPDAT LV
------------ ------------ -------- ------------------ --
orcl ORCL 6727 17 4月 2019 00:00 1
orcl ORCL 6728 17 4月 2019 01:00 1
orcl ORCL 6729 17 4月 2019 02:00 1
orcl ORCL 6730 17 4月 2019 03:00 1
orcl ORCL 6731 17 4月 2019 04:00 1
orcl ORCL 6732 17 4月 2019 05:00 1
orcl ORCL 6733 17 4月 2019 06:00 1
orcl ORCL 6734 17 4月 2019 07:00 1
orcl ORCL 6735 17 4月 2019 08:00 1
orcl ORCL 6736 17 4月 2019 09:00 1
orcl ORCL 6737 17 4月 2019 10:00 1
orcl ORCL 6738 17 4月 2019 11:00 1
orcl ORCL 6739 17 4月 2019 12:00 1
orcl ORCL 6740 17 4月 2019 13:00 1
orcl ORCL 6741 17 4月 2019 14:00 1
orcl ORCL 6742 17 4月 2019 14:13 1
orcl ORCL 6743 17 4月 2019 14:15 1
orcl OANET 6744 17 4月 2019 14:16 1
orcl OANET 6745 17 4月 2019 14:40 1
dbid
---------
4279242421
inst_num
---------
1
max_snap_time
---------
17/04/2019
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Begin Snapshot Id specified: 6743
End Snapshot Id specified: 6745
bid
---------
6743
eid
---------
6745
inst_num
---------
1
dbid
---------
4279242421
bid
---------
6743
eid
---------
6745
Cannot SET TRIMSPOOL
Cannot SET UNDERLINE
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_6743_6745.html. To use this name,
press
Using the report name awr.html
Started spooling to D:\Program Files\PLSQL Developer 8.0.3.1510\awr.html
二、AWR报告分析
2.1 AWR之DB Time
DB Time主要用来判断当前系统有没有相关瓶颈，是否较为频繁访问系统导致等待时间很长？然后要怎么看？一般来说，Elapsed时间乘以CPU个数如果大于DB Time，就是正常的，系统压力不大，反之就说明压力较大，例子如图，24.93*8很明显大于0.49，所以说明系统压力很小
2.2 AWR之load_profile
load_profile指标主要用来显示当前系统的一些指示性能的总体参数，这里介绍一些Redo_size，用来显示平均每秒的日志尺寸和平均每个事务的日志尺寸，有时候可以结合Transactions这个每秒事务数，分析当前事务的繁忙程度
如图，平均每秒的事务数Transactions非常小，说明系统压力非常小，一般来说Transactions不超过200都是正常的，或者200左右都是正常的，超过1000就是非常繁忙了，再看看平均每秒的日志尺寸是4位数的，平均每个事务的日志尺寸是5位数的，说明了系统访问不是很频繁，而单个业务是比较复杂的，如果反过来，平均每秒日志尺寸比平均每秒事务日志尺寸大很多，说明系统访问很频繁，而业务比较简单，不需要响应很久
2.3 AWR之efficiency percentages
efficiency percentages是一些命中率指标。Buffer Hint、Library Hint等表示SGA(System global area)的命中率；Soft Parse指标表示共享池的软解析率，如果小于90%，就说明存在未绑定变量的情况
2.4 AWR之top 10 events
Top 10 Foreground Events by Total Wait Time，等待事件是衡量数据库优化情况的重要指标，通过观察Event和%DB time两列就可以直观看出当前数据库的主要等待事件
如图可以看出系统面试的主要是CPU被占用太多了和锁等待
### 2.5 AWR之SQL Statistics
SQL Statistics从几个维度列举了系统执行比较慢的SQL，可以点击，然后拿SQL去调优，调优SQL可以用执行计划看看
对于AWR的性能指标还有很多，本博客是看了《收获，不止SQL优化》一书的笔记，这里只简单介绍一些比较重要的指标
IT程序员
posted @
2019-04-20 15:46
smileNicky
阅读(41850)
评论(1)
编辑
收藏
举报
会员力量，点亮园子希望
刷新页面返回顶部
公告
Copyright © 2024 smileNicky
Powered by .NET 8.0 on Kubernetes