没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
更多 IT 认证课程请访问 美河学习在线 www.eimhe.com
Oracle11g 性能调优(OCP 版)课堂笔记
第一部分 性能调优方法论
第一章:调优介绍
一、谁来调优
数据库管理员
应用架构师
应用设计师
应用开发人员
OS 系统管理员
存储系统管理员
二、DBA 在调优中做什么
1)应用调优(DBA 和开发人员合作)
SQL statement performance Change management
2)实例调优(DBA 负责)
MemoryDatabase structure
Instance configuration
3)操作系统(DBA 与系统管理员合作)
I/O
Swap
Parameters
三、调优方法论
OWI 全称 Oracle Wait Interface,即基于等待事件的调优方法。等待事件到 11g 已发展到近 1000 个。从 10g 开始,性能调优的
重点已经不再单纯是提高缓存击中率了。
OWI 是一种用于定位 process bottlenecks(即 wait events)的方式:
包括 I/O、locks、latches、bk process activities、network latencies 等等。它记录了所有这些事件的等待次数和总的等待时间。
在 OWI 之前,要定位问题必须将 checklist 上的所有项目都执行一遍,再根据经验判断问题所在,这往往浪费大量的时间而且容
易产生错误。
通过解除或者降低 Wait Events,可以直接提高系统工作效率。这些数据都被记录在动态视图中或 AWR 报告里。
Oracle 推荐使用 OWI 方法,通过等待事件的分析,直接消除问题。
调整目标具有三个特征:
1)具体的(Specific)
2)可测的(Measurable)
3)可实现的(Achievable)
OWI 方法论总结起来就是三点:
1)自顶向下,抓主要矛盾
2)选择可获得最大收益的事件入手
3)目标达到后见好就收
第二章:基本调优工具
一、性能调优工具
1)Dynamic performance views--动态性能视图
2)AWR 或 Statspack
Load Profile--系统负荷
Instance Efficiency Percentages--实例有效率
Shared Pool Statistics--共享池统计
更多 IT 认证课程请访问 美河学习在线 www.eimhe.com
Time Model Statistics--时间模型统计
Top wait events--突出的等待事件
SQL statistics
等等
3)告警日志
Alert log 文件和 Trace files 文件
4)Enterprise Manager Pages--OEM
5)诊断包和调优包
二、DB Time model
1、什么是 DB Time model
"The most important of the time model statistics is DB time. This statistics represents the total time spent in database calls and is a
indicator of the total instance workload. It is calculated by aggregating the CPU and wait times of all sessions not waiting on idle wait
events (non-idle user sessions). DB time is measured cumulatively from the time that the instance was started."
数据库消耗的总时间包括 DB time+background elapsed time
DB time 反应的是所有 user 使用的数据库资源的总和, 即:DB time=DB CPU+ DB Wait time(no-idle time)。
background elapsed time 指数据库后台进程消耗的时间,比如 PMON 进程本身,或 RMAN 备份恢复。
idle time 比如处于连接状态的空闲 session 不包括在 DB Wait time。
在一个正常的系统中一般来说 DB time 要远远大于 background elapsed time。
2、调优时,很重要的是把 DB Wait time(不包括 idle wait)和 DB CPU time 对比,看看谁占的比例大,这决定了多少时间是花
在有用的工作上,多少时间消耗在等待其他进程释放占用的资源。作为一般规则,调整 DB Wait time 比调整 DB CPU time 更为
迫切,然而,较高的 CPU time 也可能表明 SQL 本身写的很差。
而 Wait time 的急剧增加又可能反映了一个资源争用的迹象。
注意,资源争用通过增加更多的处理器,或集群节点,其作用往往是非常有限的,有时甚至可能适得其反。
在 DB time 的统计信息中,sql execute elapsed time 和 parse time elapsed 以及 DB CPU,这三项常常会占据 90%以上的 DB time,
而其中 sql execute elapsed time 又应该会在 95%以上,值得注意的是 DB CPU 和 sql execute elapsed time 是有交集的,因此你会
看到在一份 AWR 报告中有出现 DB CPU + sql execute elapsed time 超过 DB time 的情况。
更多 IT 认证课程请访问 美河学习在线 www.eimhe.com
3、两个直接反应 DB time 统计信息的视图
v$sys_time_model
v$sess_time_model
v$sys_time_model 中的 STAT_NAME 的 db time 时间单位是以微妙(microseconds)为单位,也就是百万分之一秒。
视图中常用的时间单位有:
Secord 秒
Centisecond 厘秒--百分之一秒
Millisecond 毫秒--千之一秒
Microsecond 微秒--百万分之一秒
三、统计信息和等待事件
在 Oracle 数据库中,“统计信息”和“等待事件”是性能优化目标的重要原始数据。它们都是累计的信息。
一)统计信息的概念:
数据库的活动在内存中产生了大量的信息,把这些信息分门别类的统计出来,就是所谓的统计信息。
统计信息的值是自实例启动以来至当前的累计值,单一的统计值往往不能说明什么,而两个累计值的差才能反应那段时间内数
据库的活动。
SYS@ prod>select count(distinct name) statistcs from v$sysstat;
STATISTCS
----------
604
二)等待事件的概念
先要弄清楚什么是事件
Oracle 根据数据库各类活动的特性定义了许多事件(Event),
每个事件对应一个事件 name, 每个数据库版本的事件数量是不同的。
本版本是 11.2.0.1 的, 总共有多少个事件呢?
SYS@ prod>select count(distinct name) events from v$event_name;
EVENTS
----------
1118
现在回答什么是等待事件:
当一个进程无法顺利执行,那么只能通过排队等待某种资源,因为有堵塞才有等待。等待一定发生在共享资源上,一般分两种
原因:
(1)资源不足
(2)资源争用
更多 IT 认证课程请访问 美河学习在线 www.eimhe.com
SYS@ prod>select count(distinct event) from v$system_event;
COUNT(DISTINCTEVENT)
--------------------
80
本系统没跑业务,这里有等待事件 80 个,它是自上次实例启动后到目前为止一共记录了 80 个等待 event,它们都是累计值。
如果你这时跑一个大的并发访问的应用,出现资源不足或资源争用,那么还可能增加其他的等待事件,一些事件的统计值也会
累计叠加。
资源不足的解决方案可以增加硬件,如 CPU、MEMORY 等
资源争用的解决方案需要从应用层面和数据库结构层面想办法
资源争用不能用资源不足的办法解决:
"When contention is evidenced by increased wait time,adding more CPUs to a node, or nodes to a cluster, would provide very limited
benefit. "
统计信息和等待事件之间有一定的关系,但也不是包含关系,更不是一对一关系,它们侧重点不同,细分后命名方法也不同。
从下面两个视图的对比就可说明问题。
select * from v$statname;
select * from v$event_name;
三)统计视图和等待视图
从三个方面(维度)反映重要的统计视图
1)基于系统级
v$sysstat
2)基于 session 级
v$sesstat 所有 session 分别列出统计信息,每一行是某个 session 对应的某种统计信息
v$mystat 当前 session 统计信息
3)基于 service 级
v$service_stats
此外还有一个常用的视图
v$statname 此视图提供一个统计信息的完整列表,每行对应一种统计信息
四)示例:查询日志累计统计信息
第一步, 确定 session1 的 sid 号
[oracle@cuug ~]$ sqlplus / as sysdba
SYS@ prod>grant select on v_$mystat to scott;
SYS@ prod>conn scott/scott
SCOTT@ prod>select sid from v$mystat where rownum=1;
SID
----------
更多 IT 认证课程请访问 美河学习在线 www.eimhe.com
46
第二步,在 plsql develop 端查看该 session 下的有关 redo 的两项统计信息
观察 desc v$sesstat,该视图中没有 name 字段,可以和 v$statname 联查,以便确定相关信息。
SQL>
select ss.sid,sn.name,ss.value from v$sesstat ss,v$statname sn
where ss.STATISTIC#=sn.statistic#
and sn.name in('redo entries','redo size') and ss.sid=46;
SID NAME VALUE
---------------------------------------------
46 redo entries 630
46 redo size 80264
第三步,在该 session 下做一个 dml 操作
观察 update 前后日志的变化
SCOTT@ prod>update emp set sal=sal+1000 where empno=7788
SCOTT@ prod>commit;
第四步,重复第二步并查看结果
SID NAME VALUE
---------------------------------------------
46 redo entries 631
46 redo size 80780
可以看到 46 号 session 的 update 的动作产生的日志统计信息:
产生 redo entries=1 (631-630=1)
产生 redo size=516 (80780-80264)
五)从三个方面反映重要的等待事件视图
1)基于系统级
v$system_event
2)基于 session 级
v$session_event ----所有 session 分别列出等待事件,每一行是某个 session 对应的某种等待事件
v$session_wait ----所有 session 当前正在等待的事件
3)基于 service 级
v$service_event
另外提供一个等待事件的完整列表,每行对应一种等待事件
v$event_name
理解事件的三个参数
select name,parameter1,parameter2,parameter3 from v$event_name where name like '%buffer busy%';
四、常见的几个等待事件
1、Buffer busy waits 等待事件
这个等待事件的产生说明了一个会话曾经等待一个 Buffer(数据块)
有两种情形是:
(1)当一个会话试图修改一个 Buffer,但这个 Buffer 正在被另一个会话修改时。
热块是典型的是资源争用,分析热块产生原因,才可对症下药:以下为热块发生的部位:
剩余31页未读,继续阅读
资源评论
worthcvt
- 粉丝: 90
- 资源: 407
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功