oracle11g dataguard 完全手冊

一、前言：
   網絡上關于dataguard的配置文章很多，但是很多打著oracle11g的文章實際都是只能在9 10 上運行，比如FAL_CLIENT在11g中已經廢棄，但是現在網絡上的文章都是沒有標注這一點。而且對于具體含義語焉不詳對于新手只能知其然而不知其所以然。這篇文章我就想讓像我這樣的人對于dataguard配置不僅僅知道怎么配置，還要知道為什么需要這樣配置，這樣的效果才是最好的。
  這篇文章不僅僅是記錄如何配置，還介紹了為什么是這樣，以及注意要點，我希望這個文章可以作為進行dataguard配置的一個參考手冊。

二、前提
1.主庫是歸檔模式：
  如果我們不清楚為什么是歸檔模式，那我們就應該也不會清楚dataguard是用來做什么的。透過很多修飾的官方語言，我們需要明確DG（dataguard簡稱，后同）實際上的作用就是用來高可用。而實現原理就是從主庫獲取數據到從庫，在主庫發生異常的時候，從庫接管主庫，完成身份的變化。可以一個主庫，最多9個從庫。同時分為邏輯standby和物理standby這里我們討論的是物理standby.
   一旦創建并配置成 standby 后，dg 負責傳輸 primary數據庫 redo data 到 standby 數據庫，standby 數據庫通過應用接收到的 redo data 保持與 primary 數據庫的事務一致。
   這下清楚了吧，需要保證主從庫一致，需要傳輸archive log和redo log到從庫，如果不是歸檔模式無法保證主從庫的數據一致。

2.從庫只需要安裝數據庫軟件，數據從主庫傳輸后完成。

3.很多人說11g有了active dataguard(ADG)，邏輯standby 實際上已經沒什么用處了。

4.主從庫硬件最好一致。oracle數據庫版本需要一致。
  (1)內存檢查項：
     # grep MemTotal /proc/meminfo
     交換分區檢查項：如果內存在1-2G,swap是1.5倍；2-16G,1倍；超過16G，設置為16G即可。
     # grep SwapTotal /proc/meminfo
     查看共享內存大小：
     # df -h /dev/shm

   (2)查看系統處理器架構，與oracle安裝包一致
     # uname -m

   (3)空間空間 /tmp必須大于1G
     # df -h /tmp

5.配置環境數據庫用戶必須有sysdba權限
6.后面的環境：主庫 192.168.215.101 數據庫實例名：orcl        db_unique_name:orcl
              從庫 192.168.215.102 數據庫實例名：orcl       db_unique_name:orcldg

三、配置
1.判斷DG是否已經安裝：
  select * from v$option where parameter = 'Oracle Data Guard';
  如果是true表示已經安裝可以配置，否則需要安裝相應組件。

2.設置主庫為強制記錄日志。
  默認情況下數據庫操作會記錄redo log，但是在一些特定的情況下可以使用nologging來不生成redo信息
  (1)表的批量INSERT（通過/*+APPEND */提示使用“直接路徑插入“。或采用SQL*Loader直接路徑加載）。表數據不生成redo，但是
所有索引修改會生成redo，但是所有索引修改會生成redo（盡管表不生成日志，但這個表上的索引卻會生成redo！）。
  (2)LOB操作（對大對象的更新不必生成日志）。
  (3)通過CREATE TABLE AS SELECT創建表
  (4)各種ALTER TABLE操作，如MOVE和SPLIT
  (5)在一些表遷移和表空間遷移中，可以使用alter table a nologging;或者alter tablespace snk nologging;在操作完成后再修改回logging狀態。
  這里需要多說一句，如果你使用nologging導入大批量數據，以后對這些數據的修改會在redo或者archive log中，但是基準的數據是沒有的，所以一旦介質損壞是無法完全恢復的，必須在使用nologging完成切換回logging后，做一次全備或者0級備份。

   (1)強制記錄日志：sql>alter database force logging;
   (2)檢查狀態(YEs為強制)：sql>select name,force_logging from v$database;
   (3)如果需要在主庫添加或者刪除數據文件時，這些文件也會在備份添加或刪除，使用如下：
      sql>alter system set standy_file_management='AUTO';
      默認此參數是manual手工方式 sql>show parameter standby
 
 3.創建standby log files(備用日志文件）
   從庫使用standby log files來保存從主庫接收到的重做日志。既然主要是從庫在使用，那為什么需要在主庫上也建立
   standby log files?原因主要由兩個：一是主庫可能轉換為備庫，而備庫是需要有standby log files的 二是如果主庫
   建立了standby log files那備庫會自動建立。
   建立standby如要注意以下幾點：
   <1>standby log files的大小和redo log files一樣。
      查詢redo log files文件大小（默認50M,3個）：select group#,bytes/1024/1024 as M from v$log
   <2>一般而言， standbyredo 日志文件組數要比 primary 數據庫的 online redo 日志文件組數至少多一個。
      推薦 standbyredo 日志組數量基于 primary 數據庫的線程數(這里的線程數可以理解為 rac 結構中的 rac
      節點數)。
      有一個推薦的公式可以做參考：(每線程的日志組數+1)*最大線程數
      假設現在節點是1個，則=(3+1)*1=4
      如果是雙節點       則=(3+1)*2=8
      這里我們創建4個standby logfile:
      另：不建議組號group#緊挨著redo，因為后續redo有可能調整，這里我們從建立從11到14的standby logfile
     

?

   4.密碼文件和控制文件的創建傳輸
     (1)一般數據庫默認就有密碼文件，存放在$ORACLE_HOME/dbs/orapwSID  這里為orapworcl
        如果沒有sql>orapwd file=$ORACLE_HOME/dbs/orapworcl password=oracle
     (2)檢查REMOTE_LOGIN_PASSWORDFILE值是否為 EXCLUSIVE
        sql>show parameter REMOTE_LOGIN_PASSWORDFILE
 如果值不是EXCLUSIVE，則：alter system set remote_login_passwordfile=exclusive scope=spfile;
     (3)密碼文件需要scp到從庫
        # scp orapworcl oracle@192.168.215.102:/opt/oracle/11.2/dbs 提示輸入yes
     (4)控制文件：
        11g的控制文件一共兩份，內容一樣，一份在$ORACLE_BASE/oradata/orcl/control01.ctl
 一份在/opt/oracle/flash_recovery_area/orcl/control02.ctl

 生成standby控制文件：

?

 
 然后在備庫建立對應的目錄,并授權
 mkdir orcl--- chown oracle:oinstall(或dba) orcl

?

     
    5.db_name和db_unique_name
      默認db_name和db_unique_name和實例名是一致的，這里是orcl
      需要注意在DG中主庫和從庫的db_unique_name是不能一致的，需要區分開的。
      這里我們設置主庫的db_unique_name為orcl，從庫為orcldg
      sql>show parameter db_unique_name
      設置：alter system set db_unique_name=orcl scope=spfile;
      --注意雖然默認db_unique_name和db_name是一致的，但是需要顯式設置，否則在spfile中沒有此參數
    
    6.閃回數據庫：
      強烈建議開啟數據庫閃回功能。閃回允許你將數據庫還原到以前的某一時間點。當發生故障轉移時，這個功能非常有用，
      它能讓你將老的主庫閃回到故障前，然后將其轉換為備庫。如果沒有啟用閃回功能，你就必須重建備庫，意味著要再復制一次數據文件。
      除了這個好處，閃回還能在某些情況下讓你避免從備份恢復數據。

      (1)快速恢復區(Flash/Fast Recovery Area)，默認是配置的,但是需要確認這個區域的磁盤夠大，至少300G以上（默認3G）
       sql>show parameter db_recovery_file_dest
       可以修改位置：sql>alter system set db_recovery_file_dest='新路徑';
       更改大小：sql>alter system set db_recovery_file_dest_size=400G;

      (2)查看是否啟用，默認是不開啟的
       sql>select flashback_on from v$database;
       開啟：sql>alter database flashback on;
       如果你碰到 ORA-01153 報錯，那一定是在備庫進行此操作。你需要先取消重做日志應用，啟用閃回日志，然后重新啟用日志應用。
       在主庫啟用閃回日志，不會同步備庫也啟用。你必須手動在主庫和備庫上均啟用閃回日志。
       如果不啟用閃回日志，當出現故障轉移時，你將需要完全重新開始創建一個備庫。

    7.SQL*NET設置
      (1)配置主庫的監聽
         雖然可以通過netca來進行配置，但是除了這個默認的外，我們還需要一個靜態注冊SID_LIST_LISTENER，如果沒有此從參數而且
  dataguard啟動順序不正確，主庫會報PING[ARC1]:Heartbeat failed to connect to standby '***'.Error is 12514導致歸檔無法完成
  配置如下
 

?

#vi $ORACLE_HOME/network/admin/listener.ora 加入上面的內容

       （2）配置tnsnames
        #vi $ORACLE_HOME/network/admin/tnsnames.ora

?

     
    （3）傳輸到備庫并修改listener.ora和tnsnames.ora
  

scp $ORACLE_HOME/network/admin/listener.ora oracle@192.168.215.102:/opt/oracle/11.2/network/admin/
scp $ORACLE_HOME/network/admin/tnsnames.ora oracle@192.168.215.102:/opt/oracle/11.2/network/admin/
          
--listener.ora:
          SID_LIST_LISTENER
   (SID_LIST =
     (SID_DESC =
        (GLOBAL_DBNAME = orcldg)
        (ORACLE_HOME = /opt/oracle/11.2)
        (SID_NAME = orcl)
      )
    )


 LISTENER =
   (DESCRIPTION_LIST =
     (DESCRIPTION =
       (ADDRESS = (PROTOCOL = TCP)(HOST = standbyDB)(PORT = 1521))
     )
   )

   tnsnames.ora:不需要修改

       8.重做日志傳輸配置
         (1)配置歸檔日志位置：
  查詢已經設置的歸檔路徑sql:archive log list或者show parameter log_archive_dest_1

?

 
     還可以使用快速恢復區作為歸檔目錄，如LOCATION=use_db_recovery_file_dest
     官方文檔里說使用 valid_for=(online_logfiles, all_roles)，這將導致備庫無法歸檔備用日志文件，因為它們不是在線日志。
     但如果使用 all_logfiles 選項，主備庫將都能歸檔在線以及備用日志。
     如果你想在備庫進行備份，并同時備份歸檔日志的話，必須使用 all_logfiles。
   
         (2)配置重做日志到備份庫：

?

   
  (3)要注意STANDBY_ARCHIVE_DEST 參數不需要，已經被官方棄用。設置此參數后啟動數據庫，只會報 ORA-32004:
     obsolete or deprecated parameter(s) specified for RDBMS instance 錯。

  9.配置FAL_SERVER
    這個參數指定當日志傳輸出現問題時，備庫到哪里去找缺少的歸檔日志。它用在備庫接收的到的重做日志間有缺口的時候。
    這種情況會發生在日志傳輸出現中斷時，比如你需要對備庫進行維護操作。在備庫維護期間，沒有日志傳輸過來，這時缺口就出現了。
    設置了這個參數，備庫就會主動去尋找那些缺少的日志，并要求主庫進行傳輸。
    你是主庫,就填寫:
      fal_server=從庫
    從庫上就反過來:
       fal_server=主庫
           注意:FAL_CLIENT在11g中已經廢棄，雖然可以配置但是已經不起作用了。

    sql>alter system set FAL_SERVER='orcldg';

   10.Data Guard 配置里的另外一個庫的名字
     sql> alter system set log_archive_config = 'dg_config=(orcl,orcldg)';

   以上的辦法是我們采用alter system的方式在線修改，還有一種比較方便的辦法（但是容易出錯，所以方便和安全什么時候都不可兼得）
   sql>create pfile from spfile;
   # 手工修改pfile
   sql>create spfile from pfile;
   然后用pfile生成spfile 同時傳輸pfile到從庫修改后生成spfile
   注意手工增加：
   *.log_archive_dest_state_1=enable
   *.log_archive_dest_state_2=enable
  
vi initorcl.ora

?

 scp initorcl.ora oracle@192.168.215.102:/opt/oracle/11.2/dbs/
    修改備庫的initorcl.ora 修改參數如下：

?

  
    然后sql>create spfile from pfile;
  
11.傳輸主庫數據到備庫
        （1）scp -l 8192 -rp /opt/oracle/oradata/orcl/ oracle@192.168.215.102:/opt/oracle/oradata/
            注意目的地不要加orcl 會自動創建目錄的
            -l是limit限制，這樣最大是8192/8=1M速度，是為了解決stalled問題
            -rp 循環子目錄文件
        （2）建立spfile中需要的目錄
       如/opt/oracle/admin/orcl/adump dpdump pfile

 12.啟用物理備用數據庫
       sql>startup nomount
       sql>alter database mount standby database;
       (1)啟動 redo 應用
  SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
  啟動實時應用
  SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
          這個命令指示備庫開始使用備用日志文件進行恢復。它也告訴備庫命令完成后回到命令行界面

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   此時只是暫時 redo 應用，并不是停止 Standby 數據庫，standby 仍會保持接收只不過不會再應用
                 接收到的歸檔，直到你再次啟動 redo 應用為止

        (2)停止standby
           正常情況下，首先
     SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    然后再sql>shutdown immediate
    當然也可以直接shutdown immediate

        (3)備用服務器的管理模式與只讀模式
    <1>.啟動到管理模式

?

    <2>.啟動到只讀方式    

?

     <3>如果在管理恢復模式下到只讀模式

?

      這個時候，可以給數據庫增加臨時數據文件（這個在熱備份的時候是沒有備份過來的）
      如alter tablespace temp add tempfile '/u02/oradata/test/temp01.dbf' size 100M;

     <4>.從只讀方式到管理恢復方式
     SQL> recover managed standby database disconnect from session;

         (4)應用物理備庫的幾點監控
      如果上面出了問題或者我們不知道成功了沒有，可以用下面的方法檢測

     <1>確認主備庫里的歸檔目的地配置都是有效的
        select DEST_ID, STATUS, DESTINATION, ERROR from V$ARCHIVE_DEST where DEST_ID<=2;
        目的地狀態status應該顯示為 VALID，注意如果上面沒有執行redo應用會有一條error信息

     <2>確認重做日志是否真的被應用了，在主庫執行
        select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG where name = 'JED2' order by FIRST_TIME;
        如果歸檔和日志應用均正常，APPLIED 和 ARCHIVED 列都應該是 YES。(如果沒有應用redo，applied應該是NO)
        很多教程里都讓這個查詢以 SEQUENCE# 列排序，但我不推薦。如果以 SEQUENCE# 列排序，當你做了一次故障轉移后，序列號會再從1開始，
        這時使用這個查詢，你將不能在結果最后看到最新的記錄。我曾經很奇怪為什么查不到新記錄，其實是因為新記錄不是出現在最后，
        我沒看到。所以，這個查詢都是以 FIRST_TIME 列排序.

     <3>主庫上檢查是否有重做日志缺口
        如果你發現日志沒有被應用，那可能是重做日志有了缺口，這種情況下備庫無法進行日志應用。但如果你的 FAL_SERVER 參數設置正確，這應該不會有問題
        select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;
        如果一切正常，應該返回 VALID 和 NO GAP .切記啟用redo應用才能顯示No GAP

     <4>在主備庫上執行以下查詢查看數據庫狀態
         select * from V$DATAGUARD_STATUS order by TIMESTAMP;

     <5>檢查是否成功：
        主庫上查看日志傳送情況：
        sql>select dest_name,status,error from v$archive_dest;
        應該log_archive_dest_1和2狀態應該是valid
        切換幾次日志：
        sql>alter system switch logfile;
                      查看日志序號：
        sql>select sequence# from v$archived_log;
                      備庫驗證：
        sql>select sequence#,applied from v$archived_log;

    13.dataguard啟動關閉順序
       (1)監聽
          先啟從庫再起主庫
   #lsnrctl start
       (2)啟動
          先啟從庫：
   sql>startup nomount
   sql>alter database mount standby database;
   sql>alter database recover managed standby database using current logfile disconnect from session;
   在啟主庫
   sql>startup
        (3)關閉：和開啟正好相反
           先關主庫：
    sql>shutdown immediate
    再關從庫：
    sql>alter database recover managed standby database cancel;
    sql>shutdown immediate;