天道酬勤 » Database

Oracle Database Fails to Start with Error ORA-12547

ochef — Mon, 09 Jan 2012 05:35:39 +0000

今天我的虚拟测试环境中的11.2的库自上次关机后今天启动突然报错，记录以下过程备查。

SQL> SELECT * FROM v$version;
 
BANNER
--------------------------------------------------------------------------------
Oracle DATABASE 11g Enterprise Edition RELEASE 11.2.0.2.0 - 64bit Production
PL/SQL RELEASE 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS FOR Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

启动数据库时报错：

SQL> startup
ORACLE instance started.
 
Total SYSTEM Global Area  734892032 bytes
Fixed SIZE                  2230120 bytes
Variable SIZE             448792728 bytes
DATABASE Buffers          276824064 bytes
Redo Buffers                7045120 bytes
ORA-00205: error IN identifying control FILE, CHECK alert LOG FOR more info

根据alert log找到trace文件：

[oracle@ORCL112 ~]$ more /u01/app/oracle/diag/rdbms/orcl112/orcl112/trace/orcl112_asmb_6745.trc
Trace FILE /u01/app/oracle/diag/rdbms/orcl112/orcl112/trace/orcl112_asmb_6745.trc
Oracle DATABASE 11g Enterprise Edition RELEASE 11.2.0.2.0 - 64bit Production
WITH the Partitioning, OLAP, Data Mining AND REAL Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
SYSTEM name:    Linux
Node name:      ORCL112
RELEASE:        2.6.18-92.el5
Version:        #1 SMP Fri May 23 23:40:43 EDT 2008
Machine:        x86_64
VM name:        VMWare Version: 6
Instance name: orcl112
Redo thread mounted BY this instance: 0 <none>
Oracle process NUMBER: 16
Unix process pid: 6745, image: oracle@ORCL112 (ASMB)
 
*** 2011-11-10 12:42:57.949
*** SESSION ID:(8.1) 2011-11-10 12:42:57.950
*** CLIENT ID:() 2011-11-10 12:42:57.950
*** SERVICE NAME:() 2011-11-10 12:42:57.950
*** MODULE NAME:() 2011-11-10 12:42:57.950
*** ACTION NAME:() 2011-11-10 12:42:57.950
 
WARNING: failed TO START ASMB (connection failed) state=0x1 sid='+ASM' home='/u01/app/grid/product/11.2.0/grid'
ORA-15055: unable TO CONNECT TO ASM instance
ORA-12547: TNS:lost contact

[grid@ORCL112 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER     STATE_DETAILS   Local Resources
ora.DG01.dg    ONLINE  ONLINE       orcl112                         
ora.asm        ONLINE  ONLINE       orcl112     Started

MOS上有相关文档：[ID 1307075.1]
是由于$GRID_HOME/bin/oracle和$ORACLE_HOME/bin/oracle文件权限不当导致连接ASM实例失败的。
ls -al $GRID_HOME/bin/oracle
-rwxr-x--x 1 grid oinstall 200678464 Feb 28 14:54 oracle
 
ls -al $ORACLE_HOME/bin/oracle
-rwxr-x--x 1 oracle asmadmin 228886191 Feb 28 15:41 oracle 
而在我的环境中只有$GRID_HOME/bin/oracle文件权限发生改变
[grid@ORCL112 bin]$ cd /u01/app/grid/product/11.2.0/grid/bin
[grid@ORCL112 bin]$ ls -l oracle
-rwxrwxr-x 1 grid oinstall 200678464 Jul 15 23:18 oracle

解决方法很简单：
oracle binary的正确权限是：6751
cd $GRID_HOME/bin
chmod 6751 oracle
 
cd $ORACLE_HOME/bin
chmod 6751 oracle
修改之后再检查一下
ls -l oracle
-rwsr-s--x 1 grid oinstall 152400480 Nov 24 15:49 oracle
如果数据库启动仍然失败，重新启动GI

修改之后数据库正常启动
[root@ORCL112 bin]# chmod 6751 oracle
[root@ORCL112 bin]# ls -l oracle
-rwsr-s--x 1 grid oinstall 200678464 Jul 15 23:18 oracle
SQL> startup
ORACLE instance started.
 
Total SYSTEM Global Area  734892032 bytes
Fixed SIZE                  2230120 bytes
Variable SIZE             448792728 bytes
DATABASE Buffers          276824064 bytes
Redo Buffers                7045120 bytes
DATABASE mounted.
DATABASE opened.

-The End-

Install Oracle EBS R12.1.1 on OEL5.6

ochef — Thu, 14 Apr 2011 13:12:40 +0000

最近公司有一个ERP的项目，客户选用Oracle E-Business Suit R12。在这之前我从未使用过任何ERP软件，既然这样，最好的办法就是自己搭建一个环境感受一下。

Install oracle ebs r12.1.1 on OEL5.6 x86(include demo)

View more presentations from ochef yang.

无有效备份下恢复数据库一例

ochef — Wed, 24 Nov 2010 13:30:44 +0000

昨天通宵恢复一个1T的数据库，早上6点成功恢复，立即开始备份。7点回家睡觉下午三点起床，也许这就是一个DBA的生活。本想现在写写恢复过程，不过又想睡觉了，明天好好写吧。

Updated @ 2010-12-07

一、系统背景：

硬件： P690_1和P670_1

操作系统：A IX 5.2 ML04

数据库： Oracle 9.2.0.1.0 2 Nodes RAC HA

备库P570（非DG）：与DG原理类似，利用生产库的归档日志在P570上恢复

故障时间：2010-11-23 13:20

二、故障现象：

数据库系统在13：19报告SYSTEM表空间空间不够无法自动扩展，因为系统使用RAW设备所以无法自动扩展，需要管理员手工增加RAW设备文件。

Tue Nov 23 13:18:41 2010

Completed: alter database backup controlfile to ‘/p690_1_arch

Tue Nov 23 13:19:20 2010

ORA-1653: unable to extend table WWW.MLOG$_WWW_MONEY_T by 8192 in tablespace SYSTEM

……

客户工程师在P670_1节点上新增RAW设备并增加到SYSTEM表空间：

RAW设备：/dev/rwwwdb_system04

SQL>alter tablespace system add ‘/dev/rwwwdb_system04’ reuse;

随后系统报错：

ORA-01157: cannot identify/lock data file 424 – see DBWR trace file

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

ORA-27037: unable to obtain file status

IBM AIX RISC System/6000 Error: 2: No such file or directory

Additional information: 3

Tue Nov 23 14:17:03 2010

Errors in file /oracle/ora92/admin/wwwdb/bdump/wwwdb1_dbw0_516116.trc:

ORA-01186: file 424 failed verification tests

ORA-01157: cannot identify/lock data file 424 – see DBWR trace file

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

Tue Nov 23 14:17:03 2010

File 424 not verified due to error ORA-01157

dbv检查数据文件，报文件坏块：

DBVERIFY – Verification starting : FILE = /dev/rwwwdb_system04

Page 1 is influx – most likely media corrupt

Corrupt block relative dba: 0×00000001 (file 0, block 1)

Fractured block found during dbv:

Data in bad block:

type: 0 format: 0 rdba: 0×00000000

last change scn: 0×0000.00000000 seq: 0×0 flg: 0×00

spare1: 0×0 spare2: 0×0 spare3: 0×0

consistency value in tail: 0×00000000

check value in block header: 0×0

此时，由于系统表空间不足数据库系统被挂起，欲将增加失败的数据文件离线删除后重启数据库实例报错：

SQL>ALTER DATABASE DATAFILE ‘/dev/rwwwdb_system04′ offline drop;

Tue Nov 23 14:56:18 2010

ORA-1541 signalled during: ALTER DATABASE DATAFILE ‘/dev/rwwwdb_system04′ off…

This instance was first to open

ORA-1147 signalled during: alter database open…

ORA-01122: database file 424 failed verification check

ORA-01110: data file 424: ‘/dev/rwwwdb_system04′

ORA-01251: Unknown File Header Version read for file number 26

不要受[ID 422031.1]ORA-01122, ORA-01251 or data blocks reported as corrupted影响，否则方向错了会花比较多的时间

时间：16：00

由于系统数据量大，在生产库不能短时间恢复情况下的

措施：启动P570备库

结果：启动备库P570失败

原因：在10月19增加数据库文件/dev/rphoto1026时出错，需要恢复。

时间：16：20

措施：利用生产系统RMAN备份来恢复

结果：无法恢复

原因：每晚8点的定时备份任务在14日由于备份空间不足备份失败，后续没有任务备份；系统归档日志保留策略为7天，若要恢复到14日备份前，缺少1天的归档日志文件。

时间：16：30

措施：向公司上级汇报情况，商议决策

结果：与Oracle原厂工程取得系统，商议决策如下：

1. 保护好生产系统现状

2. 使用操作系统级dd命令备份生产系统所有数据文件

3. 将备份的文件用dd命令恢复到备库P570

4. 在备库P570上做恢复测试

时间：24日2：30

措施：在P570备机上重建control file，剔除/dev/rwwwdb_system04数据文件，尝试打开数据库。

结果：open失败

原因：Oracle 9i 系统表空间数据文件不能真正删除（10g开始可以）。

再次如下恢复操作：

重新创建/dev/rwwwdb_system04文件

SQL> alter database create datafile ‘/dev/rwwwdb_system04′ as ‘/dev/rwwwdb_system04′;

结果：open成功

三、生产系统恢复过程：

1. 重建control file

获取重建控制文件的脚本，并修改相应部分

SQL> alter database backup controlfile to trace;

CREATE CONTROLFILE REUSE DATABASE “WWWDB” NORESETLOGS FORCE LOGGING ARCHIVELOG

– SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 192

MAXLOGMEMBERS 3

MAXDATAFILES 1024

MAXINSTANCES 32

MAXLOGHISTORY 3403

LOGFILE

GROUP 1 ‘/dev/rwwwdb_log24′ SIZE 268430848,

GROUP 2 ‘/dev/rwwwdb_log25′ SIZE 268430848,

GROUP 3 ‘/dev/rwwwdb_log26′ SIZE 268430848,

GROUP 4 ‘/dev/rwwwdb_log27′ SIZE 268430848,

GROUP 5 ‘/dev/rwwwdb_log28′ SIZE 268430848,

GROUP 6 ‘/dev/rwwwdb_log29′ SIZE 268430848,

GROUP 7 ‘/dev/rwwwdb_log14′ SIZE 268430848,

GROUP 8 ‘/dev/rwwwdb_log15′ SIZE 268430848,

GROUP 9 ‘/dev/rwwwdb_log16′ SIZE 268430848,

GROUP 10 ‘/dev/rwwwdb_log17′ SIZE 268430848,

GROUP 11 ‘/dev/rwwwdb_log18′ SIZE 268430848,

GROUP 12 ‘/dev/rwwwdb_log19′ SIZE 268430848

……

2. 修改启动参数文件，将控制文件存放路径临时指定到一个新位置，并启动数据库到 nomount状态

3. 执行重建控制文件的脚本，启动数据库mount状态

SQL>@bldctl.sql

SQL>alter database mount;

4. 创建数据文件/dev/rwwwdb_system04

SQL>alter database create datafile ‘/dev/rwwwdb_system04′ as ‘/dev/rwwwdb_system04′;

5. 重启数据库到mount状态,恢复/dev/rwwwdb_system04文件

SQL>startup mount;

SQL>ALTER DATABASE RECOVER datafile ‘/dev/rwwwdb_system04′ ;

Wed Nov 24 03:37:47 2010

Media Recovery Datafile: ‘/dev/rwwwdb_system04′

Media Recovery Start

Starting datafile 424 recovery in thread 2 sequence 26019

Datafile 424: ‘/dev/rwwwdb_system04′

Media Recovery Log

Recovery of Online Redo Log: Thread 2 Group 2 Seq 26019 Reading mem 0

Mem# 0 errs 0: /dev/rwwwdb_log25

Recovery of Online Redo Log: Thread 1 Group 12 Seq 31759 Reading mem 0

Mem# 0 errs 0: /dev/rwwwdb_log19

Media Recovery Complete

Completed: ALTER DATABASE RECOVER datafile ‘/dev/rwwwdb_syst em04′ ;

6. 尝试打开数据库

SQL>alter database open;

报错：ORA-1113 signalled during: alter database open…，数据库需要恢复

7. 恢复数据库

SQL>alter database recover database;

Media Recovery Start

Starting datafile 1 recovery in thread 2 sequence 26019

Datafile 1: ‘/dev/rwwwdb_system’

Starting datafile 2 recovery in thread 2 sequence 26019

Datafile 2: ‘/dev/rwwwdb_index01′

……

Successfully onlined Undo Tablespace 27.

Dictionary check beginning

Tablespace ‘WWW_PHOTO04′ #16 found in data dictionary,

but not in the controlfile. Adding to controlfile.

Tablespace ‘WWW_PHOTO06′ #17 found in data dictionary,

but not in the controlfile. Adding to controlfile.

Tablespace ‘WWW_PHOTO07′ #18 found in data dictionary,

but not in the controlfile. Adding to controlfile.

……

Wed Nov 24 03:38:45 2010

File #370 found in data dictionary but not in controlfile.

Creating OFFLINE file ‘MISSING00370′ in the controlfile.

File #371 found in data dictionary but not in controlfile.

Creating OFFLINE file ‘MISSING00371′ in the controlfile.

File #372 found in data dictionary but not in controlfile.

…

8. 重启数据库

SQL>shutdown immediate;

SQL>startup;

Wed Nov 24 04:00:11 2010

alter database open

This instance was first to open

Picked Lamport scheme to generate SCNs

Wed Nov 24 04:00:11 2010

9. 将控制文件恢复到RAW设备上

SQL>shutdown immediate;

$dd if= /dbbak/cntrl7 of= /dev/rwwwdb_cntrl3 bs=2m

$dd if= /dbbak/cntrl8 of= /dev/rwwwdb_cntrl4 bs=2m

$dd if= /dbbak/cntrl9 of= /dev/rwwwdb_cntrl5 bs=2m

修改启动参数文件initwwwdb1.ora，还原控制文件存放位置

SQL>startup pfile=?/dbs/initwwwdb1.ora

SQL>create spfile from pfile;

SQL>shutdown immediate;

SQL>startup;

10. 执行在重建控制文件时没有执行的命令，并将数据库中只读表空间online

# Files in read-only tablespaces are now named.

ALTER DATABASE RENAME FILE ‘MISSING00015′

TO ‘/dev/rwww_photo0611′;

ALTER DATABASE RENAME FILE ‘MISSING00016′

TO ‘/dev/rwww_photo0612′;

ALTER DATABASE RENAME FILE ‘MISSING00020′

TO ‘/dev/rwww_photo0626′;

ALTER DATABASE RENAME FILE ‘MISSING00022′

TO ‘/dev/rwww_photo0627′;

ALTER DATABASE RENAME FILE ‘MISSING00023′

……

# Online the files in read-only tablespaces.

ALTER TABLESPACE “WWW_PHOTO04″ ONLINE;

ALTER TABLESPACE “WWW_PHOTO06″ ONLINE;

ALTER TABLESPACE “WWW_PHOTO07″ ONLINE;

ALTER TABLESPACE “WWW_PHOTO05″ ONLINE;

ALTER TABLESPACE “WWW_PHOTO08″ ONLINE;

ALTER TABLESPACE “WWW_PHOTO09″ ONLINE;

# No tempfile entries found to add.

至此，生产系统数据库成功打开。

P670_1节点处理：

检查P670_1节点，发现主机访问DS4500存储系统上共享VG出现问题，为数据安全起见，先在P690_1节点备份数据库再处理P670_1节点。

四、故障分析：

在备份成功后，处理P670_1节点发现，DS4500存储系统B控制器坏掉，而引发了增加SYSTEM表空间失败。在更换存储系统控制器后，P670_1节点正常工作。

五、改进与预防措施：

1. 完善备份策略

2. 改善P570备库方式（采用rman备份归档日志，再恢复归档日志）

3. 每天检查生产系统的备份情况，及时发现问题及时处理。

-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-

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-