Oracle Data Gurad -- Logical Standby 相關說明

一．邏輯Standby的準備工作

1 確認操作的物件和語句是否能被邏輯Standby支援

由於邏輯Standby是通過SQL應用來保持與Primary資料庫的同步。SQL應用與REDO應用是有很大的區別，REDO應用實際上是在物理Standby端進行RECOVER；SQL應用則是分析重做日誌檔案中的REDO資訊，並將其轉換為SQL語句，在邏輯Standby端執行，因此，需要注意以下幾點：

（1）並非所有的資料型別都能被邏輯Standby支援，

邏輯Standby支援的資料型別有：

BINARY_DOUBLE、BINARY_FLOAT、BLOB、CHAR、CLOB and NCLOB、 DATE、INTERVAL YEAR TO MONTH、INTERVAL DAY TO SECOND、 LONG、LONG RAW、NCHAR、NUMBER、NVARCHAR2、RAW、TIMESTAMP、

TIMESTAMP WITH LOCAL TIMEZONE、TIMESTAMP WITH TIMEZONE、VARCHAR2 and VARCHAR

說明：下列型別在獲取Standby支援時需要注意相容性：

CLOB，需要Primary資料庫的相容級別執行於10.1或更高。

含LOB欄位的索引組織表（IOT），需要Primary資料庫的相容級別執行於10.2或更高。

不含LOB欄位的索引組織表（IOT），需要Primary資料庫的相容級別執行於10.1或更高。

不支援的資料型別有：

BFILE、Encrypted Columns、ROWID, UROWID、XMLType、物件型別、VARRAYS、巢狀表、自定義型別。

也可以通過查詢DBA_LOGSTDBY_UNSUPPORTED來確定主資料庫中是否含有不支援的物件

SQL> select * from dba_logstdby_unsupported;

注意：該檢視的ATTRIBUTES列，顯示物件不被SQL應用支援的原因。

（2）並非所有的儲存型別都能被邏輯Standby支援。

邏輯Standby能夠支援簇表（Cluster Tables）、索引組織表（Index-Organized Tables）、堆組織表（Heap-Organized Tables），但不支援段壓縮（Segment Compression）儲存型別。

（3）並非所有的PL/SQL包都能被SQL應用支援。

通常那些不會修改系統後設資料（Metadata）的Package在實際應用時不會有問題，如DBMS_OUTPUT、DBMS_RANDOM、DBMS_METADATA之類的包。

那些可能修改系統後設資料的Package不會被SQL應用支援，即使它們在Primary執行過，並且被成功傳輸到邏輯Standby端，也不會執行。如DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_REDEFINITION、DBMS_SCHEDULER及DBMS_AQ等。只有DBMS_JOB例外，Primary資料庫的jobs會被複制到邏輯Standby，不過在邏輯Standby資料庫不會執行這些job。

說明：後設資料，直接理解成物件的物理定義。舉例來說，對於某表而言，後設資料就是表結構，或表的儲存屬性等。

（4）並非所有的SQL語句都能在邏輯Standby端執行。

在預設情況下，下列SQL語句在邏輯Standby端會被SQL應用自動跳過：

ALTER DATABASE。

ALTER MATERIALIZED VIEW。

ALTER MATERIALIZED VIEW LOG。

ALTER SESSION。

ALTER SYSTEM。

CREATE CONTROL FILE。

CREATE DATABASE。

CREATE DATABASE LINK。

CREATE PFILE FROM SPFILE。

CREATE MATERIALIZED VIEW。

CREATE MATERIALIZED VIEW LOG。

CREATE SCHEMA AUTHORIZATION。

CREATE SPFILE FROM PFILE。

DROP DATABASE LINK。

DROP MATERIALIZED VIEW。

DROP MATERIALIZED VIEW LOG。

EXPLAIN。

LOCK TABLE。

SET CONSTRAINTS。

SET ROLE。

SET TRANSACTION。

另外，由於SQL語句非常靈活，即使是那些能被SQL應用支援的DDL語句，可能在附加了某些特別的引數後，也不會在邏輯Standby端執行，由於數目較多，此處不再一一列舉，感興趣的話請查閱官方文件。

（5）並非所有的DML操作都能在邏輯Standby端實面SQL應用。

維護邏輯Standby與Primary的資料庫同步是通過SQL應用實現，SQL應用轉換的SQL語句在執行時，對於INSERT還好說，對於UPDATE、DELETE操作則必須能夠唯一定位到資料庫待更新的那條記錄。問題就在這裡，如果Primary庫中表設定不當，可能就無法確認唯一條件。

你可能會說可以通過ROWID唯一嘛！千萬要謹記啊，邏輯Standby，為啥叫邏輯Standby，就是因為它只是邏輯上與Primary資料庫相同，物理上可能與Primary資料庫存在相當大差異。一定要認識到，邏輯Standby的物理結構與Primary是不相同的（即使初始邏輯Standby是通過Primary的備份建立）。

因此想通過ROWID更新顯然是不好使的，當然也就不能再將其作為唯一條件。下面來看這個問題。

2 確保Primary庫中各表的行可被唯一標識

Oracle通過主鍵、唯一索引/約束的補充日誌（Supplemental Logging）來確定待更新邏輯Standby資料庫中的行。當資料庫啟用了補充日誌，每一條UPDATE語句寫REDO的時候會附加列值唯一資訊，比如：

如果表定義了主鍵，則主鍵列會隨同被更新列一起作為UPDATE語句的一部分，以便執行時區分哪些列應該被更新。

如果沒有主鍵，則非空的唯一索引/約束會隨同被更新列作為UPDATE語句的一部分，以便執行時區分哪些列應該被更新，如果該表有多個唯一索引/約束，則Oracle自動選擇長度最短的那個，以降低生成的重做日誌大小。

如果表既無主鍵，也沒有定義唯一索引/約束，所有可定長度的列，連同被更新列同時作為UPDATE語句的一部分。更明確些，可定長度的列是指除LONG、LOB、LONG RAW、OBJECT TYPE、COLLECTION型別外的列。

Oracle 建議你為表建立一個主鍵或非空的唯一索引/約束，以儘可能確保SQL應用能夠有效應用REDO資料，更新邏輯Standby資料庫。

下列語句可以用來檢查SQL應用能否唯一識別表列，並找出不被支援的表：

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER, TABLE_N

AME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED)

AND BAD_COLUMN = 'Y';

OWNER TABLE_NAME

----- ---------------

TSMSY SRS$

提示: 關於DBA_LOGSTDBY_NOT_UNIQUE, 該檢視顯示所有既沒主鍵也沒唯一索引的表。如果表中的列包括足夠多的資訊，通常也可支援在邏輯Standby端的更新，不被支援的表通常是由於列的定義包含了不支援的資料型別。

注意BAD_COLUMN列值，該列有兩個值：

Y：表示該表中有采用大資料型別的欄位，比如LONG、CLOB。如果表中除LOG列某些行記錄完全匹配，則該表無法成功應用於邏輯Standby。Standby會嘗試維護這些表，不過你必須保證應用不允許。

N：表示該表擁有足夠的資訊，能夠支援在邏輯Standby的更新，不過仍然建議你為該表建立一個主鍵或者唯一索引/約束，以提高LOG應用效率。

假設在某張表中你可以確認資料是唯一的，但是基於效率方面的考慮，不想為其建立主鍵或唯一約束，怎麼辦呢？沒關係，Oracle早想到了這一點，你可以建立一個DISABLE的Primary-Key Rely約束：

提示: 關於Primary-Key Rely約束。

如果DBA能夠確認表中的行是唯一的，那麼可以為該表建立Rely的主鍵，Rely約束並不會造成系統維護主鍵的開銷，如你對一個表建立了RELY約束，系統則會假定該表中的行是唯一的，這樣能夠提高SQL應用時的效能。但是需要注意，由於Rely的主鍵約束只是假定唯一，如果實際並不唯一的話，有可能會造成錯誤的更新喲。

建立Rely的主鍵約束非常簡單，只要在標準的建立語句後加上RELY DISABLE即可，例如：

SQL> ALTER TABLE USER ADD PRIMARY KEY (ID) RELY DISABLE;

表已更改。

注意: 建立了Rely約束後，Oracle會假定該列是唯一的（給DBA足夠的信任），不過並不會對該列的值進行唯一性的驗證，因此該列是否唯一隻能由DBA來主動維護。

二．邏輯Standby建立時的操作步驟

1 建立物理Standby

建立邏輯Standby資料庫的第一步就是先建立一個物理Standby資料庫，然後再將其轉換成邏輯Standby資料庫。在將其轉換為邏輯Standby前，可以隨時啟動REDO應用，不過一旦決定將其轉換為邏輯Standby，就必須先停止該物理Standby的REDO應用，以避擴音前應用含LogMiner字典的REDO資料，造成轉換為邏輯Standby後，SQL應用時LogMiner字典資料不足而影響到邏輯Standby與Primary的正常同步。

2 設定Primary資料庫

在建立物理Standby資料庫時曾經設定過相關數量的初始化引數，用於Primary資料庫與物理Standby的角色切換，對於邏輯Standby的角色切換，那些引數同樣好使。

不過注意，如果希望Primary資料庫能夠正常切換為邏輯Standby角色，那麼DBA在配置環境時，還需要設定相應的LOG_ARCHIVE_DEST_n初始化引數，並注意該引數的VALID_FOR屬性值需要更改成STANDBY_LOGFILES,STANDBY_ROLE。

完成對初始化引數的配置後，必須在Primary資料庫端生成LogMiner字典資訊，例如：

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

提示：本步必須執行，並且執行本步操作時，準邏輯Standby資料庫要停止REDO應用。

該過程專門用於生成記錄的後設資料資訊到重做日誌檔案，邏輯Standby未來正是通過這些後設資料保持與Primary資料庫的同步。

提示：該過程會自動啟用Primary資料庫的補充日誌（Supplemental Logging）功能（如果未啟用的話）。

該過程需要等待當前所有事務完成後才能執行，因此如果當前有較長的事務執行，可能該過程的執行也需要多花一些等待時間。

該過程是通過閃回查詢的方式來獲取資料字典的一致性，因此Oracle初始化引數UNDO_RETENTION值不能太小，建議設定為3600，並且UNDO表空間也要有足夠的空間。

3 轉換物理Standby為邏輯Standby

執行下列語句，轉換物理Standby為邏輯Standby：

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY DB_NAME;

注意：DB_NAME不是DB_UNIQUE_NAME，不同於物理Standby，邏輯Standby是一個全新的資料庫，因此建議你指定一個唯一的與Primary不同的資料庫名。另外如果當前準邏輯Standby使用SPFILE啟動資料庫，那麼執行該語句時Oracle會自動修改SPFILE中的相關資訊，如果使用PFILE啟動資料庫，那麼在下次執行SHUTDOWN的時候，Oracle會提示你去修改DB_NAME初始化引數的值。

執行該語句前務必確保當前準邏輯Standby已經暫停了REDO應用，另外轉換是單向的，即只能由物理Standby向邏輯Standby轉換，而不能由邏輯Standby轉成物理Standby。這並不僅僅是因為DB_NAME發生了修改，更主要的原因是邏輯Standby僅是資料與Primary一致，其他如儲存結構、SCN等，甚至DBID都不相同。

執行轉換的過程中，需要應用全部的與LogMiner字典相關的REDO資料。這部分操作完全依賴於Primary資料庫DBMS_LOGSTDBY.BUILD的執行，以及傳輸到Standby資料庫端，需要應用的資料量的規模而定。如果Primary資料庫執行DBMS_LOGSTDBY.BUILD失敗，則轉換操作也不會有結果，這時候你恐怕不得不先cancel它，解決Primary資料庫的問題之後再嘗試執行轉換。取消該操作與取消REDO應用一樣，當然實際上，也正是取消REDO應用。

4 重建邏輯Standby的金鑰檔案

主要是由於轉換操作修改了資料庫名，因此密碼檔案也需要重建，這個操作我們做得比較多，這裡就不詳述了。

[oracle@localhost dbs]$ orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=admin

如果已經存在，就不用建立了。預設情況下，win下口令檔案的格式是pwdsid.ora，unix下的格式是orapwSID(大小寫敏感）

5 調整邏輯Standby初始化引數

之所以要調整初始化引數，一方面是由於此處我們的邏輯Standby是從物理Standby轉換來的，某些引數並不適合，甚至可能造成錯誤，如LOG_ARCHIVE_DEST_n引數的設定。另一方面，由於邏輯Standby預設是以OPEN READ WRITE模式開啟，有可能存在讀寫操作，因此會讀寫本地Online Redologs併產生Archive Logs，務必需要注意本地的Archive Logs路徑，不要與接收自Primary資料庫的重做日誌檔案路徑衝突。

當然歸根結底是因為邏輯Standby是從物理Standby轉換而來，因此Standby的初始化引數就需要第二次調整（第一次是建立物理Standby）。

修改初始化引數的方式有多種，既可以通過ALTER SYSTEM命令，也可以先生成PFILE並修改相關引數，然後再根據修改過的PFILE生成SPFILE。

6 開啟邏輯Standby及應用REDO資料

由於邏輯Standby與Primary資料庫事務並不一致，其實質相當於進行了不完全恢復，因此第一次開啟時必須指定RESETLOGS子句，如下：

SQL> ALTER DATABASE OPEN RESETLOGS;

在邏輯Standby端啟動SQL應用，可以通過下列語句進行：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

注意：應用REDO資料時必須是在OPEN READ WRITE模式下，這點與物理Standby有明顯的區別。

邏輯Standby也可以像物理Standby那樣啟用實時應用，只需要在啟動REDO應用時附加IMMEDIATE子句即可，如：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

如果想停止邏輯Standby資料庫的SQL應用，則可通過下列命令進行：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY IMMEDIATE;

關於Logical Standby 完成建立例項及主備切換，請參考blog：

Oracle Data Guard Linux 平臺 Logical Standby 建立例項

http://blog.csdn.net/tianlesoftware/archive/2010/05/06/5564179.aspx

三．管理邏輯Standby的相關檢視

1．DBA_LOGSTDBY_EVENTS

可以把該檢視看成邏輯Standby操作日誌，因此如果發生了錯誤，可以通過該檢視檢視近期邏輯Standby都做了些什麼。預設情況下，該檢視只保留最近100條事件的記錄（可以通過相關過程修改儲存的記錄條數）。

例如：

SQL> SELECT EVENT_TIME,STATUS,EVENT FROM DBA_LOGSTDBY_EVENTS

ORDER BY EVENT_TIMESTAMP;

EVENT_TIM STATUS EVENT

--------- -------------------------------------------------- -------------------

05-MAY-10 ORA-16111: log mining and apply setting up

05-MAY-10 ORA-16257: Switchover initiated stop apply success

2．DBA_LOGSTDBY_LOG

該檢視用來記錄當前的重做日誌的應用情況，功能類似於物理Standby中的V$ARCHIVED_LOG。

多數情況下，你只需要關注SEQUENCE#、APPLIED等有限的幾個列，即檢視日誌序號和是否應用，當然該檢視還能提供更多資訊，如應用的SCN、應用時間等，例如：

SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,

TIMESTAMP,APPLIED FROM DBA_LOGSTDBY_LOG;

SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# TIMESTAMP APPLIED

---------- ------------- ------------ --------- --------

110 572160 572171 05-MAY-10 CURRENT

111 572171 572175 05-MAY-10 NO

通常情況下，該查詢只會返回幾條記錄，如果說你的資料庫操作非常頻繁，可能記錄數會稍多一些，但如果記錄數非常多，那你就需要關注一下，是不是出了什麼問題，難道SQL應用沒有啟動？

3．V$LOGSTDBY_STATS

該檢視就是用來顯示LogMiner的狀態等相關資訊，例如：

SQL> SELECT *FROM V$LOGSTDBY_STATS;

NAME VALUE

------------------------------ -------------------------------------------------

number of preparers 1

number of appliers 5

maximum SGA for LCR cache 30

parallel servers in use 9

maximum events recorded 100

preserve commit order TRUE

transaction consistency FULL

record skip errors Y

record skip DDL Y

record applied DDL N

record unsupported operations N

4．V$LOGSTDBY_PROCESS

該檢視顯示當前日誌應用服務的相關資訊。常用於診斷歸檔日誌邏輯應用的效能問題（後面優化部分會涉及），包含的資訊也很廣，包括：

身份資訊：SID、SERIAL#、SPID。

SQL應用程式：COORDINATOR、READER、BUILDER、PREPARER、ANALYZER、或APPLIER。

程式當前的狀態：見STATUS_CODE或STATUS列。

該程式當前操作REDO記錄最大SCN：HIGH_SCN列。

例如：

SQL> SELECT SID,SERIAL#,SPID,TYPE,STATUS,HIGH_SCN FROM V$LOGSTDBY_PROCESS;

SID SERIAL# SPID TYPE STATUS

---------- ---------- ------------ --------------- -----------------------------

139 303 6831 COORDINATOR ORA-16116: no work available

153 292 6833 READER ORA-16240: Waiting for logfil

136 5 6835 BUILDER ORA-16116: no work available

137 5 6837 PREPARER ORA-16116: no work available

128 1 6841 ANALYZER ORA-16116: no work available

132 1 6843 APPLIER ORA-16116: no work available

133 2 6845 APPLIER ORA-16116: no work available

130 1 6847 APPLIER ORA-16116: no work available

129 1 6849 APPLIER ORA-16116: no work available

131 1 6851 APPLIER ORA-16116: no work available

5．V$LOGSTDBY_PROGRESS

該檢視顯示LOG應用服務當前進展狀況，如當前應用到邏輯Standby的SCN及時間，SQL應用開始應用的SCN及時間，最後接收及應用的SCN和時間等。

例如，檢視當前應用的SCN資訊：

SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN

----------- ---------- ---------- -----------

572164 572232 572166

6．V$LOGSTDBY_STATE

該檢視顯示SQL應用的大致狀態，如Primary資料庫的DBID，是否實時應用，當前SQL應用的狀態。需要注意的是該檢視的STATE列，該列可能有下述的幾種狀態。應用日誌的過程，也是這幾種狀態相互轉換的過程。

1) INITIALIZING初始化狀態。

執行ALTER DATABASE START LOGICAL STANDBY APPLY語句，啟動SQL應用時，首先就會進入初始化狀態，例如：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID STATE

---------- ------------------------------

21 INITIALIZING

這個狀態存在的時間非常短暫，多數情況下只有當ALTER DATABASE START LOGICAL STANDBY APPLY執行時檢視V$LOGSTDBY_STATE檢視，會看到初始化狀態，一旦該命令執行完，狀態就被切換為等待字典日誌或應用中的狀態了。

2) WAITING FOR DICTIONARY LOGS等待資料字典日誌。

指第一次初始化時的狀態，如剛從物理Standby轉換成邏輯Standby，需要首先應用來自Primary端生成的資料字典，在等待Primary資料字典資訊時，就會處於這一狀態。例如：

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID STATE

---------- ------------------------------

21 WAITING FOR DICTIONARY LOGS

這個過程也非常短暫。

3) LOADING DICTIONARY載入並分析。

當查詢V$LOGSTDBY_STATE檢視，顯示下列狀態時，說明處於載入資料字典的狀態：

SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;

SESSION_ID STATE

---------- ------------------------------

21 LOADING DICTIONARY

對於比較大型的資料庫系統，載入資料字典需要一些時間。此時還可以查詢V$lOGMNR_DICTIONARY_LOAD檢視獲取關於載入的更詳細的資訊，例如：

SQL>SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD

WHERE SESSION_ID =(SELECT SESSION_ID FROM V$LOGSTDBY_STATE);

APPLYING應用REDO資料。

SQL應用正在處理中，如果要檢視當前的處理進度，可以通過V$LOGSTDBY_PROGRESS檢視完成。

4) WAITING ON GAP中斷等待狀態。

SQL應用挖掘並應用了所有可用的REDO資料，正等待新的日誌檔案，也有可能是由於歸檔檔案有中斷造成的。如果查詢V$LOGSTDBY_STATE檢視時發現處於這一狀態，應該同時查詢V$ARCHIVE_GAP檢視，檢查是否有中斷的歸檔。

5) IDLE空閒狀態。

處於這一狀態也有可能不是好現象，一方面可能是邏輯Standby處理能力優秀，所有活都幹完了；也可能是Primary資料庫傳送日誌或邏輯Standby日誌出現了問題，導致SQL應用無活可幹，因此處於空閒狀態。

如果你發現你的邏輯Standby資料庫長期處於這一狀態，建議查詢DBA_LOGSTDBY_LOG檢視，確認Primary端產生的日誌檔案能被邏輯Standby資料庫正常接收。

6) SQL APPLY NOT ON。

如果你查詢V$LOGSTDBY_STATE檢視時發現提示這一狀態，說明邏輯Standby資料庫根本沒啟動SQL應用。

四．邏輯Standby資料庫的自定義配置

4.1 取消自動刪除歸檔檔案

邏輯Standby應用完歸檔後會自動刪除該歸檔檔案，這一極具體貼意味的特性，是由邏輯Standby中的一項引數控制的，如果希望禁用自動刪除的功能，可以執行下列語句：

SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

PL/SQL procedure successfully completed.

在某些情況下確實需要禁用歸檔檔案的自動刪除功能，如邏輯Standby需要執行Flashback Database操作，如果你想恢復到之前的某個時間點，然後再接著應用，就必須要有該時間點後對應的歸檔，假如LOG_AUTO_DELETE為TRUE的話，應用過的歸檔已經被刪除，想回都回不去。

提示: 如何知道當前邏輯Standby的引數設定呢？Oracle專門提供了一個資料字典DBA_LOGSTDBY_PARAMETERS，用於查詢邏輯Standby當前的引數，例如：

SQL> SELECT * FROM DBA_LOGSTDBY_PARAMETERS;

NAME VALUE

------------------------------ -------------------------------------------------

FIRST_SCN 580428

PREP_DICT_RECEIVED

PRIMARY 3409053734

LMNR_SID 1

GUARD_STANDBY READY

LOG_AUTO_DELETE FALSE

APPLY_SCN 581410

需要注意的是，如果禁止了Standby歸檔檔案的自動刪除功能，一定要有相應的其他解決方案，不能說取消了自動刪除功能，之後邏輯Standby資料庫接收到的Standby歸檔檔案就不再管它，這肯定會產生問題，最起碼要考慮到邏輯Standby資料庫的儲存空間是有限的。

邏輯Standby資料庫接收到的歸檔檔案並不會顯示在V$ARCHIVED_LOG檢視中，因此以為通過RMAN中的配置自動刪除這些檔案的希望也是會落空的。對於這類檔案的刪除，正確的刪除方法通常會按照如下步驟操作：

首先執行DBMS_LOGSTDBY.PURGE_SESSION，該過程會檢查當前所有接收到的歸檔日誌檔案，對於那些已經應用過，不再需要的檔案進行標記，例如：

SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

PL/SQL procedure successfully completed.

然後，查詢資料字典DBA_LOGMNR_PURGED_LOG，所有被DBMS_LOGSTDBY. PURGE_SESSION標記不再需要的日誌都會記錄在這裡，例如：

SQL>SELECT * FROM DBA_LOGMNR_PURGED_LOG;

FILE_NAME

-------------------------------------------------

/U01/STD/ARC00109_0680477835.001

該字典只有一列，即歸檔檔案的實際路徑。最後根據顯示的路徑找到這些檔案，然後在作業系統中刪除即可。

4.2 啟動實時應用

在預設情況下，邏輯Standby會等待單個歸檔檔案全部接收之後再啟動REDO應用，如果Standby資料庫配置了Standby Redologs，就可以開啟實時應用（Real-Time Apply），這樣邏輯Standby端就不再需要等待接收完歸檔檔案，只要有REDO資料寫入本地的Standby Redologs，即可通過相應的程式實時寫向邏輯Standby資料庫。

啟動邏輯Standby資料庫的實時應用非常簡單，只需要在邏輯Standby啟動SQL應用時加上IMMEDIATE子句即可，例如：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

4.3 定義DBA_LOGSTDBY_EVENTS記錄的事件

要檢視邏輯Standby執行REDO應用時的操作資訊，一般有兩種方式：

一種是檢視Oracle資料庫的警告日誌檔案Alert（當然該檔案不僅僅包括REDO應用的資訊），

另一種是直接查詢資料字典DBA_LOGSTDBY_EVENTS。

如果只是想檢視日誌應用資訊的話，資料字典DBA_LOGSTDBY_EVENTS實用性更高，畢竟術業有專攻嘛。不過預設情況下該字典中只保留最近的100條訊息（可以通過V$LOGSTDBY_STATS檢視檢視保留的記錄數），這個數量過於偏小，如果要修改該字典中記錄的事件數量，也是通過DBMS_LOGSTDBY.APPLY_SET過程完成。例如，設定該字典保留最近999條事件，執行語句如下：

JSSLDG> EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED','999');

PL/SQL procedure successfully completed.

注意: 執行DBMS_LOGSTDBY.APPLY_SET過程時，REDO應用必須處於停止狀態。

SQL> alter database stop logical standby apply;

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

另外，還可以通過DBMS_LOGSTDBY.APPLY_SET過程設定是否記錄DDL應用的事件，例如：

SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL','TRUE');

PL/SQL procedure successfully completed.

注：該過程同樣要停REDO.

然後啟動REDO應用，檢視當前的最大儲存記錄數及是否記錄DDL應用的事件：

SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

SQL> select * from v$logstdby_stats where name in ('maximum events recorded','record applied DDL');

NAME VALUE

------------------------------ -------------------------------------------------

maximum events recorded 999

record applied DDL N

五．修改邏輯Standby端資料

相對物理Standby，邏輯Standby的管理要複雜一點點。這個就是管理一個半資料庫和管理兩個資料庫的差異（假設Data Guard環境為一主一備的情況下），畢竟邏輯Standby只是邏輯上，彷彿與Primary資料庫一致，其實它是一個獨立執行的，甚至可能與Primary資料庫完全不同的資料庫系統，對於這種配置環境，管理上多花點工夫想想也是應該的。

5.1 指定物件跳過應用

在預設情況下，接收自Primary的REDO資料中，所有能夠被邏輯Standby資料庫支援的操作都會在邏輯Standby端執行。如果你希望跳過對某些物件的某些操作的話，DBMS_LOGSTDBY.SKIP就能派上用場了。

先來看看DBMS_LOGSTDBY.SKIP的語法：

DBMS_LOGSTDBY.SKIP (

stmt IN VARCHAR2,

schema_name IN VARCHAR2 DEFAULT NULL,

object_name IN VARCHAR2 DEFAULT NULL,

proc_name IN VARCHAR2 DEFAULT NULL,

use_like IN BOOLEAN DEFAULT TRUE,

esc IN CHAR1 DEFAULT NULL);

除stmt外，其他都是可選引數，並且看字面意義就能明白其所指。例如，你想跳過SCOTT使用者下對dept表的DML操作，可以通過執行下列語句實現（執行該過程前需要先停止REDO應用）：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

SQL> EXEC DBMS_LOGSTDBY.SKIP('DML', 'SCOTT', 'DEPT');

PL/SQL procedure successfully completed.

SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

5.2 恢復物件同步

如果邏輯Standby中的某些表取消了與Primary的同步維護，現在希望再恢復同步，沒問題，DBMS_LOGSTDBY家大業大，它還有個叫UNSKIP的門生專幹這個。

我們來看一下DBMS_LOGSTDBY.UNSKIP的語法：

DBMS_LOGSTDBY.UNSKIP (

stmt IN VARCHAR2,

schema_name IN VARCHAR2,

object_name IN VARCHAR2);

三項均為必選引數，各引數的定義與SKIP過程相同。

下面演示恢復tmp1表的同步。

首先檢視當前邏輯Standby都有哪些物件處於不同步狀態，可以通過DBA_LOGSTDBY_SKIP檢視檢視，例如：

SQL> select * from dba_logstdby_skip;

ERROR STATEMENT_OPT OWNER NAME U E PROC

----- ------------------------------ ---------- ----- - - ----------

N DML SCOTT DEPT Y

N INTERNAL SCHEMA SYSTEM % Y

N INTERNAL SCHEMA SYS % Y

N INTERNAL SCHEMA OLAPSYS % Y

N INTERNAL SCHEMA SI_INFORMT % Y

N INTERNAL SCHEMA MGMT_VIEW % Y

N INTERNAL SCHEMA ORDPLUGINS % Y

N INTERNAL SCHEMA XDB % Y

N INTERNAL SCHEMA SYSMAN % Y

N INTERNAL SCHEMA WMSYS % Y

N INTERNAL SCHEMA DBSNMP % Y

注意在執行DBMS_LOGSTDBY.UNSKIP過程前，要停止當前的SQL應用狀態：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

執行DBMS_LOGSTDBY.UNSKIP過程，恢復前面停止的scott.tmp1表的應用：

SQL> execute dbms_logstdby.unskip('DML', 'SCOTT', 'dept');

PL/SQL procedure successfully completed.

5.3 新增或重建物件

指定物件跳過應用雖然被取消，但是有可能在此期間由於Primary資料庫做過資料修改，兩端此時已經不同步，如果Standby端繼續應用極有可能導致應用錯誤的資料。

對於這類情況，Oracle也早有預見，DBMS_LOGSTDBY包中還有一個過程叫INSTANTIATE_TABLE，專門用來同步一下跳過的物件，以保持與Primary資料庫的一致。

DBMS_LOGSTDBY.INSTANTIATE_TABLE的呼叫語法如下：

DBMS_LOGSTDBY.INSTANTIATE_TABLE (

schema_name IN VARCHAR2,

table_name IN VARCHAR2,

dblink IN VARCHAR2);

除了SCHEMA名稱和表名稱外，還需要提供一個資料庫鏈，因此這裡我們首先在邏輯Standby端建立一個連線Primary資料庫的資料庫鏈：

SQL> CREATE DATABASE LINK PRE_TBL_DATA CONNECT TO SYSTEM IDENTIFIED BY ADMIN

USING 'ORCL_PD';

Database link created.

執行使用DBMS_LOGSTDBY.INSTANTIATE_TABLE過程，重新同步SCOTT.TMP1表（注意執行該過程前別忘了暫停當前的SQL應用）：

SQL>EXEC DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT', 'DEPT', 'PRE_TBL_DATA');

PL/SQL procedure successfully completed.

SQL> SELECT * FROM SCOTT.DEPT;

物件已被重建，然後重新啟動SQL應用即可：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

5.4 邏輯Standby端修改資料

邏輯Standby的一個極具實用價值的特性就是可以邊查詢邊應用，因此將其作為報表伺服器專供查詢是個很不錯的想法，而且邏輯Standby相對於物理Standby而言更具靈活性，如我們可以在邏輯Standby上，對一些表建立Primary資料庫並不方便建立的索引、約束，甚至可以做DML/DDL操作（當然，需要注意不要破壞了與Primary資料庫之間同步的邏輯關係）。

不過由於此時Data Guard仍然控制著對邏輯Standby資料庫中表的讀寫操作，因此，如果你想對邏輯Standby中的資料做些什麼的話，ALTER SESSION DISABLE|ENABLE GUARD語句就必須牢記在心了，它擁有像"芝麻開門"一樣神奇的能力。下面我們就來感受一下吧。

在邏輯Standby端啟動SQL應用的情況下，執行DDL操作：

SQL> GRANT DBA TO SCOTT;

Grant succeeded.

SQL> CONN SCOTT/TIGER;

Connected.

SQL> CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS;

CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS

*

ERROR at line 1:

ORA-01031: insufficient privileges

出錯了，提示許可權不足，實際上SCOTT被授予了DBA角色，肯定擁有CREATE TABLE許可權的，因此此處與使用者的許可權無關，而是有其他因素制約了SCOTT無法進行修改。

下面禁用Data Guard保護之後，再次嘗試運算元據：

SQL> ALTER SESSION DISABLE GUARD;

Session altered.

SQL> CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS;

Table created.

這下可以了，這就是Data Guard的作用。

注意：資料修改完之後，別忘了再次啟用Data Guard，以避免不經意的誤操作對邏輯Standby的配置造成影響（你說不手動啟用Data Guard保護，直接退出行不行，當然也可以，ALTER SESSION所做修改僅對當前會話有效，退出重新登入，原會話設定自然就失效了）。

SQL> ALTER SESSION ENABLE GUARD;

Session altered.

按照Oracle的建議，還是儘可能不要在邏輯Standby端執行DML之類操作，以免破解其與Primary之間同步的邏輯關係，

也可以通過下列語句檢視當前資料庫是否處於Data Guard保護狀態：

SQL> SELECT GUARD_STATUS FROM V$DATABASE;

GUARD_S

-------

ALL

該引數對應三個值：

ALL：表示對資料庫中所有物件啟動修改保護，除SYS使用者外，其他使用者均不能直接修改資料。

STANDBY：表示對處於邏輯Standby維護關係的物件啟動修改保護，除SYS使用者外，其他使用者均不能直接修改資料。

NONE：不啟動資料保護。

如果要永久設定資料庫的Data Guard保護模式，則是通過ALTER DATABASE命令來完成，可指定的值也正是上述的三種，例如：

SQL> ALTER DATABASE GUARD STANDBY;

Database altered.

執行完上述語句後，Data Guard僅對處於邏輯Standby維護關係的物件進行防止修改操作的保護。

考慮到邏輯Standby中也有可能對資料進行修改（正如上例演示），因此這裡引申談一談在邏輯Standby資料庫中，約束和觸發器的執行模式。預設情況下，約束和觸發器都能在邏輯Standby端正常執行。約束和觸發器在邏輯Standby端的執行可以分成兩種情況：

對於SQL應用維護的約束和觸發器，由於在Primary資料庫已經檢查過約束，因此Standby端不需要再次檢查；觸發器的情況也是這樣，Primary端操作時結果已經被記錄，因此邏輯Standby端將直接被應用，而不會二次觸發。

對於沒有SQL應用維護的約束和觸發器，其執行情況與普通的Oracle資料庫環境相同。

5.5 重定義REDO應用執行的操作

對於邏輯Standby資料庫，你甚至可以通過編寫自定義的PROCEDURE，來重新定義SQL應用時執行的操作。

如邏輯Standby資料庫的檔案路徑與Primary資料庫路徑不同，如果是物理Standby，可以通過*_FILE_NAME_CONVERT之類的引數處理，在邏輯Standby環境中這幾個引數無效，應該如何處理呢？答案就是通過編寫自定義的過程，修改SQL應用時執行的操作。

下面通過示例，演示通過編寫自定義的PROCEDURE，修改建立表空間時邏輯Standby端資料檔案的路徑。

首先當然是建立一個過程，建議建立在SYS下，因為在這個使用者下的操作肯定不會有同步的問題，如下所示：

SQL> CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (

2 OLD_STMT IN VARCHAR2,

3 STMT_TYP IN VARCHAR2,

4 SCHEMA IN VARCHAR2,

5 NAME IN VARCHAR2,

6 XIDUSN IN NUMBER,

7 XIDSLT IN NUMBER,

8 XIDSQN IN NUMBER,

9 ACTION OUT NUMBER,

10 NEW_STMT OUT VARCHAR2

11 ) AS

12 BEGIN

13

14 NEW_STMT := REPLACE(OLD_STMT, '/u01/oradata/orcl_pd/', '/u01/oradata/orcl_st');

15 ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;

16

17 EXCEPTION

18 WHEN OTHERS THEN

19 ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;

20 NEW_STMT := NULL;

21 END HANDLE_TBS_DDL;

22 /

Procedure created.

邏輯非常簡單，基本上就是一個REPLACE，不過PROCEDURE中宣告的變數看起來很多，這個是固定格式，不建議修改。

停止邏輯Standby的SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

如果不停，PROCEDURE不能生效。

執行DBMS_LOGSTDBY.SKIP過程，將編寫的過程註冊到表空間處理的SQL應用中：

SQL> EXEC DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE',proc_name => 'sys.handle_tbs_ddl');

PL/SQL procedure successfully completed.

這裡也要藉助DBMS_LOGSTDBY.SKIP過程實現。該過程功能非常強大，而且操作非常靈活。

重啟SQL應用：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

測試一下，在Primary端建立一個新的表空間：

SQL> CREATE TABLESPACE BOOKS DATAFILE '/u01/oradata/orcl_pd/books01.dbf' SIZE 20m;

Tablespace created.

SQL> SELECT FILE_NAME FROM DBA_DATA_FILES WHERE TABLESPACE_NAME='BOOKS';

FILE_NAME

-----------------------------------------------------------------------------

/u01/oradata/orcl_pd/books01.dbf

轉向邏輯Standby資料庫檢視：

SQL> SELECT FILE_NAME FROM DBA_DATA_FILES WHERE TABLESPACE_NAME='BOOKS';

FILE_NAME

----------------------------------------------------------------------------

/u01/oradata/orcl_st/books01.dbf

表空間成功建立，並且資料檔案路徑也被轉換為我們指定的路徑。

此時如果你檢視Alert日誌檔案，會發現其中記錄下了類似這樣的資訊：

LOGSTDBY stmt: create tablespace books datafile '/u01/oradata/orcl_pd/books01.dbf' size 20m

LOGSTDBY status: ORA-16110: 邏輯備用應用 DDL 的使用者過程處理

LOGSTDBY id: XID 0x0001.009.000000d1, hSCN 0x0000.0012ec41,

lSCN 0x0000.0012ec41, Thread 1, RBA 0x007f.0000079a.80,

txnCscn 0x0000.0012ec43, PID 5816, ORACLE.EXE (P004)

LOGSTDBY stmt: create tablespace books datafile '/u01/oradata/orcl_st/books01.dbf' size 20m

LOGSTDBY status: ORA-16202: 跳過過程已請求替換語句

LOGSTDBY id: XID 0x0001.009.000000d1, hSCN 0x0000.0012ec41,

lSCN 0x0000.0012ec41, Thread 1, RBA 0x007f.0000079a.80,

txnCscn 0x0000.0012ec43, PID 5816, ORACLE.EXE (P004)

create tablespace books datafile '/u01/oradata/orcl_st/books01.dbf' size 20m

Completed: create tablespace books datafile '/u01/oradata/orcl_st/books01.dbf' size 20m

LOGSTDBY stmt: create tablespace books datafile '/u01/oradata/orcl_st/books01.dbf' size 20m

LOGSTDBY status: ORA-16204: 成功應用了 DDL

六．優化邏輯Standby資料同步效能

6.1 調整APPLIER程式數

APPLIER程式就是執行應用操作的程式。在預設情況下邏輯Standby會啟動5個APPLIER程式，如果日誌應用任務繁重（或者說Primary資料庫修改量較大），則適當多啟動幾個APPLIER程式有助於提高應用的效率。

先檢視當前空閒的APPLIER程式數：

SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166;

IDLE_APPLIER

------------

0

返回結果為0，難道都在忙？這個真不一定，空閒的APPLIER程式數為0不一定代表應用非常繁忙，也有可能是因為當前沒什麼需要應用的日誌，甚至都沒啟動應用程式。

說明： status_code=16166表示程式是空閒狀態，因為stats_code=16166對應的狀態說明列STATS為ORA-16116: no work available。

檢查事務的應用情況：

SQL> SELECT NAME,VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%';

NAME VALUE

----- ---------------------------

trans 358

如果ready-applied的值比APPLIER程式數的兩倍還要大，則說明DBA有必要考慮增加APPLIER程式的數目了，反之如果applied與ready的值差不多大，或者其差比APPLIER程式數還小，則說明APPLIER程式數偏多，DBA有必要考慮適當減小程式的數目。

如果確認當前APPLIER程式都非常繁忙，要增加APPLIER程式，可按如下步驟操作：

1）停止邏輯Standby端的SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

2) 執行下列語句，調整APPLIER程式數為10：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',10);

PL/SQL procedure successfully completed.

3）重新啟動SQL應用：

JSSLDG> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

４) 查出的就是當前執行的APPLIER程式數：

SQL> SELECT COUNT(0) FROM V$LOGSTDBY_PROCESS WHERE TYPE='APPLIER';

COUNT(0)

----------

10

也可以通過V$LOGSTDBY_STATS檢視查詢，例如：

SQL> SELECT * FROM V$LOGSTDBY_STATS WHERE NAME='number of appliers';

NAME VALUE

----- ----------------------------------------------------------------

numbe 10

6.2 調整PREPARER程式數

PREPAPER程式將接收到的REDO資料中的塊修改轉換成LCRs（Logical Change Records）。一般需要調整PREPAPER程式數的機會不多，通常只有一種情況：APPLIER程式有空閒，Transactions Ready還很多，但沒有空閒的PREPAPER程式，這時候DBA可能就需要增加一些PREPAPER程式。

先檢查空閒PREPAPER程式數量：

SQL> SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS

WHERE TYPE = 'PREPARER' and status_code = 16166;

IDLE_PREPARER

-------------

0

說明：如果顯示為0，別怕，也有可能是因為當前沒什麼新的REDO資料需要處理。

如果確實需要調整PREPAPER程式數量，可以按照下列步驟進行。

首先停止SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

調整PREPAPER程式數量為4（預設只有1個PREPAPER程式）：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS',4);

PL/SQL procedure successfully completed.

重新啟動SQL應用即可：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

查看當前啟動的PREPAPER程式數, 查詢V$LOGSTDBY_STATS檢視，例如：

SQL> SELECT * FROM V$LOGSTDBY_STATS WHERE NAME='number of preparers';

NAME VALUE

----- ----------------------------------------------------------------

numbe 4

6.3 調整LCR使用的記憶體

LCR中儲存的是轉換後的塊修改的記錄，這部分資料儲存在SGA中.

查詢當前LCR可用的最大記憶體：

SQL> SELECT * FROM V$LOGSTDBY_STATS WHERE NAME='maximum SGA for LCR cache';

NAME VALUE

------------------------------------ --------------------

maximum SGA for LCR cache 30

顯示的引數值預設單位為M，當前結果顯示LCR記憶體區可用空間為30M。

要增加LCR可用的記憶體，可按照下列步驟操作。

1) 首先還是需要停止SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Database altered.

2) 調整記憶體大小為100M：

SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_SGA',100);

PL/SQL procedure successfully completed.

3）最後重啟SQL應用即可

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

6.4 調整事務應用方式

在預設情況下邏輯Standby端事務應用順序與Primary資料庫提交順序相同。如果DBA希望邏輯Standby端事務應用不按照Primary資料庫順序執行的話，可以按照下列步驟操作：

1）停止SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2）允許事務不按照Primary的提交順序應用：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');

3）重新啟動SQL應用：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

恢復邏輯Standby按照事務提交順序應用的話，可按照下列步驟操作：

1）先停止SQL應用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

2）重置引數PRESERVE_COMMIT_ORDER的初始值：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

3）重新啟動SQL應用：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

七．應用REDO資料到Standby資料庫

1．物理Standby應用REDO資料

物理Standby啟動REDO應用，資料庫要處於MOUNT狀態或是OPEN READ ONLY狀態，啟動REDO應用的命令相信大家已經非常熟悉了。

前臺應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

語句執行完成後，不會將控制權返回到命令列視窗，除非你手動中止應用。在這種情況下如果還需要對資料庫進行操作，只能新開一個命令列連線，在Oracle 8i剛推出Standby特性時（那時不叫Data Guard），只提供了這種方式。

後臺應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

這是現在比較通用的方式，語句執行完後，控制權自動返回到當前的命令列模式，REDO應用以後臺程式執行。

啟動實時應用，附加USING CURRENT LOGFILE子句即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

如果要停止REDO應用，執行下列語句即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2．邏輯Standby應用REDO資料

SQL應用的原理是將接收到的REDO資料轉換成SQL語句在邏輯Standby資料庫端執行，因此邏輯Standby需要啟動至OPEN狀態。

（1）啟動SQL應用。邏輯Standby資料庫啟動SQL應用沒有前、後臺執行之說，語句執行完之後，控制權就會自動返回當前命令列視窗。要啟動SQL應用，直接執行下列語句即可：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

如果要啟動實時應用，附加IMMEDIATE子句即可，例如：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

（2）停止SQL應用，如：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

由於是執行SQL語句的方式應用REDO資料，因此上述語句的執行需要等待當前執行的SQL觸發的事務結束，才能真正停止REDO應用的狀態。

如果不考慮事務執行情況，馬上停止REDO應用，可以通過下列的語句來完成：

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15880878/viewspace-720076/，如需轉載，請註明出處，否則將追究法律責任。

Oracle Data Gurad -- Logical Standby 相關說明

相關文章