wordpress项目插件,seo的含义,翻页h5制作软件,用凡科可以做视频网站吗** 以下所有均是基于11G版本的 ** 一、DataGuard的部署方式 DG的部署最常用的方式就是直接在备库端部署一个空库然后再设置参数#xff0c;但是这样做在初始同步时如果数据量过大会耗费较长的时间#xff1b;相对来说这中方式比较简单不易出错。 还有一种方式就是通过rman的备…** 以下所有均是基于11G版本的 ** 一、DataGuard的部署方式 DG的部署最常用的方式就是直接在备库端部署一个空库然后再设置参数但是这样做在初始同步时如果数据量过大会耗费较长的时间相对来说这中方式比较简单不易出错。 还有一种方式就是通过rman的备份恢复的方式进行部署当然也可以通过Oracle的复制库的方式部署主要说一下rman的复制命令其他的就和正常备份恢复是一样的参数配置也是一样的。 以下均在备库端执行 恢复控制文件 RMAN restore standby controlfile from ‘/sasbackup/ctl_file_g4qfmqm6_1_1_20150828’; 登录通过duplicate恢复 [oraclelocalhost ~]$ rman target sys/oracleorcl_pd auxiliary sys/oracleorcl_st RMAN duplicate target database for standby nofilenamecheck dorecover;
以上是两种相对常见的部署方式不论那种部署方式数据库的主要参数是一样的。 在数据库主要参数有以下 1.DB_NAME 只需注意DataGuard的主备各节点instance使用相同的db_name即可。推荐与service_name一致。我们这里未作重定义 2.DB_UNIQUE_NAME 1Primary与Standby端数据库的唯一名字设定后不可再更改。 2如果主备db_unique_name不一样需要与LOG_ARCHIVE_CONFIG配合使用 3db_unique_name并未规定需要与数据库service_name一致可以自定义任意名称。 3.LOG_ARCHIVE_CONFIG 列出主备库上的DB_UNIQUE_NAME 参数。默认情况下定义该参数保证数据库能够发送或接收redo log。 4.LOG_ARCHIVE_DEST_1 本地归档路径。Primary与Standby需要定义各自的online redo log的归档地址以系统实际的存放路径为准。 本例LOG_ARCHIVE_DEST_1‘LOCATION/u01/arch/ VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEbj’ 可以这样理解对于bj主库而言不管它是主库角色还是备库角色ALL_ROLES它都会自己完成归档动作并将它们归档在本地的/u01/arch下。 5.LOG_ARCHIVE_DEST_2 该参数仅当数据库角色为primary时生效指定primary传输redo log到该参数定义的standby database上。 log_archive_dest_2可以说是dataguard上最重要的参数之一它定义了redo log的传输方式(sync or async)以及传输目标(即standby apply node)直接决定了dataguard的数据保护级别。 注意SERVICE值比如bj是tnsnames.ora文件里定义的Oracle Net名称。 6.LOG_ARCHIVE_DEST_STATE_n 设置为ENABLE激活log_archive_dest_n定义的属性。 7.FAL_SERVER and FAL_CLIENT FAL是Fetch Archive Log的简写它是dataguard主备之间GAP间隙的处理机制。 Primary上不会有GAP所以fal_server和fal_client也是只在standby上生效的参数当然为了switch over的需要同样会在primary端进行预设置。 FAL参数定义的数据库名同样取自本地tnsnames.ora里配置的Oracle Net Service Name. 11g以后 FAL_CLIENT可以忽略。 本例FAL_SERVERtj的意思可以理解为:tj备库产生的归档日志间隙要从主库bj那里获得。 8.DB_FILE_NAME_CONVERT primary与standby上diskgroup的名称或是数据文件的存放路径不一致的时候需要定义该参数进行转换否则standby apply后无法创建与primary一致的数据文件并报错。 1primary上的该参数仅在主备switch over后生效 2注意格式应保持一致比如*.db_file_name_convert‘DG1/db/datafile’,‘DATAGRP/db/datafile/’ ”路径少了一个/”将导致standby apply失败。 本例 DB_FILE_NAME_CONVERT‘/u01/oradata/prodstd’,‘/u01/oradata/prod’ 使用的是物理文件路径所以可以省略”/” 3primary上执行create tablespace等add datafile操作时无须自定义datafile的全路径名称由数据库自动创建datafile即可。 9.LOG_FILE_NAME_CONVERT 同DB_FILE_NAME_CONVERT类似定义主备log文件的存放路径转换。 10STANDBY_FILE_MANAGEMENT 设置为auto时主库执行增删数据文件的动作在备库也会增删数据文件缺省是manual 需要在备库做手动增删。
二、DataGuard的同步原理 典型的SYNC 方式 实时恢复Real-TimeApply日志写入StandbyRedoLog就会立即进行恢复 归档恢复在完成对StandbyRedoLog归档才触发恢复。 典型的ASYNC方式 由主库归档进程ARCH负责推送日志MRP从备库的归档中恢复数据 注异步可以有两种模式①LGWRASYNC,②ARCHASYNC 异步和同步的传输方式 三、DataGuard的主要进程 RFS: (Remote File Server)在备库上启用的进程接收重做日志redo log和arch log LNSn: (LGWR Network Server Process)本地网络服务在主库上负责传送redo日志 MRP: (Managed Recovery Process)备库上管理恢复进程如果是物理 DG用于对redo log做recovery LSP: (Logical Standby Process)备库上逻辑备用进程逻辑DG,是对redo log中抽取的sql进行应用。
四、DataGuard的保护模式 1.最大保护Maximum Protection SYNC同步模式 这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs还要同时写入到Standby数据库的Standby Redologs并确认REDO数据至少在一个Standby数据库中可用如果有多个的话然后才会在Primary 数据库上提交。如果出现了什么故障导致Standby数据库不可用的话比如网络中断Primary 数据库会被Shutdown以防止数据丢失。使用这种方式要求Standby Database必须配置Standby Redo Log而 Primary Database必须使用LGWRSYNCAFFIRM方式归档到Standby Database.
2.最高可用Maximum availability 这种模式在不影响 Primary 数据库可用前提下提供最高级别的数据保护策略。其实现方式与最大保护模式类似也是要求本地事务在提交前必须至少写入一台俗称同步模式 Standby 数据库的 Standby Redologs 中不过与最大保护模式不同的是如果出现故障导致Standby数据库无法访问Primary数据库并不会被Shutdown而是自动转为最高性能模式等Standby数据库恢复正常之后Primary数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失但不能绝对保证数据完全一致。这种方式要求Standby Database必须配置Standby Redo Log而Primary Database 必须使用LGWR SYNCAFFIRM方式归档到Standby Database.
3.最高性能Maximum performance ASYNC异步模式 缺省模式。这种模式在不影响Primary数据库性能前提下提供最高性能级别的数据保护策略。事务可以随时提交当前Primary 数据库的REDO数据至少需要写入一个Standby数据库不过这种写入可以是不同步的。如果网络条件理想的话这种模式能够提供类似最高可用性的数据保护而仅对 Primary 数据库的性能有轻微影响。 这也是创建Standby数据库时系统的默认保护模式。这种方式可以使用 LGWR ASYNC 或者 ARCH 进程实现Standby Database也不要求使用Standby Redo Log
