SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;
备库上的操作：
1.查看switchover状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; TO PRIMARY 2.切换成主库
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SQL> shutdown immediate; SQL> startup;
SQL> alter system switch logfile; 3.查看数据库模式
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status;
SQL>select status,database_mode from v$archive_dest_status;
注意地方:
如果做了switchover,主库参数设置成以下方式，会触发ora-16009错误 Alert system set log_archive_dest_2=’service=primary DB_UNIQUE_NAME=orcl’ scope=spfile; 然后再alert_orcl.log日志中会出现以下错误内容 Thu Nov 27 10:19:12 2008 Redo Shipping Client Connect -- Connected User is Valid
RFS[2]: Assigned to RFS process 1292
RFS[2]: Database mount ID mismatch [0x4781d95f:0x47823be1] RFS[2]: Client instance is standby database i RFS[2]: Not using real app Thu Nov 27 10:19Errors in file
d:\\oracle\\product\\10.2.0\\admin\\orcl\%udump\\orc ORA-16009:远程归档日 从metalink上查到:
* fact: Oracle Server - Enterprise Edition 9
* symptom: Errors appears in alert.log on primary database * symptom: RFS: client instance is standby database instead * symptom: RFS: Not using real application clusters
* symptom: Errors appear in alert.log on standby database * symptom: database
standby database primary database
* symptom: Standby redo log files are defined on the standby database * cause: The standby redo log files are synchronously filled with redo
from the primary database. When a logswitch occur on the primary database, those files are archived on the standby database before being applyed on it. The archiving process on the standby database should only archive to the local disks on tprimarfix:
Disable the remote archiving on the standby databasExample: alter system set log_archive_dest_2 = ''
是因为没有把standby上的log_archive_dest_2清空导致的。
另外也有可 bug 4676659
Standby may not be recognised (ORA-16009)
When the log transport is LGWR ASYNC and logical standby has
LOG_ARCHIVE_DEST setting VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE) ORA-16009 is reportedregular interWorkaround:
There is no workaround to prevent ORA-16009 from appearing in alert logs.
2. Failovers：
FAILOVER切换一般是PRIMARY数据库发生故障后的切换，这种情况是STANDBY数据库发挥其作用的情况。这种切换发生后，可能会造成数据的丢失。而且这个过程不是可逆的，DATA GUARD环境会被破坏。
由于PRIMARY数据库已经无法启动，所以FAILOVER切换所需的条件并不多，只要检查STANDBY是否运行在最大保护模式下，如果是的话，需要将其置为最大性能模式，否则切换到PRIMARY角色也无法启动。 1.查看是否有日志GAP,没有应用的日志：
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有，则拷贝过来并且注册
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径'; 重复查看直到没有应用的日志： 2.然后停止应用归档：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered.
3.下面将STANDBY数据库切换为PRIMARY数据库：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; 或SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
Database altered.
SQL> SELECT DATABASE_ROLE FROM V$DATABASE; DATABASE_ROLE ---------------- PHYSICAL STANDBY
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;