Oracle Tuning Log File Sync 等待事件的几种策略

标签： oracle tuning log | 发表时间：2013-05-09 15:40 | 作者：linwaterbin
出处：http://blog.csdn.net
   
    在一个频繁 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)
   如果这个指标有异常变化、一定要尽快分析并解决问题、一旦这个指标恶化
   可能导致系统性能急剧下降、甚至会导致短暂的挂起

作者：linwaterbin 发表于2013-5-9 15:40:34 原文链接
阅读：102 评论：0 查看评论

相关 [oracle tuning log] 推荐：

Oracle Tuning Log File Sync 等待事件的几种策略

- - CSDN博客数据库推荐文章
    在一个频繁 commit/rollback 或磁盘 I/O 有问题、大量物理读写争用.    那么、我们便会经常瞧见 LOG FILE SYNC 等待事件出现在 TOP EVENTS 中.    评估 LOG FILE SYNC等待事件的指标是平均等待时间、以及 AWR 后续的 WAIT EVENT HISTOGRAM.

Oracle online redo log 扫盲

- - CSDN博客数据库推荐文章
Oracle 的日志分为：ONLINE REDO LOG 和 archived log. 一个数据库至少要有2组 redo log，每组 redo log 至少要有一个 member（出于安全考虑，建议每组 redo log 至少有 2 个多元化的 redo log member）. redo log 循环使用，当一组日志写满后，就会切换到下一组日志.

使用ORACLE SQL Tuning advisor快速优化低效的SQL语句

- - CSDN博客数据库推荐文章
ORACLE10G以后版本的SQL Tuning advisor可以从以下四个方面给出优化方案.   (1)为统计信息丢失或失效的对象收集统计信息.   (2)考虑优化器的任何数据偏差、复杂谓词或失效的统计信息.   (3)重新构建 SQL 以优化性能.   (4)提出新索引建议. 1、为SQL_id创建一个STA（SQL Tuning advisor） 分析任务（使用SYS用户执行）.

ORACLE SQL TUNING各种技巧及复杂实例

- - 数据库 - ITeye博客
ORACLE的优化器共有3种:. CHOOSE (选择性). 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须定期更新统计信息，以保证数据库中的对象统计信息(object statistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关.

【ActiveMQ Tuning】Prefetch Limit

- - 博客园_首页
   摘要：ActiveMQ优化 客户端优化 预取限制. 原文： http://fusesource.com/docs/broker/5.4/tuning/GenTuning-Consumer-Prefetch.html. Overview：图列4.1阐明了Broker在等待之前发送给客户端消息的反馈的行为.

【ActiveMQ Tuning】Serializing to Disk

- - 博客园_首页
     翻译自： http://fusesource.com/docs/broker/5.4/tuning/PersTuning-SerialToDisk.html.      KahaDB message store：KahaDB 是ActiveMQ Broker 为了高性能而推荐使用的消息存储机制.

Elasticsearch Performance Tuning Practice at eBay

- -
Elasticsearch is an open source search and analytic engine based on Apache Lucene that allows users to store, search, analyze data in near real time. This document summarizes the challenges as well as the process and tools that the Pronto team builds to address the challenges in a strategic way.

Log调试

- - ITeye博客
在开发中我们一定不能避免使用Log类，但是这个类存在一个问题就是，当你在程序中使用了大量的Log，那么在程序开发完毕的时候，这将是一个问题，因为，你需要将所有的Log记录注释掉（当然，你不注释也是可以的）. 我们可以写一个类，将Log类包装起来，使用一个boolean来控制所有的Log记录的显示. public static final boolean isDebug = true;//这里控制所有Log的显示情况.

log file sync总结

- - 数据库 - ITeye博客
log file sync等待时间发生在redo log从log buffer写入到log file期间. 下面对log file sync做个详细的解释. 1.commit或者rollback. 3.log buffer 1/3满或者已经有1M的redo数据.       更精确的解释：_LOG_IO_SIZE 大小默认是LOG_BUFFER的1/3,当log buffer中redo数据达到_LOG_IO_SIZE 大小时，发生日志写入.

宇宙微調論證（fine-tuning argument）

- Calon - 哲學哲學雞蛋糕.
這麼扯的事情竟然會發生，這只能用神蹟來解釋. 」許多人使用這種「奇蹟論證」的格式來建立支持上帝存在的主張，這些主張的不同之處，大致上在於它們訴諸不同的「神蹟」. 有些人相信上帝（或土地公，whatever）存在，因為若不是這樣，他沒有辦法解釋自己的某些奇特經歷（例如摔倒之後腦瘤就好了）. 智慧設計論者相信萬物是神創的，因為他們不認為這些具備各種奇奇怪怪精細器官的動植物，能夠經由巧合自己蹦出來.