從大資料量主庫建立備庫

年前曾經在本機上測試搭建dataguard，看到一篇挺有意思的文章

原文：http://www.dbspecialists.com/blog/database-backups/standby-database-creation-of-vldbs/

在我之前搭建理解上翻譯了一下

    The problem is that for a standby database to stay in-sync with the primary database after creation, it needs to have access to all of the redo that has been generated from the time that the files were backed up on the primary. For very large databases (ie 10Tb+), it’s not uncommon for it to take a number of days to backup/transfer datafiles from the primary to the standby database. When those datafiles are finally restored on the standby database, the redo that was generated over these days needs to be applied to the standby, before the standby can accept new redo from the primary database, and this can be a very large quantity of redo!

    

     For very large databases (ie 10Tb+), it’s not uncommon for it to take a number of days to backup/transfer datafiles from
the primary to the standby database. When those datafiles are finally restored on the standby database, the redo that was
generated over these days needs to be applied to the standby, before the standby can accept new redo from the primary
database, and this can be a very large quantity of redo!
     對於非常大的庫，通常都需要花費許多天來從主庫到備庫進行資料檔案的備份/轉移（包括redo）。當那些資料檔案最終在備庫中恢復， 而備庫在能夠接收主庫產生的新redo之前，需要應用主庫在資料檔案備份轉移這幾天過程中生成的redo，而這些redo是十分多的！

The secret
     So, what’s the secret? The main secret is to create the standby incrementally, datafile by datafile, over an extended
period of time, and keeping the datafiles transferred all synced with the primary soon after they are transferred.
     處理大資料量最主要的祕密是增量式地一個資料檔案接著一個資料檔案地建立備庫，在備庫擴充套件期間，在主庫的資料檔案傳送到備庫後不久即保持同步。
     It turns out that Oracle physical standby databases manage controlfiles differently than primary databases. When you
issue ‘alter database drop datafile mydatafile.dbf including contents and datafiles’ on a primary database, the
controlfile is updated, and the history of that datafile is wiped clean; there really is no way to restore a datafile
after it has been dropped.
     物理備庫管理控制檔案的方法有別於主庫，當主庫執行‘alter database drop datafile mydatafile.dbf including contents and datafiles’時候，控制檔案被更新，此資料檔案的歷史將被清空，並不能夠被恢復。
     However, on a standby database, when you issue a ‘alter database drop datafile mydatafile.dbf’ on a standby database,
the history of that datafile actually doesn’t go away! It is simply marked with a ‘delete’ flag in memory, which
causes the Oracle recovery process on the standby database to skip that datafile.
     然而備庫中當執行‘alter database drop datafile mydatafile.dbf’後，歷史仍然保留在控制檔案中，而只不過在記憶體中被標記為“已刪除”，oracle的恢復程式則會在備庫中恢復資料檔案時跳過此檔案。
Using this information, you can create a standby database datafile-by-datafile, over a period of days, weeks, or even
months, by:

1.Creating a standby controlfile from the primary and shipping it to the standby, 

  建立備庫控制檔案standby control file
2.Modifying parameters on the primary database to ship logs to the standby if using Enterprise Edition, 

  修改主庫引數，傳送日誌到備庫。
3.Setting up a special parameter file for the standby database that will accept redo from the primary database, 

   設定備庫引數使之能夠接受主庫日誌
4.Copy the first datafile from the primary to the standby (or restore it using RMAN)。

   複製第一個資料檔案到備庫（用RMAN恢復也可）。
5.Start the standby database in ‘mount’ mode (alter database mount standby database). You will notice that in
  v$datafile_header, the 1st datafile will have a status of ONLINE, and all other datafiles will have a status of ERROR. 

  mount到備庫上，從v$datafile_header檢視中檢查到第一個傳過來的資料檔案狀態為“ONLINE”，其他都為“ERROR”
6.For all datafiles that have a status of ERROR, issue a ‘alter database drop datafile datafile_name;’ on the standby
  database. 

  備庫上，其他資料檔案都是錯誤狀態，執行drop命令drop掉這些檔案。
7.Initiate standby recovery on the standby database, (recover managed standby database..) 

   備庫執行恢復模式
8.Initiate redo transfer from the primary to the standby (ie set the LOG_ARCHIVE_DEST_n_ENABLE parameter in the primary) 

   傳送redo日誌到備庫。
9.Insure that the standby is applying redo from the primary database (ie v$dataguard_status in the standby). 

   確保備庫正在應用傳送過來的redo日誌。
10.This is now stable; the 1st datafile will be kept up-to-date. You can’t really use (or open) the standby database yet. 

    此時備庫狀態"stable"，第一個資料檔案實時更新，保持在最新狀態。但不能open備庫並使用。
11.When you are ready for the next datafile, transfer the datafile from the primary to the standby, 

     做好傳送下一個資料檔案的準備並傳送。
12.Shut down the standby (shutdown immediate). Then, start it back up (startup nomount; alter database mount standby
     database). 

     shutdown備庫，mount之，並備份。
13.Again, note which datafiles have a status of OFFLINE in v$datafile_header. For each of those, re-issue the alter database drop datafile   datafile_name. 

     標誌狀態OFFLINE 的資料檔案，並且執行drop掉命令。
14.Begin redo application from the standby (ie alter database recover managed standby database…). 

    應用redo日誌。
15.The database is again ’stable’ – the 1st two datafiles will be kept in-sync from the primary. 

     備庫狀態再次"stable"，此時最先傳送的兩個資料檔案與主庫同步更新（up-to-date）。
16.Repeat the steps above (11-15) for each datafile in turn. If you like, you can copy a few files at a time; it depends on how big they are, and  how much redo you can keep around. 

     重複11--15步，可以一次傳送一個或數個資料檔案，取決於資料檔案大小和備庫接收redo日誌能力，直到所有資料檔案複製到備庫上。