今天在测试环境中弄DG的时候出现了ORA-16072: a minimum of one standby database destination is required的报错：

     环境如下：OS ：RHEL 5.6 X86_64   DB:11.2.0.3.2 (单机)

     原来是一个DG环境，由于备库已经损坏了，现在需要删除现有环境中的DG，重新搭建一个新的DG环境。在主库上面删除DG相关的参数、redo与相关的物理文件的。启动主库时就报错。后台日志如下：

   
   
   
   
    
    
    
    
    
  1. ARC0: Archival started 
    2. 
    
    
    
    
  2. LGWR: STARTING ARCH PROCESSES COMPLETE 
    3. 
    
    
    
    
  3. ARC0: STARTING ARCH PROCESSES 
    4. 
    
    
    
    
  4. LGWR: Primary database is in MAXIMUM AVAILABILITY mode 
    5. 
    
    
    
    
  5. LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR 
    6. 
    
    
    
    
  6. LGWR: Minimum of 1 LGWR standby database required 
    7. 
    
    
    
    
  7. Errors in file /usr/app/oracle/diag/diag/rdbms/vcm01_b/vcm01/trace/vcm01_lgwr_2803.trc: 
    8. 
    
    
    
    
  8. ORA-16072: a minimum of one standby database destination is required 
    9.

     trace文件中的内容如下：

   
   
   
   
    
    
    
    
    
  1. Trace file /usr/app/oracle/diag/diag/rdbms/vcm01_b/vcm01/trace/vcm01_lgwr_2803.trc 
    2. 
    
    
    
    
  2. Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production 
    3. 
    
    
    
    
  3. With the Partitioning, OLAP, Data Mining and Real Application Testing options 
    4. 
    
    
    
    
  4. ORACLE_HOME = /usr/app/oracle/110203/v01 
    5. 
    
    
    
    
  5. System name:    Linux 
    6. 
    
    
    
    
  6. Node name:      pekdc1-vcm-04 
    7. 
    
    
    
    
  7. Release:        2.6.18-238.el5 
    8. 
    
    
    
    
  8. Version:        #1 SMP Thu Jan 13 15:51:15 EST 2011 
    9. 
    
    
    
    
  9. Machine:        x86_64 
    10. 
    
    
    
    
  10. Instance name: vcm01 
    11. 
    
    
    
    
  11. Redo thread mounted by this instance: 1 
    12. 
    
    
    
    
  12. Oracle process number: 11 
    13. 
    
    
    
    
  13. Unix process pid: 2803, p_w_picpath: oracle@pekdc1-vcm-04 (LGWR) 
    14. 
    
    
    
    
  14.  
    15. 
    
    
    
    
  15.  
    16. 
    
    
    
    
  16. *** 2012-11-06 09:23:30.058 
    17. 
    
    
    
    
  17. *** SESSION ID:(2267.1) 2012-11-06 09:23:30.058 
    18. 
    
    
    
    
  18. *** CLIENT ID:() 2012-11-06 09:23:30.058 
    19. 
    
    
    
    
  19. *** SERVICE NAME:() 2012-11-06 09:23:30.058 
    20. 
    
    
    
    
  20. *** MODULE NAME:() 2012-11-06 09:23:30.058 
    21. 
    
    
    
    
  21. *** ACTION NAME:() 2012-11-06 09:23:30.058 
    22. 
    
    
    
    
  22.  
    23. 
    
    
    
    
  23. Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR 
    24. 
    
    
    
    
  24. Standby database verification failed:16072 
    25. 
    
    
    
    
  25. error 16072 detected in background process 
    26. 
    
    
    
    
  26. ORA-16072: a minimum of one standby database destination is required 
    27. 
    
    
    
    
  27. kjzduptcctx: Notifying DIAG for crash event 
    28. 
    
    
    
    
  28. ----- Abridged Call Stack Trace ----- 
    29. 
    
    
    
    
  29. ksedsts()+461<-kjzdssdmp()+267<-kjzduptcctx()+232<-kjzdicrshnfy()+53<-ksuitm()+1332<-ksbrdp()+3344<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+266<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36 
    30. 
    
    
    
    
  30. ----- End of Abridged Call Stack Trace ----- 
    31. 
    
    
    
    
  31.  
    32. 
    
    
    
    
  32. *** 2012-11-06 09:23:30.166 
    33. 
    
    
    
    
  33. LGWR (ospid: 2803): terminating the instance due to error 16072 
    34. 
    
    
    
    
  34. ksuitm: waiting up to [5] seconds before killing DIAG(2783) 
    35.

      原因是由于原环境配置了FSFO，数据库在最大可性的模式下面，删除DG，需要修改数据库在最大性能下面。修改语法如下：  

   
   
   
   
    
    
    
    
    
  1. sqlplus / as sysdba 
    2. 
    
    
    
    
  2. SQL> startup mount  
    3. 
    
    
    
    
  3. SQL> alter database set standby to maximize performance; 
    4. 
    
    
    
    
  4. SQL> alter database open; 
    5.

      修改后数据库启动正常。