Skip to content

遭遇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...)

3.理解redo log file header,redo block header and redo record header

昨天有人问我redo log file header,redo block header, redo record header的区别,这三个确实容易混淆,简单聊聊这三个概念,This is importance.
以16进制格式来分析.偶尔会穿插点10进制的dump格式.
一.redo log file header

redo log file header即为重做日志文件头,文件头的内容部分其实包含2个,一个为file header block,一个为redo log header block.可能这么说还有点含糊,那么看下面这张图:

3

如上图所示,一个redo log文件的头部有2个块,第一个块为file header block,第二个块为redo log header block.下面大致的分析下每个块的存储内容.
截取第一个块的内容如下(我用UE打开格式):

log1

10进制的dump格式:

DUMP OF REDO FROM FILE '/oradata/ora10g/lu10g/redo03.log'
 Opcodes *.*
 RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
 SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
 Times: creation thru eternity
 FILE HEADER:
	Compatibility Vsn = 169870080=0xa200300
	Db ID=2561616225=0x98af2961, Db Name='LU10G'
	Activation ID=2561579617=0x98ae9a61
	Control Seq=564=0x234, File size=102400=0x19000
	File Number=3, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000000009, SCN 0x00000099c24d-0x0000009a40c4"
 thread: 1 nab: 0x16910 seq: 0x00000009 hws: 0x4 eot: 0 dis: 0
 resetlogs count: 0x31bca923 scn: 0x0000.000716f7 (464631)
 resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
 prev resetlogs count: 0x268ea86b scn: 0x0000.00000001 (1)
 prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
 Low  scn: 0x0000.0099c24d (10076749) 04/15/2014 12:08:04
 Next scn: 0x0000.009a40c4 (10109124) 04/16/2014 06:56:19
 Enabled scn: 0x0000.000716f7 (464631) 12/17/2013 23:00:51
 Thread closed scn: 0x0000.0099c24d (10076749) 04/15/2014 12:08:04
 Disk cksum: 0xeb7d Calc cksum: 0xeb7d
 Terminal recovery stop scn: 0x0000.00000000
 Terminal recovery  01/01/1988 00:00:00
 Most recent redo scn: 0x0000.00000000
 Largest LWN: 2134 blocks
 End-of-redo stream : No
 Unprotected mode
 Miscellaneous flags: 0x0
 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

在ue打开的16进制中每行是16bytes,一共32行,这为第一个块file header block.这个block包含的信息有限,逐一分析:
从第一个字节开始到第二个字节为0x22,这2个字节通常为oracle 文件类型的标识,像数据文件的开头这里就为0xA2,这里的0x22就代表redo log file.接着下来第一行就没有有意义的东西了其中的0xFFC0应该和scn中的base部分有关.再看看第二行的16个字节,可以发现在第21和22字节0x0200换算成10进制格式则为512,这里即代表block size.从第25到28字节0x00019000换算成10进制后为102400,而0x00019000代表redo block的数量,这里即为代表这个file的blocks或者理解为这个file的size.而在后续跟着的0x7a7b7c7d为文件标识符,为oracle快速识别文件的一种标识.到这之后第一个块的信息就没啦!

接下来分析第二个块redo log header block,第二个块的信息是在文件中的第33行开始,具体如下:
log2

后续再更新吧,有点耗时间.

How to Dump Redo Log File Information

此文章摘自id 28989.1,为解析redo部分必读的一个文章,没翻译,大家凑合吧.
====================================================================
You are working with Oracle Technical Support. As part of the diagnostic
process, you have been asked to take a dump of the redo log files. The
information in the logs is often used to help diagnose corruption issues.

The following commands will be used in this process:

1. The ‘alter session’ command is used to dump redo headers.

2. Use the ‘alter system dump logfile’ to dump log file contents.

This command requires ‘ALTER SYSTEM’ system privilege. The database can be in
mount, nomount or open state when the command is issued. An online log file
or an archived log file can be dumped. It is even possible to dump a
file from another database, as long as the operating systems are the same.

Output from the command is put into the session’s trace file.

The following ways of dumping a redo log file are covered:

1. To dump records based in DBA (Data Block Address)
2. To dump records based on RBA (Redo Block Address)
3. To dump records based on SCN
4. To dump records based on time
5. To dump records based on layer and opcode
6. Dump the file header information
7. Dump an entire log file:

1. To dump records based on DBA (Data Block Address)
————————————————–

This will dump all redo records for the range of data
blocks specified for a given file # and block # range.

From sqlplus (sqldba or svrmgr for older versions), issue the following command:

ALTER SYSTEM DUMP LOGFILE ‘filename’
DBA MIN fileno . blockno
DBA MAX fileno . blockno;

Example:
========
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
DBA MIN 5 . 31125
DBA MAX 5 . 31150;

This will cause all the changes to the specified range of data blocks to be
dumped to the trace file. In the example given, all redo records for file #5,
blocks 31125 thru 31150 are dumped.

Note
====
For 10g:
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
DBA MIN 5 . 31125 DBA MAX 5 . 31150;

will raise:
ORA-01963: Must specify a block number

In 10g we need to skip the dot ‘.’ while doing the redo dumps
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
DBA MIN 5 31125 DBA MAX 5 31150;

@ As per Bug 3536989

2. To dump records based on RBA (Redo Block Address)
————————————————-

This will dump all redo records for the range of redo
addresses specified for the given sequence number and block number.

Syntax:
ALTER SYSTEM DUMP LOGFILE ‘filename’
RBA MIN seqno . blockno
RBA MAX seqno . blockno;

Example:
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
RBA MIN 2050 . 13255
RBA MAX 2255 . 15555;

3. To dump records based on SCN
—————————-

Using this option will cause redo records owning changes within the SCN range
specified to be dumped to the trace file.

ALTER SYSTEM DUMP LOGFILE ‘filename’
SCN MIN minscn
SCN MAX maxscn;

Example:
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
SCN MIN 103243
SCN MAX 103294;

If the purpose is to check the dumpfile you can rather do the following,
SQL> ALTER SYSTEM DUMP LOGFILE ‘filename’ SCN MIN 1 SCN MAX 1;

If the above completes sucessfully it ensures no issues with the archivelog.

4. To dump records based on time.
——————————

Using this option will cause redo records created within the time range
specified to be dumped to the trace file.

From sqlplus (sqldba or svrmgr for older versions), issue the following command:

ALTER SYSTEM DUMP LOGFILE ‘filename’
TIME MIN value
TIME MAX value;

Example:
========
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
TIME MIN 299425687
TIME MAX 299458800;

Please Note: the time value is given in REDO DUMP TIME

@See Note 34026.1 for SQL script on converting date/time to REDO DUMP time.

5. To dump records based on layer and opcode.
——————————————

LAYER and OPCODE are used to dump all log records for a particular type of
redo record, such as all dropped row pieces.

From sqlplus (sqldba or svrmgr for older versions), issue the following command:

ALTER SYSTEM DUMP LOGFILE ‘filename’
LAYER value
OPCODE value;

Example:
========
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’
LAYER 11
OPCODE 3;

@Note: See Note 29733.1 for the list of LAYER and OPCODE values and their
@meaning.

6. Dump the file header information:
———————————

This will dump file header information for every
online redo log file.

From sqlplus (sqldba or svrmgr for older versions), issue the following command:

alter session set events ‘immediate trace name redohdr level 10’;

For dumping archivelog header,issue the following command:

ALTER SYSTEM DUMP LOGFILE ‘filename’ RBA MIN 1 1 RBA MAX 1 1;

7. Dump an entire log file:
————————

From sqlplus (sqldba or svrmgr for older versions), issue the following command:

ALTER SYSTEM DUMP LOGFILE ‘filename’;

Please note:
Fully qualify the filename, and include the single quotes.

Example:
========
ALTER SYSTEM DUMP LOGFILE ‘u01/oracle/V7323/dbs/arch1_76.dbf’;

The dump of the logfile will be written into a trace file in the udump destination.
Use the command ‘show parameters dump’ within an sqlplus session.
The ouput will show the location for the udump destination where
the trace file exists.

@ References:
@ ===========
@ Note 28989.1

4.解析Redo:change vectors

声明:我写这一系列文章纯作为个人兴趣研究,只代表个人观点,如有误欢迎大家斧正.
在说明vector之前我补充要对redo log file header以及redo block header还有redo record header做个区分

change vector顾名思义变更向量,redo record中除了header之外,存储的就是change vector.它

项目工程师在服务现场如何面对客户

本文以Oracle服务为背景,讲述工程师如何面对客户,我觉得讲得很有道理,转到博客,原文摘自转自CSDN.

一. 概述
oracle数据库服务的市场需求也是十分巨大的,国内在做oracle第三方服务的厂商挺多,面对如此众多的卖方选择,面对着令人眼花缭乱的服务商,可以说既爱又恨。爱的是有时候真的能帮自己解决问题,减轻自己的压力,有时候又解决不了问题,让自己也不好交代。
客户工程师各有不同,他们有自己的喜好,有自己的情绪。而对于提供oracle服务的工程师来说,同样有自己的喜怒哀乐。客户的喜好忧愁,与服务商工程师的酸甜苦辣交织在一起,谱写了五彩斑斓的服务与被服务篇章。
作为处于弱势地位的现场工程师,如何去面对处于甲方地方的客户工程师?都值得每个现场工程师很好总结和体味。经历这些真实的挑战,一定对客户是上帝的理解十分深刻。
现场工程师,面对的不仅仅只是技术问题,实际上是一个公司的代表。很多技术也许派不上用场,需要自己灵活处置、随机应变。需要把握一个度,快速、准确、弱势、协调、解释。当然,在现场,具备解决问题的技术能力是必要的,在这个基础上,具备应对现场的过硬的交际能力和心理素质,也是非常重要的,体现了一个人的综合素质,从一方面代表公司形象。

二. 客户的分类
俗话说,林子大了,什么鸟都有。仅仅对其中一部分进行描述。
从理论上来说,我们是平等的,是一种合作关系,而现实中,我们是一种买卖的关系,确实存在不平等地位,一方是强势的甲方,一方是弱势的乙方。甲方一句话,乙方得客气的做出应答。也许没这种必要,但是,现场大多数就是这种情形。
需要服务的与提供服务的,本应该是一种合作的平等关系,但是具体到人,就变了,这是大家已经习以为常的现实。且看客户的类型。
2.1 热情周到型
有的客户十分的热情,也很周到,在你到达现场前,为你准备好了餐票。解决问题后,会好好的请你吃顿饭,更有甚者,会开车带你去兜风。这种客户一般是条件比较好的客户,而且对于你来能解决他们存在的问题心存感激。(其实没必要心存感激)。
2.2 不冷不热型
这种客户,在你到达、处理问题的过程以及离开时,都没有特别的反应,他们团队的氛围就是这样,大家彼此不需要太多的客套,属于那种非主动,一问一答型。
2.3 先礼后兵型
有些客户对于你的来到,充满期待,对你十分的热情友好,对你提出的要求,尽量满足。但是,如果你不能解决问题,或者弄出新的问题,他们会毫不犹豫的对你进行投诉。并且不允许你下次再来他们的现场,要求换人。
2.4 强烈依赖型
客户对于你的技术,有十分严重的依赖,有时候并非客户不懂,而大多数情况下,客户是不想对可能出现的后果负责,因为做数据库的操作有时候有巨大风险。所以,什么事情,都由你来做,比如扩一下表空间,删除一些不要的文件等。
2.5 自力更生型
有时候在现场,可能会让你觉得,客户买你们公司的服务是不是一种多余,因为,每次都是你们公司主动要求去做一下什么所谓的检查,好像是为了完成合同规定的任务,而去了之后,客户工程师似乎不情愿让你碰任何系统,不允许接入任何机器,你需要做的是,提供保证没有病毒的相关脚本和操作说明。他们自己来操作。
2.6 实力强大型
有时候在现场,客户似乎表现的比你技高一筹,有时候让你感到有点内心打鼓,客户无论是从交流沟通,还是貌似请教,都好像设下埋伏,对你其实在进行试探,这些人既有很快速的操作技能,也具有很深的理论水平。而且他们自己本身就有很强大的dba团队。
2.7 完全不懂型
出于某些原因,客户那边可能临时缺少人手,或者dba刚离职,客户工程师只是临时接手这个任务,或者客户就是刚刚入门,做一个不太重要的系统在维护,实际上让你能教教他,也许一个命令,敲一个字母,都需要向你咨询,这种属于完全不懂型。
2.8 压力巨大型
有时候客户工程师在现场面临强大的压力,通宵达旦,连续奋战,只要没有解决问题,他都面临上级的强大压力,或者是上级也面临这更上级的压力,这种压力是硬性的,一层层传递,最终也必然要传递到现场工程师身上。这种客户工程师可能面临考核的巨大压力,因此,对于实施服务的现场工程师具有非常高的要求,而且要确保能解决问题,并且容易出现情绪问题,容易表现在脸上。
2.9 压榨型
有些客户有一种心态,我买了你们的服务,你们就得听我使唤。而很多第三方厂商,迫于竞争的激烈,对客户是有求必应,对现场工程师也是要求尽量满足客户,进一步助长了此种心态的客户的此种心态。客户认为花了钱,就得给我好好的处理问题,尽量的提供服务,似乎是要把花出去的钱全部捞回来,尽量物有所值。你的所有时间都是客户的,包括你的周末甚至是你的夜晚。就是周末搬个桌椅,都需要你来代劳。

三. 客户的要求
3.1 快速响应
有客户曾经对我说,购买你们的服务,其中一个非常重要的因素,就是看重快速响应的机制。一般客户问问题,都要引起重视,有时候客户是在不经意间提出,有时候是比较正式的提出,无论客户自己是否重视,都应该引起你自己的足够重视,否则,可能会引起客户的不满,严重的会导致投诉。
3.2 技术靠谱
有一些客户对提供服务的工程师有比较苛刻的要求,甚至要求通过他们自己设置的面试与笔试考核,其他的客户可能要求不是很高,但是都要求技术工程师的技术要靠谱,一般来说,技术不好的工程师,往往会在一些好说话的客户、不重要的系统上先熟悉,练练手,有机会再进入重要客户的重要系统。如果没有一定的技术实力,很容易引起客户的不满意。如果一问三不知,客户也会对你失去信心。
3.3 问题的精确定位与处理
对于问题原因的精准定位,是一项非常重要的技能。也是所提供服务的质量体现。有经验的工程师能够快速熟练的去验证问题,而不太有经验的工程师,会逐一尝试排查,最终找到问题症结。不管怎样,如果对于问题的分析不合理,不具有说服力,客户可能是不会接受的。
3.4 超出合同范围的过分要求
有时候可能客户会提一些超出你能力范围的,甚至是合同范围的要求,超出能力范围的事情可以找公司协调资源,寻求帮助,但是超出合同范围的事情,你只能跟销售反映了。比如如果只是做数据库的维保服务,而客户要求你检查主机硬件,或者提出一些诸如要求你们公司组建什么水平的试验室等等的要求。

四. 问题和矛盾
4.1 有些不能解决的矛盾,这是在现实中客观存在的。
不是所有的问题都是能解决的,不是所有的技术问题非得技术手段来解决。很多问题是目前的水平没办法解决的,这些是客观存在的。就算是原厂派资深的工程师,也解决不了问题。
4.2 合同中的技术实力与现场中区别甚大
有时候,客户认为,签合同时候说的天花乱坠,合同签了之后,实际上没那么强,没那么好,甚至有很大的落差。会让客户产生一些不满。

五. 应对客户的技巧
5.1 答应客户要办的事情,一定要办。
许多时候,很多工程师,在离开客户之前,回家心切,或者想早点离开客户这里,免得又会有什么问题来麻烦自己,只要客户问的问题,往往口头上满口答应,表示回去后再看看,不过可能回去没看,没引起重视,或者忘了,就容易引起客户投诉。
答应客户的事情一定要给一个结果,不管结果如何,都要给客户反馈。
5.2 表现一种姿态
很多时候,说实在的,可能解决不了问题,但是你至少得有个姿态,表明我确实尽力了。从服务态度上加分,如果问题没解决,又一副大爷般的神态,那结果往往也会不妙。
5.3 同客户工程师搞好关系
同客户工程师搞好关系,其实也是一个工程师的能力体现。一旦同客户工程师的关系做好了,处理问题起来就会得心应手,如果跟客户关系搞不好,相互暗中抱怨,平添一堵墙。比如请客户吃顿饭,或者天南地北的说一通,或者一起深入的沟通一些他们关心的其他问题。对客户表现出一种真诚、职业、热忱、敬业的品质。搞好关系实际上是解决问题的一种润滑剂。
5.4 注意同其他厂商的工程师保持通畅的沟通
在现场,往往会有多家厂商,共同来做一件事,大家实际上有一个共同的目标,就是让系统高效稳定的运行,大家的目标是一致的,出了问题大家相互支援,尽量不要造成那种有事情相互推诿扯皮,这样大家都不好受。
5.5 其他力所能及的帮助
作为培养客户关系的一部分,适当的满足一下客户的其他要求,也是有帮助的,比如给客户拷贝一些技术资料,给客户做一个小小的培训,以解答客户心中的疑惑,往往会有很好的效果。
5.6 提交详细文档
客户工程师有很多时候,对发生的问题,需要有个技术文档,以便下次遇到同样问题,知道原因,并可能会采取措施避免,有的可能需要一份报告,向领导交差。不管怎样,事后提交一份友好、专业的报告,都是非常必要