转自：http://space.itpub.net/?uid-9253450-action-viewspace-itemid-281058

最近在开发emes系统过程中发现查询很慢，经常点一个查询，但没有结果返回，调试发现在.net的查询语句处停了，也不报错。点了几次发现没结果。查询一下死锁的session，惊奇的发现我竟然有好几个session在等待。将aspnet进程杀掉，再查询就没有了。不知道什么原因，以为是我客户端问题。

SELECT o.object_name, s.USERNAME, s.OSUSER, s.MACHINE, s.TERMINAL, s.PROGRAM
FROM v$locked_object l, dba_objects o, v$session s
WHERE l.OBJECT_ID = o.object_id
AND l.SESSION_ID = s.SID;

后来忽然听到好几个同事也抱怨数据库太慢，于是就想看看到底怎么回事。首先想看看alert.log。因为只有数据库帐号，没有OS server帐号，所以没办法直接查看alert.log文件。于是想起利用外部表来间接查看alert.log。还好开发帐号权限够大。

-- Create directory
create or replace directory BDUMP
as '/erptest2/ora10/10.2.0/admin/mestst/bdump';

CREATE TABLE "MES"."ALERT_LOG"
   ( "LOG_LINE" VARCHAR2(100),
"SEQ" NUMBER(13,0)
   )
   ORGANIZATION EXTERNAL
    ( TYPE ORACLE_LOADER
      DEFAULT DIRECTORY "BDUMP"
      ACCESS PARAMETERS
      ( records delimited by newline            )
      LOCATION
       ( 'alert_mestst.log'
       )
    )
   REJECT LIMIT 1000000000;

CREATE OR REPLACE FORCE VIEW "MES"."V_ALERTLOG" ("SEQ", "LOG_LINE") AS
select rownum seq, log_line from alert_log
;

查询alert.log最近的记录，

SELECT * FROM v_alertlog ORDER BY seq DESC ;

其中出现最多的语句是： Checkpoint not complete。这是Redo log大小过小。同时也发现log几乎是2-4分钟切换一次。

查看log状态，果然除了current外，其他日志的状态都是ACTIVE。再查看三个Redo log大小，只有50M。显然是日志过小，于是增加三个大小为500M的日志组，等原来三个日志组变成INACTIVE后，将其DROP掉。

ALTER DATABASE ADD LOGFILE '/erptest2/ora10/meststdata/redo05.dbf' SIZE 500M;

ALTER DATABASE ADD LOGFILE '/erptest2/ora10/meststdata/redo06.dbf' SIZE 500M;

ALTER DATABASE ADD LOGFILE '/erptest2/ora10/meststdata/redo07.dbf' SIZE 500M;

ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 2;
ALTER DATABASE DROP LOGFILE GROUP 3;

alter database backup controlfile to trace resetlogs

总结：
此次数据库主要问题就是日志文件过小。解决方法也就是扩大日志文件，是Oracle 10g OCP中很基础的一个操作。

ITPub博客

checkpoint not complete

最新文章