ORACLE宕机日志分析

[xiaozhang8383]

我们的ORACLE经常在半夜宕机，几次宕机的错误日志都是一样：
alert 日志内容如下：
Tue Apr 13 22:44:02 2010
Errors in file /oradata/admin/topprod/bdump/topprod_ckpt_2736222.trc:
ORA-00206: error in writing (block 3, # blocks 1) of control file
ORA-00202: control file: '/oradata/oradata/topprod/control03.ctl'
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: 8
Tue Apr 13 22:44:02 2010
Errors in file /oradata/admin/topprod/bdump/topprod_ckpt_2736222.trc:
ORA-00221: error on write to control file
ORA-00206: error in writing (block 3, # blocks 1) of control file
ORA-00202: control file: '/oradata/oradata/topprod/control03.ctl'
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: 8
Tue Apr 13 22:44:02 2010
CKPT: terminating instance due to error 221
Termination issued to instance processes. Waiting for the processes to exit
Tue Apr 13 22:44:12 2010
Instance termination failed to kill one or more processes
Instance terminated by CKPT, pid = 2736222

.trc日志内容如下：
*** 2010-03-10 22:33:39.975
*** SERVICE NAME:(SYS$BACKGROUND) 2010-03-10 22:33:39.673
*** SESSION ID:(1649.1) 2010-03-10 22:33:39.673
ORA-00206: error in writing (block 3, # blocks 1) of control file
ORA-00202: control file: '/oradata/oradata/topprod/control03.ctl'
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: 8
error 221 detected in background process
ORA-00221: error on write to control file
ORA-00206: error in writing (block 3, # blocks 1) of control file
ORA-00202: control file: '/oradata/oradata/topprod/control03.ctl'
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: 8
*** 2010-03-10 22:33:49.993
Instance termination failed to kill one or more processes
ksuitm_check: OS PID=3080572 is still alive
*** 2010-03-10 22:33:49.993
Dumping diagnostic information for oracle@hlerp01 (PSP0):
OS pid = 3080572
loadavg : 2.37 2.67 2.63
swap info: free_mem = 761.10M rsv = 33.00M
alloc = 6296.27M avail = 8448.00M swap_free = 2151.73M
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
250004 Z oracle 3080572 1 0 60 20 0:00 <defunct>
open: The file access permissions do not allow the specified action.
procstack: 3080572 is a kernel process
*** 2010-03-10 22:33:51.400
在网上查了很多相关内容都无果，咨询了很多高手也没有得到一个确切的回答。
把我这点分全献出去，希望大伙能给点帮助！！！

[kingkingzhu]

同意 一般来说控制文件一旦出错 就会报错 不会时好时坏 但是日志提示指向控制文件了
所以我怀疑连接硬盘问题
有什么看法和解决方法在这里说说嘛 大家都学习学习

[liuyi8903]

所以要看看 kernel的设置情况 啊。

lsattr -El sys0
lsattr -El aio0


没看到吗？

[liuyi8903]

oracle和aix的版本是多少？

另外，你的vmo设置情况 怎么样？




lsattr -El sys0
lsattr -El aio0

[liuyi8903]

楼上们不要乱说，会出事的。晕。还说重建控制文件。

[liuyi8903]

楼主如果搞不定可以发到我邮箱[e-mail]

[moon&sean]

应该是ORACLE控制文件的问题，可以首先尝试（这个其实你不用担心，因为三个控制文件都是一摸一样的，所以即使你删除掉也没事。）：
alter system set control_files=
'/oradata/oradata/topprod/control01.ctl',
'/oradata/oradata/topprod/control02.ctl'
SCOPE=spfile;
这样将03控制文件排开，此时直接重启也可（因为控制文件2个也可以跑，都是一样的内容相互备份）


如果必须需要第三个控制文件（上述步骤忽略），在关闭数据库的情况下，先将第三个控制文件删除掉，然后将第一个控制文件拷贝重命名为第三个控制文件的名称同名即可，但是还需要重启一次。

[jdsnhan]

又是异步IO，这个问题曾经把我郁闷够呛。
这是我的经历：
http://topic.csdn.net/u/20091207/22/fdd4ba6e-0365-4b91-872a-8a2e22f63594.html
已解决。
还有一种方法，
smit aio
选择 Change / Show Characteristics of Asynchronous I/O
把 Maximum number of REQUESTS 这个值加大，40960，重启AIX，也可以。

[jdsnhan]

[Quote=引用 10 楼 andkylee 的回复:]
引用 8 楼 liuyi8903 的回复:

楼主如果搞不定可以发到我邮箱[e-mail]


别人都不对， 就你会？？？？？？
[/Quote]

谦虚谨慎的作风，才能让我们走的更远。

[inthirties]

[Quote=引用 13 楼 liuyi8903 的回复:]

所以要看看 kernel的设置情况 啊。

lsattr -El sys0
lsattr -El aio0


没看到吗？
[/Quote]

对Aix不了解，liu兄你这里是担心是异步IO导致的问题么。

[傻儿哥]

关注下。。。

[liuyi8903]

aio相关

[liuyi8903]

看情况，另外40960也太大了，不必要。首先要排除aio的问题。

另外，你的aix的版本。

[xiaozhang8383]

#18楼的兄弟：

还有一种方法，
smit aio
选择 Change / Show Characteristics of Asynchronous I/O
把 Maximum number of REQUESTS 这个值加大，40960，重启AIX，也可以。

这样真的可以吗？？？

[jdsnhan]

[Quote=引用 20 楼 xiaozhang8383 的回复:]
#18楼的兄弟：

还有一种方法，
smit aio
选择 Change / Show Characteristics of Asynchronous I/O
把 Maximum number of REQUESTS 这个值加大，40960，重启AIX，也可以。

这样真的可以吗？？？
[/Quote]

呵呵，实践是检验真理的唯一标准，改了后，重启AIX，然后看效果吧。

这个方法不是oracle的，是IBM的。嘿嘿。

[jdsnhan]

[Quote=引用 21 楼 liuyi8903 的回复:]
看情况，另外40960也太大了，不必要。首先要排除aio的问题。

另外，你的aix的版本。
[/Quote]

AIX6.1以后就没smit aio的命令了。他那个问题出在5.3上居多

[liuyi8903]

jsdnhan你们开始用6.1了？

[jdsnhan]

[Quote=引用 24 楼 liuyi8903 的回复:]
jsdnhan你们开始用6.1了？
[/Quote]

恩。后续的550,570都是6.1 虽然有人说不是特别稳定，但目前，还没出啥问题。

[liuyi8903]

嗯，不错的说。上RAC了吗？

[xiaozhang8383]

回帖的兄弟们，我上次重建控制文件后至今还没出现问题；但是不知道是否真的是这个原因，看来这个贴子短期节不了了，如果以后没再出问题那就真是控制文件的事儿了。分数给大家平分了。
如果问题依旧反复，就只能按“jdsnhan”兄弟提供的办法打补丁了。那分都归你了。
多谢大伙儿捧场！！！

[Peter_Ray]

kao，这个贴子也太离谱了