天道酬勤

Baby,we love you!

ochef — Tue, 10 Aug 2010 14:22:49 +0000

我家宝宝（果果）于2010年08月06日 17：10出生了，是个小美女噢！近来太累，改天记录当爹的经历，哈哈!

-The End-

ORA-00600:[2103],[1],[0],[1],[900]的处理

ochef — Mon, 19 Jul 2010 02:00:31 +0000

上周四中午刚放下订餐电话，手机响起鸟，客户的一套AIX 5.2 ML04 + Oracle 10.2.0.3.0 (+Dataguard)的系统挂了，业务中断。收拾东西下楼打车赶往客户机房，大致半小时后到达客户机房登录系统检查发现系统报：“ORA-00600: internal error code, arguments: [2103], [1], [0], [1], [900]”错误。[2103]的错误与controlfile有关，[900]是等待的超时时间S。进一步检查发现，问题是出现在每天晚上0点都有crontab调度的系统备份任务：0点将系统置为热备模式—>连接FTP服务器—>CP需要备份的所有件—>最后将系统退出热备模式。metalink [ID 567891.1]说：系统处在热备份模式下，在日志发生切换时获取控制文件队列信息时发生了超时，这个等待时间默认是15分钟（900s）。虽然这里有一个Bug 6018274，但我的习惯是只有在做完了尽可能的尝试之后再认为是bug。

继续检查发现，系统一直在进行kill动作：“Killing enqueue blocker (pid=827572) on resource CF-00000000-00000000”，但遗憾的是这个动作失败了，尝试手工kill，失败。而且此时在系统中只要一发起与log相关的动作系统就挂起，无赖之下想重启oracle(这个想法很邪恶啊，如果待会儿起不来，how?),FT……正常关闭失败（意料中的），abort关机失败，回到OS中kill -9失败。万般无赖之下，只能重启OS，没想到的是AIX重启到一般的时候挂起，此时已经13：30了，还没有吃饭（12点客户叫俺一起去吃饭看到她那表情俺也有点不好意思。）不管了，先搞定系统再说吧。由于这套系统是P690上的一个分区，只要在HMC上使用“Hard Reset”选项了，鼠标移到此分区上检查了又检查了，俺视力5.2的说，但就怕这时看错了的话，后果，你知道的。在这前后几分钟，真有心跳加速的感觉，就怕待会儿库打不开啊。10分钟之后，my god，库顺利的打开了，哎呀，肚子不饿了，起应用一切顺利，先让别人开工吧。

造成ORA-00600 [2103]错误的原因有下：

1) 控制文件存放在I/O非常慢的存储系统上。

2) 频繁的日志切换，或日志文件过小或日志文件组数目过少。

3) 同时使用了异步I/O或多个数据写进程。

4) Oracle软件内部Bug。

5) OS/硬件问题。

讯问过客户工程师，确实在前一天18：30的时候进行数据整理，发生过非常频繁的日志切换，高峰时1分钟达5次日志切换，但在其后一天是正常的，由于环境复杂，暂时先做如下测试：（以影响业务程度最小化且实施难易程度依次列出）

1. 增大日志组成员大小，同时增加日志组数目。

2. 由于业务的特殊性，商讨能否修改备份策略来避开热备份。

3. 根据官方建议打补丁：Patch 5923866，在失效的情况下，将系统升级到10.2.0.4.0之上（最新分布为10.2.0.5.0）

4. 将操作系统从AIX 5.2 ML04升级到AIX 5.2 ML05（Oracle在[ID 406191.1]中建议）

BTW：在我重启完系统后问客户，此套系统应该有Dataguard的吧，答案是肯定的。到这里，可能大家会说为什么不在出问题的时候将系统切换到备机上。其实切换系统更多决定因素不仅仅只在技术层面的。

-The End-

智齿

ochef — Tue, 06 Jul 2010 13:56:41 +0000

昨天晚上开始，发现右边牙齿有点痛，开始以为是由于最近天气热加上本人又舍不下最爱的辣椒上了火，到今天越来越痛了，还伴随有点低烧和轻微头晕，原来是长智齿了。这是我第二次切身体会到什么是“牙痛不是病，痛起来真要命”，之前还是读高二的时候牙痛过一次，喝水，讲话都不行，但不是长智齿。此时，俺嘴里含着一片生姜来减轻痛苦，还喝了苦得要命的凉茶再加上消炎药。内事问了一下baidu，就算要拔也要等到消炎不痛了才行，难受中。

维基百科对“智齿”的解释：

智齿，学名第三大臼齿，俗称智慧齿、立事牙、尽头牙，是口腔最靠近喉咙的牙齿，如果全部生长出来一共4颗，上下颚各两颗，一般是于16岁或之后才生长出来，相较于幼儿时期长出的乳齿与儿童时期更换的恒齿，智齿通常是在人类心智已经趋于成熟时才长出，因而得名。在智齿的生长方面，个体差异很大，有的人20岁之前，有的人40、50岁才长，有的人终生不长，这都是正常的。而且四颗智齿也不是都必然会长全，某些人的智齿可能只长1至2颗，有的智齿甚至长到一半就不再生长，这种情况称为智齿阻生。

-The End-

新手拍微距

ochef — Wed, 19 May 2010 04:39:19 +0000

前段时间入手了Nikon D90，主要是用来记录果果的成长的，由于从来没有玩过单反，真的是七窍通了六窍啊，惭愧之至。抓紧时间在他/她出生前练练手，不然我这个老爸也太逊了^-^。来张在楼下试拍的微距以资鼓励：

-The End-

expdp的network_link参数

ochef — Wed, 19 May 2010 04:27:33 +0000

expdp是server端工具，但可以通过NETWORK_LINK参数实现远端导出，但是前提是远端也安装有Oracle数据库，只有CLIENT端是没有办法利用数据泵的。

这里要指出的是：network_link不支持远端导出分区表中的某一个分区，但可以导整个分区表。以下为测试过程：

创建分区表sales：

[oracle@ora10g ~]$ sqlplus ‘/as sysdba’

SQL> CREATE TABLE sales

(sale_date DATE NOT NULL)

PARTITION BY RANGE (sale_date)

(PARTITION sales2010_q1

VALUES LESS THAN (TO_DATE(’2010-04-01′,’YYYY-MM-DD’))

TABLESPACE sp1,

PARTITION sales2010_q2

VALUES LESS THAN (TO_DATE(’2010-07-01′,’YYYY-MM-DD’))

TABLESPACE sp2,

PARTITION sales2010_q3

VALUES LESS THAN (TO_DATE(’2010-10-01′,’YYYY-MM-DD’))

TABLESPACE sp3);

插入4条记录：

SQL> select count(*) from sales;

COUNT(*)

———-

SQL> select * from sales partition(sales2010_q1);

SALE_DATE

————

23-MAR-10

SQL> select * from sales partition(sales2010_q2);

SALE_DATE

————

23-JUN-10

22-JUN-10

SQL> select * from sales partition(sales2010_q3);

SALE_DATE

————

23-SEP-10

远端机器上创建 directory目录、赋权、创建dblink:

[oracle@node1 /]$ sqlplus ‘/as sysdba’

SQL> create directory dump_dir as ‘/backup’;

Directory created.

SQL> grant read,write on directory dump_dir to ochef;

Grant succeeded.

SQL> create database link test connect to ochef identified by oracle using ‘primary’;

Database link created.

SQL> select count(*) from ochef.sales@test;

COUNT(*)

———-

远程导出整个分区表：

[oracle@node1 ~]$ expdp ochef/oracle directory=dump_dir dumpfile=sales.dmp network_link=test tables=sales

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production

With the Partitioning, Real Application Clusters, OLAP, Data Mining

and Real Application Testing options

Starting “OCHEF”.”SYS_EXPORT_TABLE_01″: ochef/******** directory=dump_dir dumpfile=sales.dmp network_link=test tables=sales

Estimate in progress using BLOCKS method…

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 384 KB

Processing object type TABLE_EXPORT/TABLE/TABLE

. . exported “OCHEF”.”SALES” 4.960 KB 4 rows

Master table “OCHEF”.”SYS_EXPORT_TABLE_01″ successfully loaded/unloaded

******************************************************************************

Dump file set for OCHEF.SYS_EXPORT_TABLE_01 is:

/backup/sales.dmp

Job “OCHEF”.”SYS_EXPORT_TABLE_01″ successfully completed at 11:12:43

远程导出分区表的某个分区：

[oracle@node1 ~]$ expdp ochef/oracle directory=dump_dir dumpfile=sales.dmp network_link=test tables=sales:sales2010_q2

ORA-39001: invalid argument value

ORA-39203: Partition selection is not supported over a network link.

本地导出分区表的某个分区：

[oracle@ora10g ~]$ expdp ochef/oracle directory=dump_dir dumpfile=sales.dmp tables=sales:sales2010_q2

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Starting “OCHEF”.”SYS_EXPORT_TABLE_01″: ochef/******** directory=dump_dir dumpfile=sales.dmp tables=sales:sales2010_q2

Estimate in progress using BLOCKS method…

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 128 KB

Processing object type TABLE_EXPORT/TABLE/TABLE

. . exported “OCHEF”.”SALES”:”SALES2010_Q2″ 4.937 KB 2 rows

Master table “OCHEF”.”SYS_EXPORT_TABLE_01″ successfully loaded/unloaded

******************************************************************************

Dump file set for OCHEF.SYS_EXPORT_TABLE_01 is:

/backup/sales.dmp

Job “OCHEF”.”SYS_EXPORT_TABLE_01″ successfully completed at 11:07:07

关于远程expdp用户权限问题，请移步这里。

-The End-

db_unique_name与service_name

ochef — Wed, 19 May 2010 01:59:16 +0000

为了data guard在角色切换时不用事先准备好二个init.ora参数文件，那么就需要配置valid_for参数，类似如下配置（备库）：

db_unique_name=ora10gstd

log_archive_dest_1=’location=/u01/app/oracle/oradata/ora10g/archive valid_for=(all_logfiles,all_roles) db_unique_name=ora10gstd’

log_archive_dest_2=’service=standby lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=ora10g’

db_unique_name在oracle的高可用dataguard的应用中会经常使用，有和db_name不一样的作用，在物理dg中，要求主、从库都有一样的db_name（虽然他们和rac不一样，并不是同一个库），但是他们的db_unique_name是不一样的，用以进行不同的标示。

注意：如果修改了db_unique_name的值，会影响到Service_names，也会影响到动态监听的service_name，因此，也应修改tnsnames.ora文件中service_name的服务名，否则，即使tnsping能通，但无法提供相应的服务。

-The End-

Oracle Restart

ochef — Wed, 21 Apr 2010 05:21:38 +0000

接上一篇文章，我用同样的安装方法同样的配置成功了，也许还真是版本不兼容的问题。

[oracle@ora11gr2 ~]$ cat /etc/issue
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)

[oracle@ora11gr2 ~]$ uname -a
Linux ora11gr2 2.6.18-128.el5 #1 SMP Wed Jan 21 07:58:05 EST 2009 i686 i686 i386 GNU/Linux

[oracle@ora11gr2 ~]$ srvctl config database -d ora11gr2 -a
Database unique name: ora11gr2
Database name:
Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1
Oracle user: oracle
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups:
Services:
Database is enabled
[oracle@ora11gr2 ~]$

模拟了进程异常终止之后，restart将其启动的过程：

[oracle@ora11gr2 ~]$ srvctl start database -d ora11gr2
[oracle@ora11gr2 ~]$ ps -ef|grep ora_
oracle    4881     1 0 12:42 ?        00:00:00 ora_pmon_ora11gr2
oracle    4883     1 0 12:42 ?        00:00:00 ora_vktm_ora11gr2
oracle    4887     1 0 12:42 ?        00:00:00 ora_gen0_ora11gr2
oracle    4889     1 0 12:42 ?        00:00:00 ora_diag_ora11gr2
oracle    4891     1 0 12:42 ?        00:00:00 ora_dbrm_ora11gr2
oracle    4893     1 1 12:42 ?        00:00:00 ora_psp0_ora11gr2
oracle    4895     1 1 12:42 ?        00:00:00 ora_dia0_ora11gr2
oracle    4897     1 21 12:42 ?        00:00:03 ora_mman_ora11gr2
oracle    4899 1 0 12:42 ?        00:00:00 ora_dbw0_ora11gr2
oracle    4901     1 2 12:42 ?        00:00:00 ora_lgwr_ora11gr2
oracle    4903     1 0 12:42 ?        00:00:00 ora_ckpt_ora11gr2
oracle    4905     1 1 12:42 ?        00:00:00 ora_smon_ora11gr2
oracle    4907     1 0 12:42 ?        00:00:00 ora_reco_ora11gr2
oracle    4909     1 6 12:42 ?        00:00:00 ora_mmon_ora11gr2
oracle    4911     1 0 12:42 ?        00:00:00 ora_mmnl_ora11gr2
oracle    4913     1 0 12:42 ?        00:00:00 ora_d000_ora11gr2
oracle    4915     1 0 12:42 ?        00:00:00 ora_s000_ora11gr2
oracle    4985     1 0 12:42 ?        00:00:00 ora_p000_ora11gr2
oracle    4987     1 0 12:42 ?        00:00:00 ora_p001_ora11gr2
oracle    4989     1 0 12:42 ?        00:00:00 ora_qmnc_ora11gr2
oracle    5007     1 7 12:42 ?        00:00:00 ora_cjq0_ora11gr2
oracle    5011     1 34 12:42 ?        00:00:00 ora_j000_ora11gr2
oracle    5013     1 8 12:42 ?        00:00:00 ora_j001_ora11gr2
oracle    5015 3000 0 12:42 pts/0    00:00:00 grep ora_
[oracle@ora11gr2 ~]$ date
Wed Apr 21 12:42:59 CST 2010
[oracle@ora11gr2 ~]$ kill -9 4899
[oracle@ora11gr2 ~]$ ps -ef|grep ora_
oracle    5100     1 10 12:43 ?        00:00:00 ora_pmon_ora11gr2
oracle    5102     1 11 12:43 ?        00:00:00 ora_vktm_ora11gr2
oracle    5106     1 9 12:43 ?        00:00:00 ora_gen0_ora11gr2
oracle    5108     1 9 12:43 ?        00:00:00 ora_diag_ora11gr2
oracle    5110     1 10 12:43 ?        00:00:00 ora_dbrm_ora11gr2
oracle    5112     1 7 12:43 ?        00:00:00 ora_psp0_ora11gr2
oracle    5114 3000 0 12:43 pts/0    00:00:00 grep ora_
[oracle@ora11gr2 ~]$ ps -ef|grep ora_
oracle    5100     1 1 12:43 ?        00:00:00 ora_pmon_ora11gr2
oracle    5102     1 0 12:43 ?        00:00:00 ora_vktm_ora11gr2
oracle    5106     1 0 12:43 ?        00:00:00 ora_gen0_ora11gr2
oracle    5108     1 0 12:43 ?        00:00:00 ora_diag_ora11gr2
oracle    5110     1 1 12:43 ?        00:00:00 ora_dbrm_ora11gr2
oracle    5112     1 1 12:43 ?        00:00:00 ora_psp0_ora11gr2
oracle    5116     1 1 12:43 ?        00:00:00 ora_dia0_ora11gr2
oracle    5118     1 24 12:43 ?        00:00:02 ora_mman_ora11gr2
oracle    5120 1 1 12:43 ?        00:00:00 ora_dbw0_ora11gr2
oracle    5122     1 1 12:43 ?        00:00:00 ora_lgwr_ora11gr2
oracle    5124     1 1 12:43 ?        00:00:00 ora_ckpt_ora11gr2
oracle    5126     1 2 12:43 ?        00:00:00 ora_smon_ora11gr2
oracle    5128     1 0 12:43 ?        00:00:00 ora_reco_ora11gr2
oracle    5130     1 6 12:43 ?        00:00:00 ora_mmon_ora11gr2
oracle    5132     1 1 12:43 ?        00:00:00 ora_mmnl_ora11gr2
oracle    5134     1 0 12:43 ?        00:00:00 ora_d000_ora11gr2
oracle    5136     1 0 12:43 ?        00:00:00 ora_s000_ora11gr2
oracle    5206     1 2 12:43 ?        00:00:00 ora_p000_ora11gr2
oracle    5208     1 1 12:43 ?        00:00:00 ora_p001_ora11gr2
oracle    5210     1 1 12:43 ?        00:00:00 ora_qmnc_ora11gr2
oracle    5228     1 2 12:43 ?        00:00:00 ora_cjq0_ora11gr2
oracle    5232 3000 0 12:43 pts/0    00:00:00 grep ora_
[oracle@ora11gr2 ~]$ date
Wed Apr 21 12:43:35 CST 2010

这里你还可以参考kamus大师的文章。

-The End-

ORA-12547: TNS:lost contact

ochef — Sun, 18 Apr 2010 13:21:04 +0000

这个错误还真没碰到过，记录一下。

背景：原本想在VMware+OEL5.3+ORACLE 11.2（已创建了单实例数据库,32bit）上安装Grid Infrastructure，最终目的就是想使用Oracle Restart，Restart是集成在Grid Infrastructure里面的不能单独安装，可以像在10g里使用SRVCTL来管理数据库，当然单实例也是可以的，且还有另一大好处就是用restart管理的资源譬如instance、listener等在进程异常终止后会自动启动（注：在sqlplus中用命令停止的restart不能再次自动启动）。结果grid是安装成功了，但是在SRVCTL中配置实例、监听信息的时候报错无法配置成功，后来想是不是应该先安装grid再安装Oracle最后再建库（后查阅资料grid是可以在已有库上安装的），说干就干，反正按照自己写的文档ctrl+c、ctrl+v的也快，再加上RHEL不久前发布了5.5，ORACLE在之后的一个多星期也放出了OEL5.5，想着测试一下新版本，从安装OS－>修改系统参数、配置Oracle用户环境变量—>安装Oracle软件一切顺利，哪知DBCA到最后一步出现：

ORA-12547: TNS:lost contact

好家伙，半道杀出个程咬金，最初以因xmanager出问题了，由于建库的脚本刚刚已经创建，心想用CRT手工建库得了，往往越想快点看得结果却越看不到结果：

[oracle@ora11.2 ~]$ sqlplus ‘/as sysdba’

SQL*Plus: Release 11.2.0.1.0 Production on Sun Apr 18 09:24:31 2010

ERROR:
ORA-12547: TNS:lost contact

Enter user-name:

兄弟，咋的了，装了无数次系统还从未遇到这种情况啊，什么原因引起的还真不知道，唉，先google一下，说可能是libaio-0.3.106、binutils相关包没有安装，打开Oracle在线文档一个一个检查，可结果是都安装了啊

[root@ora11.2 ~]# uname -a
Linux ora11.2 2.6.18-194.el5 #1 SMP Mon Mar 29 20:06:41 EDT 2010 i686 i686 i386 GNU/Linux
[root@ora11.2 ~]# cat /etc/issue
Enterprise Linux Enterprise Linux Server release 5.5 (Carthage)

[root@ora11.2 ~]# rpm -q –verify `uname -r | awk -FEL ‘{ printf(“kernel-%s-%sEL\n”,$2,$1); }’ | sed ‘s/–/-/g’`
package kernel-2.6.18-194.el5EL is not installed

不知道为什么说我没有安装kernel,实际上是安装了的

[root@ora11.2 ~]# rpm -qa|grep kernel
kernel-headers-2.6.18-194.el5
kernel-2.6.18-194.el5

不行了，上MOS找找，根据ID 272516.1说的，应该是kernel参数设置问题，这里RedHat给出了一张图：

Name	Description	Reasonable Values
`SHMMAX`	Maximum size of shared memory segment (bytes)	250kB + 8.2kB * `shared_buffers` + 14.2kB * `max_connections` or infinity
`SHMMIN`	Minimum size of shared memory segment (bytes)	1
`SHMALL`	Total amount of shared memory available (bytes or pages)	if bytes, same as `SHMMAX`; if pages, `ceil(SHMMAX/PAGE_SIZE)`
`SHMSEG`	Maximum number of shared memory segments per process	only 1 segment is needed, but the default is much higher
`SHMMNI`	Maximum number of shared memory segments system-wide	like `SHMSEG` plus room for other applications
`SEMMNI`	Maximum number of semaphore identifiers (that is, sets)	>= ceil(max_connections / 16)
`SEMMNS`	Maximum number of semaphores system-wide	ceil(max_connections / 16) * 17 + room for other applications
`SEMMSL`	Maximum number of semaphores per set	>= 17
`SEMMAP`	Number of entries in semaphore map	see text
`SEMVMX`	Maximum value of semaphore	>= 255 (The default is often 32767, do not change unless asked to.)

结果反复的检查调整内核参数，二个比较重要的参数：

kernel.shmall = 2097152 共享内存总量，以页为单位,对于32位系统，一页=4k，也就是4096字节,2097152*4k/1024/1024 = 8G 就是说可用共享内存一共8G
kernel.shmmax = 2147483648 （默认536870912，512M）以字节为单位

检查oracle的环境变量，relink all等一系列操作结果错误依旧没有消除。突然想起在安装64位系统的时候，默认只安装了32位的包，必须手工再次安装相应64位的包，那反过来是不是安装32位是不是也需要64位的某些包（当时确实这样想的，现在觉得有点扯啊），在经历三个多小时的下载时间后强行安装部分64位的包后重启系统，测试，FT。

现在怀疑是OEL与Oracle软件版本兼容的问题，如果有解决过相同问题的朋友还请告之。

-The End-

db_files and maxdatafiles argument

ochef — Fri, 09 Apr 2010 14:33:59 +0000

今天学习了db_files和maxdatafiles两个参数，记录一下。比较了9i、10g、11g三个版本，在我的实验环境中（都是默认没有修改过的），9i、10g、11g的db_files默认值为200，而9i、11g的maxdatafiles为100，10g rac环境为1024，单实例为100。db_files参数在数据库的初始化参数文件中指定，maxdatafiles在控制文件中指定,一般db_files<=maxdatafiles。如果在添加一个数据文件时，其编号已经超出了maxdatafiles的设定值，但是小于或等于db_files的设定值，控制文件会自动扩展maxdatafiles的值以满足容纳更多的数据文件信息的需求，所以指定db_files参数的值对数据库更为关键和重要，因为maxdatafiles会自动扩展。

BTW:指定db_files的值会影响数据库内存的使用，详情请参考eagle的相关文章。

-The End-

AIX network buffer参数设置引起RAC故障

ochef — Fri, 26 Mar 2010 04:49:54 +0000

故障日期：2010年3月23日 11:30 AM

生产环境：数据库： Oracle 10.2.0.4 2Nodes RAC

操作系统：AIX 5309

故障现象：

现象1：在23日上午11:30，发现应用系统不能连接到RAC的实例1（Instance name:int1），此时实例2是正常的。

现象2：使用辅助工具TOAD也不能连接到实例1。

现象3：在实例1所在机器的本地使用SQLPLUS可以连接到实例1，此时也能在实例2上通过TNS连接到实例1。

现象4：15：19重启实例1后系统恢复正常。

故障分析：

1.根据实例1的alert log日志记载，在11：30记录的错误如下：

Tue Mar 23 11:30:08 2010

WARNING: inbound connection timed out (ORA-3136)

Tue Mar 23 11:32:05 2010

WARNING: inbound connection timed out (ORA-3136)

首先来了解ORA-3136这个错误，该错误表示客户端在sqlnet.ora文件中SQLNET.INBOUND_CONNECT_TIMEOUT参数定义的时间内没有完成登录认证，该参数默认值为60S，据Oracle官方文档记载，此默认值能够满足绝大多数条件；此外该错误还涉及到listener.ora文件中定义的参数INBOUND_CONNECT_TIMEOUT_LISTENER，Oracle 10.2.0.1之前默认值为0，从10.2.0.1开始默认值为60S，根据alert log日志记录的其它信息，目前暂时排除实例1的错误是由以上参数造成。

2.Alert log还记载

……

Tue Mar 23 12:15:36 2010

Errors in file /soft/oracle/admin/int/udump/int1_ora_2617378.trc:

ORA-00600: internal error code, arguments: [12333], [7], [2], [49], [], [], [], []

……

根据Oracle metalink文档[ID 35928.1]描述：“Fatal Two-Task Protocol Violation”

ORA-600 [12333]描述收到一个没有经过验证的无效的网络数据包，这里有二个可能：一是客户端多线程的应用发送了一个无顺序的OCI调用请求，二是网络缓冲区中的数据可能被覆盖，进一步查看trace文件，可以看到每个trace文件的开关处都有：PROTOCOL VIOLATION DETECTED。

另外，由贵行的带内网管软件Tivoli监控到故障当时RAC心跳网络（ent8）的通信流量信息证明，当时心跳网络流量确实比正常情况下高，RAC 采用UDP 协议进行节点间的互联通信，查询系统统计如下：

RACDB1# netstat -p udp -s

udp:

574337869 datagrams received

0 incomplete headers

0 bad data length fields

0 bad checksums

169617 dropped due to no socket

32335 broadcast/multicast datagrams dropped due to no socket

243 socket buffer overflows

574135674 delivered

500048775 datagrams output

RACDB2# netstat -p udp -s

udp:

500187207 datagrams received

0 incomplete headers

0 bad data length fields

0 bad checksums

171357 dropped due to no socket

32333 broadcast/multicast datagrams dropped due to no socket

2108 socket buffer overflows

499981409 delivered

574427147 datagrams output

以上信息可以看到，由于系统网络参数network buffer设置不当出现通信问题，查看涉及network buffer大小的参数：

#no -a |pg

sb_max = 1310720

udp_recvspace = 655360

udp_sendspace = 65536

sb_max被用来指定允许的TCP和UDP socket的最大缓冲区大小，默认值为1048576 bytes，1048576 bytes，很显然，udp_recvspace与udp_sendspace设置不对称且sb_max参数设置过小。

3.ORA-600 [12333]的错误也可以由JDBC驱动版本与Oracle数据库版本不一致造成，但贵行此套系统已上线很久，由此可以暂时先排除该原因。另外，根据trace文件的记录，在故障期间有大量的UNION联合查询操作，而这种大量的UNION操作会增加节点间的通信，ashrpt的报告也证实了gc buffer busy随故障时间增加，到最后被剔出RAC降下来。

初步结论：

基于以上情况分析，现初步判断此次故障为：由系统网络buffer参数设置不当引起RAC 节点间的互联网络故障，而节点间的互联网络用于协调各个节点的运行，包括全局锁(global locking) ，队列(enqueue) 和缓存管理(buffer cache management)，建议udp_sendspace 的起始值为db_block_size * db_file_multiblock_read_count ，udp_recvspace 设为udp_sendspace 的4 倍，上限为1048576 。如果发生socket 缓存溢出( 可通过 netstat -s | grep “socket buffer overflows” 命令察看) udp_recvspace 参数值需要增加，netstat -p udp -s的结果也证实了这一点。

BTW:这里还有EYGLE大师的文章供参考：

IBM AIX Oracle 9i RAC 性能因素 – udp及其他

-The End-