ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 从大数据量主库创建备库

从大数据量主库创建备库

原创 Linux操作系统 作者:JohnTam10 时间:2011-02-27 17:55:39 0 删除 编辑

年前曾经在本机上测试搭建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日志能力,直到所有数据文件复制到备库上。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24582392/viewspace-688041/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-09-10

  • 博文量
    40
  • 访问量
    88694