ora-00600: internal error code, arguments: [KGHLKREM1], [0x838000020], [], [], [], [], [], [], [], [ - 数据库编程

rently logged on

Enter user-name:
ERROR:
ORA-01017: invalid username/password; logon denied

SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus

尝试两次都提示一样的错误，无法登陆，看来数据库服务当掉了，看来只能重启数据库了，ORA-01075的错误一般是磁盘空间不够或审计原因，但我检查我的环境不是这两种原因，所以使用os命令kill进程，使用如下两个命令

1. $ ps -ef |grep $ORACLE_SID|grep -v grep|awk '{print $2}' | xargs kill -9 //kill进程
2. $ ipcs -m | grep oracle | awk '{print $2}' | xargs ipcrm shm //删除掉oracle的共享段

先查看需要kill的进程
[oracle@skate01 ~]$ ps -ef |grep $ORACLE_SID|grep -v grep |grep -v avahi

kill的进程
[oracle@skate01 ~]$ ps -ef |grep $ORACLE_SID|grep -v grep |grep -v avahi |awk '{print $2}' | xargs kill -9

如果只kill掉oracle进程，还是无法登陆oracle

查看删除的共享段
[oracle@skate01 ~]$ ipcs -m | grep oracle | awk '{print $2}'

删除共享段
[oracle@skate01 ~]$ ipcs -m | grep oracle | awk '{print $2}' | xargs ipcrm shm

resource(s) deleted
[oracle@skate01 ~]$
[oracle@skate01 ~]$ ipcs -m | grep oracle | awk '{print $2}'

尝试登录oracle
[oracle@skate01 ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.2.0 Production on Tue Feb 21 00:47:36 2012

Connected to an idle instance.

SQL> startup nomount;
ORACLE instance started.

Total System Global Area 3.5275E+10 bytes
Fixed Size 2233656 bytes
Variable Size 3623881416 bytes
Database Buffers 3.1541E+10 bytes
Redo Buffers 108003328 bytes
SQL> alter database mount standby database;

Database altered.

SQL> alter database open read only;

Database altered.

SQL> alter database recover managed standby database disconnect using current logfile;

Database altered.

然后检查alterlog看是否有异常，发现都很正常，然后检查确认os层是正常的，然后在登录数据库检查dataguard是否健康。

1.standby库和primary的时间延迟（在standby上运行）：

select 'Last applied : ' Logs,
to_char(next_time, 'DD-MON-YY:HH24:MI:SS') Time
from v$archived_log
where sequence# =
(select max(sequence#) from v$archived_log where applied = 'YES')
union
select 'Last received : ' Logs,
to_char(next_time, 'DD-MON-YY:HH24:MI:SS') Time
from v$archived_log
where sequence# = (select max(sequence#) from v$archived_log);

2.查看进程的活动状态（在standby运行）：

select process, status, thread#, sequence#, block#, blocks
from v$managed_standby;

3.检查log的恢复速度
select * from v$dataguard_status
select * from v$recovery_progress

确认库目前是正常的，然后在会头看数据库为什么会宕机，为什么会报ora-600

查看trace文件

[root@skate01 ~]# more /oracle/app/diag/rdbms/skate01/skate01/incident/incdir_264961/skate01_ora_17783_i264961.trc
Dump file /oracle/app/diag/rdbms/skate01/skate01/incident/incdir_264961/skate01_ora_17783_i264961.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/app/product/11.2.0/db_1
System name: Linux
Node name: skate01
Release: 2.6.18-194.el5
Version: #1 SMP Fri Apr 2 14:58:14 EDT 2010
Machine: x86_64
Instance name: skate01
Redo thread mounted by this instance: 1
Oracle process number: 120
Unix process pid: 17783, image: oracle@skate01

*** 2012-02-20 10:03:58.215
*** SESSION ID:(17.5) 2012-02-20 10:03:58.215
*** CLIENT ID:() 2012-02-20 10:03:58.215
*** SERVICE NAME:(SYS$USERS) 2012-02-20 10:03:58.215
*** MODULE NAME:(JDBC Thin Client) 2012-02-20 10:03:58.215
*** ACTION NAME:() 2012-02-20 10:03:58.215

Dump continued from file: /oracle/app/diag/rd

ora-00600: internal error code, arguments: [KGHLKREM1], [0x838000020], [], [], [], [], [], [], [], [(二)