環境：RHEL 6.5 + Oracle 11.2.0.4
三、監控DG的狀態
三、監控DG的狀態
3.1 監控DG備庫的狀態
在備庫查詢v$dataguard_stats視圖信息：--format
set linesize 120
col NAME for a25
col VALUE for a18
col UNIT for a30
col TIME_COMPUTED for a20
col DATUM_TIME for a20
--select v$dataguard_stats
select * from v$dataguard_stats;
上面語句的查詢結果類似下面輸出：
SQL> select * from v$dataguard_stats;
NAME VALUE UNIT TIME_COMPUTED DATUM_TIME
------------------------- ------------------ ------------------------------ -------------------- --------------------
transport lag +00 00:00:00 day(2) to second(0) interval 11/18/2016 21:49:47 11/18/2016 21:49:47
apply lag +00 00:00:00 day(2) to second(0) interval 11/18/2016 21:49:47 11/18/2016 21:49:47
apply finish time +00 00:00:00.000 day(2) to second(3) interval 11/18/2016 21:49:47
estimated startup time 23 second 11/18/2016 21:49:47
理解v$dataguard_stats視圖信息含義：
參考11.2版本的官方文檔，
Name of the metric:
APPLY FINISH TIME - An estimate of the time needed to apply all received, but unapplied redo from the primary database. If there are one or more redo gaps on the standby database, an estimate of the time needed to apply all received, but unapplied redo up to the end of the last archived redo log before the beginning of the earliest redo gap.
APPLY LAG - Apply lag is a measure of the degree to which the data in a standby database lags behind the data in the primary database, due to delays in propagating and applying redo to the standby database.
TRANSPORT LAG - Transport lag is a measure of the degree to which the transport of redo to the standby database lags behind the generation of redo on the primary database. If there are one or more redo gaps on the standby database, the transport lag is calculated as if no redo has been received after the beginning of the earliest redo gap.
ESTIMATED STARTUP TIME - An estimate of the time needed to start and open the database.
如果是10.2版本的官方文檔，有一些差異：
APPLY FINISH TIME: Estimated time before log apply services will finish applying the redo data available on the standby database. If there are gaps in the log files, this parameter shows the time it will take to resolve the gap with the lowest SCN.
APPLY LAG: Amount of time that the application of redo data on the standby database lags behind the primary database.
TRANSPORT LAG: How much redo data (in time units) generated by the primary database is not available or applicable on the standby database at the time of computation.
Note: This parameter includes the redo data that has not been transmitted to the standby database and redo data that is available on the standby database but has not been applied yet, such as the redo data for resolving a gap.
ESTIMATED STARTUP TIME: Estimated time the physical standby database was started. This is not displayed for logical standby databases.
STANDBY HAS BEEN OPEN: Indicates if the physical standby database was opened in read-only mode at any time since the last time the database was started. The parameter value indicates if the instance must be stopped and restarted after a failover. If the physical standby database has been opened in read-only mode since the last time it was started and it is the target of a failover, you must shut down the database and restart it in read/write mode. If the primary database must be shutdown and restarted, use the sum of APPLY FINISH TIME and ESTIMATED STARTUP TIME to obtain an estimated failover time (the estimate assumes SHUTDOWN ABORT).
3.2 監控主庫傳輸日志鏈路的狀態
監控主庫傳輸日志鏈路的狀態:show parameter log_archive_dest_
show parameter log_archive_dest_state_
select value from v$parameter where name='log_archive_dest_state_3';
select value from v$parameter where name='log_archive_dest_3';
select error from v$archive_dest where dest_id=3;
查詢結果類似下面輸出：
SQL> select value from v$parameter where name='log_archive_dest_state_3';
VALUE
--------------------------------------------------------------------------------
enable
SQL> select value from v$parameter where name='log_archive_dest_3';
VALUE
--------------------------------------------------------------------------------
SERVICE=jyzhao_s LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_n
ame=jyzhao_s
SQL> select error from v$archive_dest where dest_id=3;
ERROR
-----------------------------------------------------------------
四、備庫切換為snapshot standby后測試
4.1 備庫切換為snapshot standby
查看參數值：show parameter db_recovery_file_dest
--如果返回值為空，則設置一個合理的值：
Alter system set db_recovery_file_dest_size=1000G scope=spfile;
Alter system set db_recovery_file_dest='+DATA' scope=spfile;
核心步驟：
--取消日志應用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
--查詢當前數據庫SCN
select to_char(current_scn) from v$database;
--確定job_queue_processes值為0
show parameter job_queue_processes
alter system set job_queue_processes=0;
--重啟數據庫到mount狀態
shutdown immediate
startup mount;
select database_role, open_mode from v$database;
--切換數據庫到snapshot standby
alter database convert to snapshot standby;
--重新啟動數據庫
shutdown immediate
startup;
select database_role, open_mode from v$database;
操作過程類似如下：
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /u01/app/oracle/fra
db_recovery_file_dest_size big integer 4407M
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
1935528
SQL> show parameter job_queue_processes
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 1000
SQL> alter system set job_queue_processes=0;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 221331456 bytes
Fixed Size 2251856 bytes
Variable Size 163578800 bytes
Database Buffers 50331648 bytes
Redo Buffers 5169152 bytes
Database mounted.
SQL> select database_role, open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED
SQL> alter database convert to snapshot standby;
Database altered.
SQL> select database_role, open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 221331456 bytes
Fixed Size 2251856 bytes
Variable Size 163578800 bytes
Database Buffers 50331648 bytes
Redo Buffers 5169152 bytes
Database mounted.
Database opened.
SQL> select open_mode, database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ WRITE SNAPSHOT STANDBY
4.2 開始讀寫測試
連接到業務用戶jingyu下，刪除原有的test表並清空用戶回收站：SQL> conn jingyu/jingyu
Connected.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
BIN$QSRM4jesEATgU544qMBwAw==$0 TABLE
T1 TABLE
T2 TABLE
TEST TABLE
SQL> drop table test;
Table dropped.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
BIN$QSRM4jesEATgU544qMBwAw==$0 TABLE
BIN$QaFQkzu4C/XgU544qMAz3Q==$0 TABLE
T1 TABLE
T2 TABLE
SQL> purge user_recyclebin;
Recyclebin purged.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
T1 TABLE
T2 TABLE
五、備庫還原為physical standby
5.1 備庫還原為physical standby
參數值確定：--確定db_recovery_file_dest值及其大小
--選擇取消db_recovery_file_dest參數值及其大小的設定
alter system reset db_recovery_file_dest_size sid='*' scope=spfile;
alter system reset db_recovery_file_dest sid='*' scope=spfile;
--或者選擇設置db_recovery_file_dest參數值及其大小為合理值
alter system set db_recovery_file_dest='/u01/app/oracle/fra' sid='*' scope=spfile;
alter system set db_recovery_file_dest_size=4407M sid='*' scope=spfile;
核心步驟：
--重啟數據庫至mount狀態
SQL> shutdown immediate
SQL> startup mount
--切換數據庫到physical standby
SQL> alter database convert to physical standby;
--重啟數據庫
SQL> shutdown immediate
SQL> startup
--查看當前數據庫的scn
select current_scn||'' from v$database
--開啟日志應用
alter database recover managed standby database using current logfile disconnect;
--確定job_queue_processes值
alter system set job_queue_processes=1000;
--查看standby的進程和狀態
select process, status from v$managed_standby;
select database_role, open_mode from v$database;
驗證備庫的狀態信息：
--format
set linesize 120
col NAME for a25
col VALUE for a18
col UNIT for a30
col TIME_COMPUTED for a20
col DATUM_TIME for a20
--select v$dataguard_stats
select * from v$dataguard_stats;
--確定閃回數據庫是否開啟
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
5.2 驗證數據還原到切換前狀態
--確定snapshot standby期間的所有操作都是回退的；
SQL> conn jingyu/jingyu
Connected.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
BIN$QSRM4jesEATgU544qMBwAw==$0 TABLE
T1 TABLE
T2 TABLE
TEST TABLE
實驗證明： 11g snapshot standby的確可以很方便的實現讀寫測試；之后也可以方便的切換回測試前的狀態繼續做為physical standby使用。