Log file sync caused by more commit

最新推荐文章于 2024-08-05 10:50:28 发布
最新推荐文章于 2024-08-05 10:50:28 发布
阅读量1.8k 收藏
点赞数
分类专栏： oracle 文章标签： Oracle database
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ora_raymond/article/details/10459673
版权

Today, our db changes slow suddenly.

And i do a hanganalyze as following:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name:    Linux
Node name:      db42
Release:        2.6.18-164.el5
Version:        #1 SMP Thu Sep 3 04:15:13 EDT 2009
Machine:        x86_64
Instance name: cedb2
Redo thread mounted by this instance: 2
Oracle process number: 205
Unix process pid: 11618, image: oracle@db42 (TNS V1-V3)


*** 2013-08-28 15:53:14.460
*** SESSION ID:(773.44301) 2013-08-28 15:53:14.460
*** CLIENT ID:() 2013-08-28 15:53:14.460
*** SERVICE NAME:(SYS$USERS) 2013-08-28 15:53:14.460
*** MODULE NAME:(sqlplus@db42 (TNS V1-V3)) 2013-08-28 15:53:14.460
*** ACTION NAME:() 2013-08-28 15:53:14.460

Processing Oradebug command 'hanganalyze 3'

*** 2013-08-28 15:53:15.164
===============================================================================
HANG ANALYSIS:
  instances (db_name.oracle_sid): cedb.cedb2
  oradebug_node_dump_level: 3
  analysis initiated by oradebug
  os thread scheduling delay history: (sampling every 1.000000 secs)
    0.000000 secs at [ 15:53:14 ]
      NOTE: scheduling delay has not been sampled for 0.294437 secs    0.000000 secs from [ 15:53:10 - 15:53:15 ], 5 sec avg
    0.000000 secs from [ 15:52:15 - 15:53:15 ], 1 min avg
    0.000000 secs from [ 15:48:15 - 15:53:15 ], 5 min avg
===============================================================================

Chains most likely to have caused the hang:
 [a] Chain 1 Signature: 'log file parallel write'<='log file sync'
     Chain 1 Signature Hash: 0x9a625f43
 [b] Chain 2 Signature: 'log file parallel write'<='log file sync'
     Chain 2 Signature Hash: 0x9a625f43
 [c] Chain 3 Signature: 'log file parallel write'<='log file sync'
     Chain 3 Signature Hash: 0x9a625f43

===============================================================================
Non-intersecting chains:

-------------------------------------------------------------------------------
Chain 1:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 10456
              process id: 202, oracle@db42
              session id: 595
        session serial #: 44879
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6fa9
                      p2: 'sync scn'=0x6f01c17c
            time in wait: 1.268483 sec
           timeout after: never
                 wait id: 1777
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000143 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.001444 sec
                     wait id: 1776            p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000012 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000002 sec
                     wait id: 1775            p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000646 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.000828 sec
                     wait id: 1774            p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by
 => Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 11611
              process id: 28, oracle@db42 (LGWR)
              session id: 1653
        session serial #: 1
    }
    which is waiting for 'log file parallel write' with wait info:
    {
                      p1: 'files'=0x2
                      p2: 'blocks'=0x18
                      p3: 'requests'=0x2
            time in wait: 2.999912 sec
           timeout after: never
                 wait id: 309360511
                blocking: 6 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-read()+16<-kfk_block()+940<-kfk_transit_waitIO()+188<-kf
k_transitIO()+1739<-kfioWaitIO()+721<-kfioRequestPriv()+351<-kfioRequest()+706<-ksfd_kfioRequest()+649<-ksfd_osmbio()+438<-ksfdbio()+1487<-kcrfw_do_write()+98
8<-kcrfw_redo_write()+3449<-ksbabs()+771<-ksbrdp()+971<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+266<-ssthrdmain()+252<-main()+201<-__libc_start
_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000098 sec
              1.       event: 'LGWR wait for redo copy'
                 time waited: 0.000023 sec
                     wait id: 309360510       p1: 'copy latch #'=0x5
              * time between wait #1 and #2: 0.000009 sec
              2.       event: 'rdbms ipc message'
                 time waited: 0.001294 sec
                     wait id: 309360509       p1: 'timeout'=0x13
              * time between wait #2 and #3: 0.000040 sec
              3.       event: 'log file parallel write'
                 time waited: 0.000293 sec
                     wait id: 309360508       p1: 'files'=0x2
                                              p2: 'blocks'=0x2
                                              p3: 'requests'=0x2
    }

Chain 1 Signature: 'log file parallel write'<='log file sync'
Chain 1 Signature Hash: 0x9a625f43
-------------------------------------------------------------------------------

===============================================================================
Intersecting chains:

-------------------------------------------------------------------------------
Chain 2:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 12760
              process id: 102, oracle@db42
              session id: 2245
        session serial #: 1577
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6f9d
                      p2: 'sync scn'=0x6f01b311
            time in wait: 2.999925 sec
           timeout after: never
                 wait id: 52573
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000240 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.000985 sec
                     wait id: 52572           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000014 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000002 sec
                     wait id: 52571           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000820 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.000716 sec
                     wait id: 52570           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by 'instance: 2, os id: 11611, session id: 1653',
    which is a member of 'Chain 1'.

Chain 2 Signature: 'log file parallel write'<='log file sync'
Chain 2 Signature Hash: 0x9a625f43
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Chain 3:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 12762
              process id: 103, oracle@db42
              session id: 2304
        session serial #: 1077
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6fa9
                      p2: 'sync scn'=0x6f01b313
            time in wait: 2.999726 sec
           timeout after: never
                 wait id: 54709
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000175 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.000301 sec
                     wait id: 54708           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000033 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000003 sec
                     wait id: 54707           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000850 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.001152 sec
                     wait id: 54706           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by 'instance: 2, os id: 11611, session id: 1653',
    which is a member of 'Chain 1'.

Chain 3 Signature: 'log file parallel write'<='log file sync'
Chain 3 Signature Hash: 0x9a625f43
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Chain 4:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 12764
              process id: 104, oracle@db42
              session id: 2364
        session serial #: 44511
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6fa9
                      p2: 'sync scn'=0x6f01b314
            time in wait: 2.999371 sec
           timeout after: never
                 wait id: 52571
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000135 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.000313 sec
                     wait id: 52570           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000017 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000002 sec
                     wait id: 52569           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000906 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.000614 sec
                     wait id: 52568           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by 'instance: 2, os id: 11611, session id: 1653',
    which is a member of 'Chain 1'.

Chain 4 Signature: 'log file parallel write'<='log file sync'
Chain 4 Signature Hash: 0x9a625f43
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Chain 5:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 12766
              process id: 105, oracle@db42
              session id: 2425
        session serial #: 16133
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6fa9
                      p2: 'sync scn'=0x6f01b315
            time in wait: 2.998936 sec
           timeout after: never
                 wait id: 55819
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000141 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.000252 sec
                     wait id: 55818           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000013 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000002 sec
                     wait id: 55817           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000596 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.000944 sec
                     wait id: 55816           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by 'instance: 2, os id: 11611, session id: 1653',
    which is a member of 'Chain 1'.

Chain 5 Signature: 'log file parallel write'<='log file sync'
Chain 5 Signature Hash: 0x9a625f43
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Chain 6:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 2 (cedb.cedb2)
                   os id: 22034
              process id: 63, oracle@db42
              session id: 3720
        session serial #: 1513
    }
    is waiting for 'log file sync' with wait info:
    {
                      p1: 'buffer#'=0x6fa9
                      p2: 'sync scn'=0x6f01b3c4
            time in wait: 2.779358 sec
           timeout after: never
                 wait id: 32770
                blocking: 0 sessions
             current sql: <none>
             short stack: ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1876<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwai
tctx()+163<-kcrf_commit_force()+972<-kcbdsy()+44<-ksupop()+1090<-opiodr()+1008<-ttcpip()+2242<-opitsk()+1673<-opiino()+966<-opiodr()+916<-opidrv()+570<-sou2o(
)+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
            wait history:
              * time between current wait and wait #1: 0.000208 sec
              1.       event: 'SQL*Net message from client'
                 time waited: 0.001506 sec
                     wait id: 32769           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #1 and #2: 0.000011 sec
              2.       event: 'SQL*Net message to client'
                 time waited: 0.000002 sec
                     wait id: 32768           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
              * time between wait #2 and #3: 0.000845 sec
              3.       event: 'SQL*Net message from client'
                 time waited: 0.001030 sec
                     wait id: 32767           p1: 'driver id'=0x54435000
                                              p2: '#bytes'=0x1
    }
    and is blocked by 'instance: 2, os id: 11611, session id: 1653',
    which is a member of 'Chain 1'.

Chain 6 Signature: 'log file parallel write'<='log file sync'
Chain 6 Signature Hash: 0x9a625f43

Combine the ash report that there are more tan 20000 commit operations.  

Call Type                                     Count % Activity Avg Active
---------------------------------------- ---------- ---------- ----------
COMMIT                                       22,124      55.99      12.29
V8 Bundled Exec                              10,652      26.96       5.92
OAUTH                                         2,249       5.69       1.25
LOGOFF                                          584       1.48       0.32
          -------------------------------------------------------------

With the awr report top 5 event  

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
log file sync                       269,309      33,931    126   75.7 Commit
log buffer space                        104       5,424  52157   12.1 Configurat
buffer busy waits                     2,593       3,580   1381    8.0 Concurrenc
log file switch completion               24         892  37155    2.0 Configurat
DB CPU                                              888           2.0
^LHost CPU (CPUs:   64 Cores:   32 Sockets:    4)

The log file sync wait event which average wait time is 126ms is percent 75.7 of DB time. In order to reduce this wait event, it should modify the application software to reduce commit operation.

Kevin_ora
关注
专栏目录
Hudi Flink MOR 学习总结
主要分享大数据相关的知识，如Spark、Hudi
05-28 434
之前很少用MOR表，现在来学习总结一下。首先总结一下 compaction 遇到的问题。
【docker】安装redis和mysql生产实战
阿杰
11-23 463
docker安装诸如redis，mysql等程序非常方便，但是如果不是为了学习，生产环境的部署还是要注意很多问题的 redis 拉取镜像 创建映射目录 修改配置文件官网： https://github.com/redis/redis/blob/6.0.16/redis.conf下载对应本版的配置文件redis/redis.conf at 6.0.16 · redis/redis · GitHub（单独复制redis.conf或则将整个源码拉下来） 然后将配置文件放在上面创建的 /usr/docker/t
理解LGWR,Log File Sync Waits以及Commit的性能问题
09-07 2250
理解LGWR,Log File Sync Waits以及Commit的性能问题 一．概要： 1.  Commit和log filesync的工作机制 2.  为什么log file wait太久 3.   如何去度量问题出在那里呢？ 二．log file sync等待的原因 1.  默认情况下我们commit一个事务是要等待logfile sync,这其中包括： (1)User  c
2017-04-12 DBA日记，频繁commit导致的log file sync的诊断
IT匠人的专栏
04-12 1414
背景： 2017-04-11 19:20收到开发员反馈，在某库db1上执行update语句很快，但commit很慢，至少执行了5分钟commit都没有返回。 问题： 是什么原因导致commit被挂起/阻塞呢？ 分析： 1）当前正在运行什么后台作业呢？备份？还是之前发现的一个从18:00跑到21点的后台作业呢？ 2）确认备份完成时间，发现在18:51完成，不在本次
oracle commit_log,Oracle log file sync 等待事件 与 COMMIT_WAIT，COMMIT_LOGGING 参数说明
weixin_36349918的博客
04-11 737
在Oracle 数据库中，log file sync是一个非常常见的等待事件，导致该事件的原因主要有2个因素：一是commit提交过于频繁，二是redo log 对应的IO根不上。 所以对于log file sync等待事件我们通常考虑的是用SSD 来提升IO，增加online redo log 文件的大小，或者从业务侧降低commit频率。在MOS文章：RAC 环境中最常见的 5 个数据库和/或...
log file sync等待事件和log file parallel write等待事件
kiwi的专栏
05-08 3289
本文主要转载魏兴华大师的一篇帖子： http://www.itpub.net/thread-1807437-1-1.html
log file sync（ 日志文件同步）等待事件
鲨鱼胃的博客
05-09 4872
log file sync等待事件发生 log file sync等待事件发生在redo log从log buffer写入到log file期间。 在一个提交（commit）十分频繁的数据库中，一般会出现log file sync等待事件，当这个等待事件出现在top5中，这个时侯我们需要针对log file sync等待事件进行优化，一定要尽快分析并解决问题，否则当log file sync等待时间从几毫秒直接到20几毫秒可能导致系统性能急剧下降，甚至会导致短暂的挂起。 何时发生日志写入 1.commit或
互联网解决方案-文件存储方案：seafile真实案例
最新发布
纸上得来终觉浅，绝知此事要躬行
08-05 886
Seafile 是一款开源的企业云盘，注重可靠性和性能，支持全平台客户端。Seafile 内置协同文档 SeaDoc ，让协作撰写、管理和发布文档更便捷。它支持私有化部署，能够满足诸多文件协同的应用场景。 只提供真实案例！！！
MySQL主从不一致问题相关处理
热门推荐
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
09-26 1万+
某业务采取mysql的主从架构，但因为存储的问题，导致备库一直无法存储，数据同步一致性问题一直也未恢复，某次安全检查要求完成主备倒换演练，必须限期恢复主备，但是在恢复过程中，同步显示正常一段时间后，便会出现sql线程异常，主备数据不一致导致的同步错误情况。主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全。
semi-sync插件崩溃导致MySQL重启故障详析
老叶茶馆
09-22 1582
导读 semi-sync插件崩溃导致MySQL重启的故障分析全过程~ 作者：刘安 现为爱可生高级测试工程师，拥有丰富的自动测试开发经验；曾先后在文思海辉、Splunk担任测试工程师。 一、起因： 在公司测试MySQL高可用组件时发现一个异常。如下： 停止从库，高可用组件将从库自动启动后，主库发生了重启。然而，正常情况下，主库不应发生重启。 二、
LOG FILE SYNC概述（第二篇）
cotchte0421的博客
04-19 192
Commit做了什么？ commit与log file sync是息息相关的，在每次事务提交时，commit会触发增进系统的SCN（通过函数kcmgas），然后产生一个commit的改变向量被拷贝进lo...
log file sync等待事件
数据库
10-30 1548
概念： 1、REDO组件： redolog buffer=>位于SGA中，是一块循环使用的内存区域，保存数据库变更的相关信息并以重做条目redoentries形式存储,包含DML及DDL语句; LGWR=>通过此进程把redo buffer的内容写到redo log file中; redo log file=>(在归档模式下被ARC n最终写入归档日志)。最少两组重做日志，每组最少一个成员
故障排除："log file sync"等待
u010719917的专栏
07-23 3242
（这篇来自metalink一篇文章，在此引用做分享）       搜索: log file sync     故障排除："log file sync"等待 文档内容     用途     排错步骤      什么是'log file sync'等待事件？      用户应该搜集那些信息，来初步分析'log file sync'等待事件？      什么原因造成了很高的’lo
【DBA笔记】log file sync等待事件案例（一）
m0_55928215的博客
03-02 281
该参数效果显著且稳定，可逐步调整到log file sync压力比较大的库中并调整标准化建库手册/自动化任务。（3）待隐含参数效果明确后，逐步下发到所有oracle 11.2.0.3.0 及以上版本的数据库中，减少log file sync等待对性能的影响。（4）隐含参数导致进程调度模式变化有关系：_use_adaptive_log_file_sync。（2）调整_use_adaptive_log_file_sync参数为false。检查操作系统与数据库参数（若变更则影响较大，风险较高，方案待定）
Oracle-log file sync等待事件分析
sinat_36757755的博客
04-17 5550
Oracle-log file sync等待事件分析
红色警报 ORACLE RAC 11.2.0.4 FOR SOLARIS 10 ASM 和DB因集群心跳丢失重启
clm20482的博客
05-23 456
ORACLE RAC 11.2.0.4 FOR SOLARIS 10 ASM 和DB因集群心跳丢失重启。该问题是BUG 10194190 18740837 导致的，修复该问题需要打patch 25142...
一例log file sync
cimic1223的博客
05-15 623
os：rhel6.8 2.6.32-642.el6.x86_64 db：oracle 11.2.0.3.11 rac 今天早晨7点过在地铁上接到了数据库告警信息，当时没办法处理，打电话请运营的同事查看了下系统大概...
oracle 等待事件---log file switch
bestinter2010的博客
08-14 1070
当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的记录的信息（比如一些脏数据块产生的redo log）被写到磁盘上（checkpoint），这样做的原因是，如果一个在线日志文件的信息被覆盖，而依赖这些redo信息做恢复的数据块尚未被写到磁盘上（checkpoint），此时系统down掉的话，Oracle将没有办法进行实例恢复。当数据库日志文件发生切换时出现，LGWR需要关闭当前日志组，切换并打开下一个日志组，在这个切换过程中，数据库的所有DML操作都处于停顿状态，直至这个切换完成。
oracle lmhb进程,love wife love life —Roger的Oracle/MySQL数据恢复博客
weixin_42298878的博客
04-07 1007
前段时间某客户的一套核心系统Oracle RAC节点实例突然被重启，如下是简单的分析过程，供参考。节点1 alert log如下：Sun Aug 02 12:00:13 2015Archived Log entry 7156 added for thread 1 sequence 3618 ID 0x46c8ccfe dest 1:Sun Aug 02 14:06:13 2015LMS1 (osp...
"Can't initialize rotatable log file :: caused by :: Failed to open D:\\mongodb\\log\\mongod.log"
09-29
如果你遇到了"Can't initialize rotatable log file :: caused by :: Failed to open D:\\mongodb\\log\\mongod.log"的错误提示，这可能是因为程序无法打开指定路径下的文件。请确保指定的文件路径和文件名是正确的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值