前天用户突然反映一个软件总是报ora-00603错误。一开始一位就是个普通的表空间不足之类的，可是一看日志却发现不是那么简单。
截取部分日志如下：
Thu Nov 05 15:28:53 2009
Errors in file d:\oracle\admin\orcl\udump\orcl_ora_4684.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
ORA-01114: IO error writing block to file 11 (block # 42773)
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
里面的File 11就是我的那个程序使用的表空间的一个数据文件。表空间总共有四个数据文件加起来8G左右，总体使用率在70%左右。数据文件号分别为9，11，13，14。出问题的文件号不一定，时间也是随机的，有可能一分钟就会重复上面那段日志，有可能几秒就重复一次。
下面是orcl_ora_4684.trc文件的片段：
JServer Release 9.2.0.1.0 - Production
Windows 2000 Version 5.2 Service Pack 2, CPU type 586
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 30
Windows thread id: 4684, image: ORACLE.EXE
*** SESSION ID:(39.280) 2009-11-05 15:28:52.000
*** 2009-11-05 15:28:52.000
ksedmp: internal or fatal error
ORA-01114: 将块写入文件 11 时出现 IO 错误 (块 # 42773)
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
ORA-01114: 将块写入文件 11 时出现 IO 错误 (块 # 42773)
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
ORA-01114: 将块写入文件 11 时出现 IO 错误 (块 # 42773)
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
Current SQL statement for this session:
INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_ksedmp+147 CALLrel _ksedst+0
..1.44_7.except.114 CALLrel _ksedmp+0 3
+fc
..1.1_3.except.34+a CALLrel _ksupop+0 2
f
_ttcpip+a86 CALLreg 00000000 5E 14 8ACE738 0
_opitsk+2f4 CALLrel _ttcpip+0
_opiino+5fc CALLrel _opitsk+0 0 0 A616320 6D1F564 C2 0
_opiodr+4cd CALLreg 00000000 3C 4 8ACFBD8
_opidrv+233 CALLrel _opiodr+0 3C 4 8ACFBD8 0
_sou2o+19 CALLrel _opidrv+0
_opimai+10a CALLrel _sou2o+0
_OracleThreadStart@ CALLrel _opimai+0
4+35c
7C824826 CALLreg 00000000
从这个日志中看，“Current SQL statement for this session:
INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”这句话说明了是在执行“INSERT INTO "VIO_JDCZP" ("XH","HPHM","HPZL","PHOTO1") VALUES (:1,:2,:3,:4) RETURNING ROWID into :5”这句话时出的问题，而且说有的错误都是这样。这句话是将一个图片写入数据库。
软件是CS结构的，总共有八个客户端。八个客户端每3秒录入一条数据，数据包括一些文本类的信息还有就是有一张图片，图片大小在80KB至200KB不等。图片是直接存入数据库中的。
现在是单个用户录入时不会出现问题，八个用户一起录入时很快就会出现这个问题。查了oracle的参数，没有用户数方面的限制和Session的限制。
现在就是觉得奇怪了，ORACLE是大型数据库，不可能会出现这种类似于并发访问的问题的。从日志简单的分析上来看是一个用户数据写入未完成时另一个用户写入数据造成数据文件被占用造成的。程序里试验过，使用事务和不使用事务结果是一样的，基本上可以排除事务将文件给锁住的原因。
两个解决方法：
1 将数据库升级到9.2.0.1以上，不是一定得用10G之类的，升级成9.2.0.3或更高的，当然越高越好。
2 图片不写入数据库，存成文件之类的。
老外的解决问题的方法：
The solution is (as proposed on this thread):
alter system set events '10046 trace name context off';
alter system set timed_statistics=false;
执行完这两条脚本，问题果然解决。
注：
timed_staticstices 用于启动或禁止对定时统计信息（如CUP时间、占用时间），以及动态性能表中多种统计信息的收集功能。
ORA-00603错误解决过程
今天在查看job运行情况时，发现一同步数据的job执行了很长时间，但也没有出现异常记录。手动执行之后出现ORA-00603错误，解决过程如下：
1.插入操作报ORA-00603错误，上网搜索说是temp空间不够，但实际用户所用的临时表空间不是系统的temp空间，而自定义的临时表空间大小也没超出，尝试添加datafile还是解决不了问题。
2.考虑到插入的语句是通过dblink访问远程数据库，可能存在数据量过大的原因，尝试只执行一条插入语句，然后就commit，但只执行一条commit语句也出错，而且程序一直处于停滞状态。
3.排除数据量过大的原因，因为有类似的表也是通过dblink同步远程数据，怀疑是个别表出问题了，于是注释对某个表的插入代码后程序通过，没有报错，锁定目标为表结构或数据出问题。
4.查看alert文件，发现如下错误：
Following on-commit snapshots not refreshed :IMS.V$AGENT_INCORRECT_INFO，看到这个信息就明白了。原来是materialized 视图在自动同步更新数据时失败，因为原表执行了大批量的插入操作，而且数据量较大。同时还要更新视图，导致数据写入堵塞。而materialized 视图是昨天才建立的，改成demand方式更新materialized视图即解决问题。
喜欢 
顶
难过
囧
围观
无聊
