...........
http://zhaolinjnu.blog.sohu.com/30862949.html
data guard中主備庫的啟動順序
今天有網友在itpub上討論data guard中主備庫的啟動順序問題,針對data guard采用不同的模式,主備庫的啟動順序如下:
max performance(最大性能):主庫,備庫的啟動和關閉順序沒有先后
max availability(最大可用):要先啟動備庫,再啟動主庫,如果啟動順序相反,主庫仍然能啟動,但會在主庫的alert.log文件中出現如下出錯提示:
Tue Jan 23 09:36:26 2007
alter database open
Tue Jan 23 09:36:26 2007
LGWR: Primary database is in CLUSTER CONSISTENT mode
LGWR: Primary database is in MAXIMUM AVAILABILITY mode
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LNS0 started with pid=12
Tue Jan 23 09:36:29 2007
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing...
Tue Jan 23 09:36:29 2007
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30979.trc:
ORA-01034: ORACLE not available
LGWR: Error 1034 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'test_stb_186'
Thread 1 advanced to log sequence 73
Thread 1 opened at log sequence 73
Current log# 3 seq# 73 mem# 0: /forum_dbf/redo03.log
Successful open of redo thread 1
Tue Jan 23 09:36:33 2007
ARC0: Evaluating archive log 1 thread 1 sequence 72
ARC0: Beginning to archive log 1 thread 1 sequence 72
Creating archive destination LOG_ARCHIVE_DEST_1: '/archive_log/archive/1_72.arc'
Tue Jan 23 09:36:33 2007
ARC1: Evaluating archive log 1 thread 1 sequence 72
ARC1: Unable to archive log 1 thread 1 sequence 72
Log actively being archived by another process
Tue Jan 23 09:36:33 2007
SMON: enabling cache recovery
Tue Jan 23 09:36:33 2007
ARC0: Completed archiving log 1 thread 1 sequence 72
Tue Jan 23 09:36:33 2007
Successfully onlined Undo Tablespace 1.
Tue Jan 23 09:36:33 2007
SMON: enabling tx recovery
Tue Jan 23 09:36:33 2007
Database Characterset is US7ASCII
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open
max protection(最大保護):先啟動備庫,再啟動主庫,如果順序相反,主庫實例會自動中斷,數據庫無法啟動,並會在alert.log文件中留下如下的信息:
Tue Jan 23 09:34:00 2007
alter database open
Tue Jan 23 09:34:00 2007
LGWR: Primary database is in CLUSTER CONSISTENT mode
LGWR: Primary database is in MAXIMUM PROTECTION mode
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LNS0 started with pid=12
Tue Jan 23 09:34:03 2007
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing...
Tue Jan 23 09:34:03 2007
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:
ORA-01034: ORACLE not available
LGWR: Error 1034 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'test_stb_186'
LGWR: Minimum of 1 applicable standby database required
Tue Jan 23 09:34:07 2007
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:
ORA-16072: a minimum of one standby database destination is required
LGWR: terminating instance due to error 16072
Instance terminated by LGWR, pid = 30812
###################
http://www.itpub.net/thread-1382270-1-1.html
不取消日志應用，直接關閉dg物理備庫，會不會有問題？
即直接執行：
SHUTDOWN IMMEDIATE;
而不執行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
--------
只要 不是最大保護狀態，
| 你直接關掉唯一的物理備庫，是沒有問題的。主庫會報一些日志無法應用還是傳輸的錯誤。對主庫沒有影響。
|
| 最好不要這樣~而且還應該在備庫停止日志應用之前先讓主庫停止日志發送，這樣更好 |
這要看你主庫的參數配置了,如果主庫設置了最少歸檔成功數,備庫關閉后,會導致主庫出問題.
另外,備庫關閉了,主庫在向備庫歸檔時,發現備庫關閉,會報錯的.
#####################
http://space.itpub.net/12087396/viewspace-625818
1。然后給主庫關閉數據庫（不行把，呵呵，都進不去了怎么執行SHUTDOWN。。命令啊。沒辦法直接重起機器，打上了補丁，STARTUP數據庫）還好比較順利/
2。物理DG跟主庫是一樣的配置，所以跟主庫一樣進行處理，但是並沒有那么順利，機器起動不起來了，查找了許久（大概1。2小時），才發現是盤掛載不上去了。然后進行了一些修復，謝天謝地，終於順利啟動起來了。然后也打上了補丁，啟動了備庫，查看了ALTER日志發現MRP進程在恢復幾個歸檔。以為就沒事了。
3。第二天上班檢查發現備庫接收不到主庫傳送的歸檔，那個急啊，馬上開始找原因了，A：查看網絡（主備庫互相都可以TNSPING通 log_archive_config='dg_config=(AAA,BBB)'的AAA,BBB），B：密碼文件又沒去動過它，應該不是這里的問題。C：開始查看參數文件，仔細的核對該有的參數都有了，也沒去動過它。問題也不應該不在這啊，反反復復GOOGLE來GOOGLE去，也沒搞出結果，最后看到有人說主庫重起一下就好了（這個是正解），可是不敢確定啊，而且生產庫豈是你隨便可以起的。最后還是尋求了一些幫助進行確認，然后跟主管進行請示（夜里重起DB），終於在夜里得到了驗證。心理松了好大一口氣，可以睡個好覺拉/
4。我覺的應該是主庫在往備庫傳歸檔的時候在一定時間或者是一定數據后如果傳不過去，那主庫將停止往備庫傳歸檔（因為我后來發現我手工切換主庫日期，歸檔沒傳到備庫，但是主庫也ALTER日志也沒報任何錯誤，備庫更是沒信息，可見主庫已經“拋棄”備庫了），而我主庫當時起來的時候，備庫還是掛起的狀態，主庫嘗試往備庫發歸檔，始終不成功。之后主庫就開始“拋棄”備庫了。初步我就這么解釋這個原因了/
5 好了改睡覺拉/困/
#########################
http://www.eygle.com/archives/2009/11/dataguard_restart_lns.html
Oracle Dataguard備庫失敗與主庫響應測試
在客戶環境中，使用了Oracle 10.2.0.4 DataGuard技術，通過最大可用性模式進行數據保護。
以下簡單測試，當備庫關閉后，再重啟備庫，主庫及備庫的響應過程。
在備庫執行如下步驟：
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size 2084400 bytes
Variable Size 385876432 bytes
Database Buffers 1207959552 bytes
Redo Buffers 14692352 bytes
Database mounted.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Database altered.
SQL> exit
當備庫關閉后，主庫立即檢測到備庫的失敗：
Tue Nov 17 20:34:58 2009
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby STANDBY.
Tue Nov 17 20:35:17 2009
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Tue Nov 17 20:35:17 2009
Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:
ORA-03113: end-of-file on communication channel
LGWR: Network asynch I/O wait error 3113 log 1 service 'STANDBY'
Tue Nov 17 20:35:17 2009
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: Failed to archive log 1 thread 1 sequence 3466 (3113)
Tue Nov 17 20:35:18 2009
LGWR: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'STANDBY' (error 3113)
(oradbt)
Tue Nov 17 20:35:18 2009
Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:
ORA-01041: internal error. hostdef extension doesn't exist
LGWR: Error 1041 closing archivelog file 'STANDBY'
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'STANDBY'
當備庫重啟后：
Tue Nov 17 20:35:23 2009
Thread 1 advanced to log sequence 3467 (LGWR switch)
Current log# 2 seq# 3467 mem# 0: /redodata/oradbt/redo02.log
Tue Nov 17 20:38:34 2009
Thread 1 advanced to log sequence 3468 (LGWR switch)
Current log# 3 seq# 3468 mem# 0: /redodata/oradbt/redo03.log
Tue Nov 17 20:39:59 2009
Thread 1 cannot allocate new log, sequence 3469
Checkpoint not complete
Current log# 3 seq# 3468 mem# 0: /redodata/oradbt/redo03.log
LNSb started with pid=19, OS id=573716
Tue Nov 17 20:40:05 2009
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Standby redo logfile selected to archive thread 1 sequence 3469
LGWR: Standby redo logfile selected for thread 1 sequence 3469 for destination LOG_ARCHIVE_DEST_2
Tue Nov 17 20:40:05 2009
Thread 1 advanced to log sequence 3469 (LGWR switch)
Current log# 1 seq# 3469 mem# 0: /redodata/oradbt/redo01.log
Tue Nov 17 20:40:05 2009
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARC0: Standby redo logfile selected for thread 1 sequence 3468 for destination LOG_ARCHIVE_DEST_2
此時備庫也恢復了同步：
Tue Nov 17 20:35:30 2009
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
Tue Nov 17 20:35:30 2009
Attempt to start background Managed Standby Recovery process (oradbt)
MRP0 started with pid=19, OS id=254276
Tue Nov 17 20:35:30 2009
MRP0: Background Managed Standby Recovery process started (oradbt)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 11 processes
Tue Nov 17 20:35:35 2009
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 3466
Tue Nov 17 20:35:36 2009
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 172068
RFS[1]: Identified database type as 'physical standby'
Tue Nov 17 20:39:58 2009
RFS LogMiner: Client disabled from further notification
RFS[1]: Archived Log: '/oradata/archive/1_3466_690213276.dbf'
RFS[1]: Archived Log: '/oradata/archive/1_3467_690213276.dbf'
Tue Nov 17 20:40:00 2009
Media Recovery Log /oradata/archive/1_3466_690213276.dbf
Media Recovery Log /oradata/archive/1_3467_690213276.dbf
Media Recovery Waiting for thread 1 sequence 3468
Tue Nov 17 20:40:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 1441960
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY level
RFS[2]: Successfully opened standby log 4: '/redodata/oradbt/stdrd1.log'
Tue Nov 17 20:40:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 1442140
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Successfully opened standby log 5: '/redodata/oradbt/stdrd2.log'
Tue Nov 17 20:40:06 2009
Media Recovery Log /oradata/archive/1_3468_690213276.dbf
Media Recovery Waiting for thread 1 sequence 3469 (in transit)
檢查主庫的LGWR日志，可以看到整個過程的后台處理：
*** 2009-11-17 20:35:23.248 64165 kcrr.c
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'STANDBY'
Ignoring krslcmp() detach error 1041
kcrrtsync: Standby mount ID 0xc896b692 not found
*** 2009-11-17 20:35:23.249 2342 krsl.c
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.
*** 2009-11-17 20:38:34.160
kcrrtsync: Standby mount ID 0xc896b692 not found
*** 2009-11-17 20:38:34.160 2342 krsl.c
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.
*** 2009-11-17 20:40:02.286
kcrrtsync: Standby mount ID 0xc896b692 not found
Oracle通過數據庫的Mount ID來查找目標實例，備庫關閉Mount ID不存在，則錯誤出現。
重新初始化加你LNS進程的過程如下：
*** 2009-11-17 20:40:02.286 56939 kcrr.c
Initializing NetServer[LNSb] for dest=STANDBY mode SYNC
LNSb is not running anymore.
New SYNC LNSb needs to be started
Waiting for subscriber count on LGWR-LNSb channel to go to zero
Subscriber count went to zero - time now is <11/17/2009 20:40:02>
Starting LNSb ...
Waiting for LNSb to initialize itself
*** 2009-11-17 20:40:05.330 57230 kcrr.c
Netserver LNSb [pid 573716] for mode SYNC has been initialized
Performing a channel reset to ignore previous responses
Successfully started LNSb [pid 573716] for dest STANDBY mode SYNC ocis=0x1104db358
*** 2009-11-17 20:40:05.330 57733 kcrr.c
Making upiahm request to LNSb [pid 573716]: Begin Time is <11/17/2009 20:40:02>. NET_TIMEOUT = <180> seconds
Waiting for LNSb to respond to upiahm
*** 2009-11-17 20:40:05.413 57897 kcrr.c
upiahm connect done status is 0
Receiving message from LNSb
Receiving message from LNSb
Receiving message from LNSb
*** 2009-11-17 20:40:05.609 59112 kcrr.c
Making upinbls request to LNSb (ocis 0x1104db358). Begin time is <11/17/2009 20:40:02> and NET_TIMEOUT is <180> seconds
NetServer pid:573716
清晰的了解這個過程是很有意思的，記錄一下。
-The End-
###############################
http://www.itpub.net/thread-1459850-1-1.html
另外問下 到底是哪個為准？
網絡上有人這樣確定啟動關閉主從次序
第一種日常維護先后次序
1、正確打開主庫和備庫
主庫:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
備庫:
SQL> STARTUP MOUNT;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;
2、正確關閉順序
備庫:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>SHUTDOWN IMMEDIATE;
主庫
SQL>SHUTDOWN IMMEDIATE;
第二種日常維護先后次序
但是有一些文檔說的啟動應該是
先備庫 后從庫
關閉先主庫 后備庫。
現在頭疼 以哪一個為准？
=======
其實你只要搞清原理無所謂哪個先后的~
DG很強大的
我一般都是先停掉主庫archive 發送
然后備庫停止應用然后再關閉備庫
啟動的時候先啟動備庫在啟動主庫~
主要是減少無謂的報錯和對DG工作原理的熟悉很重要
######################################
http://space.itpub.net/23071790/viewspace-688383
DataGuard物理standby管理 - 主備切換
switchover一般用於 數據庫或硬件升級，這時只需要較短時間中斷數據庫訪問，主備庫的角色切換完成后，即可打開primary角色的備庫來提供數據庫訪問。
failover，主庫已經無法使用，必須切換到備庫，當備庫failover切換為primary，則主庫不再是dataguard的一部分，無法再轉換為備庫。
如果是RAC的物理standby，則在執行切換時只能啟動一個instance，切換完畢后再啟動其他實例。
Switchover
一定要按照先主庫，后備庫的順序執行切換命令，否則會報錯，如果強行切換就變成failover了。
主庫端：
由於主庫是處於open狀態，有訪問的，所以v$database視圖中，switchover_status為sessions active。而由primary切換到standby需要數據庫為open狀態，因此，執行切換命令時，帶上with session shutdown選項即可。
執行完切換命令后，關閉數據庫，重新啟動數據庫到mount狀態等待日志傳輸，開啟日志應用。
查看alert.log可以看到主庫做了哪些動作：主庫斷開所有session（未提交事務會回滾），切換日志並歸檔，傳輸日志到備庫，給備庫一個End-Of-REDO的信號，切換為standby，重新啟動到mount。
SYS@dev01> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STAT
--------------- ---------------
PRIMARY SESSIONS ACTIVE
SYS@dev01>alter database commit to switchover to physical standby with session shutdown;
Database altered.
SYS@dev01> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
SYS@dev01> startup mount;
ORACLE instance started.
Total System Global Area 536870912 bytes
Fixed Size 2085288 bytes
Variable Size 209718872 bytes
Database Buffers 318767104 bytes
Redo Buffers 6299648 bytes
Database mounted.
SYS@dev01>alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SYS@dev01> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYSESSIONS ACTIVE
SYS@dev01>
備庫端：
確認是否可以切換為主庫，如果switchover_status為recovery needed或switchover latent，需要apply完所有歸檔日志才能切換。如果是sessions active則帶上with session shutdown選項。apply完所有日志后，即可切換為primary，然后打開數據庫。
查看alert.log可以看到備庫做了哪些動作：接收主庫日志，接收到主庫End-Of-REDO的信號，apply完所有日志，清空online redo log以便打開數據庫，切換為primary，打開數據庫。
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYSWITCHOVER LATENT
SYS@dev01dg> alter database commit to switchover to primary with session shutdown;
alter database commit to switchover to primary with session shutdown
*
ERROR at line 1:
ORA-16139: media recovery required
SYS@dev01dg>alter database recover managed standby database disconnect from session;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYTO PRIMARY
SYS@dev01dg>alter database commit to switchover to primary with session shutdown;
Database altered.
SYS@dev01dg>alter database open;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PRIMARY SESSIONS ACTIVE
SYS@dev01dg>
以上過過程中，由於主庫斷開所有session並歸檔，傳輸日志到備庫，發給備庫End-Of-REDO的信號，因此正常switchover時，是不會丟失數據的。
切換完成后可以在主庫歸檔，驗證一下是否切換成功，備庫是否能正常接收日志。
Failover
當主庫當掉，無法使用時，此時的切換即為failover，如果保護模式為最大性能模式，是可能丟失數據的。
備庫端：
如果是最大保護和最大可用性模式，則可以直接在備庫端執行failover切換。如果是最大性能模式，為了盡可能減少數據丟失，需要檢查主庫是否有日志沒有傳輸到備庫，手動傳輸備庫進行注冊和恢復。注意RAC環境下，歸檔日志是分線程的。
SYS@dev01dg>select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
THREAD# A
---------- ----------
1 457
SYS@dev01dg>
[oracle@testdb dev01]$ scp * oracle@192.168.0.8:/u01/archive/dev01dg
注冊歸檔日志有如下兩種方法，較為簡單當然是用rman了，一次注冊多個。
RMAN>catalog start with '/u01/archive/dev01';
SYS@dev01dg>alter database register logfile '/u01/archive/dev01dg/arch_e8fe6364_1_712757927_460.dbf';
apply歸檔日志也有兩種方法。
SYS@dev01dg>alter database recover managed standby database disconnect from session;
Database altered.
SYS@dev01dg>
SYS@dev01dg>recover standby database;
ORA-00279: change 2863819 generated at 03/20/2010 21:58:17 needed for thread 1
ORA-00289: suggestion : /u01/archive/dev01dg/arch_e8fe6364_1_712757927_461.dbf
ORA-00280: change 2863819 for thread 1 is in sequence #461
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.
SYS@dev01dg>
當手動apply完所有日志后，就可以failover切換到primary了。但是要注意的時，由於備庫沒有收到主庫End-Of-REDO的信號，所以直接轉換會報錯，要求介質恢復。此時需要提交命令告訴備庫，日志恢復已經finish了，需要進行failover切換。注意switchover時千萬不要帶有finish選項，否則就會變成failover了。
SYS@dev01dg> alter database commit to switchover to primary with session shutdown;
alter database commit to switchover to primary with session shutdown
*
ERROR at line 1:
ORA-16139: media recovery required
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYNOT ALLOWED
SYS@dev01dg>alter database recover managed standby databasefinish[force];
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYTO PRIMARY
SYS@dev01dg>alter database commit to switchover to primary with session shutdown;
Database altered.
SYS@dev01dg>alter database open;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PRIMARY SESSIONS ACTIVE
SYS@dev01dg>
failover完成后，數據庫其實是以resetlogs方式打開的，如果log_archive_format='arch_%d_%t_%r_%s.dbf'，可以看到歸檔日志的文件名會有新的resetlogs ID和sequence number，以此與原有的歸檔日志進行區分。
==================
http://blog.csdn.net/dream19881003/article/details/5514401
啟動到管理模式
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
啟動到只讀的模式
shutdown immediate
startup nomount
alter database mount standby database;
alter database database open read only;
如果在管理恢復的模式下到只讀模式
recover managed standby database cancel;
alter database open read only;
這個時候可以給數據庫增加臨時數據庫文件(這時候熱備份是沒有備份過來的)
在只讀模式下到管理恢復方式
recover managed standby database disconnect from session;
主庫和備庫的切換
switchover時只能先從primary切換到standby，再從standby到primary
最簡單的辦法是把兩個數據庫的文件互換，
primary到standby
sqlplus /nolog < connect / as sysdba
alter database commit switchover to physical standby with session shutdown;
shutdown immediate;
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbsdby.ora';
startup nomount;
alter database mount standby disconnect;
exit
eof
lsnrctl stop
lsnrctl start listenerdb
修改主機的tnsnames.ora 將主機的ip與備機的ip兌換
standby到primary
more switchprimary.sh
sqlplus /nolog < connect / as sysdba
shutdown immediate
create spfile from '/../product/10.1.0/db_1/dbs/inittdbdprim.ora';
startup
exit
eof
lsnrctl stop listenerdb
lsnrctl start
修改備庫的tnsname.ora 主備庫的ip互換
這樣切換的要求是主備機各有兩個listener，listener監聽的是1521，listenerdb監聽的是1522
任何一個節點，在primary期間啟動listener，standby期間啟動listenerdb
連接data guard的客戶端的tnsname配置，這樣可以實現失敗對換，對客戶端是透明的：
BOSS =
(DESCRIPTION =
(failover = on )
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 主)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 備)(PORT = 1521))
)
(CONNECT_DATA =
(SID = BOSS)
)
備庫的失敗切換
1，失敗的切換
一般是主服務器已經不能使用，必須切換到備用的服務器，所以只操作備用服務器這一端，提供一切換腳本
more switchprimary.sh
cd $HOME
.bash_profile
sqlplus /nolog < connect / as sysdba
recover managed standby database cancel;
--if standby hava standby redo logfile;
--alter database recover managed standby database finish;
--else
alter database recover managed standby database finish skip standby logfile;
--switch
alter database recover managed standby database finish skip standby logfile;
--open
shutdown immediate
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora';
startup
exit
eof
lsnrctl stop linstenerdb
lsnrctl start
最后將tnsname.ora將住備庫的ip對換
如果在備用端有活動的為歸檔的日志，或者有從主數據庫拷貝過來的聯機日志，可以采用如下的辦法注冊並恢復
alter database register logfile '/../oradata/tbdb/archive/1_87.dbf';
recover standby database;
如果有活動日志必須用
alter database recover managed standby database finish;
否則用
alter database recover managed standby database finish skip standby logfile;
這樣切換的備用服務器可以避免最小的數據丟失和不用retlogs，特別是對於用多個備用服務器的時候，該服務器可以馬上作為主服務器而不用重新創建備用的服務器。
強行切換(激活)
這種切換是以激活備用服務器來完成的，在重新啟動數據庫的時候，備用激活resetlogs，這樣會影響到其他的備用服務器而且必須重新再主服務器上重新構造備用服務器，一般不建議這樣做
$more activeprimary.sh
#!/bin/bash
#switch to primary with cancel;
cd $HOME
. .bash_profile
#cancel and startup database;
sqlplus /notog < connect / as sysdba
alter system arcive log current;
recover managed standby database cancel;
alter database activete standby database;
shutdown immediate;
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora';
startup
exit
eof
lsnrctl stop listenerdb
lsnrctl start
備用庫的備份與恢復
1,從備用庫上恢復主庫的數據文件
在某些情況下，主服務器可能會損壞一到兩個數據文件，如果是從主庫的備份設備恢復，理論是可以的，但是可能會因為需要太多的日志，實際耗時太大，這個時候，我們可以考慮從備份的服務器上恢復該數據，因為備份的服務器和主數據庫一般只是相差一個日志文件左右。
1》關閉備用的數據庫
recover managed standby database cancel;
shutdown immediate;
2》拷貝或ftp損壞的數據文件到主數據庫
3》在主數據庫recover database datafile ‘文件名'即可
2，在備用數據庫上進行備份
如果想減輕主庫的壓力，可以在備用數據庫上進行備份，因為備用數據庫的特性關系，在對standby的rman備份中，不能修改rman的配置，所以沒有辦法自動備份控制文件。
可以采取一下方法進行備份
1》備份備用數據庫，可以停止恢復進程，跳轉到read only的模式下，通過backup database，來備份數據庫，這樣的數據庫處於一致的模式下
2》采用恢復目錄備份standby數據庫
rman target sys@dbstandby
backup database format '/../oradata/rman_backup/full_%d_%T_s%s_p%p';
backup archivelog all delete input format '/../oradate/rman_backup/ctl_%d_%T_s%s_p%p';
如果采用控制文件做恢復的目錄，注意
alter database backup controlfile to '/../ordata/rman_backup/ctl_%d_%T_s%s_p%p';
#############################################
http://space.itpub.net/658698/viewspace-622212
第一部分 日常維護
一 正確打開主庫和備庫
1 主庫:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
2 備庫:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
二 正確關閉順序
1 備庫:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>SHUTDOWN IMMEDIATE;
2 主庫
SQL>SHUTDOWN IMMEDIATE;
三 備庫Read-Only模式打開
當前主庫正常OPEN狀態
備庫處於日志傳送狀態.
1 在備庫停止日志傳送
SQL> recover managed standby database cancel;
2 備庫Read-only模式打開
SQL> alter database open read only;
3 備庫回到日志傳送模式
SQL> recover managed standby database disconnect from session;
Media recovery complete.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
四 日志傳送狀態監控
1 主庫察看當前日志狀況
SQL> select sequence#,status from v$log;
SEQUENCE# STATUS
---------- ----------------
51 ACTIVE
52 CURRENT
50 INACTIVE
2 備庫察看RFS(Remote File Service)接收日志情況和MRP應用日志同步主庫情況
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
2 FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
RFS RECEIVING 0 0 0 0
MRP0 WAIT_FOR_LOG 1 52 0 0
RFS RECEIVING 0 0 0 0
可以看到備庫MPR0正等待SEQUENCE#為52的redo.
3 察看備庫是否和主庫同步
SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ#
2 FROM V$ARCHIVE_DEST_STATUS;
ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#
---------------- ------------- --------------- ------------
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
1 51 1 50
可以看到備庫已經將SEQUENCE#51的日志歸檔,已經將SEQUENCE#50的redo應用到備庫.
由於已經將SEQUENCE#51的日志歸檔,所以SEQUENCE#51以前的數據不會丟失.
4 察看備庫已經歸檔的redo
SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,
2 NEXT_CHANGE# FROM V$ARCHIVED_LOG;
REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
------- ------- ---------- ---------- ------------- ------------
SRMN SRMN 1 37 572907 573346
RFS ARCH 1 38 573346 573538
RFS ARCH 1 39 573538 573623
RFS ARCH 1 40 573623 573627
RFS ARCH 1 41 573627 574326
RFS ARCH 1 42 574326 574480
RFS ARCH 1 43 574480 590971
RFS ARCH 1 44 590971 593948
RFS FGRD 1 45 593948 595131
RFS FGRD 1 46 595131 595471
FGRD FGRD 1 46 595131 595471
REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
------- ------- ---------- ---------- ------------- ------------
RFS ARCH 1 47 595471 595731
RFS ARCH 1 48 595731 601476
RFS ARCH 1 49 601476 601532
RFS ARCH 1 50 601532 606932
RFS ARCH 1 51 606932 607256
5 察看備庫已經應用的redo
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
2 FROM V$LOG_HISTORY;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 1 366852 368222
1 2 368222 369590
1 3 369590 371071
1 4 371071 372388
1 5 372388 376781
1 6 376781 397744
1 7 397744 407738
1 8 407738 413035
1 9 413035 413037
1 10 413037 413039
1 11 413039 413098
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 12 413098 428161
1 13 428161 444373
1 14 444373 457815
1 15 457815 463016
1 16 463016 476931
1 17 476931 492919
1 18 492919 505086
1 19 505086 520683
1 20 520683 530241
1 21 530241 545619
1 22 545619 549203
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 23 549203 552403
1 24 552403 553230
1 25 553230 553398
1 26 553398 553695
1 27 553695 554327
1 28 554327 557569
1 29 557569 561279
1 30 561279 561385
1 31 561385 566069
1 32 566069 566825
1 33 566825 570683
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 34 570683 571627
1 35 571627 571867
1 36 571867 572907
1 37 572907 573346
1 38 573346 573538
1 39 573538 573623
1 40 573623 573627
1 41 573627 574326
1 42 574326 574480
1 43 574480 590971
1 44 590971 593948
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 45 593948 595131
1 46 595131 595471
1 47 595471 595731
1 48 595731 601476
1 49 601476 601532
1 50 601532 606932
1 51 606932 607256
可以看到備庫已經將SEQUENCE#為51的歸檔文件應用到備庫.
6 察看備庫接收,應用redo數據過程.
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
--------------------------------------------------------------------------------
ARC0: Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Archival started
ARC1: Becoming the heartbeat ARCH
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 19740
RFS[1]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Attempt to start background Managed Standby Recovery process
MESSAGE
--------------------------------------------------------------------------------
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Clearing online redo logfile 7 /oraguard/redo1/redo_7_1.log
Clearing online redo logfile 7 complete
Media Recovery Waiting for thread 1 sequence 47
RFS[1]: No standby redo logfiles created
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 19746
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
MESSAGE
--------------------------------------------------------------------------------
Committing creation of archivelog '/arch/1_47_552308270.arc'
Media Recovery Log /arch/1_47_552308270.arc
Media Recovery Waiting for thread 1 sequence 48
MRP0: Background Media Recovery cancelled with status 16037
MRP0: Background Media Recovery process shutdown
Managed Standby Recovery Canceled
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 48
RFS[1]: No standby redo logfiles created
MESSAGE
--------------------------------------------------------------------------------
Committing creation of archivelog '/arch/1_48_552308270.arc'
Media Recovery Log /arch/1_48_552308270.arc
Media Recovery Waiting for thread 1 sequence 49
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_49_552308270.arc'
Media Recovery Log /arch/1_49_552308270.arc
Media Recovery Waiting for thread 1 sequence 50
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_50_552308270.arc'
Media Recovery Log /arch/1_50_552308270.arc
Media Recovery Waiting for thread 1 sequence 51
MESSAGE
--------------------------------------------------------------------------------
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_51_552308270.arc'
Media Recovery Log /arch/1_51_552308270.arc
Media Recovery Waiting for thread 1 sequence 52
可以看到RFS接收到sequence#為51的歸檔文件並存至備庫歸檔目錄/arch/1_51_552308270.arc.
Oracle自動應用文件/arch/1_51_552308270.arc進行備庫與主庫同步
Oracle繼續等待主庫sequence 52的歸檔文件
五 備庫歸檔目錄維護
1 找到備庫歸檔目錄
SQL> show parameter log_archive_dest_1
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
log_archive_dest_1 string
LOCATION=/arch
VALID_FOR=(ALL_LOGFILES,ALL_RO
LES)
DB_UNIQUE_NAME=ora2
log_archive_dest_10 string
2 維護策略
每周2,4,7刪除已經應用的歸檔文件
具體參見附錄二
第二部分 主庫正常切換
一 人工干預主庫正常切換
1 在主庫端檢驗數據庫可切換狀態
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected
SWITCHOVER_STATUS:TO STANDBY表示可以正常切換.
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE,表示當前有會話處於ACTIVE狀態
2 開始主庫正常切換
如果SWITCHOVER_STATUS的值為TO STANDBY 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
成功運行這個命令后，主庫被修改為備庫
3 重啟先前的主庫
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4 在備庫驗證可切換狀態
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
5 將目標備庫轉換為主庫
如果SWITCHOVER_STATUS的值為TO STANDBY 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
成功運行這個命令后，備庫被修改為主庫
6 重啟目標備庫
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
7 先前主庫啟動日志傳送進程
SQL> alter database recover managed standby database disconnect;
總結: 這樣主庫的一次正常切換完成.切換后的狀態,原先的主庫變為備庫,原先的備庫變為主庫.
二 通過運行腳本實現主庫正常切換
1 主庫切換為備庫
在主庫上運行腳本
/admin/dataGuard/switchover/primary_to_standby.sh
2 備庫切換為主庫
在備庫上運行腳本
/admin/dataGuard/switchover/standby_to_primary.sh
腳本1成功運行后,再運行腳本2,不能同時運行兩個腳本.
經過這次切換后原來的主庫變為備庫,原先的備庫變為主數據並且OPEN對應用提供服務.
3 復原最初狀態
在原備庫上運行腳本
/admin/dataGuard/switchover/primary_to_standby.sh
成功完成后
在原主庫上運行腳本
/admin/dataGuard/switchover/standby_to_primary.sh
第三部分 主庫災難切換
一 人工干預主庫災難切換
二 通過運行腳本實現主庫災難切換
SQL>alter database recover managed standby database cancel;
SQL>shutdown immediate
SQL>startup mount
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
SQL>alter database recover managed standby database finish;
-- switch
SQL>alter database commit to switchover to primary with session shutdown;
-- open
SQL>shutdown immediate
SQL>startup
附:
一 有選擇察看redo傳送與應用情況
select message from v$dataguard_status
where message_num>&message_num;
二 備庫歸檔目錄維護腳本
在crontab 中定制每日執行removeCommand.sh即可。
流程:每日11:50PM執行removeCommand.sh
假設今日2005-04-05 則刪除04-04和04-03兩日已應用歸檔日志.保留今日已應用歸檔日志
[oracle@db_gurid admin]$ crontab -l
50 23 * * * sh /oraguard/admin/removeCommand.sh>>removeArch.log
##################
[oracle@db_gurid admin]$ cat removeCommand.sh
#!/bin/sh
export ORACLE_BASE=/ora10g/app
export ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1
export ORACLE_SID=ora2
cd /oraguard/admin
$ORACLE_HOME/bin/sqlplus /nolog<<EOF
conn / as sysdba
@/oraguard/admin/removeArch.sql
EOF
chmod +x /oraguard/admin/removeArch.sh
/oraguard/admin/removeArch.sh>>removeArch2.log
##################
[oracle@db_gurid admin]$ cat removeArch.sql
set feed off
set heading off
set echo off
spool removeArch.sh
select 'rm '||name from v$archived_log where applied='YES' and completion_time>trunc(sysdate-3) and completion_time<trunc(sysdate);
spool off
#####################################################
http://www.qqread.com/oracle/2010/01/q488670.html
一、日志應用服務介紹
日志應用服務自動應用重做到備數據庫，以維護與主數據庫的同步並允許對數據庫的事務一致性訪問。
默認地，日志應用服務在應用歸檔重做日志文件到備數據庫之前等待完全的歸檔重做日志文件到達備數據庫。從主數據庫傳送的重做數據被備系統上的遠程文件服務進程（RFS）接收，在那里RFS 進程寫重做數據到歸檔重做日志文件或備重做日志文件。然而，如果你使用備重做日志文件，你能允許實時應用，這允許Data Guard從正在被RFS 進程寫的當前備重做日志文件恢復重做數據。
日志應用服務使用下面的方法來維護物理和邏輯備數據庫：
重做應用（只有物理備數據庫）
使用介質恢復來保持主和物理備數據庫同步。
注意：
你也能以只讀模式打開物理備數據庫，允許用戶查詢備數據庫用作報表用途。當打開的時候，還是接收重做數據的；然而，重做應用停止並且物理備數據庫沒有與主數據庫保持同步。如果在此時間發生故障，會延長故障轉移操作完成所需的時間
SQL應用（只有邏輯備數據庫）
從主數據庫接收的重做重組SQL語句並在邏輯備數據庫上執行SQL語句。
邏輯備數據庫能以讀/寫模式打開，但是由邏輯備數據庫維護的目標表只能以只讀模式打開以用於報表用途（倘若數據庫guard 適當設置）。SQL 應用允許你使用邏輯備數據庫用於報表活動，即使當SQL 語句被應用時。
二、日志應用服務配置選項
使用實時應用來立即應用重做數據
如果允許了實時應用特性，日志應用服務能在接收重做數據時應用，而不用等待當前備重做日志文件歸檔。這導致更快的切換和故障轉移時間，因為備重做日志文件在故障轉移或切換開始的時候已經應用到備數據庫。
使用 ALTER DATABASE 語句來允許實時應用特性，如下：
對於物理備數據庫，執行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 語句。
對於邏輯備數據庫，執行ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 語句。
注意：使用實時應用需要備重做日志文件。
圖 1 顯示了使用本地目的地和備目的地的Data Guard 配置。當遠程文件服務（RFS）進程在備數據上寫重做數據到備重做日志文件時，日志應用服務能從正在被寫的備重做日志文件恢復重做。
圖1 使用實時應用應用重做數據到備目的地
對歸檔重做日志文件的應用指定時間延遲
在一些情況下，你可能想在重做數據從主站點接收到它應用到備數據庫的時間之間創建一個時間延遲。你能指定時間間隔（分鍾）來保護損壞或錯誤的數據的應用到備數據庫，當你設置DELAY 間隔，它不是延遲重做數據的傳輸到備數據庫。替代地，你指定的時間延遲從重做數據完整地歸檔到備目的地開始。
注：如果你定義對一個允許實時應用的目的地的延遲，則該延遲被忽略。
指定時間延遲
你能使用 LOG_ARCHIVE_DEST_n 初始化參數的DELAY=minutes 屬性，在主和備數據庫上設置時間延遲來延遲應用歸檔重做日志文件到備數據庫。默認地，沒有時間延遲。如果你指定DELAY 而沒有指定一個值，則默認的延遲間隔是30 分鍾。
取消時間延遲
你能取消指定的延遲間隔，如下：
對於物理備數據庫，使用 RECOVER MANAGED STANDBY DATABASE 字句的NODELAY 關鍵詞：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY；
對於邏輯備數據庫，指定下面的 SQL 語句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY；
這些命令導致日志應用在時間間隔過期之前，立即開始應用歸檔重做日志文件到備數據庫。
使用Flashback 數據庫作為設置時間延遲的另一選擇
作為設置應用延遲的另一選擇，你能使用Flashback 數據庫來從損壞或錯誤數據的應用中恢復到備數據庫。Flashback 數據庫能快速、簡單地閃回備數據庫到一個任意的時間點。
三、應用重做數據到物理備數據庫
默認地，重做數據從歸檔重做日志文件應用。當執行重做應用時，物理備數據庫能使用實時應用特性來從正在被RFS 進程寫的備重做日志文件直接應用重做。注意當物理備數據庫以只讀模式打開時日志應用服務不能應用重做數據。
開始重做應用
要在物理備數據庫上開始日志應用服務，確保物理備數據庫是啟動並安裝的，然后使用SQL:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 語句來開始重做應用。
你能指定重做應用作為前台會話或后台進程運行，並允許它實時應用。
要在前台開始重做應用，執行下面的 SQL 語句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE；
如果你開始一個前台會話，控制不會返回到命令提示符，直到恢復被其它會話取消了。?? 要在后台開始重做應用，在 SQL 語句中包括DISCONNECT 關鍵詞。例如：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT；
這條語句開始了一個分離的服務進程並立即返回控制到用戶。當管理恢復進程在后台執行恢復，執行RECOVER 語句的前台進程能繼續執行其它任務。這不會斷開當前的SQL 會話。
要開始實時應用，在 SQL 語句上包含USING CURRENT LOGFILE 字句。例如：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE；
停止重做應用
要停止重做應用，在其它窗口執行下面的 SQL 語句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL；
四、應用重做數據到邏輯備數據庫
SQL 應用從歸檔重做日志或備重做日志轉換數據到SQL 語句，然后在邏輯備數據庫上執行這些SQL 語句。因為邏輯備數據庫保持打開，維護的表能同時用於其它任務，如報表、總結、和查詢。
開始SQL 應用
要開始 SQL 應用，啟動邏輯備數據庫並執行下面語句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
在邏輯備數據庫上停止SQL應用
要停止SQL 應用，在邏輯備數據庫上執行下面語句：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
當你執行該語句，SQL 應用等待直到它提交了所有在應該過程中完成的事務。這樣，該命令可能不能立即停止SQL 應用進程。如果你想立即停止 SQL 應用，執行下面語句：
SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;