提交优化Oracle Tuning Log File Sync 等待事件的几种策略
发一下牢骚和主题无关:
在
一个繁频 commit/rollback 或盘磁 I/O 有问题、量大物理读写争用
那么、我们便会经常瞧见 LOG FILE SYNC 待等事件出现在 TOP EVENTS 中
评估 LOG FILE SYNC待等事件的标指是均匀待等时间、以及 AWR 后续的 WAIT EVENT HISTOGRAM
对于 OLTP、均匀待等时间 7 ms算畸形、畸形情况下均匀待等时间不会超越 10 ms
面下给出几种优化的策略、
㈠ 优化 REDO 日记的 I/O
如果够能优化 REDO 日记文件的存储、使之存放到更快的盘磁、可便增长这个待等事件单次待等时间
㈡ 加大 LOG BUFFER
加大 LOG BUFFER 、可以使均匀每次写入 REDO 日记文件的 REDO 字节数增长
从而、增长 REDO 的 I/O 次数、进而到达优化 REDO 日记文件写待等时间的的目
㈢ 增长提交次数
通过加大一次提交记载的数量、增长提交批次、也可效有增长 LOG FILE SYNC待等时间
不过、此法可能须要更变用应、价值较大
㈣ 分部经常提交的事务设置为异步提交
通过设置 COMMIT_WRITE参数、可以控制异步提交
该参数持支系统级、但也持支会话级
其中、"IMMEDIATE,NOWAIT"是较为用常的优化案方
可通过:
● 更变参数 commit_write
● 直接令命:commit write immediate nowait
最后、Rocky 想在絮聒 3 下、我们在数据库的平常护维中应当对此建立线基(baseline)
如果这个标指有异常化变、一定要尽快析分并解决问题、一旦这个标指化恶
可能致导系统性能急剧下降、甚至会致导长久的起挂
文章结束给大家分享下程序员的一些笑话语录:
Borland说我很有前途,Sun笑了;Sun说我很有钱,IBM笑了;IBM说我很专业,Sybase笑了;Sybase说我数据库很牛,Oracle笑了;Oracle说我是开放的,Linux笑了;Linux说我要打败Unix,微软笑了;微软说我的系统很稳定,我们都笑了。