ORA-00600 内部错误代码, 参数: [kcratr1_lastbwr], [], []...

昨天对一台生产Oracle服务器进行拷贝，没有关闭oracle直接打包oracle的所有文件到另一台机子(对数据一致性要求不严谨)，但是启动的时候报错了两个错。

错误1.

SQL> startup 
ORA-27125: unable to create shared memory segment 
Linux-x86_64 Error: 1: Operation not permitted

通常是group组值不对，查看oracle用户所在的组

[oracle@bankdb01 ~]$ id oracle
uid=500(oracle) gid=501(oinstall) 组=501(oinstall),500(dba)

[oracle@bankdb01 ~]$ more  /proc/sys/vm/hugetlb_shm_group
0

--两者不一致，要同步一下
[root@bankdb01 ~]$ echo 500 > /proc/sys/vm/hugetlb_shm_group
[root@bankdb01 ~]$ more  /proc/sys/vm/hugetlb_shm_group
500

--永久生效就写到/etc/sysctl.conf 
[root@bankdb01 ~] echo vm.hugetlb_shm_group=500 >> /etc/sysctl.conf
[root@bankdb01 ~] sysctl -p   

关闭再启动就遇到了错误2 错误2.

ORA-00600 内部错误代码, 参数: [kcratr1_lastbwr], [], [], [], [], [], [], []

查看alert文件，里面的600错误信息多一点，

*** 2013-07-30 18:22:27.178
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000001 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000001 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?

网上资料多是手工recovery database来修复 打开rman修复

[oracle@bankdb01 ~]$rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on 星期三 7月 31 09:42:34 2013

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1327106293)

RMAN> recovery database;

再次启动就正常了。

关于hugetlb_shm_group这个文件

hugetlb_shm_group contains group id that is allowed to create SysV shared memory segment using hugetlb page
When a process uses some memory, The CPU is marking the RAW as used by that process For efficiency, the CPU allocate RAW by chunks of 4k bytes (it's the default value on many platforms). Those chunksare named pages. Those pages can be swapped to disk.
Since the process address space are virtual, the CPU and the operating system have to remember which page belong to which process, and where it is stored Obviously, the more pages you have, the more time it takes to find where the memory is mapped. When a process uses 1GB of memory, that's 262144 entries to lookup (1GB/4k). If on Page Table Entry consume 8bytes, that's 2MB (262144 * 8) to look-up.
Most current CPU architectures support bigger pages (so the CPU/OS have less entries to look-up), those are named HugPages (on Linux), Spuer Pages (On BSD) or Large Pages (on Windows), but it all the same thing.

参考：http://www.eygle.com/archives/2011/12/hugepageshugetl.html