线上oracle datagard备库由于断电以及误删除从库的归档日志文件,所以导致,备库主库数据不一致,备库须要紧急恢复。以下是大概恢复过程

1,从主库上面备份控制文件
[oracle@localhost rman_recover]$ rman target /
RMAN> backup current controlfile for standby format '/data/oracle/backup/data/ctlfile.bak';
Starting backup at 22-MAY-14                                                                                                                                                                   
allocated channel: ORA_DISK_1                                                                                                                                                                  
channel ORA_DISK_1: SID=1094 device type=DISK
channel ORA_DISK_1: starting full datafile backup set                                                                                                                                          
channel ORA_DISK_1: specifying datafile(s) in backup set
including standby control file in backup set                                                                                                                                                   
channel ORA_DISK_1: starting piece 1 at 22-MAY-14
channel ORA_DISK_1: finished piece 1 at 22-MAY-14                                                                                                                                              
piece handle=/data/oracle/backup/data/ctlfile.bak tag=TAG20140522T165431 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 22-MAY-14

Starting Control File and SPFILE Autobackup at 22-MAY-14                                                                                                                                       
piece handle=/data/oracle/backup/data/ctl_auto/c-3391761643-20140522-02 comment=NONE                                                                                                           
Finished Control File and SPFILE Autobackup at 22-MAY-1   
RMAN>

2。准备备份文件
备份整库,这个步骤能够省去,用今天凌晨3点rman备份好的,并且由于备份文件夹从库也能够直接訪问,所以不用scp了。
RMAN> backup database format '/u01/rman_recover/%full_backup_%T_%t.bak';

3,copy主库的备份到备库相同的文件夹以下。
这个不用了,备份文件在share磁盘里面,主库备库都能够訪问得到。

4,然后关闭从库
SQL> shutdown abort                                                                                                                                                                            
ORACLE instance shut down.                                                                                                                                                                     
SQL> exit

[oracle@localhost ~]$ ps -eaf|grep oracle
oracle    3137     1  0 May04 ?        00:00:54 /oracle/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr LISTENER -inherit
root     24061 24009  0 15:19 pts/2    00:00:00 su - oracle
oracle   24062 24061  0 15:19 pts/2    00:00:00 -bash
root     24423 22842  0 17:06 pts/0    00:00:00 su - oracle
oracle   24424 24423  0 17:06 pts/0    00:00:00 -bash
oracle   24465 24062  0 17:14 pts/2    00:00:00 ps -eaf
oracle   24466 24062  0 17:14 pts/2    00:00:00 grep oracle
[oracle@localhost ~]$

5。先备份原有的控制文件路径。再copy新的控制文件覆盖备库的控制文件。

5.1备库上查找控制文件路径:
SQL> select name from v$controlfile;                                                                                                                                                           
NAME
--------------------------------------------------------------------------------
/home/oradata/psdtest/control01.ctl
/oracle/app/oracle/flash_recovery_area/psdtest/control02.ctl
SQL>

再在备库上copy新的控制文件覆盖原有的控制文件
5.2先备份:
[oracle@localhost ~]$ cp /home/oradata/psdtest/control01.ctl /tmp/control01.ctl.bak
[oracle@localhost ~]$ cp /oracle/app/oracle/flash_recovery_area/psdtest/control02.ctl /tmp/control02.ctl.bak

5.3 再覆盖:
copy控制文件进行覆盖:
cp /data/oracle/backup/data/ctlfile.bak /home/oradata/psdtest/control01.ctl
cp /data/oracle/backup/data/ctlfile.bak /oracle/app/oracle/flash_recovery_area/psdtest/control02.ctl

5.4删除备库归档日志文件夹下的所有文件
mv /data/oracle/oradgdata/standby_archive/* /data/oracle/backup/data/back_0522_108

6。将备库实例启动到nomount状态。 
启动备库实例:
SQL> startup nomount
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                  1218316 bytes
Variable Size              75499764 bytes
Database Buffers           88080384 bytes
Redo Buffers                2973696 bytes

7,获取备库的tns名字,准备用rman登录
7.1,获取备库的tns:(我的是orcl_s.2_tns)
cat $ORACLE_HOME/network/admin/tnsnames.ora
[oracle@localhost data]$ cat $ORACLE_HOME/network/admin/tnsnames.ora
PD_DG =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.108)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID= psdtest)
    )
  )

PD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.107)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = pdunq)
    )
  )

PD_DG 这个是你的备库108tns名称,PD就是主库107的tns名称

7.2。再次查看主库SID名称是否统一:
备库: [oracle@localhost archivelog]$ echo $ORACLE_SID
psdtest

主库: [oracle@localhost ~]$ echo $ORACLE_SID
psdtest

7,3 rman 远程登录pd_dg从库库:
再连接
[oracle@localhost ~]$ rlwrap rman target / auxiliary sys/passwdxxx@PD_DG

Recovery Manager: Release 11.2.0.1.0 - Production on Thu May 22 18:11:31 2014

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: psdtest (DBID=3391761643)
connected to auxiliary database: psdtest (not mounted)

RMAN>

7.4。运行恢复命令
run {
allocate auxiliary channel c1 device type disk;
allocate auxiliary channel c2 device type disk;
duplicate target database for standby nofilenamecheck dorecover;
release channel c1;
release channel c2;
}
#nofilenamecheck:必须指定NOFILENAMECHECK參数,避免覆盖primary数据库的当前的数据文件。另外主从路径一致。不须要运行文件路径以及check了
#release :这是关闭 前两行开启的通道

開始运行:
RMAN>run {                                                                                                                                                                                          
allocate auxiliary channel c1 device type disk;                                                                                                                                                
allocate auxiliary channel c2 device type disk;                                                                                                                                                
duplicate target database for standby nofilenamecheck dorecover;                                                                                                                               
release channel c1;                                                                                                                                                                            
release channel c2;                                                                                                                                                                            
3> 4> 5> 6> 7> }

using target database control file instead of recovery catalog
allocated channel: c1                                                                                                                                                                          
channel c1: SID=386 device type=DISK
                                                                                                                                                                                               
allocated channel: c2                                                                                                                                                                          
channel c2: SID=482 device type=DISK
                                                                                                                                                                                               
Starting Duplicate Db at 23-MAY-14                                                                                                                                                             
                                                                                                                                                                                               
contents of Memory Script:
{
   set until scn  10436786792;
   restore clone standby controlfile;
}
executing Memory Script
executing command: SET until clause
Starting restore at 23-MAY-14                                                                                                                                                                  
channel c1: starting datafile backup set restore                                                                                                                                               
channel c1: restoring control file
channel c1: reading from backup piece /data/oracle/backup/data/ctl_auto/c-3391761643-20140523-00
channel c1: piece handle=/data/oracle/backup/data/ctl_auto/c-3391761643-20140523-00 tag=TAG20140523T033551                                                                                     
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:00:01
output file name=/home/oradata/psdtest/control01.ctl
output file name=/oracle/app/oracle/flash_recovery_area/psdtest/control02.ctl
Finished restore at 23-MAY-14
                                                                                                                                                                                               
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
sql statement: alter database mount standby databas  
contents of Memory Script:
{
   set until scn  10436786792;
   set newname for tempfile  1 to 
 "/home/oradata/psdtest/temp01.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to 
 "/home/oradata/psdtest/system01.dbf";
   set newname for datafile  2 to 
 "/home/oradata/psdtest/sysaux01.dbf";
   set newname for datafile  3 to 
 "/home/oradata/psdtest/undotbs01.dbf";
   set newname for datafile  4 to 
 "/home/oradata/psdtest/users01.dbf";
   set newname for datafile  5 to 
 "/home/oradata/psdtest/psdtestk01.dbf";
   set newname for datafile  6 to 
 "/home/oradata/psdtest/plas01.dbf";
   set newname for datafile  7 to 
 "/home/oradata/psdtest/pl01.dbf";
   set newname for datafile  8 to 
 "/home/oradata/psdtest/help01.dbf";
   set newname for datafile  9 to 
 "/home/oradata/psdtest/adobelc01.dbf";
   restore
   clone database
   ;
}
executing Memory Script
executing command: SET until clause
executing command: SET NEWNAME
renamed tempfile 1 to /home/oradata/psdtest/temp01.dbf in control file                                                                                                                        
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 23-MAY-14                                                                                                                                                                  
channel c1: starting datafile backup set restore                                                                                                                                               
channel c1: specifying datafile(s) to restore from backup set
channel c1: restoring datafile 00001 to /home/oradata/psdtest/system01.dbf
channel c1: restoring datafile 00002 to /home/oradata/psdtest/sysaux01.dbf
channel c1: restoring datafile 00003 to /home/oradata/psdtest/undotbs01.dbf
channel c1: restoring datafile 00004 to /home/oradata/psdtest/users01.dbf
channel c1: restoring datafile 00005 to /home/oradata/psdtest/psdtestk01.dbf
channel c1: restoring datafile 00006 to /home/oradata/psdtest/plas01.dbf
channel c1: restoring datafile 00007 to /home/oradata/psdtest/pl01.dbf
channel c1: restoring datafile 00008 to /home/oradata/psdtest/help01.dbf
channel c1: restoring datafile 00009 to /home/oradata/psdtest/adobelc01.dbf
channel c1: reading from backup piece /data/oracle/backup/data/2014-05-23/full_psdtest_20140523_1304.bak
channel c1: piece handle=/data/oracle/backup/data/2014-05-23/full_psdtest_20140523_1304.bak tag=TAG20140523T032104                                                                            
channel c1: restored backup piece 1
channel c1: restore complete, elapsed time: 00:20:15
Finished restore at 23-MAY-14                                                                                                                                                                                                                                                                                                                                                              
contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script

datafile 1 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=1 STAMP=848313777 file name=/home/oradata/psdtest/system01.dbf
datafile 2 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=2 STAMP=848313777 file name=/home/oradata/psdtest/sysaux01.dbf
datafile 3 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=3 STAMP=848313777 file name=/home/oradata/psdtest/undotbs01.dbf
datafile 4 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=4 STAMP=848313777 file name=/home/oradata/psdtest/users01.dbf
datafile 5 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=5 STAMP=848313777 file name=/home/oradata/psdtest/psdtestk01.dbf
datafile 6 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=6 STAMP=848313777 file name=/home/oradata/psdtest/plas01.dbf
datafile 7 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=7 STAMP=848313777 file name=/home/oradata/psdtest/pl01.dbf
datafile 8 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=8 STAMP=848313777 file name=/home/oradata/psdtest/help01.dbf
datafile 9 switched to datafile copy                                                                                                                                                           
input datafile copy RECID=9 STAMP=848313778 file name=/home/oradata/psdtest/adobelc01.dbf

contents of Memory Script:
{
   set until scn  10436786792;
   recover
   standby
   clone database
    delete archivelog
   ;
}
executing Memory Script
executing command: SET until clause
Starting recover at 23-MAY-14                                                                                                                                                                                                                                                                                                                                                                
starting media recovery                                                                                                                                                                                                                                                                                                                                                                      
released channel: c1                                                                                                                                                                           
released channel: c2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 05/23/2014 10:44:21
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 8254 and starting SCN of 10436680710 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8253 and starting SCN of 10436636473 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8252 and starting SCN of 10436621186 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8251 and starting SCN of 10436616182 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8250 and starting SCN of 10436611843 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8249 and starting SCN of 10436606580 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8248 and starting SCN of 10436589966 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 8247 and starting SCN of 10436589919 found to restore
有报错信息,查看alert日志信息:
贴一下从库的alert日志信息:
[oracle@localhost data]$   tail -f /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/alert_psdtest.log
[oracle@localhost standby_archive]$ history |grep tail
  804  tail -f /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/alert_psdtest.log
  813    tail -f /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/alert_psdtest.log
  878  history |grep tail
[oracle@localhost standby_archive]$ tail -f /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/alert_psdtest.log
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/psdtest_arc2_478.trc:
ORA-16191: Primary log shipping client not logged on standby
ARCj: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Fri May 23 10:22:45 2014
Full restore complete of datafile 8 /home/oradata/psdtest/help01.dbf.  Elapsed time: 0:00:02 
  checkpoint is 10436588043
  last deallocation scn is 9881798870
Full restore complete of datafile 9 /home/oradata/psdtest/adobelc01.dbf.  Elapsed time: 0:00:00 
  checkpoint is 10436588043
Fri May 23 10:23:25 2014
Full restore complete of datafile 7 /home/oradata/psdtest/pl01.dbf.  Elapsed time: 0:00:26 
  checkpoint is 10436588043
  last deallocation scn is 10430929064
Fri May 23 10:24:22 2014
Full restore complete of datafile 3 /home/oradata/psdtest/undotbs01.dbf.  Elapsed time: 0:01:19 
  checkpoint is 10436588043
  last deallocation scn is 10436580283
  Undo Optimization current scn is 10436537601
Fri May 23 10:25:34 2014
Full restore complete of datafile 4 /home/oradata/psdtest/users01.dbf.  Elapsed time: 0:02:52 
  checkpoint is 10436588043
  last deallocation scn is 10431120328
Fri May 23 10:27:10 2014
Full restore complete of datafile 1 /home/oradata/psdtest/system01.dbf.  Elapsed time: 0:04:06 
  checkpoint is 10436588043
  last deallocation scn is 10431182430
  Undo Optimization current scn is 10436537601
Fri May 23 10:30:07 2014
Full restore complete of datafile 6 /home/oradata/psdtest/plas01.dbf.  Elapsed time: 0:07:23 
  checkpoint is 10436588043
  last deallocation scn is 10431118551
Fri May 23 10:30:30 2014
Full restore complete of datafile 2 /home/oradata/psdtest/sysaux01.dbf.  Elapsed time: 0:07:46 
  checkpoint is 10436588043
  last deallocation scn is 10436477741
Fri May 23 10:36:02 2014
db_recovery_file_dest_size of 15360 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Fri May 23 10:42:47 2014
Full restore complete of datafile 5 /home/oradata/psdtest/psdtestk01.dbf.  Elapsed time: 0:19:52 
  checkpoint is 10436588043
  last deallocation scn is 10431121555
Fri May 23 10:42:58 2014
Switch of datafile 1 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 2 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 3 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 4 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 5 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 6 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 7 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 8 complete to datafile copy 
  checkpoint is 10436588043
Switch of datafile 9 complete to datafile copy 
  checkpoint is 10436588043
Using STANDBY_ARCHIVE_DEST parameter default value as /data/oracle/oradgdata/standby_archive
alter database recover datafile list clear
Completed: alter database recover datafile list clear
alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9
Completed: alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9
alter database recover if needed
 standby start until change 10436786792
Media Recovery Start
 started logmerger process
Fri May 23 10:43:00 2014
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 16 slaves
ORA-279 signalled during: alter database recover if needed
 standby start until change 10436786792
...
Fri May 23 10:43:22 2014
alter database recover cancel
Fri May 23 10:43:22 2014
Signalling error 1152 for datafile 1!
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/psdtest_pr00_676.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup 
ORA-01110: data file 1: '/home/oradata/psdtest/system01.dbf'
Slave exiting with ORA-1547 exception
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/psdtest/trace/psdtest_pr00_676.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup 
ORA-01110: data file 1: '/home/oradata/psdtest/system01.dbf'
ORA-10879 signalled during: alter database recover cancel...

8,看到报错了。去备库,看看实例状态是否为MOUNTED
select status from v$instance;
SQL> select status from v$instance;                                                                                                                                                            
STATUS
------------
MOUNTED

SQL> 
SQL> select name,applied from v$archived_log;   
no rows selected
SQL>

再查看下日志归档到哪里了:
从库上:
SQL> archive log list                                                                                                                                                                          
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     8245
Next log sequence to archive   8247
Current log sequence       8247
SQL>  
主库上:
SQL> archive log list                                                                                                                                                                          
Database log mode              Archive Mode                                                                                                                                                    
Automatic archival       Enabled
Archive destination       /oracle/app/oracle/flash_recovery_area/archivelog
Oldest online log sequence     8255
Next log sequence to archive   8257
Current log sequence       8257
SQL>               
主库从库相差10个archive log点。
主库上运行:
select local.thread#,local.sequence# from
    (select thread#,sequence# from v$archived_log where dest_id=1) local
     where local.sequence# not in
    (select sequence# from v$archived_log where dest_id=2 and
    thread# = local.thread#);

查看备份库的tns信息例如以下:
cat $ORACLE_HOME/network/admin/tnsnames.ora
备库上验证tns
[oracle@localhost standby_archive]$ sqlplus sys/passwdxxx@PD as sysdba;
SQL*Plus: Release 11.2.0.1.0 Production on Fri May 23 11:17:51 2014

Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL> 
能够登录。证明tns是正常的。

备库上再运行:
SQL> alter database open;
alter database open                                                                                                                                                                            
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/home/oradata/psdtest/system01.dbf'

查看主库备库的scn号码:
SQL> select to_char(current_scn) from v$database;                                                                                                                                              
TO_CHAR(CURRENT_SCN)
----------------------------------------
10436589934

SQL> select to_char(current_scn) from v$database;                                                                                                                                              
TO_CHAR(CURRENT_SCN)
----------------------------------------
10437053152

9,上一步中,假设为MOUNTED。则能够開始启动备库的REDO应用。去从库运行:
alter database recover managed standby database disconnect from session;
备库运行:
SQL> alter database recover managed standby database disconnect from session;                                                                                                                  
Database altered.
SQL>

SQL> select name,applied from v$archived_log;                                                                                                                                                  
no rows selected
SQL> archive log list;                                                                                                                                                                         
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     0
Next log sequence to archive   0
Current log sequence       0
SQL>

主库从库运行:
 select dbms_flashback.get_system_change_number from dual
SQL>  select dbms_flashback.get_system_change_number from dual;                                                                                                                                
GET_SYSTEM_CHANGE_NUMBER
------------------------
     1.0436E+10

SQL>  
备库运行:
SQL> select dbms_flashback.get_system_change_number from dual;                                                                                                                                 
select dbms_flashback.get_system_change_number from dual
       *
ERROR at line 1:
ORA-00904: "DBMS_FLASHBACK"."GET_SYSTEM_CHANGE_NUMBER": invalid identifier
SQL>

总结原因,问了一些前辈:
从ORA-01152: file 1 was not restored from a sufficiently old backup。猜測是由于使用的控制文件是今天当前的,
而duplicate target databas运行的最新备份是凌晨3点运行的全备,所以报错。他们建议等明天又一次使用今天的控制文件
运行duplicate target databas看看。

10。等到第二天,用前一天的控制文件,又一次运行恢复。过程例如以下:
(1) 停止备库:
shutdown abort

(2) 备库直接copy控制文件覆盖:
cp /data/oracle/backup/data/ctlfile.bak /home/oradata/psdtest/control01.ctl
cp /data/oracle/backup/data/ctlfile.bak /oracle/app/oracle/flash_recovery_area/psdtest/control02.ctl

(3) 启动备库到nomount
startup nomount

(4) 主库登入rman,运行恢复
rlwrap rman target / auxiliary sys/passwdxxx@PD_DG
运行:
run {
allocate auxiliary channel c1 device type disk;
allocate auxiliary channel c2 device type disk;
duplicate target database for standby nofilenamecheck dorecover;
release channel c1;
release channel c2;
}
.......
一切正常顺利

(5) 看主库alert日志,有报错信息:
[oracle@localhost ~]$ tail -f /oracle/app/oracle/diag/rdbms/pdunq/psdtest/trace/alert_psdtest.log
FAL[server, ARC4]: FAL archive failed, see trace file.
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/psdtest/trace/psdtest_arc4_3253.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance psdtest - Archival Error. Archiver continuing.
Fri May 23 15:54:21 2014
Error 1031 received logging on to the standby
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/psdtest/trace/psdtest_arc1_3247.trc:
ORA-01031: insufficient privileges
PING[ARC1]: Heartbeat failed to connect to standby 'PD_DG'. Error is 1031.

check从库归档日志。没有新的变化,
SQL> archive log list                                                                                                                                                                          
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     8245
Next log sequence to archive   8247
Current log sequence       8247

去从库运行日志切换,看看主库上新产生的告警信息:
alter system switch logfile;

archive log list; 查看归档日志信息
主库日志传不到从库。非常大可能是网络问题或者主从password不一样。
check主备库的password
cd $ORACLE_HOME/dbs
strings orapw[SID]
strings orapwpsdtest
发现主库比从库多了一行nt5L,所以须要统一主库从库的orapwpsdtest password配置文件
直接把主库的password配置文件cp过去就能够了。

然后去主库运行:alter system set log_archive_dest_state_2=enable;运行完了再check scn
主库:
SQL> select to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
----------------------------------------
10437558617

备库:
SQL> select to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
----------------------------------------
10436589934
看到主库备库的SCN还是有差距的。

用select name,applied from v$archived_log; 命令查看主库备库归档日志是否都已经统一了。备库上面归档日志是否都已经传过来了。

開始应用日志
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;                                                                                                                                                                                                                                                                                                      
Database altered.
SQL>

继续查询主库备库的scn,看到备库一直在添加。就表示应用日志已经開始起作用了:
select to_char(current_scn) from v$database;    
SQL> select to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
----------------------------------------
10437099045

SQL> select to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
----------------------------------------
10437257415

SQL>

再继续运行select name,applied from v$archived_log命令观察从库,当从库上都是YES的时候,证明归档日志所有传过来了。
当从库上applied所有为YES的时候,运行例如以下。取消应用(不取消不让打开数据库)
alter database recover managed standby database cancel;
然后alter database open;
SQL> alter database recover managed standby database cancel;                                                                                                                                                                                                                                                                                                                      
Database altered.
SQL> alter database open;                                                                                                                                                                      
                                                                                                                                                                                               
Database altered.
SQL>

看看mode是:
SQL> select database_role,open_mode from v$database;

DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY

假设是read only模式,那么启动应用就好了。

再次启动redo
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;                                                                                                                  
                                                                                                                                                                                               
Database altered.

SQL> 
再查看mode模式,就是READ ONLY WITH APPLY了。
SQL> select database_role,open_mode from v$database;

DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY

SQL> 
再运行 select name,applied from v$archived_log; 都是YES了。

证明主库备库数据已经全然一致了。

11,附带:删除曾经的旧的归档日志:
先移除掉日志:
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_75* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_76* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_77* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_78* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_79* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_80* /data/oracle/backup/data/archivelog/tmp_bak_2014/
mv /oracle/app/oracle/flash_recovery_area/archivelog/1_81* /data/oracle/backup/data/archivelog/tmp_bak_2014/

(1) 登录:
rlwrap rman target /
(2) 检查:crosscheck archivelog all;
crosscheck archivelog all:验证的是DB的归档日志即log_archive_dest參数指定位置的文件。当手工删除了归档日志以后,
Rman备份会检測到日志缺失,从而无法进一步继续运行Rman备份,所以此时须要手工运行crosscheck过程,查看所有的归档日
志文件是否都是正常的然后再来运行Rman备份。
....
validation succeeded for archived log
archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_8272_821708334.dbf RECID=15437 STAMP=848338357
validation succeeded for archived log
archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_8273_821708334.dbf RECID=15439 STAMP=848338718
validation succeeded for archived log
archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_8274_821708334.dbf RECID=15441 STAMP=848339078
validation succeeded for archived log
archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_8275_821708334.dbf RECID=15443 STAMP=848339439
validation succeeded for archived log
archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_8276_821708334.dbf RECID=15445 STAMP=848339802
Crosschecked 720 objects

(3) delete expired archivelog all;
这时候我们再去OEM中就看不到这些日志文件了,假设你的从来没有做过这个动作的话。我们能够比較这个动作前的controlfile
和动作后的controlfile的文件大小。
參考: http://mingyue19850801.blog.163.com/blog/static/19520820201162233314720/

(4) 主库上面SQL模式下运行:
alter system set log_archive_dest_state_3=defer;
这个是检查日志的,通过检查日志rman能标记处已经废弃的日志,接下来才干够删除被标记的日志
SQL> alter system set log_archive_dest_state_3=defer;                                                                                                                                                  
System altered.
SQL>

(5) 备库上sql模式运行;
SQL> archive log list                                                                                                                                                                          
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     8276
Next log sequence to archive   0
Current log sequence       8278
SQL>

多运行几次,归档号码会变化
SQL> archive log list                                                                                                                                                                          
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     8276
Next log sequence to archive   0
Current log sequence       8279

(6) 主库上sql模式下运行:
ALTER SYSTEM SET log_archive_dest_3='';
SQL> ALTER SYSTEM SET log_archive_dest_3='';   
System altered.
SQL>
刚才我们不是加入的dest_3的归档吗,如今dest_2就能够了。不须要这个了,所以把这个置为空

(7) 主库sql模式下切换日志
alter system switch logfile;
SQL> alter system switch logfile;                                                                                                                                                                                                                                                                                                                                                             
System altered.
SQL>  
然后去从库上看日志号码。变成8280了。
SQL> archive log list                                                                                                                                                                          
Database log mode       Archive Mode
Automatic archival       Enabled
Archive destination       /data/oracle/oradgdata/standby_archive
Oldest online log sequence     8277
Next log sequence to archive   0
Current log sequence       8280

去从库sql模式下查看 select name,applied from v$archived_log;都是YES
......
NAME
--------------------------------------------------------------------------------
APPLIED
---------
/data/oracle/oradgdata/standby_archive/1_8276_821708334.dbf
YES

/data/oracle/oradgdata/standby_archive/1_8277_821708334.dbf
YES

/data/oracle/oradgdata/standby_archive/1_8278_821708334.dbf
YES

33 rows selected.
主库上是NO是正常的,由于它不须要应用日志,日志就是它自己产生的,仅仅要从库上是YES就能够了。

然后再去主库上操作:
主库上运行sql:
alter system set log_archive_dest_state_3=enable;
SQL> alter system set log_archive_dest_state_3=enable;                                                                                                                                                                                      
System altered.

然后查看archive參数
SQL> show parameter archive
能够看到例如以下信息
...
log_archive_dest_state_1     string ENABLE
...
log_archive_dest_state_2     string ENABLE
...
log_archive_dest_state_3     string ENABLE
...

3个通道都是打开的。OK了。
这个恢复得到网友团团的协助。在此非常感谢:
參考文章:  http://www.eygle.com/archives/2007/08/rman_dataguard_duplicate.html

版权声明:本文博主原创文章,博客,未经同意不得转载。

采用Duplicate target database在线恢复秩序oracle datagard图书馆设备的更多相关文章

  1. 使用duplicate target database ... from active database复制数据库

    使用duplicate target database ... from active database复制数据库 source db:ora11auxiliary db:dupdb 1.修改监听文件 ...

  2. DG duplicate报错:RMAN-05001:auxiliary file name /u01/app/oracle/oradata/fratbs01.dbf conflicts with a file used by the target database

    问题:rman duplicate时报错: RMAN-05001:auxiliary file name /u01/app/oracle/oradata/fratbs01.dbf conflicts ...

  3. Oracle Database 12c Using duplicate standby database from active database Created Active DataGuard

    primary database db_name=zwc, db_unique_name=zwc standby database db_name=zwc, db_unique_name=standb ...

  4. 【RMAN】RMAN-05001: auxiliary filename conflicts with the target database

    oracle 11.2.0.4 运行以下脚本,使用活动数据库复制技术创建dataguard备库报错rman-005001: run{ duplicate target database for sta ...

  5. RMAN-05541: no archived logs found in target database

    执行 duplicate target databaseto orcl from active database nofilenamecheck报错如下: RMAN> duplicate tar ...

  6. 转 RMAN-20005: target database name is ambiguous

    发生的这个错误的由于: 在RMAN CATALOG中,register了一个name叫test的数据库,后来这个库被我搞坏了.就重建了一个test的数据库,名称没有更改,又重新register到RMA ...

  7. asp.net在线恢复数据库

    用于asp.net还原与恢复SqlServer数据库的KillSpid存储过程 CREATE PROCEDURE KillSpid(@dbName varchar(20)) AS BEGIN DECL ...

  8. windows 环境怎样恢复 (oracle 11g grid) ocr voting 损坏的集群

     windows 环境怎样恢复 (oracle 11g grid) ocr voting 损坏的集群 oracle 11g 以后 ocr 能够放到 asm 磁盘上,而ASM的启动依赖于ocr和vo ...

  9. Database Initialization Parameters for Oracle E-Business Suite Release 12 (文档 ID 396009.1)

    In This Document Section 1: Common Database Initialization Parameters For All Releases Section 2: Re ...

随机推荐

  1. ovs处理openflow消息的流程

    OVS处理各个openflow消息的详细代码在 ofproto/ofproto.c 中: static enum ofperr handle_openflow__(struct ofconn *ofc ...

  2. (转)FFMPEG解码流程

    http://www.douban.com/note/228831821/ FFMPEG解码流程:     1. 注册所有容器格式和CODEC: av_register_all()     2. 打开 ...

  3. Json的反序列化 .net Newtonsoft.Json

    项目中有个.json文件. { "instances": [ { "name": "baidu", "url": &qu ...

  4. CentOS7 已安装telnet维修

    今天搞下 Centos 7 以下升级 openssl 和 openssh ,顺便说下安装 telnet # 设备 telnet 避 ssh 无法登录 yum -y install xinetd tel ...

  5. Java模式(适配器型号)

    今天阅读Java该适配器模式,这里有一个小的总结和下谈感受.对于将来使用. 首先.让我们有关适配器先说说. 适应是“来源”至“目标”适应.其中连接这两个的关系是适配器.它负责“源”过度到“目标”. 举 ...

  6. [LeetCode160]Intersection of Two Linked Lists

    题目: Write a program to find the node at which the intersection of two singly linked lists begins.   ...

  7. android:强大的图像下载和缓存库Picasso

    1.Picasso一个简短的引论 Picasso它是Square该公司生产的一个强大的图像下载并缓存画廊.官方网站:http://square.github.io/picasso/ 仅仅须要一句代码就 ...

  8. 安卓培训第五天---上传文件SD卡

    有关如何将文件上传到先说说SD卡: package com.example.lesson05_02; import java.io.File; import java.io.FileNotFoundE ...

  9. 【PHP】PHP获得第一章

    一,PHP上部和下部壳体敏感 1)所有的用户定义的函数.类和keyword敏感. 例如以下结果输出一致: echo  "hello world" Echo  "hello ...

  10. 【Shell剧本练习】得出的结论是当前用户

    推断是否当前用户root.假设是暗示root用户,假设而不是提示对于普通用户 #!/bin/bash #title: testus.sh #author: orangleliu #date: 2014 ...