天道酬勤 » Database

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-

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-

中国Oracle用户组

ochef — Sun, 07 Mar 2010 10:31:13 +0000

最近一老失眠，今儿一大清早就爬起来上网，从google的订阅服务得知：由EYGLE与KAMUS二位大师发起并成立了中国Oracle用户组ACOUG（All China Oracle User Group）。届时，越来越多的数据库爱好者、Oracle爱好者将会出没这里。well，so……一线民工以此博文当贺电来表达喜悦心情，各位工友欲知更多详情请参考官网，谢谢!

-The End-

Surprise!第一本《Oracle DBA手记》

ochef — Fri, 22 Jan 2010 15:20:26 +0000

Wow，昨天在Eygle大师的Blog上看到《Oracle DBA手记》已经上架了，先恭喜一下这几位大牛（Eygle、Yangtingkun、老熊、zergduan、banping）出了新作。继续往下看，没想到第一本书是寄给我的，这里谢谢Eygle，谢谢几位大牛们，感谢Julia，因为我想大师业务缠身应该没有时间寄书：）。农历新年快到了，这本书对我来说是新年最好的礼物，同时也是莫大的鼓舞，告诫自己努力。图片作证：

-The End-

VIP Failover Take Long Time After Network Cable Pulled

ochef — Mon, 11 Jan 2010 02:13:25 +0000

在一个10g RAC环境中测试拔掉网线，vip的切换花了很长时间，在oracle support上搜索如下：

[ID 403743.1]

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.1.0.7

This problem can occur on any platform.

Symptoms

This example is based on SUN Solaris platform, with IPMP configured for the public network. In this case, VIP failover takes almost 4 minutes to complete when both network cables of the public network are pulled from one node.

crsd.log shows:

2006-12-07 13:14:05.401: [ CRSAPP][4588] CheckResource error for ora.node1.vip error code = 1

2006-12-07 13:14:05.408: [ CRSRES][4588] In stateChanged, ora.node1.vip target is ONLINE

2006-12-07 13:14:05.409: [ CRSRES][4588] ora.node1.vip on node1 went OFFLINE unexpectedly

<<< detect network cable failure and VIP OFFLINE immediately

2006-12-07 13:14:05.410: [ CRSRES][4588] StopResource: setting CLI values

2006-12-07 13:14:05.420: [ CRSRES][4588] Attempting to stop `ora.node1.vip` on member `node1`

2006-12-07 13:14:06.651: [ CRSRES][4588] Stop of `ora.node1.vip` on member `node1` succeeded.

2006-12-07 13:14:06.652: [ CRSRES][4588] ora.node1.vip RESTART_COUNT=0 RESTART_ATTEMPTS=0

2006-12-07 13:14:06.667: [ CRSRES][4588] ora.node1.vip failed on node1 relocating.

2006-12-07 13:14:06.758: [ CRSRES][4588] StopResource: setting CLI values

2006-12-07 13:14:06.766: [ CRSRES][4588] Attempting to stop `ora.node1.LISTENER_NODE1.lsnr` on member `node1`

2006-12-07 13:17:41.399: [ CRSRES][4588] Stop of `ora.node1.LISTENER_NODE1.lsnr` on member `node1` succeeded.

<<< takes 3.5 minutes to stop listener

2006-12-07 13:17:41.402: Attempting to stop `ora.node1.ASM1.asm` on member `node1`

<<< stop dependant inst and ASM

2006-12-07 13:17:55.610: [ CRSRES][4588] Stop of `ora.node1.ASM1.asm` on member `node1` succeeded.

2006-12-07 13:17:55.661: [ CRSRES][4588] Attempting to start `ora.node1.vip` on member `node2`

2006-12-07 13:18:00.260: [ CRSRES][4588] Start of `ora.node1.vip` on member `node2` succeeded.

<<< now VIP failover complete after almost 4 mins

ora.node1.LISTENER_NODE1.lsnr.log shows:

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1vip)(PORT=1521)(IP=FIRST)))

TNS-12535: TNS:operation timed

2006-12-07 13:17:41.329: [ RACG][1] [23916][1][ora.node1.LISTENER_NODE1.lsnr]: out

TNS-12560: TNS:protocol adapter error

TNS-00505: Operation timed out

Solaris Error: 145: Connection timed out

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.10.100)(PORT=1521)(IP=FIRST)))

The command completed successfully

Client connection hang during this failover time.

Changes

This may be a new setup, or a setup that was migrated from an earlier release.

Cause

This problem is caused by the first address in the listener.ora configuration being an address that uses the TCP protocol.

In this circumstance, when a network cable is pulled, “lsnrctl stop” listener has to wait for TCP timeout before it can check next address. On the Solaris platform, TCP timeout is defined by tcp_ip_abort_cinterval with a default value of 180000 (3 minutes). That is why shutting down listener almost took 3.5 minutes. (TCP timeout on other platforms may vary). The error message “Solaris Error: 145: Connection timed out” in ora.node1.LISTENER_NODE1.lsnr.log also indicates it is waiting for tcp timeout.

The listener.ora in this scenario is defined as:

LISTENER_NODE1 =
 
(DESCRIPTION_LIST =
 
(DESCRIPTION =
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = TCP)(HOST = node1vip)(PORT = 1521)(IP = FIRST))
 
)
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.100)(PORT = 1521)(IP = FIRST))
 
)
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
 
)
 
)
 
)

Solution

To prevent this, move the IPC address to be the first address for the listener in the listener.ora, eg:

LISTENER_NODE1 =
 
(DESCRIPTION_LIST =
 
(DESCRIPTION =
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
 
)
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = TCP)(HOST = node1vip)(PORT = 1521)(IP = FIRST))
 
)
 
(ADDRESS_LIST =
 
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.100)(PORT = 1521)(IP = FIRST))
 
)
 
)
 
)

When lsnrctl tries to stop the listener, it will now connect to the IPC address first, which is available during that time. It will not have to wait for tcp timeout.

After the above change, the VIP failover only takes 48 to 50 seconds to complete regardless of the tcp_ip_abort_cinterval setting.

Please note, listener.ora files newly created from 10.2.0.3 to 11.1.0.7 should have the IPC protocol as the first address in listener.ora in most cases. However, if you have upgraded from a previous release, or manually modified/copied over a listener.ora from a previous install, you may not have the IPC protocol as the first address, regardless of your version. Manual modification is required to move IPC protocol to be the first address to avoid the problem described in this note.

BTW：梦想有多远的blog也有说明。

-The End-