第一步：建立参数文件，这个文件可以从其他地方已有的数据库复制过来修改，也可以从init.ora的基础上修改，主要内容如下：

*.audit_file_dest='/u01/app/oracle/admin/erpwh/adump'
*.background_dump_dest='/u01/app/oracle/admin/erpwh/bdump'
*.compatible='10.2.0.1.0'
*.control_files='+DGWH/erpwh/control01.ctl','+DGWH/erpwh/control02.ctl','+DGWH/erpwh/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/erpwh/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='erpwh'
*.db_recovery_file_dest='+DGWH'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=erpoptmXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=1073741824
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=2147483648
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/erpwh/udump'

可以看到参数文件主要是指定了数据库名、跟踪文件的位置、控制文件的位置、数据块大小、内存参数等。Linux 系统中，该文件位置应在$ORACLE_HOME/dbs目录下。

第二步：建立密码文件，该文件用于sys用户以sysdba身份远程管理登录，这里的密码可以和建立数据库脚本理的sys密码不同，如果是远程以sysdba身份登录则需要使用这里的密码。密码文件和参数文件在相同的目录下：

[oracle@erpdevdb dbs]$ orapwd file=/u01/app/oracle/oracle/product/10.2.0/db_1/dbs/orapwerpwh password=erpwh entries=5

第三步：建立跟踪、日志等文件的路径：

[oracle@erpdevdb dbs]$ cd /u01/app/oracle/admin/

[oracle@erpdevdb admin]$ mkdir erpwh
[oracle@erpdevdb admin]$ cd erpwh
[oracle@erpdevdb erpwh]$ ll
total 0
[oracle@erpdevdb erpwh]$ mkdir adump bdump udump cdump
[oracle@erpdevdb erpwh]$ ll
total 32
drwxr-xr-x 2 oracle oinstall 4096 Mar 10 15:16 adump
drwxr-xr-x 2 oracle oinstall 4096 Mar 10 15:16 bdump
drwxr-xr-x 2 oracle oinstall 4096 Mar 10 15:16 cdump
drwxr-xr-x 2 oracle oinstall 4096 Mar 10 15:16 udump

第四步：启动数据库到nomount状态：

[oracle@erpdevdb dbs]$ export ORACLE_SID=erpwh
[oracle@erpdevdb dbs]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Mar 10 15:18:09 2010

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

Connected to an idle instance.

SQL> startup nomount
ORA-27102: out of memory
Linux-x86_64 Error: 28: No space left on device

如果出现以上错误，是操作系统参数设置的内存不够，参见这篇文章修改即可：

[root@erpdevdb ~]# vi /etc/sysctl.conf

kernel.shmall = 4718592

或者调小参数文件里的内存参数也可以，取决于系统资源情况。

SQL> startup nomount
ORACLE instance started.

Total System Global Area 2147483648 bytes
Fixed Size 2022144 bytes
Variable Size 486540544 bytes
Database Buffers 1644167168 bytes
Redo Buffers 14753792 bytes

第五步，运行建立数据库的脚本

CREATE DATABASE erpwh
USER SYS IDENTIFIED BY sys
USER SYSTEM IDENTIFIED BY sys
LOGFILE GROUP 1 ('+DGWH/erpwh/redo01.log') SIZE 100M,
GROUP 2 ('+DGWH/erpwh/redo02.log') SIZE 100M,
GROUP 3 ('+DGWH/erpwh/redo03.log') SIZE 100M
MAXLOGFILES 16
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 2
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
DATAFILE '+DGWH/erpwh/system01.dbf' SIZE 2048M REUSE
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '+DGWH/erpwh/sysaux01.dbf' SIZE 1024M REUSE
DEFAULT TEMPORARY TABLESPACE temptbs1
TEMPFILE '+DGWH/erpwh/temp01.dbf'
SIZE 2048M REUSE
UNDO TABLESPACE undotbs1
DATAFILE '+DGWH/erpwh/undotbs01.dbf'
SIZE 1024M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

脚本主要是指定sys和system的密码，redo文件，字符集，数据文件，临时表空间和回滚段等信息。

但有时候在建库脚本里指定默认表空间DEFAULT TABLESPACE erp会报错：

SQL> CREATE DATABASE erpwh
2 USER SYS IDENTIFIED BY sys
3 USER SYSTEM IDENTIFIED BY sys
4 LOGFILE GROUP 1 ('+DGWH/erpwh/redo01.log') SIZE 100M,
5 GROUP 2 ('+DGWH/erpwh/redo02.log') SIZE 100M,
6 GROUP 3 ('+DGWH/erpwh/redo03.log') SIZE 100M
7 MAXLOGFILES 16
8 MAXLOGMEMBERS 5
9 MAXDATAFILES 100
10 MAXINSTANCES 8
11 MAXLOGHISTORY 29200
12 CHARACTER SET ZHS16GBK
13 NATIONAL CHARACTER SET AL16UTF16
14 DATAFILE '+DGWH/erpwh/system01.dbf' SIZE 2048M REUSE
15 EXTENT MANAGEMENT LOCAL
16 SYSAUX DATAFILE '+DGWH/erpwh/sysaux01.dbf' SIZE 1024M REUSE
17 DEFAULT TABLESPACE erp
18 DEFAULT TEMPORARY TABLESPACE temptbs1
19 TEMPFILE '+DGWH/erpwh/temp01.dbf'
20 SIZE 2048M REUSE
21 UNDO TABLESPACE undotbs1
22 DATAFILE '+DGWH/erpwh/undotbs01.dbf'
23 SIZE 1024M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
CREATE DATABASE erpwh
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced

这种情况一般是建库脚本哪里写的不对，需要检查。从asm存储来看各种数据文件都建立了，但是数据库并没有创建成功，这时把已经建立的数据文件删掉，并删除建库脚本理的默认表空间这行就可以了：

SQL> CREATE DATABASE erpwh
2 USER SYS IDENTIFIED BY sys
3 USER SYSTEM IDENTIFIED BY sys
4 LOGFILE GROUP 1 ('+DGWH/erpwh/redo01.log') SIZE 100M,
5 GROUP 2 ('+DGWH/erpwh/redo02.log') SIZE 100M,
6 GROUP 3 ('+DGWH/erpwh/redo03.log') SIZE 100M
7 MAXLOGFILES 16
8 MAXLOGMEMBERS 5
9 MAXDATAFILES 100
10 MAXINSTANCES 8
11 MAXLOGHISTORY 2
12 CHARACTER SET ZHS16GBK
13 NATIONAL CHARACTER SET AL16UTF16
14 DATAFILE '+DGWH/erpwh/system01.dbf' SIZE 2048M REUSE
15 EXTENT MANAGEMENT LOCAL
16 SYSAUX DATAFILE '+DGWH/erpwh/sysaux01.dbf' SIZE 1024M REUSE
17 DEFAULT TEMPORARY TABLESPACE temptbs1
18 TEMPFILE '+DGWH/erpwh/temp01.dbf'
19 SIZE 2048M REUSE
20 UNDO TABLESPACE undotbs1
21 DATAFILE '+DGWH/erpwh/undotbs01.dbf'
22 SIZE 1024M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

Database created.

第六步，建立其他表空间和数据字典：

SQL> create tablespace erp datafile '+DGWH' size 30720m;

Tablespace created.

SQL> @?/rdbms/admin/catalog.sql

......

PL/SQL procedure successfully completed.

SQL> @?/rdbms/admin/catproc.sql

......

PL/SQL procedure successfully completed.

第七步，建立spfile：

SQL> create spfile='+DGWH/ERPWH/spfileerpwh.ora' from pfile;

File created.

要注意的是，Oracle下次启动的时候不不会默认使用这种方式建立的spfile，

SQL> show parameter spfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string

不指定spfile路径的时候就可以了：

SQL> create spfile from pfile;

File created.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 2147483648 bytes
Fixed Size 2022144 bytes
Variable Size 486540544 bytes
Database Buffers 1644167168 bytes
Redo Buffers 14753792 bytes
Database mounted.
Database opened.
SQL> show parameter spfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string /u01/app/oracle/oracle/product
/10.2.0/db_1/dbs/spfileerpwh.o
ra

第八步，建立用户

SQL> create user erp identified by erp default tablespace ERP temporary tablespace temptbs1 profile DEFAULT;

User created.

SQL> grant dba to erp;

Grant succeeded.

SQL> connect erp/erp
Error accessing PRODUCT_USER_PROFILE
Warning: Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM
Connected.

出现这个错误提示并不会影响数据库的使用，手动建库一般会有这个警告出现。 PRODUCT_USER_PROFILE是SYSTEM用户的一个表，存储客户端程序执行命令方面的限制信息，可以根据提示用system用户执行脚本来消除：

SQL> connect system/sys
Connected.
SQL>
SQL> @$ORACLE_HOME/sqlplus/admin/pupbld.sql

.......

SQL> connect erp/erp
Connected.
SQL>
SQL>
SQL> show user
USER is "ERP"

第九步，配置网络服务：

[oracle@erpdevdb admin]$ vi tnsnames.ora

ERPWH =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = erpdevdb)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = erpwh)
)
)

至此手动建立数据库完成，客户端可以连接上来使用了。

源库SID：erptest    目标库SID：erpoptm

第一步，首先获取源库的参数文件

SQL> CREATE PFILE='/tmp/init_temp.ora' from spfile;

File created.

参照以上文件建立一个目标库的参数文件initerpoptm.ora如下：

erptest.__db_cache_size=1828716544
erptest.__java_pool_size=16777216
erptest.__large_pool_size=16777216
erptest.__shared_pool_size=268435456
erptest.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/erpoptm/adump'
*.background_dump_dest='/u01/app/oracle/admin/erpoptm/bdump'
*.compatible='10.2.0.1.0'
*.control_files='+DGOPTM/erpoptm/control01.ctl','+DGOPTM/erpoptm/control02.ctl','+DGOPTM/erpoptm/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/erpoptm/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='erptest'
*.db_recovery_file_dest='+DGOPTM'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=erpoptmXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=1073741824
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=2147483648
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS2'
*.user_dump_dest='/u01/app/oracle/admin/erpoptm/udump'

改动的内容都是各种文件的路径，注意这里的db_name不要修改，否则无法mount数据库，因为db_name要和数据文件头记录的db_name一致。

第二步，建立对应的日志、跟踪等文件的路径

[oracle@erpdevdb tmp]$ cd /u01/app/oracle/admin/

[oracle@erpdevdb admin]$ mkdir erpoptm

[oracle@erpdevdb admin]$ cd erpoptm
[oracle@erpdevdb erpoptm]$ ll
total 0
[oracle@erpdevdb erpoptm]$ mkdir adump
[oracle@erpdevdb erpoptm]$ mkdir bdump
[oracle@erpdevdb erpoptm]$ mkdir udump
[oracle@erpdevdb erpoptm]$ mkdir cdump
[oracle@erpdevdb erpoptm]$ ll
total 32
drwxr-xr-x  2 oracle oinstall 4096 Mar  8 11:45 adump
drwxr-xr-x  2 oracle oinstall 4096 Mar  8 11:45 bdump
drwxr-xr-x  2 oracle oinstall 4096 Mar  8 11:45 cdump
drwxr-xr-x  2 oracle oinstall 4096 Mar  8 11:45 udump

第三步，获取源库的控制文件内容并修改

SQL> alter database backup controlfile to trace;

Database altered.

在udump目录下查看生成的trace文件，找到建立控制文件的部分脚本并修改如下：

CREATE CONTROLFILE REUSE DATABASE "ERPTEST" NORESETLOGS  NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 29200
LOGFILE
GROUP 1 '+DGOPTM/erpoptm/redo01.log'  SIZE 50M,
GROUP 2 '+DGOPTM/erpoptm/redo02.log'  SIZE 50M,
GROUP 3 '+DGOPTM/erpoptm/redo03.log'  SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'+DGOPTM/erpoptm/system01.dbf',
'+DGOPTM/erpoptm/undotbs01.dbf',
'+DGOPTM/erpoptm/sysaux01.dbf',
'+DGOPTM/erpoptm/users01.dbf',
'+DGOPTM/erpoptm/datafile/erp_ht.268',
'+DGOPTM/erpoptm/datafile/erp_ht.269',
'+DGOPTM/erpoptm/datafile/erp_index.270',
'+DGOPTM/erpoptm/datafile/erp_wl.271',
'+DGOPTM/erpoptm/datafile/erp.272',
'+DGOPTM/erpoptm/datafile/erp_sp.273',
'+DGOPTM/erpoptm/datafile/erp_cw.274',
'+DGOPTM/erpoptm/datafile/erp_zj.275',
'+DGOPTM/erpoptm/datafile/erp_xm.276',
'+DGOPTM/erpoptm/datafile/erp_ht.277'
CHARACTER SET ZHS16GBK

第四步，拷贝源库的数据文件到目标库的对应路径：

先要为目标库建立好ASM磁盘组，建立的详细步骤可参考这篇文章：

[root@erpdevdb ~]# oracleasm createdisk VOL5 /dev/sda10
Writing disk header: done
Instantiating disk: done

[oracle@erpdevdb ~]$ export ORACLE_SID=+ASM

SQL> create diskgroup DGOPTM external redundancy disk 'ORCL:VOL5';

Diskgroup created.

[oracle@erpdevdb ~]$ asmcmd
ASMCMD> ls
DGDEV/
DGOPTM/
DGPAPER/
DGSTUDY/
DGTEST/
ASMCMD> cd DGOPTM/

ASMCMD> mkdir ERPOPTM/

然后在源库的实例中用DBMS_FILE_TRANSFER.COPY_FILE包拷贝文件：

SQL> create directory DGFROM as '+DGTEST/ERPTEST/DATAFILE';

Directory created.

SQL> create directory DGTO as '+DGOPTM/ERPOPTM/DATAFILE';

Directory created.

执行以下命令拷贝数据文件：

exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_ht.268.711907283','DGTO','erp_ht.268');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_ht.269.711907397','DGTO','erp_ht.269');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_ht.277.711972029','DGTO','erp_ht.277');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_index.270.711907487','DGTO','erp_index.270');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_wl.271.711907545','DGTO','erp_wl.271');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp.272.711907565','DGTO','erp.272');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_sp.273.711907695','DGTO','erp_sp.273');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_cw.274.711907757','DGTO','erp_cw.274');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_xm.276.711907831','DGTO','erp_xm.276');
exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','erp_zj.275.711907801','DGTO','erp_zj.275');

要注意的是，这里的目标文件名不能带有ASM自身生成的那一串数字，否则会报错如下：

ORA-19504: failed to create file
"+DGOPTM/ERPOPTM/DATAFILE/erp_zj.275.711907801"
ORA-17502: ksfdcre:4 Failed to create file
+DGOPTM/ERPOPTM/DATAFILE/erp_zj.275.711907801
ORA-15046: ASM file name '+DGOPTM/ERPOPTM/DATAFILE/erp_zj.275.711907801' is not
in single-file creation form
ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 84
ORA-06512: at "SYS.DBMS_FILE_TRANSFER", line 193
ORA-06512: at line 1

这是因为这串数字是ASM用来进行标识的信息，文档Doc ID: Note:452158.1中有说明。老杨的一篇文章描述了类似的问题。

然后再拷贝system等表空间和redo等文件：

SQL> drop directory DGFROM;

Directory dropped.

SQL> create directory DGFROM as '+DGTEST/ERPTEST';

Directory created.

SQL> drop directory DGTO;

Directory dropped.

SQL> create directory DGTO as '+DGOPTM/ERPOPTM';

Directory created.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','redo01.log','DGTO','redo01.log');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','redo02.log','DGTO','redo02.log');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','redo03.log','DGTO','redo03.log');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','system01.dbf','DGTO','system01.dbf');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','undotbs01.dbf','DGTO','undotbs01.dbf');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','sysaux01.dbf','DGTO','sysaux01.dbf');

PL/SQL procedure successfully completed.

SQL> exec DBMS_FILE_TRANSFER.COPY_FILE('DGFROM','users01.dbf','DGTO','users01.dbf');

PL/SQL procedure successfully completed.

需要注意的是，copy过来的文件并不是文件存储的实际路径，而是按原有的路径组织的，新的文件名只是一个alias而已：

ASMCMD> cd ERPOPTM/
ASMCMD> ls -l
Type         Redund  Striped  Time             Sys  Name
N    DATAFILE/
N    control01.ctl => +DGOPTM/ERPTEST/CONTROLFILE/Current.273.713177855
N    control02.ctl => +DGOPTM/ERPTEST/CONTROLFILE/Current.274.713177855
N    control03.ctl => +DGOPTM/ERPTEST/CONTROLFILE/Current.275.713177855
N    redo01.log => +DGOPTM/ERPTEST/ONLINELOG/group_0.266.713120427
N    redo02.log => +DGOPTM/ERPTEST/ONLINELOG/group_0.267.713120435
N    redo03.log => +DGOPTM/ERPTEST/ONLINELOG/group_0.268.713120441
N    sysaux01.dbf => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.271.713120497
N    system01.dbf => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.269.713120449
N    undotbs01.dbf => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.270.713120467
N    users01.dbf => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.272.713120509

ASMCMD> cd DATAFILE/
ASMCMD> ls -l
Type      Redund  Striped  Time             Sys  Name
N    erp.272 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.261.713119325
N    erp_cw.274 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.263.713119613
N    erp_ht.268 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.257.713118643
N    erp_ht.269 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.256.713118843
N    erp_ht.277 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.258.713119001
N    erp_index.270 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.259.713119135
N    erp_sp.273 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.262.713119553
N    erp_wl.271 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.260.713119275
N    erp_xm.276 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.264.713119665
N    erp_zj.275 => +DGOPTM/ERPTEST/DATAFILE/COPY_FILE.265.713119693

至此文件拷贝完成。

第五步，建立密码文件

[oracle@erpdevdb dbs]$ orapwd file=/u01/app/oracle/oracle/product/10.2.0/db_1/dbs/orapwerpoptm password=erpoptm entries=5

第六步，启动数据库

先启动到nomount状态，这时会用到参数文件：

[oracle@erpdevdb dbs]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Mar 8 14:01:08 2010

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

Connected to an idle instance.

SQL> startup nomount
ORACLE instance started.

Total System Global Area 2147483648 bytes
Fixed Size                  2022144 bytes
Variable Size             486540544 bytes
Database Buffers         1644167168 bytes
Redo Buffers               14753792 bytes
SQL>
SQL> alter database mount
2  /
alter database mount
*
ERROR at line 1:
ORA-00205: error in identifying control file, check alert log for more info

oracle会先找spfile，然后找pfile，找若没有参数文件，则会报错：

[oracle@erpdevdb dbs]$ export ORACLE_SID=erpoptm
[oracle@erpdevdb dbs]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Mar 8 14:00:10 2010

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

Connected to an idle instance.

SQL> startup nomount
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/oracle/product/10.2.0/db_1/dbs/initerpoptm.ora'

mount时会找控制文件，没有则会出现如上所示的错误，可以在nomount阶段来建立控制文件，先关闭源库，然后在目标库启动到nomount阶段来建立控制文件：

SQL> CREATE CONTROLFILE REUSE DATABASE "ERPTEST" NORESETLOGS  NOARCHIVELOG
2      MAXLOGFILES 16
3      MAXLOGMEMBERS 3
4      MAXDATAFILES 100
5      MAXINSTANCES 8
6      MAXLOGHISTORY 29200
7  LOGFILE
8    GROUP 1 '+DGOPTM/erpoptm/redo01.log'  SIZE 50M,
9    GROUP 2 '+DGOPTM/erpoptm/redo02.log'  SIZE 50M,
10    GROUP 3 '+DGOPTM/erpoptm/redo03.log'  SIZE 50M
11  -- STANDBY LOGFILE
12  DATAFILE
13    '+DGOPTM/erpoptm/system01.dbf',
14    '+DGOPTM/erpoptm/undotbs01.dbf',
15    '+DGOPTM/erpoptm/sysaux01.dbf',
16    '+DGOPTM/erpoptm/users01.dbf',
17    '+DGOPTM/erpoptm/datafile/erp_ht.268',
18    '+DGOPTM/erpoptm/datafile/erp_ht.269',
19    '+DGOPTM/erpoptm/datafile/erp_index.270',
20    '+DGOPTM/erpoptm/datafile/erp_wl.271',
21    '+DGOPTM/erpoptm/datafile/erp.272',
22    '+DGOPTM/erpoptm/datafile/erp_sp.273',
23    '+DGOPTM/erpoptm/datafile/erp_cw.274',
24    '+DGOPTM/erpoptm/datafile/erp_zj.275',
25    '+DGOPTM/erpoptm/datafile/erp_xm.276',
26    '+DGOPTM/erpoptm/datafile/erp_ht.277'
27  CHARACTER SET ZHS16GBK
28  /

Control file created.

为什么要先关闭源库呢，这是因为二者有相同的db_name，oracle通过一个lk开头的文件来在运行阶段lock某个库，如果不关闭会在alert日志中看到以下错误：

Tue Mar  9 08:53:20 2010
sculkget: failed to lock /u01/app/oracle/oracle/product/10.2.0/db_1/dbs/lkERPTEST exclusive
sculkget: lock held by PID: 29747
Tue Mar  9 08:53:21 2010
ORA-09968: unable to lock file
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 29747
Tue Mar  9 08:53:21 2010
Errors in file /u01/app/oracle/admin/erpoptm/udump/erpoptm_ora_26143.trc:
ORA-01158: database  already mounted

由于现在在同一个主机上有两个相同db_name的数据库，那么如何能同时启动呢，这需要指定参数db_unique_ name来区分开来，这个参数在standby环境也是必须设置的。

修改源库的db_unique_name如下：

SQL> alter system set db_unique_name=erptest scope=spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

回到正题，在创建控制文件的过程中会验证数据文件是否存在，如果不存在则报以下错误：

ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01565: error in identifying file '+DGOPTM/erpoptm/system01.dbf'
ORA-17503: ksfdopn:2 Failed to open file +DGOPTM/erpoptm/system01.dbf
ORA-15173: entry 'system01.dbf' does not exist in directory 'erpoptm'

也会检查参数文件中的db_name和数据文件头的db_name是否相同，否则报以下错误:

ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01161: database name ERPTEST in file header does not match given name of
ERPOPTM
ORA-01110: data file 1: '+DGOPTM/erpoptm/system01.dbf'

接着打开数据库：

SQL> alter database open
2  /
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '+DGOPTM/erpoptm/system01.dbf'

这说明需要介质恢复，可以一个一个数据文件的来recover，也可以直接recover database：

SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

SQL> show parameter db_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      erptest
SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_name                        string      erpoptm

注意这种情况下启动的数据库会做实例恢复，因为redo和数据文件等都是copy过来的。这样就建立了一个db_name为erptest，而instance_name和SID为erpoptm的数据库。

然后要马上建立临时表空间：

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '+DGOPTM/erpoptm/temp01.dbf' SIZE 8192M REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;

Tablespace altered.

但是事情并没有结束，很快就发些这个新搭建的库会很快死掉，alert日志记录了如下的信息：

Tue Mar  9 10:11:24 2010
Errors in file /u01/app/oracle/admin/erpoptm/bdump/erpoptm_mmon_30564.trc:
ORA-00600: internal error code, arguments: [504], [0x06000AD18], [1], [0], [ksv instance], [0], [0], [0x0DCFCE590]
Tue Mar  9 10:11:26 2010
Errors in file /u01/app/oracle/admin/erpoptm/bdump/erpoptm_mmon_30564.trc:
ORA-00600: internal error code, arguments: [504], [0x06000AD18], [1], [0], [ksv instance], [0], [0], [0x0DCFCE590]
Tue Mar  9 10:11:26 2010
Errors in file /u01/app/oracle/admin/erpoptm/bdump/erpoptm_mmon_30564.trc:
ORA-00600: internal error code, arguments: [4193], [2887], [2890], [], [], [], [], []

碰到很多4193的600错误，这种一般和undo有关，重建一下undo即可：

SQL> show parameter  undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1

SQL> create undo tablespace undotbs2 datafile '+DGOPTM/ERPOPTM/undotbs2.dbf' size 1024m;

Tablespace created.

SQL> alter system set undo_tablespace=undotbs2;

System altered.

SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS2

再修改一下参数文件initerpoptm.ora，修改这里的undo：

*.undo_tablespace='UNDOTBS2'

重新启动数据库，设置db_unique_name和spfile：

SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string
SQL>
SQL> create spfile from pfile;

File created.

SQL> shutdown immediate

SQL> startup
ORACLE instance started.
Database mounted.
Database opened.
SQL> show parameter spfile

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      /u01/app/oracle/oracle/product
/10.2.0/db_1/dbs/spfileerpoptm
.ora
SQL> alter system set db_unique_name=erpoptm scope=spfile;

System altered.

SQL> shutdown immediate
SQL> startup
SQL>
SQL> show parameter db_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_name                              string      erptest
SQL>
SQL>
SQL>
SQL> show parameter instance_name;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_name                        string      erpoptm
SQL>
SQL>
SQL>
SQL> show parameter db_unique_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      ERPOPTM

可以看到spfile默认会放到dbs目录下。至此这个数据库应该是可用了，当然还要配置一下网络监听等服务：

[oracle@erpdevdb admin]$ vi tnsnames.ora

ERPOPTM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = erpdevdb)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = erpoptm)
)
)

[oracle@erpdevdb admin]$ lsnrctl

LSNRCTL> help
The following operations are available
An asterisk (*) denotes a modifier or extended command:

start               stop                status
services            version             reload
save_config         trace               spawn
change_password     quit                exit
set*                show*

LSNRCTL> reload
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
The command completed successfully

[oracle@erpdevdb admin]$ vi /etc/oratab

erpoptm:/u01/app/oracle/oracle/product/10.2.0/db_1:Y

其中DML Event Clause为：

其中referencing_clause为：

一般来说建立after的触发器效率比较高，为了提高效率，我们应该细化限制触发的条件，比如指定字段和值的范围才触发：

CREATE TRIGGER hr.salary_check

BEFORE INSERT OR UPDATE OF salary, job_id ON hr.employees

FOR EACH ROW

WHEN (new.job_id <> 'AD_VP')

pl/sql_block ......

触发器和引起触发的SQL是同一个事务，除非用PRAGMA AUTONOMOUS_TRANSACTION参数指定自治事务，但可能会出现数据结果不一致的问题。

以下信息是数据库实例crash的记录：

Sun Feb 14 20:07:18 2010
Shutting down instance (abort)
License high water mark = 381
Instance terminated by USER, pid = 619164

取消实例依赖VIP的方法是导出实例部分的资源配置，修改后再注册回去。步骤如下：

DB1@/home/oracle>crs_stat -p ora.racdb.rac1.inst >> /tmp/ora.racdb.rac1.inst.cap

然后编辑这个文件，去掉对vip的依赖：

DB1@/home/oracle>vi /tmp/ora.racdb.rac1.inst.cap

REQUIRED_RESOURCES= 这里设为空

然后再注册回去：

DB1@/home/oracle>crs_register -u ora.racdb.rac1.inst -dir /tmp

所有的节点都需要修改，再用crs_stat -p命令查看已经生效了。如果RAC环境中断网引起的实例崩溃，很可能就是这个问题。

查看当前分区：

[root@erpdevdb ~]# fdisk -l

Disk /dev/sda: 1048.5 GB, 1048576000000 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          65      522081   83  Linux
/dev/sda2              66        2676    20972857+  8e  Linux LVM
/dev/sda3            2677        5287    20972857+  8e  Linux LVM
/dev/sda4            5288      127482   981531337+   5  Extended
/dev/sda5            5288        7898    20972826   8e  Linux LVM
/dev/sda6            7899       20400   100422283+  8e  Linux LVM
/dev/sda7           20401       32850   100004593+  8e  Linux LVM
/dev/sda8           32851       57750   200009218+  8e  Linux LVM

Disk /dev/sdb: 1198.8 GB, 1198899855360 bytes
255 heads, 63 sectors/track, 145757 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       37349   300005811   83  Linux
/dev/sdb2           37350       74698   300005842+  83  Linux
/dev/sdb3           74699      136946   500007060   83  Linux

在/dev/sda设备上创建一个新的分区：

[root@erpdevdb ~]# fdisk /dev/sda

The number of cylinders for this disk is set to 127482.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help): p

Disk /dev/sda: 1048.5 GB, 1048576000000 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          65      522081   83  Linux
/dev/sda2              66        2676    20972857+  8e  Linux LVM
/dev/sda3            2677        5287    20972857+  8e  Linux LVM
/dev/sda4            5288      127482   981531337+   5  Extended
/dev/sda5            5288        7898    20972826   8e  Linux LVM
/dev/sda6            7899       20400   100422283+  8e  Linux LVM
/dev/sda7           20401       32850   100004593+  8e  Linux LVM
/dev/sda8           32851       57750   200009218+  8e  Linux LVM

Command (m for help): n
First cylinder (57751-127482, default 57751):
Using default value 57751
Last cylinder or +size or +sizeM or +sizeK (57751-127482, default 127482): +300000M

Command (m for help): p

Disk /dev/sda: 1048.5 GB, 1048576000000 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          65      522081   83  Linux
/dev/sda2              66        2676    20972857+  8e  Linux LVM
/dev/sda3            2677        5287    20972857+  8e  Linux LVM
/dev/sda4            5288      127482   981531337+   5  Extended
/dev/sda5            5288        7898    20972826   8e  Linux LVM
/dev/sda6            7899       20400   100422283+  8e  Linux LVM
/dev/sda7           20401       32850   100004593+  8e  Linux LVM
/dev/sda8           32851       57750   200009218+  8e  Linux LVM
/dev/sda9           57751       94224   292977373+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
[root@erpdevdb ~]#

这时能看到新的分区：

[root@erpdevdb ~]# fdisk -l

Disk /dev/sda: 1048.5 GB, 1048576000000 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          65      522081   83  Linux
/dev/sda2              66        2676    20972857+  8e  Linux LVM
/dev/sda3            2677        5287    20972857+  8e  Linux LVM
/dev/sda4            5288      127482   981531337+   5  Extended
/dev/sda5            5288        7898    20972826   8e  Linux LVM
/dev/sda6            7899       20400   100422283+  8e  Linux LVM
/dev/sda7           20401       32850   100004593+  8e  Linux LVM
/dev/sda8           32851       57750   200009218+  8e  Linux LVM
/dev/sda9           57751       94224   292977373+  83  Linux
/dev/sda10          94225      127482   267144853+  83  Linux

Disk /dev/sdb: 1198.8 GB, 1198899855360 bytes
255 heads, 63 sectors/track, 145757 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       37349   300005811   83  Linux
/dev/sdb2           37350       74698   300005842+  83  Linux
/dev/sdb3           74699      136946   500007060   83  Linux
/dev/sdb4          136947      145757    70774357+  83  Linux

查看当前的ASM磁盘组：

[root@erpdevdb ~]# /etc/init.d/oracleasm listdisks
VOL1
VOL2
VOL3

这时创建新的ASM磁盘组会报错，正如前面创建分区保存时提示的，需要重启后才生效。

[root@erpdevdb ~]# /etc/init.d/oracleasm createdisk VOL4 /dev/sda9
Marking disk "VOL4" as an ASM disk: [FAILED]

关闭已有的oracle 实例和ASM实例：

[oracle@erpdevdb ~]$ export ORACLE_SID=devdb
[oracle@erpdevdb ~]$ sqlplus " / as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Feb 25 12:52:48 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

[oracle@erpdevdb ~]$ export ORACLE_SID=+ASM
[oracle@erpdevdb ~]$ sqlplus " /  as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Feb 25 12:57:24 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

关闭listener ：

[oracle@erpdevdb ~]$ lsnrctl

LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 25-FEB-2010 12:58:32

Copyright (c) 1991, 2005, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> stat   
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Start Date                29-NOV-2009 13:13:31
Uptime                    87 days 23 hr. 45 min. 5 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=erpdevdb.chinacnd.com)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
LSNRCTL> stop
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
The command completed successfully
LSNRCTL> exit

重启服务器：

[root@erpdevdb ~]# reboot

Broadcast message from root (pts/1) (Thu Feb 25 12:59:17 2010):

The system is going down for reboot NOW!

重启后启动Listerner：

[root@erpdevdb ~]# su - oracle
[oracle@erpdevdb ~]$ lsnrctl start

LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 25-FEB-2010 13:03:58

Copyright (c) 1991, 2005, Oracle.  All rights reserved.

Starting /u01/app/oracle/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.1.0 - Production
System parameter file is /u01/app/oracle/oracle/product/10.2.0/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/oracle/product/10.2.0/db_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=erpdevdb.chinacnd.com)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Start Date                25-FEB-2010 13:03:58
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=erpdevdb.chinacnd.com)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
[oracle@erpdevdb ~]$

启动Asm实例：

[oracle@erpdevdb ~]$ export ORACLE_SID=+ASM
[oracle@erpdevdb ~]$ sqlplus  "/  as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Feb 25 13:04:17 2010

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

Connected to an idle instance.

SQL> startup
ASM instance started

Total System Global Area  130023424 bytes
Fixed Size                  2019032 bytes
Variable Size             102838568 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

启动其他数据库实例：

[oracle@erpdevdb ~]$ export ORACLE_SID=devdb
[oracle@erpdevdb ~]$ sqlplus  "/  as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Feb 25 13:04:40 2010

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

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 4294967296 bytes
Fixed Size                  2026296 bytes
Variable Size             285213896 bytes
Database Buffers         3992977408 bytes
Redo Buffers               14749696 bytes
Database mounted.
Database opened.
SQL> exit

创建Asm设备：

[root@erpdevdb ~]# /etc/init.d/oracleasm createdisk VOL4 /dev/sda9
Marking disk "VOL4" as an ASM disk: [  OK  ]
[root@erpdevdb ~]#
[root@erpdevdb ~]#
[root@erpdevdb ~]#
[root@erpdevdb ~]# /etc/init.d/oracleasm listdisks
VOL1
VOL2
VOL3
VOL4

创建ASM磁盘组：

[root@erpdevdb ~]# su - oracle
[oracle@erpdevdb ~]$ export ORACLE_SID=+ASM
[oracle@erpdevdb ~]$ sqlplus  "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Feb 25 13:52:44 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL>
SQL>
SQL> create diskgroup DGTEST external redundancy disk 'ORCL:VOL4';

Diskgroup created.

SQL>
SQL> select name,group_number,disk_number,mode_status from v$asm_disk;

NAME                           GROUP_NUMBER DISK_NUMBER MODE_ST
------------------------------ ------------ ----------- -------
VOL1                                      3           0 ONLINE
VOL2                                      1           0 ONLINE
VOL3                                      2           0 ONLINE
VOL4                                      4           0 ONLINE

SQL> select group_number,name,total_mb,free_mb from v$asm_diskgroup;

GROUP_NUMBER NAME                             TOTAL_MB    FREE_MB
------------ ------------------------------ ---------- ----------
           1 DGDEV                              292974     151815
           2 DGPAPER                            488288     328379
           3 DGSTUDY                            292974     168839
           4 DGTEST                             286110     286058

SQL> exit

然后通过dbca工具创建新的实例，在创建过程中存储选择这里新建的DGTEST磁盘组即可：

首先去下载软件，地址分别是

http://java.sun.com/javase/downloads/index.jsp

和

http://tomcat.apache.org/

注意选择自己需要的合适的版本，比如我下载的是apache-tomcat-5.5.23.tar.gz和jdk-6u18-linux-x64-rpm.bin.gz，然后上传到/tmp目录下。

安装JDK：

[root@tomcat1 tmp]# sh jdk-6u18-linux-x64-rpm.bin

Sun Microsystems, Inc. Binary Code License Agreement

for the JAVA SE DEVELOPMENT KIT (JDK), VERSION 6

......

Do you agree to the above license terms? [yes or no]
           yes
Unpacking...
Checksumming...
Extracting...

......

Press Enter to continue.....
Done.

安装完成后，JDK被安装在/usr/java目录下。这个版本会在当前路径下安装javaDB，以前的版本不会。

安装tomcat ：

[root@tomcat1 tmp]# tar -zxvf apache-tomcat-5.5.23.tar.gz

然后会在当前路径下生成apache-tomcat-5.5.23文件夹，把它mv或cp到你想要的路径即可。

[root@tomcat1 tmp]# cp -a apache-tomcat-5.5.23 /usr/local/

然后配置环境变量：

[root@tomcat1 tmp]# vi /etc/profile

#set java environment
JAVA_HOME=/usr/java/jdk1.6.0_18
export TOMCAT_HOME=/usr/local/apache-tomcat-5.5.23

CLASSPATH=.:$JAVA_HOME/lib/tools.jar
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASSPATH PATH

[root@tomcat1 tmp]# source /etc/profile

查看java的版本号已经生效了：

[root@tomcat1 tmp]# java -version
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

测试tomcat ：

[root@tomcat1 tmp]# cd /usr/local/apache-tomcat-5.5.23/bin/

[root@tomcat1 bin]# ./startup.sh
Using CATALINA_BASE:   /usr/local/apache-tomcat-5.5.23
Using CATALINA_HOME:   /usr/local/apache-tomcat-5.5.23
Using CATALINA_TMPDIR: /usr/local/apache-tomcat-5.5.23/temp
Using JRE_HOME:       /usr/java/jdk1.6.0_18

打开网页查看8080端口就能看到可爱的猫了。

Mon Feb  8 10:00:54 2010
Errors in file /u01/admin/erpdb/bdump/erpdb2_m001_598774.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Mon Feb  8 10:00:58 2010
Trace dumping is performing id=[cdmp_20100208100058]

检查trace文件，发现了执行的SQL语句如下：

*** 2010-02-08 10:00:54.825
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Current SQL statement for this session:

SELECT count(*) over() as total_count,
sd_xe_ash_nm.event_name,
sd_xe_ash_nm.event_id,
sd_xe_ash_nm.parameter1 as p1text,
(CASE
WHEN (sd_xe_ash_nm.parameter1 is NULL OR
sd_xe_ash_nm.parameter1 = '0') THEN
0
ELSE
1
END) as p1valid,
sd_xe_ash_nm.parameter2 as p2text,
(CASE
WHEN (sd_xe_ash_nm.parameter2 is NULL OR
sd_xe_ash_nm.parameter2 = '0') THEN
0
ELSE
1
END) as p2valid,
sd_xe_ash_nm.parameter3 as p3text,
(CASE
WHEN (sd_xe_ash_nm.parameter3 is NULL OR
sd_xe_ash_nm.parameter3 = '0') THEN
0
ELSE
1
END) as p3valid,
sd_xe_ash_nm.keh_evt_id,
nvl(xc.class#, 0) as class_num,
sd_xe_ash_nm.wait_class_id,
nvl(xc.keh_id, 0) as keh_ecl_id,
sd_xe_ash_nm.ash_cnt,
sd_xe_ash_nm.tot_wts_diff,
sd_xe_ash_nm.tot_tmo_diff,
sd_xe_ash_nm.tim_wait_diff
FROM (SELECT sd_xe_ash.*,
evtname.event_name,
evtname.wait_class_id,
evtname.parameter1,
evtname.parameter2,
evtname.parameter3
FROM (SELECT sd_xe.*, nvl(ash.cnt, 0) as ash_cnt
FROM (SELECT nvl(xe.keh_id, 0) as keh_evt_id,
nvl(sd.event_id, xe.event_hash) as event_id,
nvl(sd.tot_wts_diff, 0) as tot_wts_diff,
nvl(sd.tot_tmo_diff, 0) as tot_tmo_diff,
nvl(sd.tim_wait_diff, 0) as tim_wait_diff
FROM (SELECT endsn.event_id as event_id,
(endsn.total_waits -
nvl(begsn.total_waits, 0)) as tot_wts_diff,
(endsn.total_timeouts -
nvl(begsn.total_timeouts, 0)) as tot_tmo_diff,
(endsn.time_waited_micro -
nvl(begsn.time_waited_micro, 0)) as tim_wait_diff
FROM (SELECT end_snap.*
FROM (SELECT t1.*
FROM WRH$_SYSTEM_EVENT t1,
WRM$_SNAPSHOT     s1
WHERE t1.dbid = s1.dbid
AND t1.instance_number =
s1.instance_number
AND t1.snap_id = s1.snap_id
AND s1.bl_moved = 0
UNION ALL
SELECT t2.*
FROM WRH$_SYSTEM_EVENT_BL t2,
WRM$_SNAPSHOT        s2
WHERE t2.dbid = s2.dbid
AND t2.instance_number =
s2.instance_number
AND t2.snap_id = s2.snap_id
AND s2.bl_moved <> 0) end_snap
WHERE end_snap.dbid = :dbid
and end_snap.instance_number =
:instance_number
and end_snap.snap_id = :end_snap) endsn
LEFT OUTER JOIN (SELECT beg_snap.*
FROM (SELECT t1.*
FROM WRH$_SYSTEM_EVENT t1,
WRM$_SNAPSHOT     s1
WHERE t1.dbid =
s1.dbid
AND t1.instance_number =
s1.instance_number
AND t1.snap_id =
s1.snap_id
AND s1.bl_moved = 0
UNION ALL
SELECT t2.*
FROM WRH$_SYSTEM_EVENT_BL t2,
WRM$_SNAPSHOT        s2
WHERE t2.dbid =
s2.dbid
AND t2.instance_number =
s2.instance_number
AND t2.snap_id =
s2.snap_id
AND s2.bl_moved <> 0) beg_snap
WHERE beg_snap.dbid = :dbid
and beg_snap.instance_number =
:instance_number
and beg_snap.snap_id =
:beg_snap) begsn ON endsn.event_id =
begsn.event_id) sd
FULL OUTER JOIN X$KEHEVTMAP xe ON sd.event_id =
xe.event_hash) sd_xe
LEFT OUTER JOIN (SELECT a.event_id, count(*) as cnt
FROM (SELECT t1.*
FROM WRH$_ACTIVE_SESSION_HISTORY t1,
WRM$_SNAPSHOT               s1
WHERE t1.dbid = s1.dbid
AND t1.instance_number =
s1.instance_number
AND t1.snap_id = s1.snap_id
AND s1.bl_moved = 0
UNION ALL
SELECT t2.*
FROM WRH$_ACTIVE_SESSION_HISTORY_BL t2,
WRM$_SNAPSHOT                  s2
WHERE t2.dbid = s2.dbid
AND t2.instance_number =
s2.instance_number
AND t2.snap_id = s2.snap_id
AND s2.bl_moved <> 0) a
WHERE a.dbid = :dbid
and a.instance_number = :instance_number
and a.snap_id > :beg_snap
and a.snap_id <= :end_snap
and a.wait_time = 0
GROUP BY a.event_id) ash ON sd_xe.event_id =
ash.event_id) sd_xe_ash,
WRH$_EVENT_NAME evtname
WHERE evtname.event_id = sd_xe_ash.event_id
and evtname.event_id > 0
and evtname.dbid = :dbid) sd_xe_ash_nm,
X$KEHECLMAP xc
WHERE sd_xe_ash_nm.wait_class_id = xc.class_hash
ORDER BY sd_xe_ash_nm.wait_class_id,
sd_xe_ash_nm.tim_wait_diff DESC,
sd_xe_ash_nm.event_id

到了晚上，收集统计信息的时候日志再次出现提示：

Mon Feb  8 22:05:29 2010
Errors in file /u01/admin/erpdb/bdump/erpdb2_j000_270930.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [2], [0], [7], [], [], [], []
Mon Feb  8 22:05:32 2010
Trace dumping is performing id=[cdmp_20100208220532]
Mon Feb  8 22:05:36 2010
Errors in file /u01/admin/erpdb/bdump/erpdb2_j000_270930.trc:
ORA-00600: internal error code, arguments: [ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [2], [0], [7], [], [], [], []
ORA-06512: at "SYS.DBMS_STATS", line 19089
], [], [], [], [], [], [], []

而从trace文件查看这次是执行了以下SQL语句：

insert /*+ append */
into sys.ora_temp_2_ds_1073343
select /*+ no_parallel(t) no_parallel_index(t) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring */
"PLSQL_ENTRY_OBJECT_ID",
"PLSQL_ENTRY_SUBPROGRAM_ID",
"PLSQL_OBJECT_ID",
"PLSQL_SUBPROGRAM_ID",
"SNAP_ID",
"DBID",
"INSTANCE_NUMBER",
"SAMPLE_ID",
"SAMPLE_TIME",
"SESSION_ID",
"SESSION_SERIAL#",
"USER_ID",
"SQL_ID",
"SQL_CHILD_NUMBER",
"SQL_PLAN_HASH_VALUE",
"SERVICE_HASH",
"SESSION_TYPE",
"SQL_OPCODE",
"QC_SESSION_ID",
"QC_INSTANCE_ID",
"CURRENT_OBJ#",
"CURRENT_FILE#",
"CURRENT_BLOCK#",
"SEQ#",
"EVENT_ID",
"P1",
"P2",
"P3",
"WAIT_TIME",
"TIME_WAITED",
"PROGRAM",
"MODULE",
"ACTION",
"CLIENT_ID",
"FORCE_MATCHING_SIGNATURE",
"BLOCKING_SESSION",
"BLOCKING_SESSION_SERIAL#",
"XID"
from "SYS"."WRH$_ACTIVE_SESSION_HISTORY" sample(6.1241078288) t

从metalink查看这个错误可能是以下原因：

一、并行查询导致的，解决办法就是改用串行查询

Bug# 6405339   See Note:6405339.8
Corruption / OERI[kcbz_check_objd_typ_3] / OERI:5400 / OERI:5357 from PQ
Fixed: 10.2.0.5, 11.1.0.7, 11.2

Bug 6405339  Corruption / OERI[kcbz_check_objd_typ_3] / OERI:5400 / OERI:5357 from PQ
A parallel query which uses TEMP segments can suffer corruption
within temporary segments between the slaves leading to various ORA-600
errors like:

ORA-600 [kcbz_check_objd_typ_3]
ORA-600 [5400]
ORA-600 [5357]

Workaround
Run the query serially

二、基于SCN的恢复之后

Bug# 5689412   See Note:5689412.8
ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery
Fixed: 10.2.0.5

Bug 5689412  ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery

ORA-600 [kcbz_check_objd_typ_3] after SCN based recovery to SCN just before
a TRUNCATE operation.

eg:
On primary
create table y (d date, v varchar2(30));
insert into y values (SYSDATE, 'test1');
insert into y values (SYSDATE, 'test2');
truncate table y;

Recover the standby to a point just prior to the
truncate to recover this specific table. (Detemine
the SCN by mining the redo)

recover standby database until change <SCN>;
-> media recovery completes successfully

alter database open read only;
select * from y;
^
ORA-600 [kcbz_check_objd_typ_3]

三、using a multi-table insert SQL with direct load operations

Bug# 4592596   See Note:4592596.8
Corruption (ORA-1410 / ORA-8103) from multi-table insert with direct load
Fixed: 10.2.0.4, 11.1.0.6, 10.2.0.2.P01, 10.2.0.2.P08, 10.2.0.3.P03
Bug 4592596  Corruption (ORA-1410 / ORA-8103) from multi-table insert with direct load

Corruption can occur using a multi-table insert SQL with
direct load operations. Eg: If the SQL goes parallel.

This can result in subsequent ORA-1410 / ORA-8103 type errors on selects
from the target table/s.

In the case of an internal error like ORA-600 [kcbz_check_objd_typ_3] the
trace file may contain a redo dump with OP:19.1 for the affected object:

OP:19.1 Direct Loader block redo entry

It may affect AWR tables as some of them are populated with Direct Load.

四、Segment advisor带来的buffer坏块，这应该也是本案例的原因所在，可以禁用AUTO_SPACE_ADVISOR_JOB并清空buffer来解决。

Bug# 4430244 +  See Note:4430244.8
Segment advisor can load blocks of dropped objects into buffer cache (KCB OERI errors)
Fixed: 10.2.0.4, 11.1.0.6, 10.2.0.2.P11, 10.2.0.3.P11
Bug 4430244  Segment advisor can load blocks of dropped objects into buffer cache (KCB OERI errors)

Segment advisor code (eg: DBMS_SPACE.OBJECT_GROWTH_TREND)
can load blocks into the cache for DROPped objects as
CURRENT leading to subsequent operations seeing an incorrect
(old) version of a block.
This can lead to various internal buffer cache related
errors such as ORA-600 [kcbnew_3] / ORA-600 [kcbz_check_objd_typ_3].
The exact error depends on which code sees the block.

eg:
If the segment advisor decides to scan table USER1.TAB1
then this table is concurrently dropped then the advisor
may read blocks for the dropped object into the cache as
"CURRENT" block images.
A seperate session may do a direct load of a block from
the dropped object so the block now belongs to USER2.TAB2.
A subsequent select from USER2.TAB2 can see the old
USER1.TAB1 block in the cache so fails.

Workaround
Do not use segment advisor to prevent the problem occurring.
eg:  connect / as sysdba;
exec dbms_scheduler.disable('AUTO_SPACE_ADVISOR_JOB');

Use "alter system flush buffer_cache" to clear bad blocks
from the cache (In RAC the block may have sourced from a
different instance so you need to flush all buffer caches).

另外一个Bug 和这个类似，解决办法相同：5218905  OERI[kcbnew_3] when segment advisor has been used。

Thu Jan 28 10:29:48 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation
Thu Jan 28 10:29:50 2010
Trace dumping is performing id=[cdmp_20100128102950]

Thu Jan 28 10:30:03 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []
Thu Jan 28 10:30:04 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []

这里也明确提示了是执行SQL导致的问题，而用户取消了这个操作。通过查看trace文件也确实发现了干坏事的人：

O/S info: user: sxw, term: ITB_SXW_XP, ospid: 5392:4416, machine: XC\ITB_SXW_XP
program: plsqldev.exe
application name: PL/SQL Developer, hash value=1190136663
action name: Test Window - Script for procedu, hash value=3367543201

经过确认确实是有开发人员执行一个大存储过程，长时间没出来结果后强制取消了操作。通过AWR报告也印证了这一点：

可见这个SQL花费了13分钟，而执行次数确是0次。

虽然没引起实例崩溃，但在生产环境调试程序仍然要小心，数据库是脆弱的，我们必须对其心存敬畏。

p5a1@/#snap -r

The following directories and files will be deleted:
-----------------------------------------------------------
/tmp/ibmsupt/general (directory)
/tmp/ibmsupt/other (directory)
/tmp/ibmsupt/testcase (directory)
/tmp/ibmsupt/ssa (directory)
/tmp/ibmsupt/pcixscsi (directory)
/tmp/ibmsupt/snap.pax.Z (file)

Do you want me to remove these directories (y/n)? y
Removing... done.

如果以前未做过snap，会提示：

nothing to clean up

清理完成后可以开始收集：

p5a1@/#snap -gbLc
/var/adm/ras/trcfile: No such file or directory
Checking space requirement for general information.... done.
.********Checking and initializing directory structure
Creating /tmp/ibmsupt/svCollect directory tree... done.
Creating /tmp/ibmsupt/client_collect directory tree... done.
Creating /tmp/ibmsupt/lvm directory tree... done.
Creating /tmp/ibmsupt/ssa directory tree... done.
Creating /tmp/ibmsupt/general directory tree... done.
Creating /tmp/ibmsupt/general/diagnostics directory tree... done.
Creating /tmp/ibmsupt/pcixscsi directory tree... done.
Creating /tmp/ibmsupt/testcase directory tree... done.
Creating /tmp/ibmsupt/other directory tree... done.
********Finished setting up directory /tmp/ibmsupt

Checking Space requirement for svCollect
The script svCollect is not executable in /usr/lib/ras/snapscripts
Checking Space requirement for client_collect
Checking space requirement for ssa information.......... done.
Checking space requirement for logical volume manager information......
Checking space requirement for Enhanced CLVM information..../tmp/ch.log.* not found
done.
Checking for enough free space in filesystem... done.

/var/adm/ras/trcfile: No such file or directory
Gathering general system information............ done.
Gathering platform/scanout information.done.
Gathering svCollect data
The script svCollect is not executable in /usr/lib/ras/snapscripts
Gathering client_collect data
Gathering pcixscsi system information........... done.
Gathering ssa system information.......... done.
Gathering logical volume manager information..........
Gathering Enhanced CLVM information..../tmp/ch.log.* not found
done.

Creating compressed pax file...
Starting pax/compress process... Please wait... done.

-rw-------   1 0        0           1259857 Jan 20 09:24 snap.pax.Z

收集完成后，通过ftp就可以拿下这个文件了：

Microsoft Windows XP [版本 5.1.2600]
(C) 版权所有 1985-2001 Microsoft Corp.

C:\Documents and Settings\banping>ftp 172.16.0.62
Connected to 172.16.0.62.
220 p5a1 FTP server (Version 4.2 Thu Jul 12 13:39:06 CDT 2007) ready.
User (172.16.0.62:(none)): root
331 Password required for root.
Password:
230-Last unsuccessful login: Sat Jan 16 09:43:39 BEIST 2010 on /dev/pts/0 from i
user.banping.com
230-Last login: Tue Jan 19 09:10:37 BEIST 2010 on ftp from user.banping.com
230 User root logged in.
ftp> bin
200 Type set to I.
ftp> get /tmp/ibmsupt/snap.pax.Z
200 PORT command successful.
150 Opening data connection for /tmp/ibmsupt/snap.pax.Z (1259857 bytes).
226 Transfer complete.
ftp: 收到 1259857 字节，用时 0.09Seconds 13402.73Kbytes/sec.

去user用户的document目录下就能拿到这个文件了。

话说那时是2010年第一个工作日，早上来发现备份库小型机一个目录占满了：

p55a@/home/oracle> df -g

Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on

/dev/fslv01       53.50      0.00  100%     1167    68% /stb_arch

查看可用的存储空间：

p55a@/home/oracle> lsvg
rootvg
backvg

p55a@/home/oracle> lsvg backvg
VOLUME GROUP:       backvg                   VG IDENTIFIER:  000221f30000d600000001141bb7ac12
VG STATE:           active                   PP SIZE:        256 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      546 (139776 megabytes)
MAX LVs:            256                      FREE PPs:       0 (0 megabytes)
LVs:                4                        USED PPs:       546 (139776 megabytes)
OPEN LVs:           3                        QUORUM:         2
TOTAL PVs:          1                        VG DESCRIPTORS: 2
STALE PVs:          0                        STALE PPs:      0
ACTIVE PVs:         1                        AUTO ON:        yes
MAX PPs per VG:     32512
MAX PPs per PV:     1016                     MAX PVs:        32
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

已经没有足够的空间可以分配，而这个/stb_arch是存放主库传过来的归档日志，很显然备库在apply这些归档时出现了阻塞，导致主库过来的归档文件不断积压，最终占满了空间。

先去主库暂停到备库的日志同步：

SQL> show parameter log_archive_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest                     string
log_archive_dest_1                   string      LOCATION=/ora_arch VALID_FOR=(
ALL_LOGFILES,ALL_ROLES) DB_UNI
QUE_NAME=erpdb
log_archive_dest_10                  string
log_archive_dest_2                   string      SERVICE=bkdb VALID_FOR=(ONLIN
E_LOGFILES,PRIMARY_ROLE) DB_UN
IQUE_NAME=bkdb

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

在备库查看DBA_LOGSTDBY_EVENTS视图：

SELECT EVENT_TIME,EVENT,XIDUSN, XIDSLT, XIDSQN FROM DBA_LOGSTDBY_EVENTS order by 1 desc;

发现有建立临时表的操作引起了阻塞：

create global temporary table sntempStoreOut090407 on commit preserve rows as
select
g.islcode,idx,g.bcode as bcode1,g.bcode
,g.scode,g.hcode,g.receivecode,g.ihcode,g.ecode
,g.gcode,g.gattr1,g.gattr2,g.gattr3,g.gattr4,
,g.qtx,g.qtp,g.qtpunit,g.qtycount,g.qtyunit,g.qty,g.iodate as iodate,g.ratifydate as ratifydate,g.stockfrom,g.piecewt,g.slstatus
,g.rmb2,upric0 as upric0
,g.rmb0 as rmb0
,g.gtcode1 as gtcode1
,g.slcode
,g.ecode2
,g.busimode1
,busimode2
,bcode as vpreapre
,g.ccode as ccode
,g.gcode as gcode0
,g.sbcode
,g.upislcode
,g.slcodex,g.etrdcode,g.busimode3,g.inoutmode
from
storeslistg g where 1 <> 1

先停止standby，跳过这个事务，kill使用原来的临时表的session，手动执行以上SQL，然后开启standby：

SQL> alter database stop logical standby apply;

Database altered.

SQL> exec dbms_logstdby.skip_transaction(9,27,994864);

PL/SQL procedure successfully completed.

SQL> alter database start logical standby apply;

这样这个引起阻塞的事务就能过去了，但是由于空间占满了，应用仍然有问题，这时可以手动转移走一些比较靠后的不会马上应用的归档，然后有足够的空间后再还原回来，要注意的就是要保证这些文件的属主是Oracle用户。

# cd /tmp/log_2010
# ls -l
total 1025568
-rw-r-----   1 root     system      1547264 Jan 04 08:52 1_118088_640266118.dbf
-rw-r-----   1 root     system       110080 Jan 04 08:52 1_118089_640266118.dbf
-rw-r-----   1 root     system        52224 Jan 04 08:52 1_118090_640266118.dbf
-rw-r-----   1 root     system        52736 Jan 04 08:52 1_118091_640266118.dbf
-rw-r-----   1 root     system        65024 Jan 04 08:52 1_118092_640266118.dbf
-rw-r-----   1 root     system        56832 Jan 04 08:52 1_118093_640266118.dbf
-rw-r-----   1 root     system      1138688 Jan 04 08:52 1_118094_640266118.dbf
-rw-r-----   1 root     system        52736 Jan 04 08:52 1_118095_640266118.dbf
-rw-r-----   1 root     system        59904 Jan 04 08:52 1_118096_640266118.dbf
-rw-r-----   1 root     system        57344 Jan 04 08:52 1_118097_640266118.dbf
-rw-r-----   1 root     system    520338944 Jan 04 08:52 2_125502_640266118.dbf
-rw-r-----   1 root     system      1545216 Jan 04 08:52 2_125518_640266118.dbf
# chown oracle.oinstall *
# ls -l
total 1025568
-rw-r-----   1 oracle   oinstall    1547264 Jan 04 08:52 1_118088_640266118.dbf
-rw-r-----   1 oracle   oinstall     110080 Jan 04 08:52 1_118089_640266118.dbf
-rw-r-----   1 oracle   oinstall      52224 Jan 04 08:52 1_118090_640266118.dbf
-rw-r-----   1 oracle   oinstall      52736 Jan 04 08:52 1_118091_640266118.dbf
-rw-r-----   1 oracle   oinstall      65024 Jan 04 08:52 1_118092_640266118.dbf
-rw-r-----   1 oracle   oinstall      56832 Jan 04 08:52 1_118093_640266118.dbf
-rw-r-----   1 oracle   oinstall    1138688 Jan 04 08:52 1_118094_640266118.dbf
-rw-r-----   1 oracle   oinstall      52736 Jan 04 08:52 1_118095_640266118.dbf
-rw-r-----   1 oracle   oinstall      59904 Jan 04 08:52 1_118096_640266118.dbf
-rw-r-----   1 oracle   oinstall      57344 Jan 04 08:52 1_118097_640266118.dbf
-rw-r-----   1 oracle   oinstall  520338944 Jan 04 08:52 2_125502_640266118.dbf
-rw-r-----   1 oracle   oinstall    1545216 Jan 04 08:52 2_125518_640266118.dbf
# pwd
/tmp/log_2010
# cp * /stb_arch

之后在备库的同步继续进行，然后又经历了2个临时表的手动干预后，终于腾出了足够的空间，这时可以打开主库的同步：

SQL> alter system set log_archive_dest_state_2=enable;

System altered.

后来又发现备库出现了停滞，而并没有引起阻塞的事务，仔细查看DBA_LOGSTDBY_LOG视图发现有些归档丢失，没有传到备库，去主库找归档时发现已经删除了，这时只能从RMAN中恢复这些文件。根据缺失的sequence来找对应的RMAN备份片：

ERPDB2@/orabak/arch/transmited>rman target /

RMAN> list backup of archivelog from sequence 125504 until sequence 125554 thread 2;

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
16862   1.14G      DISK        00:04:57     04-JAN-10
BP Key: 19677   Status: AVAILABLE  Compressed: YES  Tag: TAG20100104T130015
Piece Name: /orabak/arch/ERPDB_arch_20100104_707403929_16929_1

List of Archived Logs in backup set 16862
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
2    125504  11523639376 04-JAN-10 11523954045 04-JAN-10
. . . . . .
2    125509  11525286806 04-JAN-10 11525631638 04-JAN-10

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
16864   453.25M    DISK        00:01:57     04-JAN-10
BP Key: 19679   Status: AVAILABLE  Compressed: YES  Tag: TAG20100104T130015
Piece Name: /orabak/arch/ERPDB_arch_20100104_707404542_16931_1

List of Archived Logs in backup set 16864
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
2    125510  11525631638 04-JAN-10 11525981043 04-JAN-10
. . . . . .
2    125522  11526443719 04-JAN-10 11526475093 04-JAN-10

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
16867   401.53M    DISK        00:01:42     04-JAN-10
BP Key: 19682   Status: AVAILABLE  Compressed: YES  Tag: TAG20100104T213015
Piece Name: /orabak/arch/ERPDB_arch_20100104_707434218_16935_1

List of Archived Logs in backup set 16867
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
2    125523  11526475093 04-JAN-10 11526613894 04-JAN-10
. . . . . .
2    125554  11529391158 04-JAN-10 11529453386 04-JAN-10

RMAN> exit

从这里的Piece Name可以看出缺少3个备份片文件，找到这3个文件，放到RMAN备份的目的地/orabak/arch/目录下。写到这里我发现《Oracle DBA手记》书稿里一个类似的操作被我写成了放到默认的归档日志路径下，可能是晚上赶稿神志不清吧，道歉先。

然后恢复出来归档日志到指定的目录：

RMAN> run {
2> set archivelog destination to '/orabak/testarch';
3> restore archivelog from sequence 125504 until sequence 125554 thread 2;
4> }

在恢复的过程中会自动把这些归档同时传到备库，无需手动再传。

备库端归档日志全了，就能顺利的同步了。至此这个问题得到解决。这个案例和我在《Oracle DBA手记》里记录的一个案例类似，可互相参看印证。