ORA-16072: a minimum of one standby database destination is required
ORA-16072: a minimum of one standby database destination is required
问题描述：
startup 去启动数据库时报错：ora-3113
后台alert.log r如下：
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LGWR: Minimum of 1 LGWR standby database requiredErrors in file /u01/app/oracle/diag/rdbms/oradb/oradb1/trace/oradb1_lgwr_17084.trc:
ORA-16072: a minimum of one standby database destination is required
Wed Mar 12 09:42:05 2014
System state dump requested by (instance=1, osid=17084 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/oracle/diag/rdbms/oradb/oradb1/trace/oradb1_diag_17058.trc
LGWR (ospid: 17084): terminating the instance due to error 16072
Wed Mar 12 09:42:06 2014
ORA-1092 : opitsk aborting process
Dumping diagnostic data in directory=[cdmp_20140312094205], requested by (instance=1, osid=17084 (LGWR)), summary=[abnormal instance termination].
Wed Mar 12 09:42:06 2014
Errors in file /u01/app/oracle/diag/rdbms/oradb/oradb1/trace/oradb1_lgwr_17084.trc: 如下：
Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
Standby database verification failed:16072
error 16072 detected in background process
ORA-16072: a minimum of one standby database destination is required
kjzduptcctx: Notifying DIAG for crash event
----- Abridged Call Stack Trace -----
ksedsts()+461<-kjzdssdmp()+267<-kjzduptcctx()+232<-kjzdicrshnfy()+53<-ksuitm()+
1325<-ksbrdp()+3344<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+266
<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244<-_start()+36
----- End of Abridged Call Stack Trace -----
*** 2014-03-12 09:42:06.422
LGWR (ospid: 17084): terminating the instance due to error 16072
ksuitm: waiting up to [5] seconds before killing DIAG(17058)
问题诊断：
启动数据库到mount 状态：
1.查看 show parameter log_archive_log
结果;没有设置
2.查看dg 模式
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PRIMARY MAXIMUM AVAILABILITY UNPROTECTED
这里补充下dg的3大数据保护模式：
最大保护
这种保护模式确保如果主数据库故障不会发生数据丢失。要提供这种级别的
保护，恢复每个事务所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少
一个备数据库上的备重做日志。要确保不发生数据丢失，如果故障导致主数据库无法写重做
流到至少一个事务一致性备数据库的备重做日志时，主数据库会关闭。
最大可用性
这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可
用性相折衷。与最大保护模式相同，在恢复事务所需的重做写到本地联机重做日志和至少一
个事务一致性备数据库上的备重做日志之前，事务将不会提交。与最大保护模式不同的是，
如果故障导致主数据库无法写重做流到异地备重做日志时，主数据库不会关闭。替代地，主
数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件中的中断。当所有中
断解决之后，主数据库自动继续以最大可用性模式运行。
这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从
主数据库发送到至少一个备数据库时，不发生数据丢失。
最大性能
这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据
库的性能。这是通过允许事务在恢复该事务所需重做数据在写到本地联机重做日志后立即提
交而实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建
重做数据的事务是异步写的。
当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级
别，并且对主数据库性能的影响最小。
最大保护和最大可用性模式需要备重做日志文件配置在配置中的至少一个备数据库上。
所有三种保护模式需要在LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性
以发送重做数据到至少一个备数据库
于是先切换dg的保护模式：
SQL> alter database set standby to maximize performance;
Database altered.
SQL> alter database open;
Database altered.
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL---------------- -------------------- --------------------
PRIMARY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
然后
alter database mount；
alter database open ；
数据库正常打开。