软件设计与开发
民航气象数据库系统重做日志的在线调整
朱娜
(民航中南空管局气象中心气象信息室广东广州510740)
数事术与质用
摘要：笔者以在工作中经历的一次问题为例详细介绍在orace数据库运行过程中由于在线重做日志问题而导致应用系统大量实时数据无法正常入库的解决方法。关键调：民航气象数据库系统在线调整
中图分类号：TP
文献标识码：A
文章编号：1007-9416（2011)06-010001
中南地区气象数据库系统是以广州为地区中心，深圳、汕头、湛江、南宁、桂林、长沙、武汉、郑州、海口、三亚作为空管分局站组成的一套气象信息存储转发业务系统。作为地区中心，既与民航气象中心进行数据交换，又通过交换服务器对各分局航站进行数据分发。该系统运行在IBMP520服务器上，运行ORACLE10g数据库、IBM的MQ
中间件以及一些业务引用程序等。 1、问题发现
经过一段时间的运行以后，系统出现了大量实时气象资料无法正常进人气象数据库系统的现象，在排除了网络故障、AIX操作系统故障后，问题集中在()racle数据库响应缓慢，应用请求无法返回上。
检查数据库的alertZGGG.log文件，可见应用程序接收到新数据要进行数据库写操作的时候，一方面系统无法分配新的日志文件，另一方面checkpoint不能完成，造成频繁的日志切换，引起数据丢失；另外，登录数据库查询重做日志组的状态发现，日志组
除cument外都处于active状态。 2、解决方法
重做日志文件是Oracle数据库中一种非常重要的日志文件，它把对数据文件的修改在写人数据文件之前记求下来。日志文件以一种循环的方式被写人信息。当一个日志组被写满时，会自动向另～个日志组写入。只有在事务的请求被写到重微做日志后，请求才能被完成
当发生重做日志切换而生成一个新的检查点时，数据库日志写进程LGWR等待数据库写进程DBWR写脏缓冲器块，如果经常发生checkpointcannotcomplete的警告，一方面是LCWR等待 checkpoint完成，另一方面，是loghuffer里面的东西无法写到到当前的redolog文件中，所以新的DMI.无法把redo信息写到Logbuffer 里面，导致实例单面所有的DML/DDL都无法继续。
首先通过下列语旬检查系统联机目志大小以及日志状态 SQL> select group#,status,member from vSlogfile
SQL>select * from vslog; SQL>host
oracle@ZGGGEXCH &ed /u0/oracle/oradata/ZGGG oracle@ZGGGEXCH Sls 1
上述命令执行后可知，系统自动分配的3个联机日志文件 redo01.log、redo02.Jog、redo03.log，每个文件大小为50M。现在要在业务不停止的情况下，将联机日志文件redo01.log、redo02.log、 redo03.log扩大到200M，解决影响系统性能的瓶须。
(1)首先创建中间过渡日志文件mdlo04Jog、redn05.log、rod06Jog：
SQL> alter database add logfile group N*uO/oracle/oradtata/ZGGG /redoON.log'
size200M
此处N分别为4.5、6.命令执行完毕后，在/u0/oracleloradata/ ZCGC求下同时创建3个文件rrdo04.log、mrlo05.lng和redo06.log。
(2)分别强制进行日志切换，将旧的联机日志文件切换到新建立的日志文件上，保证以前旧的日志文件处于inactive状态：
SQL> alter system switch logfile;
使用下列语句确认日志已经被强制切换到新建的日志文件上，3个旧的联机日志状态为inactive
SQL> srlect group,status from v$log;
(3)分别删除旧的redo01.log、redo02.log、redo03.log： G100
方方数据
SQL> alter database drop logfile group N; N分别为1、2、3
当重做日志文件被删除后，相关的操作系统文件也被删除，数据库控制文件也被更新。现在系统使用redo04.log、redo05.log、 redo06.log作为联机日志文件。
为了不引起以后数据库系统管理的混乱，现在再分别增加各 200M大小的新的日志文件redo01.log、redo02.log、redo03.log，将第一步创律的中间过度文件替换：
SQL> alter datahase add logfile group N
'/u0/oracle/oradata/ZGGG/redo0N.log’ size 200M 此处N分别为1、2、3
(4)再次强制进行日志切换，将日志文件组切换到新建立的日志文件redo01.log、redo02.log、redo03.log上：
SQL> alter system switch logfile;
(5)通过检查数据字典表，验证日志组目前使用情况：
SQL> select group#,status from vSlog GROUP#STATUS
1INACTIVE 2CURRENT 3UNUSED 4INACTIVE 5INACTIVE 6 INACTIVE
通过显示结果可见，强制日志切换以后，第一步创建的4、5、6号
日志文件已经处于inartive状态，这样就可以把它们删除了。
(6)删除中间过渡4、5、6号日志文件：SQL>alterdatabasedrop logfilegroupN;N分别为4、5、6。
至此，重做日志组的在线调整完毕，数据库的重做日志文件由原来的50M在线扩大到200M。
(7)检查alertZCGG.log文件，观察是否出现检查点没完成或者
不能分配新的日志文件的错误。 3、总结与改进
本例所示的数据库运行瓶颈问题可以通过增加在线日志文件大小、增加在线日志文件数量或者增加更快的磁盘1/0来解决，考虑到数据库岩机对用户造成的影响，笔者使用了最快速的在线扩大联机日志的方法，完成此次性能调整。
通过使用中间日志文件的方法在线扩大联机日志大小，经过长时间运行观察，oracle日志文件记载的日志切换的时间已经从原来的最短的20秒左右一次变为45分钟左右一次，不再出现 cannot allocate newlog以及Checkpoint not eomplete的错误，并且运行过程中应用程序对数据库的写库操作恢复正常。
Oracle数据库性能调优是一个慢慢学习研究的过程，尤其在运行
的生产系统上进行在线参数的修改更加需要考虑到可能起的意外需要数据库管理员对知识的熟练掌握，还需要管理者的耐心和毅力。