Linux – 第2页 – Ludatou's data life

遭遇ORA-27300: OS system dependent operation:fork failed with status: 12

系统平台为

Oracle Solaris on SPARC (64-bit)

数据库版本

11.2.0.3

遭遇这个错误主要是因为备份恢复出问题了，执行介质恢复一下吃光了而且系统告警日志报错如下：

/opt/app/oracle/diag/rdbms/standbydbrtps/RTPS/trace/RTPS_psp0_6332.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3

在系统的/var/adm/messages中同时也收到信息如下：

shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,

经过诊断与Oracle bug 18387547吻合.该bug信息如下：

Hdr: 18387547 11.2.0.3 RDBMS 11.2.0.3 SECURITY PRODID-5 PORTID-23
Abstract: MEMORY LEAK OF RECOVERY PROCESS IF TDE IS ENABLED

*** 03/12/14 01:45 am ***

PROBLEM:
--------
Customer uses TDE and physical standby. The memory will be eaten by the
recovery process (manual or managed).

DIAGNOSTIC ANALYSIS:
--------------------
When media recovery starts, process that do media recovery (ora_mrp if
recovery is run without parallelism or ora_pr if it is parallel recovery), is
allocating 96 bytes buffers in order to do ioctl() for /dev/crypto, but the
memory is not beeing freed (dtrace shows only malloc() calls, and no free()
calls). Each ioctl() call will be issued with new 96 buffer, and that will
deplete memory on server, causing server to stop once all virtual memory is
used.

In /var/adm/messages we can see the errors:
Feb 9 18:19:58 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16090 (oracle_server_mo)
Feb 9 18:21:43 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16097 (oracle_server_mo)
Feb 9 18:23:33 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16103 (oracle_server_mo)
Feb 9 18:25:19 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16106 (oracle_server_mo)
Feb 9 18:27:05 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16110 (oracle_server_mo)
Feb 9 18:28:54 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16117 (oracle_server_mo)
Feb 9 18:30:42 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16129 (oracle_server_mo)
Feb 9 18:32:31 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16138 (oracle_server_mo)
Feb 9 18:34:17 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16148 (oracle_server_mo)
Feb 9 18:36:03 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16151 (oracle_server_mo)
Feb 9 18:37:50 shadowdog-FO genunix: [ID 470503 kern.warning] WARNING: Sorry,
no swap space to grow stack for pid 16156 (oracle_server_mo)

In alert log:
Process startup failed, error stack:
Errors in file
/u01/app/oracle/diag/rdbms/standbydbrtps/RTPS/trace/RTPS_psp0_6631.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3

WORKAROUND:
-----------
Restart MRP

RELATED BUGS:
-------------


REPRODUCIBILITY:
----------------


TEST CASE:
----------


STACK TRACE:
------------


SUPPORTING INFORMATION:
-----------------------


24 HOUR CONTACT INFORMATION FOR P1 BUGS:
----------------------------------------


DIAL-IN INFORMATION:
--------------------


IMPACT DATE:
------------


*** 03/12/14 01:46 am ***
*** 03/12/14 01:47 am ***
*** 03/12/14 01:48 am ***
*** 03/27/14 04:40 am ***
*** 03/27/14 05:30 am *** (CHG: Sta->10)
*** 03/27/14 05:30 am ***

*** 04/01/14 01:27 am *** (CHG: Sta->16)
*** 04/01/14 01:27 am ***
*** 04/01/14 03:28 am ***
*** 04/01/14 04:54 am *** (CHG: Sta->10)
*** 04/01/14 04:54 am ***
*** 04/01/14 05:02 am ***
*** 04/15/14 11:25 pm *** (CHG: Sta->16)
*** 04/15/14 11:25 pm ***
*** 04/20/14 12:59 am *** (CHG: Sta->91)
*** 04/20/14 01:00 am ***
*** 04/20/14 01:00 am *** (ADD: Impact/Symptom->LEAK - DB MEMORY/OTH...)

Linux Oracle Oracle 排障配置与调整 | Guang Cai Li | 2014-04-21 | ORA-27300，shadowdog-FO genunix: [ID 470503

libXp.so.6: cannot open shared object file,during installing oracle database 11g on rhel as 6.1 x64

报错信息：

/tmp/OraInstall2011-09-24_10-16-11PM/jre/1.4.2/lib
/i386/libawt.so: libXp .so.6: cannot open  shared object file: No such file or directory occurred..

这个错误是我在以前安装时候碰到的，最近问的人挺多，则顺便趁早上这个点发布出来.首先我们从错误上看能很明显看到是libxp.so.6这个文件出问题了，但是你使用rpm -qa | grap libXp你会发现，这个包已经安装了，
仔细检查你会发现，系统提示的是/tmp/OraInstall2011-09-24_10-16-11PM/jre/1.4.2/lib/i386/libawt.so，i386而不是686，而现在安装的平台都常都是linux 6.1 x64上,默认安装的libXp版本也是64bit版本的，所以这里的解决办法基本就可以明了了，使用rpm -e | grep libXp，然后安装正确的386版本的libXp即可。如果有依赖包先卸载依赖包。

Database Linux Oracle Oracle 排障配置与调整 | Guang Cai Li | 2014-04-16 | libXp.so.6 oracle 11g

使用Strace让oracle hgng住的测试

数据库hang住的原因很多,以往碰到得案例不少,大部分都和内存的抖动引起的进程僵死，或者bug造成，或者其他类似如归档满了，dg最高级模式下网络阻塞等原因.今天这里我介绍的这个案例偏门，几乎很难碰到.这里测试的版本为11.2.0.2版本，基于linux内核2.6.18 ×64. 且10g和11r1版本此类测试无效.这应该算是11.0.2.2的一个bug.

在linux中有一个命令strace，它常被用来跟踪进程执行时的系统调用和所接收的信号。
具体的参数含义如下：

-c 统计每一系统调用的所执行的时间,次数和出错的次数等.
-d 输出strace关于标准错误的调试信息.
-f 跟踪由fork调用所产生的子进程.
-ff 如果提供-o filename,则所有进程的跟踪结果输出到相应的filename.pid中,pid是各进程的进程号.
-F 尝试跟踪vfork调用.在-f时,vfork不被跟踪.
-h 输出简要的帮助信息.
-i 输出系统调用的入口指针.
-q 禁止输出关于脱离的消息.
-r 打印出相对时间关于,,每一个系统调用.
-t 在输出中的每一行前加上时间信息.
-tt 在输出中的每一行前加上时间信息,微秒级.
-ttt 微秒级输出,以秒了表示时间.
-T 显示每一调用所耗的时间.
-v 输出所有的系统调用.一些调用关于环境变量,状态,输入输出等调用由于使用频繁,默认不输出.
-V 输出strace的版本信息.
-x 以十六进制形式输出非标准字符串
-xx 所有字符串以十六进制形式输出.
-a column
设置返回值的输出位置.默认 为40.
-e expr
指定一个表达式,用来控制如何跟踪.格式如下:
[qualifier=][!]value1[,value2]...
qualifier只能是 trace,abbrev,verbose,raw,signal,read,write其中之一.value是用来限定的符号或数字.默认的 qualifier是 trace.感叹号是否定符号.例如:
-eopen等价于 -e trace=open,表示只跟踪open调用.而-etrace!=open表示跟踪除了open以外的其他调用.有两个特殊的符号 all 和 none.
注意有些shell使用!来执行历史记录里的命令,所以要使用\\.
-e trace=set
只跟踪指定的系统 调用.例如:-e trace=open,close,rean,write表示只跟踪这四个系统调用.默认的为set=all.
-e trace=file
只跟踪有关文件操作的系统调用.
-e trace=process
只跟踪有关进程控制的系统调用.
-e trace=network
跟踪与网络有关的所有系统调用.
-e strace=signal
跟踪所有与系统信号有关的 系统调用
-e trace=ipc
跟踪所有与进程通讯有关的系统调用
-e abbrev=set
设定 strace输出的系统调用的结果集.-v 等与 abbrev=none.默认为abbrev=all.
-e raw=set
将指 定的系统调用的参数以十六进制显示.
-e signal=set
指定跟踪的系统信号.默认为all.如 signal=!SIGIO(或者signal=!io),表示不跟踪SIGIO信号.
-e read=set
输出从指定文件中读出 的数据.例如:
-e read=3,5
-e write=set
输出写入到指定文件中的数据.
-o filename
将strace的输出写入文件filename
-p pid
跟踪指定的进程pid.
-s strsize
指定输出的字符串的最大长度.默认为32.文件名一直全部输出.
-u username
以username 的UID和GID执行被跟踪的命令

如果做过在linux的开发，那么对这个命令一定不会陌生，哈哈。闲话不多说，我们接着猪蹄，今天我们主要是采用-p -o这2个参数，用它对oracle的进程进行跟踪调用。
首先我对lgwr进程进行跟踪调用，执行如下：

[root@ludatou ~]# ps -ef | grep lgwr
root     10136  9578  0 06:30 pts/1    00:00:00 grep lgwr
ora10g   32496     1  0 Apr15 ?        00:00:04 ora_lgwr_lu11r2
[root@ludatou ~]# export ORACLE_SID=lu11r2
[root@ludatou ~]# strace -p $(pgrep -fx ora_lgwr_$ORACLE_SID) -o /tmp/l.out -T &
[1] 10257
[root@ludatou ~]# Process 32496 attached - interrupt to quit

这个时候日志l.out的输出大致如下（我db是空闲的）：

gettimeofday({1397602111, 401986}, NULL) = 0 <0.000032>
gettimeofday({1397602111, 402111}, NULL) = 0 <0.000032>
gettimeofday({1397602111, 402233}, NULL) = 0 <0.000032>
gettimeofday({1397602111, 402356}, NULL) = 0 <0.000031>
gettimeofday({1397602111, 402510}, NULL) = 0 <0.000032>
gettimeofday({1397602111, 402537}, NULL) = 0 <0.000011>
gettimeofday({1397602111, 402551}, NULL) = 0 <0.000007>
gettimeofday({1397602111, 402560}, NULL) = 0 <0.000005>
times(NULL)                             = 436324232 <0.000002>
gettimeofday({1397602111, 402570}, NULL) = 0 <0.000003>
gettimeofday({1397602111, 402573}, NULL) = 0 <0.000002>
semtimedop(131073, 0xbfa12088, 1, {3, 0}

这个时候数据库运行正常，正常读写提交，具体如下：

SQL> conn luda/luda
Connected.
SQL> create table t1 as select * from dba_objects;

Table created.

SQL> alter table t1 add ludatou varchar2(200);

Table altered.

SQL> update t1 set ludatou=250;

50068 rows updated.

SQL> commit;

Commit complete.

下一步我将strace跟踪lgwr的进程杀掉后，再看看数据库是否运行正常，具体如下：

1.杀掉跟踪进程

[root@ludatou ~]# kill %1
[root@ludatou ~]# Process 32496 detached
--这个时候提示守护进程和32496进程（lgwr）分离

2.在数据库层面执行
SQL> update t1 set ludatou=250;

50068 rows updated.

SQL> commit;

到这一步会发现….一直没反应，查看全库等待事件为log file sync.这个时候检测lgwr的进程状态可以发现为如下：

[ora11g@ludatou ~]$ ps $(pgrep -fx ora_lgwr_$ORACLE_SID)
  PID TTY      STAT   TIME COMMAND
32496 ?        Ts     0:00 ora_lgwr_lu11r2

进程32496为Ts的状态，意味着该进程为停止状态或者该进程被其他进程控制.但是实际上我已经把strace停止。我们将其唤醒：

kill -SIGCONT 32496
[ora11g@ludatou ~]$ ps $(pgrep -fx ora_lgwr_$ORACLE_SID)
  PID TTY      STAT   TIME COMMAND
32496 ?        Ss     0:00 ora_lgwr_lu11r2

这个时候进程变为ss状态，而且数据库也随之恢复正常。这不知道应算是数据库的bug还是linux的bug，个人更倾向linux，毕竟我执行退出strace了，实际上strace进程还附加在lgwr进程上不断callout进程。这个测试我只在11.2.0.2，11.1.0.7，10.2.0.4版本上测试过，目前只有11.2.0.2有这个情况。

Database Grid and Cluster Linux Oracle Oracle 排障配置与调整等待事件 | Guang Cai Li | 2014-04-16

linux huge page

Linux Oracle Unix and Linux | Guang Cai Li | 2013-12-02

Linux：设置用户变量ps1

设定的PS1的值

PS1="[u@h w]$"

PATH=$PATH:$HOME/bin

#使用export把PS1输出，以使它可以在子shell中生效,这会造成ROOT用户的也采用此样式

#export PS1 要慎用

export PATH

unset USERNAME

下面简单说说环境下默认的特殊符号所代表的意义：

d ：代表日期，格式为weekday month date，例如："Mon Aug 1"

H ：完整的主机名称。例如：我的机器名称为：fc4.linux，则这个名称就是fc4.linux

h ：仅取主机的第一个名字，如上例，则为fc4，.linux则被省略

t ：显示时间为24小时格式，如：HH：MM：SS

T ：显示时间为12小时格式

A ：显示时间为24小时格式：HH：MM

u ：当前用户的账号名称

v ：BASH的版本信息

w ：完整的工作目录名称。家目录会以 ~代替

W ：利用basename取得工作目录名称，所以只会列出最后一个目录

# ：下达的第几个命令

$ ：提示字符，如果是root时，提示符为：# ，普通用户则为：$

例子：

export PS1="[oracle t->w]"

Linux Oracle Unix and Linux | Guang Cai Li | 2011-06-16

Linux - 2. page

遭遇ORA-27300: OS system dependent operation:fork failed with status: 12

libXp.so.6: cannot open shared object file,during installing oracle database 11g on rhel as 6.1 x64

使用Strace让oracle hgng住的测试

linux huge page

Linux：设置用户变量ps1

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!

近期活动

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事 获取定期发布的数据库运维的有趣事情!

近期活动

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!