数据库遇ora-600异常宕机，无资料可查，请刘大帮忙分析....

yshappy

刘大，你好！
    公司的数据库在2013年12月29日9点28分，遭遇ora-600错误，导致异常宕机，之后9点42分才把数据库节点启动起来。在做宕机分析时候，发现在metlink和互联网上并没有发现有用信息。我把数据库日志相关信息打包上传了，麻烦帮忙一起分析一下宕机原因和预防措施，谢谢了。

宕机日志如下
Sun Dec 29 09:13:23 2013
ARCH: Evaluating archive   log 5 thread 1 sequence 204192
ARCH: Beginning to archive log 5 thread 1 sequence 204192
Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/1_204192.dbf'
Sun Dec 29 09:13:23 2013
ARC1: Evaluating archive   log 5 thread 1 sequence 204192
ARC1: Unable to archive log 5 thread 1 sequence 204192
      Log actively being archived by another process
Sun Dec 29 09:13:23 2013
ARCH: Completed archiving  log 5 thread 1 sequence 204192
Sun Dec 29 09:15:35 2013
Starting control autobackup
Control autobackup written to SBT_TAPE device
        comment 'API Version 2.0,MMS Version 9.0.0.84',
        media 'V01763L3'
        handle 'c-3618287844-20131229-0d'
Sun Dec 29 09:28:14 2013
Errors in file /oracle/app/oracle/admin/acct/udump/acct_ora_3408330.trc:
ORA-00600: internal error code, arguments: [kglsim_pinhp1], [0x7000015C1B84DA0], [], [], [], [], [], []
Sun Dec 29 09:28:20 2013
Errors in file /oracle/app/oracle/admin/acct/udump/acct_ora_3408330.trc:
ORA-00600: internal error code, arguments: [kglsim_chginv1], [6], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kglsim_pinhp1], [0x7000015C1B84DA0], [], [], [], [], [], []
Sun Dec 29 09:28:23 2013
Errors in file /oracle/app/oracle/admin/acct/udump/acct_ora_3408330.trc:
ORA-00600: internal error code, arguments: [kglsim_chginv1], [6], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kglsim_chginv1], [6], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kglsim_pinhp1], [0x7000015C1B84DA0], [], [], [], [], [], []
Sun Dec 29 09:28:28 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_pmon_1282890.trc:
ORA-00600: internal error code, arguments: [kglsim_chginv1], [6], [], [], [], [], [], []
Sun Dec 29 09:28:31 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_pmon_1282890.trc:
ORA-00600: internal error code, arguments: [kglsim_chginv1], [6], [], [], [], [], [], []
Sun Dec 29 09:28:31 2013
PMON: terminating instance due to error 600
Sun Dec 29 09:28:32 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_lgwr_1565342.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Sun Dec 29 09:28:32 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_dbw6_2094496.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Sun Dec 29 09:28:33 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_dbw2_1548332.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Sun Dec 29 09:28:33 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_dbw5_2032446.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Sun Dec 29 09:28:33 2013
Errors in file /oracle/app/oracle/admin/acct/bdump/acct_dbw1_2160606.trc:
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Instance terminated by PMON, pid = 1282890
Sun Dec 29 09:42:06 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
   

数据库服务器环境为：aix5.3，单实例数据库 9.2.0.6.0
环境如下
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
ORACLE_HOME = /oracle/app/oracle/product/9.2.0
System name:        AIX
Node name:        P595C_ACCT_DB
Release:        3
Version:        5
Machine:        00CC2BF54C00
Instance name: acct
Redo thread mounted by this instance: 1

Liu Maclean(刘相兵

ORA-00600: internal error code, arguments: [kglsim_pinhp1], [0x7000015C1B84DA0], [], [], [], [], [], []
No current SQL statement being executed.
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
7000015efce0040        62  function COMM.F_GET_VALID_BALANCE
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               1028CFE8C ?
ksfdmp+0018          bl       01FD80B0            
kgerinv+00e8         bl       _ptrgl               
kgesinv+0020         bl       kgerinv              0D47F0DE0 ? 7000015327453A8 ?
                                                   000003A97 ? 7000015327453B0 ?
                                                   70000152C4675F0 ?
kgesin+003c          bl       kgesinv              0000004E0 ? 70000152AC04658 ?
                                                   700001532743E10 ? 00000000D ?
                                                   000000000 ?
kglsim_pin_simhp+01  bl       kgesin               110005EB0 ? 1103DB288 ?
38                                                 1028CEE78 ? 100000001 ?
                                                   000000002 ? 7000015C1B84DA0 ?
                                                   12E0BE826D694B2F ?
                                                   000000000 ?
kglsim_upd_newhp+07  bl       kglsim_pin_simhp     7000009FDA7D890 ? 110005EB0 ?
e0                                                





kglsim_upd_newhp => kglsim_pin_simhp

yshappy

刘大，请教你个问题。
这个数据库一直都存在共享池碎片化严重的问题，平时只能在通过扩大共享池和重启数据库的方法缓解共享池碎片的情况。
这次宕机原因是否和共享池碎片化有直接关系，还是和function COMM.F_GET_VALID_BALANCE的问题导致宕机的？
我把function COMM.F_GET_VALID_BALANCE发上来，麻烦你帮忙分析一下，谢谢了。