【每日一摩斯】-LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4

LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4 Database (文档 ID 601316.1)

LGWR的trace日志中记录:

Warning: log write time 540ms, size 5444KB
*** 2008-05-14 10:19:02.686
Warning: log write time 1470ms, size 5533KB
*** 2008-05-14 10:19:03.546
Warning: log write time 860ms, size 2230KB
*** 2008-05-14 10:23:04.183
Warning: log write time 2940ms, size 5701KB
*** 2008-05-14 10:23:05.758
Warning: log write time 1580ms, size 4234KB
*** 2008-05-14 10:23:07.559
Warning: log write time 1800ms, size 5701KB

这是Warning信息,在10.2.0.4中,Oracle规定如果log write的时间大于500ms,就会记录到LGWR的trace日志中。

官方建议的解决方法是:

这是警告信息,意味着日志写进程没有像预期那样快。所以你可能需要检查是否因为潜在的OS问题导致磁盘变慢。如果硬件或OS级别都没有问题,例如就是因为它自己的特性导致环境不能提供较快的服务,完全可以忽略这种报错信息,删了这个trace文件就行了。

同样有人也开了一个defect:Bug 7559549 : TRACES GENERATED CONTAIN WARNING: LOG WRITE TIME 1330MS, SIZE 168KB

类型 B - Defect 
严重性 2 - Severe Loss of Service 
产品版本 10.2.0.4.0 
状态 92 - Closed, Not a Bug 
平台 212 - IBM AIX on POWER Systems (64-bit) 
基本 Bug N/A 
影响平台  Generic 
WORKAROUND:-----------No workaround.

补充下:

1、LGWR的trace日志路径在bdump中。(bdump主要保存一些后台进程的trace日志,b代表background)。

2、eygle也曾在自己的blog中记录过这个问题:http://www.eygle.com/archives/2009/11/log_write_time.html

也指出有可能是IO存在问题,引起写缓慢。如果认为硬件没有问题就行。

时间: 2024-10-25 13:38:28

【每日一摩斯】-LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4的相关文章

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列3

LGWR & DBWR 这两个进程通常是和IO相关的,但是当存在操作系统问题,这两个进程可能"spin(等待)"直到IO操作完成.这种等待是一种CPU操作.异步IO操作的缓慢或失败也能证明它们是高CPU消耗的. 如果LGWR间歇地占用100%的CPU资源,那么异步输入输出AIO配置应该重新检查.作为一种临时性的方法,可以设置下面的参数防止LGWR出现等待的现象: _lgwr_async_io=false 这个参数可以关闭LGWR的异步输入输出. Note: 813473.1 L

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列6

如果问题是一个正运行的缓慢的查询SQL,那么就应该对该查询进行调优,避免它耗费过高的CPU资源.如果它做了许多的hash连接和全表扫描,那么就应该添加索引以提高效率. 下面的文章可以帮助判断查询的问题: Note:215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL Note:199083.1 Master Note: SQL Query Performance Overview 实时SQL监控是11g的一个新特性,它能监控正运

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列4

Jobs (CJQ0, Jn, SNPn) Job进程运行用户定义的以及系统定义的类似于batch的任务.检查Job进程占用大量CPU资源的方法,就像检查用户进程一样. 可以根据以下视图检查Job进程运行的状态:DBA_JOBS_* , DBA_SCHEDULER_*, DBA_AUTOTASK_*. 这些进程可能会消耗大量的CPU资源,因为他们无限循环地查询job队列. Note: 8531434.8 Bug 8531434 - Solaris: Excessive CPU by MMNL/C

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列1

这篇文章的目的是帮助寻找消耗CPU较高的Oracle进程. 高CPU应用不一定就是问题,或者说系统资源正在被充分利用.然而,如果CPU使用持续高,但系统负载低.系统性能差,那么就应该调查下CPU高使用率的原因.特别地,如果一个或多个进程持续是以其它进程为代价,持续消耗CPU资源,那么就应该调查这个CPU进程.除了为解决一些问题来收集的信息,几乎没有办法停止这些进程消耗CPU资源.另一方面,我们可以防止这种情况的发生.Oracle提供了两种方法限制个人用户使用的CPU资源: Profiles  N

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列2

当一个进程使用大量CPU资源时,需要查找哪些线索呢? 哪些进程在使用CPU? 后台进程 Oracle用户进程 和Oracle无关的操作系统进程 僵尸进程 后台进程: PMON: 当清理进程或在监听注册时,PMON进程占用CPU较高资源的主要原因可能是某个BUG. SMON: SMON进程负责空间整合与交易恢复,如果使用的是字典管理表空间,那么可能会产生巨大的消耗. 字典管理表空间中,如果一个包含很多extent区的大表被drop或truncate,SMON能让数据库hang住. 从9i开始,本地

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列5

Oracle(用户)进程 以下这些操作都是需要消耗大量CPU资源的:解析大型查询,存储过程编译或执行,空间管理和排序. 下面这几篇文章可以帮助采集关于使用高CPU资源的进程的更多信息: Note:352648.1 How to Diagnose High CPU Usage Problems to the Module Level  Note:452358.1 How to Collect Diagnostics for Database Hanging Issues 补充:Oracle用户进程

【每日一摩斯】-RAC and Sequences (853652.1)

序列有四种组合: a. CACHE + NOORDER b. CACHE + ORDER c. NOCACHE + NOORDER d. NOCACHE + ORDER 即使在单例配置下,当有大量的sequence需要产生的时候,性能压力和存储sequence值的行锁定代价相关. NOCACHE与CACHE的性能       当使用cache时,dictionary cache(row cache)仅仅当出现新的水位线时才会更新一次.例如当cache是20,nextval第一次请求时,dicti

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列4

CURSOR_SHARING 参数 (8.1.6 以上)        这个参数需要小心使用.如果它被设为FORCE,那么Oracle会尽可能用系统产生的绑定变量来替换原来SQL中的literals部分.对于很多仅仅是literal不一样的相似的语句,这会让它们共享cursor.这个参数可以在系统级别或者session级别动态设置: ALTER SESSION SET cursor_sharing = FORCE; 或者 ALTER SYSTEM SET cursor_sharing = FOR

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列5

Flushing(清空) SHARED POOL        在使用大量literal SQL的系统中,shared pool随时间推移会产生大量碎片进而导致并发能力的下降.Flushing shared pool能够使得很多小块碎片合并,所以经常能够在一段时间内恢复系统的性能.清空之后可能也会产生短暂的性能下降(补充:因为需要做第一次的硬解析),因为这个操作同时也会把没造成shared pool碎片的共享SQL也清除了.清空shared pool的命令是: ALTER SYSTEM FLUS