首页 > 编程知识 正文

oracle和mysql的优缺点,awr报告

时间:2023-05-06 18:19:27 阅读:14152 作者:3625

要查看数据库运行的总体情况:

数据库时间不包括Oracle后台进程所消耗的时间。 对于数据库

Time远远短于Elapsed时间,表明数据库处于空闲状态

db time=cpu time wait time ()空闲等待(不包括后台进程以外的进程)=cpu time all of

非空闲等待事件时间

数据库负载为: DB

时间/(elapsed * CPUs ) *100%。 根据AWR报告中显示的一段时间内的统计数据,如果快照的跨度中包含大量空闲时间,则计算出的CPU平均利用率也较低。

BEGIN SNAP数据库有166个会话,到11点为止,数据库有181个会话

要查看路线图:

加载配置文件

重做大小:重做大小单位bytes,重做

size可用于估计更新/插入/删除的频率和较大的重做

size经常在lgwr上写日志,给arch归档带来I/O压力。

如何解决每秒发生大量重做?

增加重做日志的大小

添加重做日志组

添加重做缓冲器

逻辑读取、块更改、物理读取、物理

writes :评估数据库读写的繁忙程度,判断数据库活动的性质和规模。

逻辑读取单位为块,表中每秒读取50290.4块时,大小为50290.4*8K=393M的逻辑读取会影响所有表扫描。

Logons每秒1~2个,大于Hard

parses超过每秒100且所有parses超过每秒300表示可能存在冲突问题。

Parses,hard parses :根据SQL软分析和硬分析的次数,评估是否需要优化SQL。

执行、每秒事务处理/每事务处理的SQL执行次数、每秒事务处理数。 每秒发生的事务数反映数据库负载是否繁重。 其中硬分析的次数表明,硬分析过多,SQL重用率不高。 每秒的硬分析次数,

如果超过每秒100次,绑定可能使用不良,或者共享池设置可能不合理。

应收帐款

Call :递归调用占所有操作的百分比。 如果有很多PL/SQL,则递归调用的百分比会较高。

回滚(每秒回滚率和所有回滚率。 由于回滚占用资源,如果回滚率过高,数据库可能受到了过多的无效操作

过度回滚还可能带来还原阻止竞争。

查看实例效率分析报告:

实例性能

“Percentages”报表显示Oracle主要度量的内存命中率和其他数据库实例操作的效率:

Buffer Nowait % :未等待在内存中获取数据的百分比。 该值通常需要大于99%。 否则,可能会发生冲突。

Buffer Hit

% :数据块在数据缓冲区中的命中率通常必须至少为95%。 否则,必须调整关键参数,小于90%可能添加db_cache_size。 在典型的OLTP系统中,如果此值小于80%,则需要为数据库分配更多内存

library hit:SQL在共享区域的命中率通常必须至少为95%。 对于library hit

ratio不到90%,可能需要充实的蜡烛pool区

Soft Parse % :软分析的比例通常应该在95%以上。

Execute to Parse % :语句执行和分析的百分比。 反映SQL的再利用率。

重做通告指示在日志缓冲区中获得缓冲区的未等待百分比。 过低时(可以参照90%的阈值),考虑增加LOG

缓冲区。

内存储器

Sort :内存中排序的百分比。 如果太低,则表示临时表空间进行了大量排序。 考虑调整PGA(10g )。 如果小于95%,则可以通过适当增大初始化参数PGA_AGGREGATE_TARGET或SORT_AREA_SIZE来解决。

请注意,这两个参数的功能范围不同: SORT_AREA_SIZE为每个session设置,PGA_AGGREGATE_TARGET为所有sesion设置。

软件

Parse :“软分析百分比”(softs/softs hards )近似为sql在共享区域的命中率,如果太低,则必须调整APP应用程序以使用绑定变量。 sql在共享区域的命中率小于95%,必须考虑绑定。 如果小于80%,则sql可能很少被重用。

要查看共享池统计信息报告:

shared pool静态

内存使用

% :共享池的内存利用率通常必须在75 %到90 %之间。 过低表示有浪费,过高表示有竞争。 如果这个比例太低,共享池的设置就会太大,会增加管理负担,在某些情况下可能会导致性行为

能的下降。

如果这个百分率太高,会使共享池外部的组件老化,如果SQL语句被再次执行,这将使得SQL语句被硬解析。

% SQL with

executions>1:执行次数大于1的SQL的比例,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。。

% Memory for SQL

w/exec>1:执行次数大于1的SQL消耗内存的占比,在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。

当前性能问题的确定,我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容,hit统计帮助我们发现和预测一些系统将要产生的性能问题,由此我们可以做到未雨绸缪。而wait事件,就是表明当前数据库已经出现了性能问题需要解决,所以是亡羊补牢的性质。

查看系统Top10等待 Total Call Time

如果‘buffer busy wait’是较严重的等待事件,我们应当继续研究报告中Buffer

Wait和File/Tablespace

IO区的内容,识别哪些文件导致了问题。如果最严重的等待事件是I/O事件,我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O,并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待,就需要察看详细的LATCH统计识别哪些LATCH产生的问题。

一个性能良好的系统,DB CPU项应该排在前5之内,否则说明你的系统大部分时间都用在等待上.

查看SQL统计信息:

SQL ordered by Elapsed Time:记录了执行总时间最长的Top SQL,其中Elapsed Time

= CPU Time + Wait Time

SQL ordered by CPU Time:记录了占CPU时间最长的Top SQL

SQL ordered by User I/O Wait Time:记录了执行过程中等待IO时间最长的Top

SQL

SQL ordered by Gets:记录了执行最多逻辑读(逻辑IO)的Top SQL

SQL ordered by Reads:记录了执行最多物理读(物理IO)的Top SQL

SQL ordered by Executions:记录了执行次数最多的Top

SQL,即使单条SQL运行速度飞快,任何被执行几百万次的操作都将耗用大量的时间。

SQL ordered by Parse Calls:记录了软解析次数最多的Top SQL

查看Undo资源信息:

Undo Statistics部分记录了回滚相关的信息:

查看行锁等待信息:

Segments by Row Lock Waits表展示了行锁等待信息:

当一个进程在正被其它进程锁住的数据行上获得排它锁时会发生等待,这种等待经常是由在一个有主键索引的表上做大量INSERT操作时引起。

等待事件:

log file parallel write:从log buffer 写redo 记录到redo log

文件,主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员,当flush log

buffer 时,写操作是并行的,这时候此等待事件可能出现。尽管这个写操作并行处理,直到所有I/O

操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE,那么即使只有一个redo log file

member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file

的写入成本。通常称为同步成本率。改善这个等待的方法是将redo

logs放到I/O快的盘中,尽量不使用raid5,确保表空间不是处在热备模式下,确保redo

log和data的数据文件位于不同的磁盘中。

log file

sync:当一个用户提交或回滚数据时,LGWR将会话的redo记录从日志缓冲区填充到日志文件中,用户的进程必须等待这个填充工作完成。在每次提交时都出现,如果这个等待事件影响到数据库性能,那么就需要修改应用程序的提交频率,

为减少这个等待事件,须一次提交更多记录,或者将重做日志REDO LOG 文件访在不同的物理磁盘上,提高I/O的性能。

需要注意在很多情况下,使用索引并不是最佳的选择,比如读取较大表中大量的数据,全表扫描可能会明显快于索引扫描,所以在开发中就应该注意,对于这样的查询应该进行避免使用索引扫描。

Direct Path Read:一般直接路径读取是指将数据块直接读入PGA中。一般用于排序、并行查询和read

ahead操作。这个等待可能是由于I/O造成的。使用异步I/O模式或者限制排序在磁盘上,可能会降低这里的等待时间。

direct path write:直接路径写该等待发生在,系统等待确认所有未完成的异步I/O

都已写入磁盘。对于这一写入等待,我们应该找到I/O

操作最为频繁的数据文件(如果有过多的排序操作,很有可能就是临时文件),分散负载,加快其写入操作。如果系统存在过多的磁盘排序,会导致临时表空间操作频繁,对于这种情况,可以考虑使用Local管理表空间,分成多个小文件,写入不同磁盘或者裸设备。

查询所有等待事件及其属性:

select event#, name, parameter1, parameter2, parameter3 from

v$event_name order by name;

参考

https://blog.csdn.net/daf380/article/details/86598468

https://blog.csdn.net/demonson/article/details/79474133

--单实例下生成AWR报告

SQL> @?/rdbms/admin/awrrpt.sql

--RAC环境下生成AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrgrpt.sql

--指定数据库实例生成AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrrpti.sql

--生成SQL语句AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

--指定实例生成SQL语句AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpi.sql

--生成比较的AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

--RAC环境下生成比较的AWR报告

@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。