1. Errors in file /u01/app/oracle/admin/oral/bdump/lgwr_800.trc:
ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900], [], [], []
LGWR: terminating instance due to error 600

2.Errors in file /u01/app/oracle/admin/oral/bdump/ora_908.trc:
ORA-00600: internal error code, arguments: [12235], [], [], [], [], [], [], []
Wed Jan 12 18:31:22 2005

你可以看管理版的精华区帖子。

谢谢帮忙，
只是链接帖子中的600错误的参数和我遇到的不一样
可能会是不一样的原因吧

看看这个

Problem Description:
==================== ORA-00600 [2103] during peak processing period Problem Explanation:
==================== The controlfile "enqueue" could not be acquired after waiting for a specific time period. The default is for 15 minutes (900 seconds). At times the database immediately abended after the error. At other times, that database would receive multiple ORA-600 [2103] [900] errors before abending. Search Words:
============= IBM AIX async I/O IO CKPT checkpoint timeout OS hardware Solution Description:
===================== Contact your OS hardware vendor to check on I/O performance. Also check for any hardware errors. Solution Explanation:
==================== If you are experiencing this problem on an IBM AIX (319 or 610) platform, check out IBM patch 81863. If you are on a generic platform, this is still an OS or hardware issue. The I/O is simply too slow to complete the CKPT process that is holding the enqueue. Hardware failures or slow disk writes will cause the default timeout interval of 900 seconds (15 minutes) waiting for the controlfile enqueue to be reached and the instance will crash. The workaround of increasing the parameter _controlfile_enqueue_timeout to a value greater than 900 may avoid the error if the writes are merely slow, but not completely stopped. This problem is normally seen during peak processing periods when you have a lot of database files to checkpoint. Even if you have a lot of files in your database, the default timeout period of 15 minutes should be sufficient. For example if you have 1,000 datafiles and the CKPT process is exceeding 15 minutes, then it amounts to close to 1 second per file. This is a completely unreasonable response time from the disk drives with today's disk speeds. In all cases, when encountering this error, you should contact your OS hardware vendor, as this is not considered as an Oracle bug and the hardware should be evaluated. When Asynchronous I/O is used, there may also be an O/S patch required, so customers should consult their O/S vendor when these errors are encountered. The following suggestions will help, if it is impossible to improve your I/O performance on the hardware. 1. Determine if async I/O is in use in any form. Do not use multiple db writers when async I/O is used. 2. Use multiple DB writers if async I/O is not allowed on the device. 3. Tune redo logs and the checkpoint process to reduce the frequency of encountering this problem. Lastly, check out [BUG:700416] ARCH OR DBWR PERIODICALLY CRASHES DB WITH ORA- 600 [2103] to increase the timeout period. Please note use of any underscore parameter is not recommended. References ========== 1. The following are port specific. PR:1058389.6: IBM AIX 4.3:ORA-00600 [2103] TIMEOUT ON CONTROLFILE ENQUEUE APPLY IBM PATCH IX 81863

谢谢了

第一个前面的人说的很详细了，由于控制文件在900秒内没写入导致的。升级到.5就可以解决 。
第二个600 【12235】这个直接忽略好了，在操作系统里面输入oracle就会发生，无关痛痒的一个600

学习