V$EVENT_NAME
BUFFER_BUSY_WAITS参数
段头块竞争(freelist不够), 段中块竞争(初始事务槽不够), 回滚段竞争 空闲等待:
正在等待某动作发生(网络等待) 必须等待 非空闲等待:
数据库发生了竞争
高速缓存忙等待等 统计事件的视图:
V$SYSTEM_EVENT(系统级) 主动优化
数据库建立到现在
一个事件的所有会话统计 V$SESSION_EVENT(会话级)
比SYSTEM_EVENT多了个会话ID 被动优化
从会话建立到现在 V$SESSION_WAIT(瞬时)
正在发生或刚刚结束的等待事件 重点关注等待事件时间长,次数多的 块等待v$waitstat
OEM的tuning包和diagnostics包 自动性能优化指导(10G) SQL自动调整(11g) 应用级:
Autotrace SQL trace 。。。 辅助相关文件
告警日志文件(关系很小) 用户进程跟踪文件
执行计划和统计信息(做SQL调优) Alter session(收集自己的) ORADEBUG 第三方工具
故障诊断和调优相关视图: 系统级
竞争:锁,内存锁,回滚段 会话级
性能监控的解决方案 查动态性能视图
Statspack AWR ADDM
查看等待,看是什么等待,分析
OracleDBA+性能优化8日游笔记——第五天(三) 2010-01-06 16:18
二.数据库优化 内存优化
增加内存:
性能提高越来越不明显, 理论增加到平滑点为止
需要内存远远大于物理内存:增加到拐点以上 两种方法判断平滑点和拐点: 尝试不断增大
使用9i内存大小建议 调整内存管理方法
数据高速缓冲区
暂存最近最常使用的数据块 块状态:
空的
Free:用过清空的 脏的
正在访问的 块维护:
LRU list Dirty list
SGA
数据缓冲区
影响执行效率
由多个独立的子缓存区和多种块大小(非标准块)的缓存区组成
DB_BLOCK_SIZE决定了标准块的大小 非标准块:
先设置非标准块内存区,再设置块大小 调优目的:
服务器能够在缓存区中招到数据
OLTP中要求90%的命中率(最好95%) 查命中率在运行一段时间后查 单池命中率:通过V$sysstat计算 多池命中率
一个性能糟糕的数据库命中率同
样能达到99%
当算法正确的情况下命中率高性能越好
命中率低了一般都不好 使用多池:
常用池 不常用池 其他池 定义多池 使用多池:
设置存储对象的存储特性 Keep池:
设置大小:所有常用块数的总大小 命中:99% RECYCLE池:
放不常用的块 命中:50% DEFAULT池
命中:90% 用CATCH表
用CATCH子句创建表 用CATCH子句修改表
用hint:SELECT /*+CATCH*/ * FROM 表
共享池
影响解析效率
减少大量的硬解析就减少了CPU消耗
对于大量重复执行的SQL语句进行解析优化
库高缓存
暂存最近最常使用的SQL语句文本,分析代码,执行计划
让我们能不解析就不解析
在解析前先算hash value,通hash value找相同的文本信息等
V$librarycatch(算命中率判断代码共享量)
命中率和重载率决定影响
没共享原因: 所有动态SQL都是硬解析
对dual表的访问肯定是硬解析
共享池太小
调大
语句本身不共享
调代码
语句看上去一样,但值不一样(输入条件不一样)
建立代码规范
绑定变量代替
ORACLE先解析,后绑定,再执行
语句一样,但之前对表结构做了DDL操作
最好不要在业务繁忙期做对象维护
11G新特性,当语句跟表相关,对表结构的改变对语句没有影响的时候不失效
V$SGASTAT查看大小
V$SQL,V$SQLAREA等视图查看SQL代码共享情况
看上去一样的SQL语句,哪怕多个空过或换行或某个大小写不一样都不能共享
完全相同的语句,值也相同,哪怕不是同一个会话也可以共享
11g让以上操作造成的失效率变低了
其他调优方法
防止碎片: 为大的内存需求保留空间
碎片会造成内存不够用,使大程序把频繁访问的小程序挤出缓存区,造成重载
SHARED_POOL_RESERVED_SIZE
默认共享池大小的10%
最大不能超过共享池大小的50%
将被频繁访问的大对象保留(pin)在内存中
EXECUTE dbms_shared_pool_.keep(‘package_name’)
EXECUTE dbms_shared_pool_.onkeep(‘package_name’)
影响库高缓存的其他参数:
OPEN_CURSORS 一个用户最多可打开的游标个数
执行的语句不一样且很多,就要调高
CURSORS_SPACE_FRO_TIME
空间换时间
空间打开不释放
有很多语句在频繁调用的时候用
字典高速缓存区
在不得不解析的情况下加速解析
内容:对象的定义 V$ROWCATCH SUM(GETMISSES)/ SUM(GET)应该小于15%
在共享模式下配置足够大的大池存放UGA
UGA会在共享模式下从SGA跑到PGA
重做日志缓冲区
跟日志产生的操作有关
日志的I/O操作可能比数据操作造成的I./O总量要大的多
以写为主的系统,日志可能会是一个性能平均
等待事件
百度搜索“70edu”或“70教育网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,70教育网,提供经典综合文库OracleDBA性能优化8日游笔记(8)在线全文阅读。
相关推荐: