转自: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 backup controlfile to trace resetlogs |
总结:
此次数据库主要问题就是日志文件过小。解决方法也就是扩大日志文件,是Oracle 10g OCP中很基础的一个操作。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12778571/viewspace-468434/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12778571/viewspace-468434/