blue_prince: Oracle

RAC:Write-to-Read Transfer

Fri, 13 Jun 2008 06:07:59 GMT

The behavior of the write-to-read transfer is determined by the _FAIRNESS_THRESHOLD parameter,which was introduced in Oracle 8.1.5 and defaults to 4. Prior to the introduction of this parameter,when Instance A held a block in exclusive mode and Instance B requested a read-only copy of that block, Instance A would downgrade its exclusive lock to a shared lock and send the block to Instance B,which would also set a shared lock on the block. However, if Instance A is performing frequent updates
on the block, it will need to reacquire the block and set an exclusive lock again. If this process is repeated frequently, then Instance A will be continually interrupted, as it has to downgrade the exclusive lock to a shared lock and wait until Instance B has finished reading the block before it can convert the shared lock back into an exclusive lock.
The _FAIRNESS_THRESHOLD parameter modifies this behavior. When this parameter is set,Instance A will no longer downgrade the exclusive lock. Instead, it sends a null lock to Instance B,and then it can continue processing. However, if instance B requests the block _FAIRNESS_THRESHOLD times, by default 4, then Instance A will revert to the original behavior—it will downgrade the exclusive lock to a shared lock and ship the block to Instance B, which will also set a shared lock on the block.

From:Pro Database 10g RAC on Linux

RAC建库时报ASM单实例错误的解决办法

Thu, 12 Jun 2008 03:06:08 GMT

安装好RAC后，在用DBCA建库时选择ASM做为存储方案时，有时候会报错说ASM是单实例环境，不是RAC环境，这样就无法继续建库下来，出错信息如下：

The ASM instance configured on the local node is a single-instance ASM.To create a single-instance database using this ASM instance ,restart DBCA and select the single-instance database option ,to create a RAC database using this ASM instance,convert it to RAC ASM first.

这个错误一般是发生在重装clusterware和database后，这样无论怎么样重启DBCA运行都会报同样的错。具体的解决办法便是在/etc/oratab里面的关于ASM的记录：+ASM1:/u01/app/oracle/product/10.2.0/db_1:N这么一行删除掉，再接着建库就可以了。碰到过多次这个错误，记录在这里备忘一下。

使用DBMS_FILE_TRANSFER配置DATA GURAD和克隆数据库

Thu, 15 May 2008 08:36:41 GMT

通常我们配置DATA GUARD，都需要对主库进行备份，再把备份的备份集复制到备库端进行配置。但是当数据库非常大时，尤其是数据库采用ASM作为存储方案时，如果没有足够的空间用于存放备份集，这样显然就无法通过常规的方式来配置STANDBY。利用DBMS_FILE_TRANSFER则可以方便地将主库的数据文件直接传递至备库的ASM磁盘组，这样再也不需要使用中间存储存放备份文件。下面简单介绍一下通过DBMS_FILE_TRANSFER配置基于ASM存储方案的DATA GUARD和克隆数据库的方法。

一、在备用数据库端创建好ASM磁盘组和一个中间数据库。
首先必须要在备用数据库端配置好ASM实例，创建好ASM磁盘组，并且ASM磁盘组的名字最好是和主库一样的。当然，名字不一样也可以，那就需要一些额外的设置。另外由于DBMS_FILE_TRANSFER远程传输是基于DB LINK的，因此需要在备用库端创建一个中间数据库，这个中间数据库的主要作用便是用于DB LINK传输数据文件。假定我们创建的ASM磁盘组叫DATA，中间数据库名字叫transfer。
二、在备用库的中间数据库上创建一个到主库的DB LINK。做之前需要配置好到主库的TNS。

SQL>create database link lnk_pri connect to system identified by password using ‘primary’;

三、在主库端创建到数据文件目录的directory。

SQL> create or replace directory pri_dir as ‘+DATA/TEST/datafile’;

四、在备库端创建好备库的相应目录，比如bdump，udump等目录，另外在备库的ASM实例中创建备库的数据文件、控制文件等目录。

SQL> alter diskgroup DATA add directory ‘+DATA/TEST/’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/DATAFILE’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/CRONTROLFILE’;
SQL> alter diskgroup DATA add directory ‘+DATA/TEST/TEMPFILE’;

五、在备库的中间数据库上创建好两个DIRECTORY，用于存放传递过来的数据文件和控制文件。

SQL> create or replace directory stb_dir as ‘+DATA/TEST/datafile’;
SQL> create or replace directory stb_ctl_dir as ‘+DATA/TEST/controlfile’;

六、在中间数据库开始传输数据文件。
由于是在线配置STANDBY，在传输数据文件之前，必须先在主库把相应的表空间置于恢复模式，然后利用dbms_file_transfer进行数据文件的传输，最后再把相应的表空间置为正常状态：

SQL> conn sys/password@lnk_pri as sysdba
SQL> alter tablespace system begin backup;
SQL> conn /as sysdba
SQL>begin
dbms_file_transfer.get_file(
source_directory_object => ‘ pri_dir ‘,
source_file_name => ‘ system.286.650339101′,
destination_directory_object => ‘ stb_dir ‘,
destination_file_name => ‘ system01.dbf ‘,
source_database => ‘lnk_pri’);
end;
/
SQL> conn sys/password@lnk_pri as sysdba
SQL> alter tablespace system end backup;

这样依次对主库的每个数据文件进行处理传递后，主库上的数据文件都会传递至备库的ASM磁盘组上。
七、传输备库的控制文件。
首先在主库端生成备库的控制文件：

SQL> alter database create standby controlfile as ‘+DATA/TEST/datafilefile/standby.ctl’;

如果是克隆数据库的话，那么生成一个普通备份控制文件即可：

SQL> alter database backup controlfile to ‘+DATA/TEST/datafilefile/standby.ctl’;

然后传输控制文件：

SQL>begin
dbms_file_transfer.get_file(
source_directory_object => ‘ pri_dir ‘,
source_file_name => ‘ standby.ctl’,
destination_directory_object => ‘ stb_ctl_dir ‘,
destination_file_name => ‘ control01.ctl ‘,
source_database => ‘lnk_pri’);
end;
/

八、配置备用库。

首先配置好备库的参数文件，并且配置好主库和备库的TNS，接下就可以配置备用库了：
启动备库至mount状态

SQL > startup nomount
SQL > alter database mount standby database;

如果是配置克隆数据库的话，则直接将数据库MOUNT就行：

SQL > alter database mount;

执行RMAN的catalog命令，以使控制文件能够识别传输过来的数据文件：

RMAN> catalog start with ‘+DATA/TEST/DATAFILE’;

然后将这些数据文件转换为备库的数据文件：

RMAN >switch database to copy;

如果是配置DATA GUARD的话，则可以将备库置为恢复模式：

SQL > alter database recover managed standby database disconnect from session;

如果是配置克隆数据库的话，那么直接恢复数据库并打开：

SQL >recover database until cancel;
SQL >alter database open resetlogs;

这样DATA GUARD和克隆数据库就配置完成了。最后可以把中间操作创建的directory，DB LINK和中间数据库删除掉。

利用DBMS_FILE_TRANSFER传输数据库文件

Wed, 14 May 2008 08:05:13 GMT

从Oracle 10g开始，Oracle提供了DBMS_FILE_TRANSFER这么一个程序包，可以方便地在本地数据库和远程数据库，ASM和文件系统间传输数据库文件。这样数据库文件的传输就方便了许多，尤其是在传输基于ASM存储的数据文件时，不再局限于利用RMAN来进行传输。下面介绍一下这个包的用法。

DBMS_FILE_TRANSFER包一共包含了3个存储过程，分别提供本机之间、本机从远程主机抓取以及本机上传至远程主机三种传输数据库文件的功能。要求传输用户有对源目录读和对目标目录写的权限，单个数据库文件必须是512字节的整数倍并且文件大小必须小于或者等于2TB。

1、COPY_FILE。可以在数据库本机的文件系统之间，ASM磁盘组之间或者文件系统和ASM磁盘组之间方便地传输数据库文件。

DBMS_FILE_TRANSFER.COPY_FILE(
source_directory_object IN VARCHAR2,–源目录
source_file_name IN VARCHAR2,–源文件名
destination_directory_object IN VARCHAR2,–目标目录
destination_file_name IN VARCHAR2);–目标文件名
SQL> create directory data as ‘+DATA/HELLODB/DATAFILE’;
SQL> create directory test as ‘+TEST/HELLODB/DATAFILE’;
SQL> exec DBMS_FILE_TRANSFER.COPY_FILE(’DATA’,’system.286.650339101′, ‘TEST’,’system.dbf’)
ASMCMD> ls -a
+TEST/HELLODB/DATAFILE/system.dbf => COPY_FILE.256.654701983

2、GET_FILE。从远程数据库读取数据库文件并在本机的文件系统或者ASM磁盘组上创建一份复制文件。

DBMS_FILE_TRANSFER.GET_FILE(
source_directory_object IN VARCHAR2,
source_file_name IN VARCHAR2,
source_database IN VARCHAR2, –到远程数据库的db link名
destination_directory_object IN VARCHAR2,
destination_file_name IN VARCHAR2);
begin
DBMS_FILE_TRANSFER.COPY_FILE(’DATA’,’system.286.650339101′, ‘lnk_test’,’TEST1′,’system.dbf’);
end;
/

3、PUT_FILE。在本地数据库将数据库文件传输至远程数据库的文件系统或者ASM磁盘组。

DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object IN VARCHAR2,
source_file_name IN VARCHAR2,
destination_directory_object IN VARCHAR2,
destination_file_name IN VARCHAR2,
destination_database IN VARCHAR2); –到目标数据库的db link名
begin
DBMS_FILE_TRANSFER.COPY_FILE(’DATA’,’system.286.650339101′, ‘TEST2′,’system.dbf’, ‘lnk_test’);
end;
/

RAC升级到10.2.0.4碰到的几个问题及处理办法

Wed, 02 Apr 2008 06:20:56 GMT

上周末将10.2.0.3的RAC数据库升级到10.2.0.4。在升级过程中碰到了几个问题，记录一下解决办法。

第一个是在CRS打完Patch之后运行root102.sh脚本时报：

Preparing to recopy patched init and RC scripts.

Recopying init and RC scripts.

ocrcheck failed. Check /u01/oracle/product/10g/crs/srvm/log for more details

这一步事实上是这时候CRS无法启动，而且在/u01/oracle/product/10g/crs/srvm/log这个目录下面没有记录任何东西。尝试着手工启动CRS，报：

/u01/oracle/product/10g/crs/bin/crsctl.bin: error while loading shared libraries: /u01/oracle/product/10g/crs/lib/libclntsh.so.10.1: file too short

查看一下libclntsh.so.10.1，文件大小居然为0。查看该目录下的其他文件的大小和更改时间和备份的目录相比都没变化，解决办法便是将报错的libclntsh.so.10.1文件从升级之前备份的CRS目录COPY回来，再运行脚本就可以了。可见在升级之前做好备份有多重要。

第二个问题是打完PATCH，准备用DBUA升级数据库时将所有节点启动至MOUNT状态，DBUA运行下一步时报错：

DBUA thinks this is a Rerun operation and is trying to connect to the database with oracle home /u01/oracle/product/10g/db. If you believe this is not a Rerun operation, remove the below file and invoke DBUA again.

/u01/oracle/product/10g/db/cfgtoollogs/dbua/logs/Welcome_dwdb.txt

但是Welcome_dwdb.txt这个文件压根不存在。这时候只好抛弃DBUA了，手工运行升级脚本，这样数据库才能正常升级成功。

第三个问题是发现发现我们原来RAC内部互联采用的是Infiniband RDS协议变成普通的UDP协议互联了：

Fri Mar 28 21:12:14 2008

cluster interconnect IPC version:Oracle UDP/IP (generic)

IPC Vendor 1 proto 2

这个问题是由于在升级过程中ORACLE又重新将内部互联的方案更改为默认的UDP方式。需要重新配置一下RDS内部互联，在配置之前需要把ASM和数据库都停掉，然后重新RELINK成RDS互联：

$ cd $ORACLE_HOME/rdbms/lib

$ make -f ins_rdbms.mk ipc_rds ioracle

这样以后，内部互联就恢复成正常的RDS了：

Fri Mar 28 21:25:39 2008

cluster interconnect IPC version:Oracle RDS/IP (generic)

在升级之后我们碰到了一个新的BUG，数据库会报：

ORA-00600: internal error code, arguments: [kddummy_blkchk], [47], [935468], [18038], [], [], [], []

解决办法是将db_block_checksum这个参数改为FALSE，不过这样做会有较大的风险，目前这个BUG ORACLE已经提交BUG开发部门进行开发了。

说说在Metalink上开SR这件事

Fri, 07 Mar 2008 08:25:07 GMT

看到一个朋友的MSN签名是：“我不是在开SR，就是准备在开SR”。心里颇有感触，这个朋友是做ORACLE ERP的，听说ORACLE ERP非常复杂，需要经常上METALINK求助。做为一名ORACLE DBA，METALINK是非常重要的资料来源，很多案例查一下METALINK都会有比较好的解决方案。不过METALINK也不是万能的，碰到没有相似的方案，你只能开SR求助于ORACLE SUPPORT了。

我在去年以前从来没有在METALINK上开过SR，基本上日常工作碰到的问题都可以通过种种办法查出原因并解决。但是在采用了最新的Oracle 10g R2 RAC数据库后，碰到了一系列莫名其妙的问题，这时候便只好开SR求助了。从开第一个SR到现在一共开了有十几个SR，真正解决问题的没有几个，往往都是不了了之。最开始便是让你发一通文件，这些文件分布在RAC的好几台主机，我只好一台台主机去找他们要求的文件最后面再打包上传。这是一个非常烦琐的过程，OS日志、CRS日志、CSS日志、alert log、TRACE文件……结果我好不容易将一大堆文件打包上传了，格式是.rar格式的，他们只能打开.zip格式的压缩包，要求重新上传。重新上传完以后，他们说根据已经上传的这些文件还是找不出原因，让部署Oracle的OS Watcher这个工具，等以后出现类似问题时再找原因。于是费了一番精力再部署这东西上去，另外他们还要求部署RDA，也一并弄上去。结果有一次再出现类似问题后，又是一通地找文件，最后压缩文件居然有500MB之大。在自己机器上上传了一天传不上去，就在同事的机器上挂机传了一天。这次传上去了，结果SUPPORTER跟我说传上去的文件太大了，他们也无法打开，让我再传至METALINK的FTP，好，再折腾，又费了一天传至FTP。结果他们还是没有找到问题，给我来这么一句：Now it seems to be LMS are started in Real time mode.We can check if the problem is re-producing or not。只能关掉SR，等待问题重现时再让他们诊断。于是这个SR到现在一个半月了，中间交涉了好多次，今天我还在上传他们要求的文件。

还有另外一次我们生产库的ASM磁盘头损坏，我们之前都没碰到这一类的故障，METALINK上也没有相应案例。我开了1级紧急SR，本来指望他们响应快一些，结果他们还是慢吞吞地在处理，最多的一句话是：Thank you for your patience。而且Oracle Support技术水平不一，有些SUPPORT根据内部文档给出一个建议后也不说明为什么要这么做，下一步要做什么？我们碰到ASM磁盘头损坏后第一个SUPPORT一个劲地让我们清空前1M的内容。问他为什么要清空前1MB的内容他就是不说，就说对照着做把结果告诉他就行了？我们问那清空后下一步怎么办？他就是不说，最后面发现他找到一个错误的解决案例，假如我们按这个SUPPORT的建议来处理的话，那么有可能会丢失整个数据库的数据。还是这个案例，后面问题解决了，我们要找出原因，他们说根据ORACLE的策略，只能另外开一个SR。另外开了SR后，换了另外一个SUPPORT来支持了，结果这个SUPPORT又不清楚具体的情况，于是我又费了一番周折把情况说明清楚，英语本来就不好，好不容易憋出几句英文把情况说明清楚，结果响应又巨慢无比。只好通过销售来推动，这次倒好了，说是因为时区的关系，我的SR负责的工程师刚好是非洲的，而且又出去度假去了。给我换了个印度的工程师，又是不熟悉情况，又是从头介绍情况，结果现在还是在处理状态。

还有一些其他的问题，总之指望METALINK来解决问题你需要足够的耐心，也不能指望能够解决紧急的问题。话说回来，通过网络来解决问题，在对具体环境不熟悉的情况下，他们是需要调查清楚情况后再做出处理，或许他们在工作的同时也在处理其他的案例，毕竟不仅仅就你这么一个案例。ORACLE也有自己的流程和策略，不过这个流程对于用户来说实在是太繁琐了。

SR，你让我怎么说你才好？

解决STANDBY ASM添加数据文件失败故障

Thu, 06 Mar 2008 02:22:09 GMT

今天凌晨STANDBY突然出错，导致数据库实例和ASM实例通信的ASMB进程宕掉，无法连接ASM实例，数据库直接宕掉。

Successfully added datafile 430 to media recovery
Datafile #430: '+DATA/test/datafile/ttt.4272.648621851'
Thu Mar 6 04:45:35 2008
Errors in file /u01/oracle/admin/test/bdump/test_asmb_13907.trc:
ORA-04031: unable to allocate 3936 bytes of shared memory ("shared pool","unknown object","sga heap(1,1)","ASM extent pointer array")
Thu Mar 6 04:45:35 2008
ASMB: terminating instance due to error 4031
Instance terminated by ASMB, pid = 13907
MRP0: Background Media Recovery terminated with error 1111

重启数据库以后，发现无法创建主库新添加的数据文件，显然是由于恢复过程中的突然宕机，现在控制文件无法识别新创建的数据文件：

Thu Mar 6 04:55:32 2008
Errors in file /u01/oracle/admin/test/bdump/test_mrp0_31695.trc:
ORA-01111: name for data file 431 is unknown - rename to correct file
ORA-01110: data file 431: '/u01/oracle/product/10g/db/dbs/UNNAMED00431'
ORA-01157: cannot identify/lock data file 431 - see DBWR trace file
ORA-01111: name for data file 431 is unknown - rename to correct file
ORA-01110: data file 431: '/u01/oracle/product/10g/db/dbs/UNNAMED00431'

由于主库和备库都采用ASM做为存储方案，数据文件名在主库和备库上面都会不一样，那么是无法采用常规解决办法进行处理的。

正确的处理办法是首先将standby_file_management从原来的true改为false，然后手工创建出错的数据文件：

alter database create datafile 432 as '+data' size 20g autoextend off;

记住这里面的size和autoextend特性都必须按主库添加数据文件时该文件的参数显式指定的，要不将会添加失败。处理好后记得把standby_file_management改回到true，要不STANDBY数据库添加接下新增的数据文件又会出错。

关于以数字命名奇怪的segment_name

Thu, 13 Dec 2007 07:21:05 GMT

事情的起因是缘于昨天半夜的一次问题处理，当时报警表空间将满，马上查找了一下该表空间下面的segment空间使用情况：

select segment_name,sum(bytes)/1048576

from dba_segments

where tablespace_name='TEST'

group by segment_name

order by 2;

发现有这么一个奇怪的以数字命名的SEGMENT占用了200多G的空间：

299.20715 202681MB

这个以前也碰到过，不过没啥留意，只知道是在装载数据时生成的临时段，比如在create table t as select * from t1的过程中，会生产类似一个数字的SEGMENT。在GOOGLE到eygle的文章：Oracle中独一无二的Cache对象，才知道这个段名的含义：299.10715，299是数据文件号，10715是该段在这个数据文件中的块号。

知道了原理后并不能解决问题，v$access无法找出是哪个SID在访问这个OBJECT，只好把v$sqltext中以create和insert开头的SQL语句都找出来，发现只有零星的几条SQL语句在CREATE和INSERT，这些应用的表平时都不足以增大到这么大的空间。于是只好另外定位原因，查到有sql loader在装载数据，看来只能这个东西出问题了，备份好装载脚本后，KILL掉SQL LOADER的进程，果然这个SEGMENT没了，空间也释放出来了。今天才知道由于应用的原因，生成的文本文件由原来的几十G增长到将近1个T，导致平时正常的装载延长到大半夜，空间呈现了数量级的增长。

Oracle 11g在Windows与Linux异构平台下的DATA GURAD配置

Wed, 12 Dec 2007 11:32:06 GMT

      从Oracle 11g开始，ORACLE支持在特定条件下WINDOWS与LINUX两个不同OS平台之间配置DATA GUARD，这样DATA GUARD再也不受原来需要同样OS平台的限制了。今天测试了一下这个配置，以下是配置过程：

主库：Windows 2003 +Oracle 11.1.0.6
SID : orcl
数据文件目录：D:\ORACLE\ORADATA\ORCL\
备用库：RHEL 4 U5+Oracle 11.1.0.6
SID:standby
数据文件目录：/home/oracle/opt/oradata/standby/

1、验证主库是归档模式，并将主库置于FORCE LOGGING模式：

SQL*Plus: Release 11.1.0.6.0 - Production on 星期三 12月 12 10:33:51 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> archive log list
Database log mode             Archive Mode
Automatic archival          Enabled
Archive destination          USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence    229
Next log sequence to archive 231
Current log sequence          231

SQL> alter database force logging;

Database altered.

2、对主库做一个全库的RMAN备份，用于STANDBY配置：

C:\Documents and Settings\Administrator>rman target /

Recovery Manager: Release 11.1.0.6.0 - Production on 星期三 12月 12 10:40:12 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1165203189)
RMAN> backup database format 'd:\db_%U.bak';

Starting backup at 12-12月-07
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=98 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=D:\ORACLE\ORADATA\ORCL\SYSAUX01.DBF
input datafile file number=00001 name=D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF
input datafile file number=00004 name=D:\ORACLE\ORADATA\ORCL\USERS01.DBF
input datafile file number=00003 name=D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF
input datafile file number=00005 name=D:\ORACLE\ORADATA\ORCL\EXAMPLE01.DBF
channel ORA_DISK_1: starting piece 1 at 12-12月-07
channel ORA_DISK_1: finished piece 1 at 12-12月-07
piece handle=D:\DB_04J3DK0Q_1_1.BAK tag=TAG20071212T104026 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:55
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 12-12月-07
channel ORA_DISK_1: finished piece 1 at 12-12月-07
piece handle=D:\DB_05J3DK6N_1_1.BAK tag=TAG20071212T104026 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-12月-07

3、准备STANDBY数据文件路径和其他路径：
[oracle@test51 oradata]$ pwd
/home/oracle/opt/oradata
[oracle@test51 oradata]$ mkdir standby
[oracle@test51 oradata]$ cd standby
[oracle@test51 oradata]$ mkdir archive
[oracle@test51 oradata]$ cd $ORACLE_BASE/admin
[oracle@test51 admin]$ mkdir standby
[oracle@test51 oradata]$ cd standby
[oracle@test51 standby]$mkdir adump
[oracle@test51 standby]$mkdir dpdump
[oracle@test51 standby]$mkdir pfile
[oracle@test51 standby]$ ls
adump  dpdump  pfile

4、生成standby 初始化参数文件：
SQL> create pfile='d:/init.ora' from spfile;

File created.

添加以下几个STANDBY参数：

*.log_archive_config='DG_CONFIG=(orcl,standby)'
*.fal_client='standby'
*.fal_server='primary'
*.db_file_name_convert='D:\ORACLE\ORADATA\ORCL\','/home/oracle/opt/oradata/standby/'
*.log_file_name_convert='D:\ORACLE\ORADATA\ORCL\','/home/oracle/opt/oradata/standby/'
*.standby_file_management='auto'
*.log_archive_dest_1='location=/home/oracle/opt/oradata/standby/archive VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'

完整的STANDBY端参数如下：

standby.__db_cache_size=234881024
standby.__java_pool_size=12582912
standby.__large_pool_size=4194304
standby.__oracle_base='/home/oracle/opt'#ORACLE_BASE set from environment
standby.__pga_aggregate_target=209715200
standby.__sga_target=629145600
standby.__shared_io_pool_size=0
standby.__shared_pool_size=369098752
standby.__streams_pool_size=0
*.audit_file_dest='/home/oracle/opt/admin/standby/adump'
*.audit_trail='db'
*.compatible='11.1.0.0.0'
*.control_files='/home/oracle/opt/oradata/standby/control01.ctl','/home/oracle/opt/oradata/standby/control02.ctl','/home/oracle/opt/oradata/standby/control03.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='orcl'
*.db_recovery_file_dest='/home/oracle/opt/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.db_unique_name='standby'
*.ddl_lock_timeout=10
*.diagnostic_dest='/home/oracle/opt'
*.dispatchers=''
*.job_queue_processes=0
*.memory_target=838860800
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'

*.log_archive_config='DG_CONFIG=(orcl,standby)'
*.fal_client='standby'
*.fal_server='primary'
*.db_file_name_convert='D:\ORACLE\ORADATA\ORCL\','/home/oracle/opt/oradata/standby/'
*.log_file_name_convert='D:\ORACLE\ORADATA\ORCL\','/home/oracle/opt/oradata/standby/'
*.standby_file_management='auto'
*.log_archive_dest_1='location=/home/oracle/opt/oradata/standby/archive VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'

5、生成STANDBY控制文件：

SQL> alter database create standby controlfile as 'd:\ control01.ctl';

Database altered.

并将生成的STANDBY控制文件、初始化参数文件、备份集分别COPY至STANDBY端相应的目录，另外注意密码文件也需要COPY并在STANDBY端改名，因为主库和备库需要相同的密码文件，否则STANDBY无法配置成功：

[oracle@test51 standby]$ cp control01.ctl control02.ctl
[oracle@test51 standby]$ cp control01.ctl control03.ctl
[oracle@test51 standby]$ ls
archive control01.ctl  control02.ctl  control03.ctl  db_04j3dk0q_1_1.bak db_05j3dk6n_1_1.bak

6、在STANDBY端MOUNT STANDBY数据库，可以看到从WINDOWS COPY过来的备份控制文件可以直接在LINUX底下MOUNT成功：

idle> startup mount pfile='/home/oracle/opt/admin/standby/pfile/init_standby.ora';
ORACLE instance started.

Total System Global Area  836976640 bytes
Fixed Size                1303132 bytes
Variable Size          595594660 bytes
Database Buffers       234881024 bytes
Redo Buffers             5197824 bytes
Database mounted.

7、RESTORE  STANDBY数据库：
[oracle@test51 bin]$ export ORACLE_SID=standby

由于控制文件里面记录的备份信息还是在WINDOWS上主库的备份信息，我们需要使用RMAN的catalog命令来使RMAN认出在STANDBY端从WINDOWS主库COPY过来的备份集：

[oracle@test51 bin]$ ./rman target /

Recovery Manager: Release 11.1.0.6.0 - Production on Wed Dec 12 11:44:29 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1165203189, not open)

RMAN> list backup;

using target database control file instead of recovery catalog

List of Backup Sets
===================
BS Key  Type LV Size    Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3    Full 1.75G    DISK       00:03:03    12-DEC-07
      BP Key: 3 Status: AVAILABLE  Compressed: NO  Tag: TAG20071212T104026
      Piece Name: D:\DB_04J3DK0Q_1_1.BAK
  List of Datafiles in backup set 3
  File LV Type Ckp SCN Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1    Full 8852434 12-DEC-07 D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF
  2    Full 8852434 12-DEC-07 D:\ORACLE\ORADATA\ORCL\SYSAUX01.DBF
  3    Full 8852434 12-DEC-07 D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF
  4    Full 8852434 12-DEC-07 D:\ORACLE\ORADATA\ORCL\USERS01.DBF
  5    Full 8852434 12-DEC-07 D:\ORACLE\ORADATA\ORCL\EXAMPLE01.DBF

BS Key  Type LV Size    Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4    Full 9.64M    DISK       00:00:17    12-DEC-07
      BP Key: 4 Status: AVAILABLE  Compressed: NO  Tag: TAG20071212T104026
      Piece Name: D:\DB_05J3DK6N_1_1.BAK
  SPFILE Included: Modification time: 30-NOV-07
  SPFILE db_unique_name: ORCL
  Control File Included: Ckp SCN: 8852584    Ckp time: 12-DEC-07

RMAN> catalog start with '/home/oracle/opt/oradata/standby';

using target database control file instead of recovery catalog
searching for all files that match the pattern /home/oracle/opt/oradata/standby

List of Files Unknown to the Database
=====================================
File Name: /home/oracle/opt/oradata/standby/db_05j3dk6n_1_1.bak
File Name: /home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /home/oracle/opt/oradata/standby/db_05j3dk6n_1_1.bak
File Name: /home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak

RMAN> crosscheck backup;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=146 device type=DISK
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=D:\01J16E8N_1_1.BAK RECID=1 STAMP=638794021
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=D:\DB_&U.BAK RECID=2 STAMP=641126128
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=D:\DB_04J3DK0Q_1_1.BAK RECID=3 STAMP=641126440
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak RECID=6 STAMP=641137919
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=D:\DB_05J3DK6N_1_1.BAK RECID=4 STAMP=641126632
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/home/oracle/opt/oradata/standby/db_05j3dk6n_1_1.bak RECID=5 STAMP=641137919
Crosschecked 6 objects

RMAN> delete expired backup;

using channel ORA_DISK_1

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status    Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1    1    1 1 EXPIRED    DISK       D:\01J16E8N_1_1.BAK
2    2    1 1 EXPIRED    DISK       D:\DB_&U.BAK
3    3    1 1 EXPIRED    DISK       D:\DB_04J3DK0Q_1_1.BAK
4    4    1 1 EXPIRED    DISK       D:\DB_05J3DK6N_1_1.BAK

Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=D:\01J16E8N_1_1.BAK RECID=1 STAMP=638794021
deleted backup piece
backup piece handle=D:\DB_&U.BAK RECID=2 STAMP=641126128
deleted backup piece
backup piece handle=D:\DB_04J3DK0Q_1_1.BAK RECID=3 STAMP=641126440
deleted backup piece
backup piece handle=D:\DB_05J3DK6N_1_1.BAK RECID=4 STAMP=641126632
Deleted 4 EXPIRED objects

等到RMAN能够正切认出STANDBY端的备份集后，我们就可以对数据库进行RESTORE了：

RMAN> list backup;

List of Backup Sets

BS Key  Type LV Size    Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3    Full 1.75G    DISK       00:03:03    12-DEC-07
      BP Key: 6 Status: AVAILABLE  Compressed: NO  Tag: TAG20071212T104026
      Piece Name: /home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak
  List of Datafiles in backup set 3
  File LV Type Ckp SCN Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1    Full 8852434 12-DEC-07 /home/oracle/opt/oradata/standby/SYSTEM01.DBF
  2    Full 8852434 12-DEC-07 /home/oracle/opt/oradata/standby/SYSAUX01.DBF
  3    Full 8852434 12-DEC-07 /home/oracle/opt/oradata/standby/UNDOTBS01.DBF
  4    Full 8852434 12-DEC-07 /home/oracle/opt/oradata/standby/USERS01.DBF
  5    Full 8852434 12-DEC-07 /home/oracle/opt/oradata/standby/EXAMPLE01.DBF

BS Key  Type LV Size    Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4    Full 9.64M    DISK       00:00:17    12-DEC-07
      BP Key: 5 Status: AVAILABLE  Compressed: NO  Tag: TAG20071212T104026
      Piece Name: /home/oracle/opt/oradata/standby/db_05j3dk6n_1_1.bak
  SPFILE Included: Modification time: 30-NOV-07
  SPFILE db_unique_name: ORCL
  Control File Included: Ckp SCN: 8852584    Ckp time: 12-DEC-07

RMAN> restore database;

Starting restore at 12-DEC-07
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /home/oracle/opt/oradata/standby/SYSTEM01.DBF
channel ORA_DISK_1: restoring datafile 00002 to /home/oracle/opt/oradata/standby/SYSAUX01.DBF
channel ORA_DISK_1: restoring datafile 00003 to /home/oracle/opt/oradata/standby/UNDOTBS01.DBF
channel ORA_DISK_1: restoring datafile 00004 to /home/oracle/opt/oradata/standby/USERS01.DBF
channel ORA_DISK_1: restoring datafile 00005 to /home/oracle/opt/oradata/standby/EXAMPLE01.DBF
channel ORA_DISK_1: reading from backup piece /home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/opt/oradata/standby/db_04j3dk0q_1_1.bak tag=TAG20071212T104026
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
Finished restore at 12-DEC-07

8、在主库和备用库端分别更改tnsnames配置，添加主库和备用库的TNS连接字，并确保在主库和STANDBY都能够连接上对方：

primary =
  (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.200.168)(PORT = 1521))
(CONNECT_DATA =
   (SERVER = DEDICATED)
   (SERVICE_NAME = orcl)
)
  )

standby =
  (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =192.168.200.169)(PORT = 1522))
(CONNECT_DATA =
   (SERVER = DEDICATED)
   (SERVICE_NAME = standby)
)
  )

9、添加STANDBY LOGFILE，启动STANDBY至恢复管理模式：

idle> alter database add standby logfile '/home/oracle/opt/oradata/standby/redo04.log' size 50M;

Database altered.

idle>  alter database add standby logfile '/home/oracle/opt/oradata/standby/redo05.log' size 50M;

Database altered.

idle>  alter database add standby logfile '/home/oracle/opt/oradata/standby/redo06.log' size 50M;

Database altered.

idle> recover managed standby database disconnect from session;
Media recovery complete.

10、主库配置到STANDBY的归档，另外注意主库需要设置log_archive_config这个参数，否则归档将不会从主库传至STANDBY端：

Sys@orcl> alter system set log_archive_dest_2='service=standby ASYNC VALID_FOR=(
ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby';

System altered.

Sys@orcl> alter system set log_archive_dest_state_2=enable;

System altered.

Sys@orcl> alter system set log_archive_config='DG_CONFIG=(orcl,standby)';

System altered.

这样异构STANDBY就配置成功了：

Wed Dec 12 14:42:34 2007
Using STANDBY_ARCHIVE_DEST parameter default value as /home/oracle/opt/oradata/standby/archive
Wed Dec 12 15:28:17 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 3774
RFS[1]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
RFS LogMiner: Client disabled from further notification
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Successfully opened standby log 4: '/home/oracle/opt/oradata/standby/redo04.log'
Wed Dec 12 15:28:18 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 3780
RFS[2]: Identified database type as 'physical standby'
kcrrvslf: active RFS archival for log 4 thread 1 sequence 249
RFS[2]: Successfully opened standby log 5: '/home/oracle/opt/oradata/standby/redo05.log'
Wed Dec 12 15:28:21 2007
Fetching gap sequence in thread 1, gap sequence 231-247
Wed Dec 12 15:28:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 3786
RFS[3]: Identified database type as 'physical standby'
Wed Dec 12 15:28:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 3792
RFS[4]: Identified database type as 'physical standby'
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_232_637422457.dbf'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_231_637422457.dbf'
RFS[3]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_233_637422457.dbf'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_235_637422457.dbf'
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_234_637422457.dbf'
RFS[3]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_236_637422457.dbf'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_237_637422457.dbf'
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_238_637422457.dbf'
RFS[3]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_239_637422457.dbf'
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_240_637422457.dbf'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_241_637422457.dbf'
FS[3]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_242_637422457.dbf'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_243_637422457.dbf'
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_244_637422457.dbf'
RFS[3]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_245_637422457.dbf'
Wed Dec 12 15:28:29 2007
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Successfully opened standby log 5: '/home/oracle/opt/oradata/standby/redo05.log'
RFS[4]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_246_637422457.dbf'
Wed Dec 12 15:28:30 2007
RFS[2]: Archived Log: '/home/oracle/opt/oradata/standby/archive/1_247_637422457.dbf'
Wed Dec 12 15:28:52 2007
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_231_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_232_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_233_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_234_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_235_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_236_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_237_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_238_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_239_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_240_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_241_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_242_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_243_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_244_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_245_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_246_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_247_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_248_637422457.dbf
Media Recovery Log /home/oracle/opt/oradata/standby/archive/1_249_637422457.dbf
Media Recovery Waiting for thread 1 sequence 250 (in transit)

ASM中如何配置多个控制文件

Mon, 03 Dec 2007 03:23:43 GMT

我们日常对数据库进行配置管理时，为了保证数据库的安全，通常会配置多个控制文件，以防单一控制文件的损坏引起数据库的宕机。如果数据库采用了ASM存储方案，假如只创建一个ASM磁盘组的话，控制文件默认只有一个，这样显然无助于数据库的保护。事实上我们可以通过简单的一些操作把对ASM中的控制文件进行多个配置：

一、将控制文件从文件系统迁移到ASM：

SQL> show parameter control_files

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

control_files string /home/oracle/control01.ctl, /h

ome/oracle/control02.ctl, /hom

e/oracle/control03.ctl

SQL> show parameter db_create_file_dest

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_create_file_dest string +DATA

SQL> alter system reset control_files scope=spfile;

alter system reset control_files scope=spfile

ERROR at line 1:

ORA-00905: missing keyword

SQL> alter system reset control_files scope=spfile sid='*';

System altered.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 8388608000 bytes

Fixed Size 2086096 bytes

Variable Size 4479519536 bytes

Database Buffers 3892314112 bytes

Redo Buffers 14688256 bytes

dw2:/u01/oracle/product/10g/db/bin>$./rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Mon Dec 3 10:17:05 2007

connected to target database: test (not mounted)

RMAN> restore controlfile from '/home/oracle/control01.ctl';

Starting restore at 2007-12-03 10:17:12

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=1091 devtype=DISK

channel ORA_DISK_1: copied control file copy

output filename=+DATA/test/controlfile/current.1623.640347437

Finished restore at 2007-12-03 10:17:21

二、可以看到ASM默认只会创建一个控制文件+DATA/test/controlfile/current.1623.640347437，且控制文件的名字由于遵循了ASM的命名方式，比较怪异。我们现在要将名字改为control01.ctl,control02.ctl,control03.ctl这样比较直观的名字。首先对当前控制文件进行一个备份，备份的路径为我们想要的ASM上的控制文件：

SQL> alter database mount database;

Database altered.

SQL> alter database backup controlfile to '+DATA/test/controlfile/control01.ctl';

Database altered.

SQL> alter system set control_files='+DATA/test/controlfile/control01.ctl' scope=spfile;

System altered.

Elapsed: 00:00:00.00

SQL> shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

三、以新的控制文件MOUNT数据库，然后再对控制文件依样进行备份，更改参数文件，成功地配置了多个控制文件：

SQL> startup nomount

ORACLE instance started.

Total System Global Area 8388608000 bytes

Fixed Size 2086096 bytes

Variable Size 4479519536 bytes

Database Buffers 3892314112 bytes

Redo Buffers 14688256 bytes

SQL> alter database mount database;

Database altered.

SQL> alter database backup controlfile to '+DATA/test/controlfile/control02.ctl';

Database altered.

SQL> alter database backup controlfile to '+DATA/test/controlfile/control03.ctl';

Database altered.

SQL> alter system set control_files='+DATA/test/controlfile/control01.ctl','+DATA/test/controlfile/control02.ctl','+DATA/test/controlfile/control03.ctl' scope=spfile;

System altered.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 8388608000 bytes

Fixed Size 2086096 bytes

Variable Size 4479519536 bytes

Database Buffers 3892314112 bytes

Redo Buffers 14688256 bytes

SQL> alter database mount database;

Database altered.

四、通过ASM命令行工具asmcmd可以看到事实上我们设置的控制文件命名规范还是遵照ASM的命名方式的，它会通过一个LINK链接到我们想要的控制文件名字：

ASMCMD> ls

Backup.2882.640347745

Backup.4733.640348283

Backup.5043.640348291

control01.ctl

control02.ctl

control03.ctl

current.1623.640347437

ASMCMD> rm Backup.2882.640347745

ORA-15032: not all alterations performed

ORA-15028: ASM file '+DATA/TEST/CONTROLFILE/Backup.2882.640347745' not dropped; currently being accessed (DBD ERROR: OCIStmtExecute)

ASMCMD> ls -alt

Type Redund Striped Time Sys Name

CONTROLFILE UNPROT FINE DEC 03 10:00:00 Y none => current.1623.640347437

N control03.ctl => +DATA/TEST/CONTROLFILE/Backup.5043.640348291

N control02.ctl => +DATA/TEST/CONTROLFILE/Backup.4733.640348283

N control01.ctl => +DATA/TEST/CONTROLFILE/Backup.2882.640347745

CONTROLFILE UNPROT FINE DEC 03 10:00:00 Y +DATA/TEST/CONTROLFILE/control03.ctl => Backup.5043.640348291

CONTROLFILE UNPROT FINE DEC 03 10:00:00 Y +DATA/TEST/CONTROLFILE/control02.ctl => Backup.4733.640348283

CONTROLFILE UNPROT FINE DEC 03 10:00:00 Y +DATA/TEST/CONTROLFILE/control01.ctl => Backup.2882.640347745

ASM装载磁盘组时ORA-15063错误处理

Mon, 08 Oct 2007 07:47:12 GMT

一次重启LINUX后，启动ASM实例时，发生了这个错误：

SQL> startup

ASM instance started

Total System Global Area 130023424 bytes

Fixed Size 2071000 bytes

Variable Size 102786600 bytes

ASM Cache 25165824 bytes

ORA-15032: not all alterations performed

ORA-15063: ASM discovered an insufficient number of disks for diskgroup

"DWDATA"

查看错误信息：

15063, 00000, "ASM discovered an insufficient number of disks for diskgroup \"%s\""

// *Cause: ASM was unable to find a sufficient number of disks belonging to the

// diskgroup to continue the operation.

// *Action: Check that the disks in the diskgroup are present and functioning,

// that the owner of the ORACLE binary has read/write permission to

// the disks, and that the ASM_DISKSTRING initialization parameter

// has been set correctly. Verify that ASM discovers the appropriate

// disks by querying V$ASM_DISK from the ASM instance.

可以看到这个错误是由于ASM实例无法装载硬盘组的所有磁盘而引起的，有可能是权限问题。马上想到是否是由于OS重启后祼设备的用户、权限是否变更，导致ORACLE用户没有权限访问祼设备。将祼设备的权限更改完后，果然ASM能够正常启动。其实这个问题还是很简单的，LINUX启动后默认会把祼设备的拥有者改为root用户，只需把/etc/udev/permissions.d/50-udev.permissions 这个文件中的行“raw/*:root:disk:0660”注释掉，添加新行“raw/*:oracle:dba:0660”，这样系统启动后祼设备的拥有者就变为ORACLE用户了，当然如果祼设备还有其他用户的话，那么就需要针对不同的祼设备进行更改了。