本文详细介绍了Oracle DataGuard的安装与配置过程，包括DataGuard基础知识、物理和逻辑备用数据库的创建步骤、数据保护模式以及日志传输和应用服务。通过学习，读者能够掌握如何创建物理和逻辑备用数据库，实现数据的实时同步与高可用性。
ORACLE DATAGURD
知识学习及安装步骤
| 数据库版本 | 10．2．0．1 |
| 文档版本 | 1．0 |
| 作者 | dashu |
| 保护模式 | 最大性能保护 |
| 操作系统 | Window xp |
| 完成日期 | 2010．7．6 |
目录
1.2.7、Role Management Services
2.1.2、创建standby 实例（此步骤在STANDBY库中进行设置）
2.2.1、连接primary 和standby(在执行前对primary进行一次全库备分)
2.4.1、最高性能--在没有创建standby日志时日志传输的流程图(归档进程)
2.4.2、最高性能--在创建standby日志时日志传输的流程图(归档进程)
3.5、确保启用追加的日志(supplemental logging)
3.5.3 确保启用supplemental logging
目标：通过学习DATAGURD的基础知识及DATATAGURD处理流程、能用 RMAN快速创建物
理或逻辑DATAGURD，本文以保护模式为最大性能进行讲述，在同一台WINDOWS机器上创建，主服（primary）数据库为的jssweb,要创建的备服（standby ）的db_unique_name命名为jssrman（因为在同一台机所以要不一样），因为是同一台机所有相关的文件都要重新定义，如数据文件、日志文件。
1、DataGuard基础知识
1.1、环境的准备
数据库环境：
操作系统环境：
Windows xp service sp1
1.2、Dataguard基本概念
Dataguard是ORACLE 推出的一种高可用性(HIGH AVAILABLE)的数据库方案,在8i之前称之为standby database，从9i开始，正式更名为Dataguard，它是在主节点与备用节点间通过日志同步来保证数据的同步，可以实现快速切换与灾难性恢复。
Dataguard只是在软件上对数据库进行设置，并不需要额外购买任何组件，它能在对主数据库影响很小的情况下，实现备数据库的同步，而主备机的数据差异只在在线日志部分。
1.2.1、DataGuard的发展史
ORACLE 从7.3 开始支持standby database。7.3.x-8.0.x 需要手工拷贝所有归档日志并手工同步，从ORACLE815 开始，开始支持多节点复制，并实现了自动同步，但是这种同步是数据异步模式的，可能引起数据丢失。从ORACLE9i开始，备用服务器已经换了一种新的称呼，叫数据保护(DATA GUARD)，在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，并增加了一个新的后台进程叫DMON 监控数据的同步，支持多达9个节点的同时复制。从920开始，还开始支持物理与逻辑备用服务器。
1.2.2、运行要求
1、主机运行在归档模式下
2、主备数据库的版本必须一样，操作系统必须一样。Standby可以使用与primary不同的目录结构。
3、主备硬件和操作系统的结构必须一样，例如，两者都要运行在32位或64位的格式下。
4、主数据库和备数据库可以是single的，也可以是RAC。
5、主备硬件（如，CPU的数量，内存大小，存储设置）可以不一样。
6、每个数据库都必须有自己的控制文件。
7、避免nologing的方式，这样会导致standby无法与primary同步。
1.2.3、DataGuard的备用模式
物理模式是当前用得最多的模式，它从7.3就开始存在了，技术上比较成熟，可以做为主机的一个备份。它的缺点是无法在打开的数据库的同时进行恢复。针对这个问题，oracle推出了逻辑模式，它弥补了物理模式无法在打开的数据库的同时进行恢复的缺点，但这毕竟是在9i中才提出来的新特性，难免会有些不尽人意的地方，在应用过程中会有不少的bug，然而，随着10的推出，逻辑模式已经逐渐成熟。今后也会成为dataguard的主流模式之一。
physical standby database
物理备用机在物理上和主据库的结构完全一样。也就是说，物理备机除了control 文件和主机不一样以及在线日志是可选的以外，其他都和主数据库一样。物理备机是靠应用主机所产生的归档文件来实现主备的一致。
物理备用机的结构图
从上图可以看到，日志从主数据库通过网络传到备库上，并在备机上应用传过来的归档文件，以实现两台机的同步。
物理备用机的两种数据库打开的模式:
1、Managed recovery mode
归档文件从主数据传到备用数据库，log apply services把这些日志应用到备用数据库中。
2、Read only mode
这种模式可供用户只读的操作数据库，归档日志仍然会从主数据库传到备用数据库，但Log apply services不可以把这些日志应用到备用数据库中。
优点：
（1）支持所有的DDL和DML语句
不管是什么数据类型、表的类型，任何DDL和DML语句都可以应用在物理备用数据库上。
（2）性能优势
相对于logical standby database而言，physical standby database的性能要优越很多，特别是有大型操作的时候，physical是直接应用归档日志的，而logical的方式则是需要把所有的归档转换成SQL语句再在logical standby database上执行它。这会占用大量的系统资源，如CPU，memory,I/O等。
减轻主数据库的备份压力
物理备机的中的数据文件可以用来恢复主数据库的数据文件
减轻主数据库的工作压力
数据库可以用只读来打开，可以分担一部分查询的工作
相关进程
_ Remote file server (RFS)
负责从主数据库上接收归档文件
_ Archiver (ARCn)
将日志进行归档。
Managed recovery process (MRP)
将归档文件应用到备用机上
logical standby database
逻辑备用机在逻辑上和主据库一样，也就是说，两台服务器的表、视图等对像需要保持一致，对物理结构上则不需要保持一致。
逻辑备用机是靠把主机传过来的归档日志翻译成SQL语句，并应用到备用机上来进行更新的，与物理备用机不同的是它可以在更新的同时对数据库进行查询。
可以看到，日志从主数据库通过网络传到备库上，并在备机上把日志转换成SQL语句，并应用到备机上，以此实现两台机的同步。
优点
（1） 数据是实时更新的，而且也可以让用户进行查询操作
（2）可以在standby中建立索引和物化视图以方便用户的查询。
相关进程
_ Remote file server (RFS)
负责从主数据库上接收归档文件
_ Archiver (ARCn)
将日志进行归档。
Logical standby process (LSP)
logical standby process (LSP)将归档文件应用到备用机上
它是一个协调的进程，用于聚集所有parallel server processes (Pnnn)对归档中的sql事务进行读取，分析及将其应用到备用数据库中。
1.2.4、数据保护模式
在9i以前，oracle只提供一种数据的保护模式，就是最大性能的模式，也就是说，靠归档日志来实现数据的同步，这样就产生了一个问题，如果数据库突然垮了，在线日志没有归档的情况下，就会有部分数据丢失了，基于这个问题，oracle9i提出了无数据的模式，也就是直接把在线日志传到备用机上，以保证数据的完全一致。下面就是oracle9i所支持的三种数据保护模式
1、 MAXIMIZE PROTECTION
最大数据保护与无数据分歧。LGWR将同时把日志信息传送到online redo和备用节点上，在主节点事务确认之前，至少有一个备用节点需要收到日志，如果备用节点无法接受日志信息，则该事务就无法提交。这就确保了数据的完全同步。但在网络不好的情况下，引起LGWR不能传送数据，将引起严重的性能问题，导致主节点DOWN机。如果采用这种模式，最好能建立多个standby database，以确保日志能够至少归档到一台备用机上，减少down机的机会。
logical standby databases的primary database不可以处于maximum protection模式。到了10G的时候，最大的保护模式也可以应用到logical standby了。这种模式下，备用机必须建立自己的online redo log，还要用LGWR进行日志的传输。在RAC模式下，任何一个节点的与某个standby的连接出现错误，都会导致整个cluster终止与该standby进行通讯。就是说。如果只有一个standby的话，任一个primary node与standby的连接出现错误都会导致primary shut down。
2、 MAXIMIZE AVAILABILITY
无数据丢失模式，允许数据分歧，允许异步传送。正常情况下运行在最大保护模式，在主节点与备用节点的网络断开或连接不正常时，自动切换到最大性能模式，主节点的操作还是可以继续的。如果只有一台standby，又不想有数据丢失的话，推荐采用这种模式。
3、 MAXIMIZE PERFORMANCE
这种模式应当可以说是从8i继承过来的备用服务器模式，异步传送，无数据同步检查，可能丢失数据，但是能获得主节点的最大性能。9i在配置DATA GUARD 的时候默认就是MAXIMIZE PERFORMANCE
可以用LGWR或ARCn来传输归档文件，也可以指定synchronous或asynchronous的网络传输模式。如果用primary采用LGWR来传输日志给physical standby，则standby就要有自己的online redo。否则。Standby不需要建立自己的online redo log。
在RAC模式下，如果有一个节点的与standby的连接出现错误，其他节点会继续向这个standby继续传输日志。
也可以用LGWR或ARCn来传输归档文件，你也可以指定synchronous或asynchronous的网络传输模式。如果用primary采用LGWR来传输日志给physical standby，则standby就要有自己的online redo。否则。Standby不需要建立自己的online redo log。
在RAC模式下，如果有一个节点的与standby的连接出现错误，其他节点会继续向这个standby继续传输日志。
可以用以下语句来进行模式间的切换，默认是maximize performance。
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
1.2.5、Log Transport Services
Log Transport Services会被物理的和逻辑的standby database 都用到。它提供的功能包括控制不同的日志传输机制、日志传输错误处理和报告、以及在系统失败后获取丢失的日志。使用任何新的日志传输模式，数据的保护都可以得到保证。
1.2.6、Log apply services
把在备用机上的归档文件应用到备用服务器上。物理备用机有两种模式：Managed recovery mode归档文件从主数据传到备用数据库，log apply services把这些日志应用到备用数据库中。Read only mode这种模式可供用户只读的操作数据库，归档日志仍然会从主数据库传到备用数据库，但Log apply services不可以把这些日志应用到备用数据库中。
1.2.7、Role Management Services
role management services用于主备数据库之间的切换。
1.2.8、Log transport services
log transport services负责主数据库与备用数据库之间的归档文件的传输，在Dataguard中，log transport services组件结合log apply services 和role management services一起实现主备数据库的switchover和failover
1.3、Dataguard的相关进程
on primary database:
Log writer process (LGWR):把数据写到在线日志中
Data Guard除了以上传统的Arch日志传送过程外，还可以采用联机日志的传送，在备用端建议创建一组备用日志，并保持与主数据库备用日志相同大小，而且最好比主数据库的联机日志多一组以上。
如果LGWR传送日志，但是不在备用端创建备用日志的话，联机日志将自动写到备用端的归档日志中？？？。
即使是用LGWR进行日志的传输，备用库的online redo log的内容是不能马上被应用的，必须当归档完成后才由MRPn进程应用到备用数据库，所以说，恢复不是连续的，但是，传送过程可以是连续的。
即使备用数据库不是在归档的模式，所有的在线日志还是会进行归档的操作，前提是ARCn进程必须打开。
Archiver process (ARCn)：COPY在线日志到本地或远程。这就是归档日志。
Fetch archive log (FAL) process (physical standby databases only)：
FAL提供一个client/server的机制来检测主备机上的归档是否有间断。由standby上的FAL client和和primary上FAL server来实现此工作。由FAL_CLIENT 和 FAL_SERVER参数决定primary database和standby database。
On the standby location，log transport services使用下面的进程
Remote file server (RFS)：用于从primary上接受归档文件
ARCn process
当standby使用online redo的时候，也就是maximum protection或 maximum availability模式下，ARCn用于归档。
_ On the standby location, log apply services使用下面的进程
Managed recovery process (MRP)（For physical standby databases only）：用于把归档应用到standby database
Logical standby process (LSP)(For logical standby databases only):用SQL接口把归档应用到logical database
_ On the primary and standby locations, the Data Guard broker使用下面进程
Data Guard broker monitor (DMON):用于监控数据库的状态，管理log transport services and log apply services
2、DATAGURD 创建（物理最大性能）
2.1、前期准备工作
2.1.1、创建主库（priamry）
创建时oracle_sid命名为jssweb
主库不是归档模式要改成归档模式
1)SQL>STARTUP MOUNT;
2)SQL>ALTER DATABASE ARCHIVELOG;
3)SQL>ALTER DATABASE OPEN;
4)SQL>ALTER DATABASE FORCE LOGGING;
此步骤不再讲述
2.1.2、创建standby 实例（此步骤在STANDBY库中进行设置）
2.1.2.1、通过oradim 命令创建实例
以上说明创建standby 实例成功；
2.1.2.2、配置TNSNAME.ora，如果不在同一台机，那么两边都要配
2.1.2.3配置监听，监听只要配置本机的实例就行了，以为本机的两个实例
在同一台机上，所以监听配了两个
2.1.3、创建standby初始化参数文件
Standby的参数文件可以从primary库中生成一个然后再修改下就行了
2.1.3.1、创建成功之后修改参数文件
*.audit_file_dest='E:/oracle/product/10.2.0/admin/jssrman/adump'
*.background_dump_dest='E:/oracle/product/10.2.0/admin/jssrman/bdump'
*.compatible='10.2.0.1.0'
*.control_files='E:/ORACLE/PRODUCT/10.2.0/ORADATA/JSSRMAN/CONTROL01.CTL','E:/ORACLE/PRODUCT/10.2.0/ORADATA/JSSRMAN/CONTROL02.CTL','E:/ORACLE/PRODUCT/10.2.0/ORADATA/JSSRMAN/CONTROL03.CTL'#Restore Controlfile
*.core_dump_dest='E:/oracle/product/10.2.0/admin/jssrman/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.DB_FILE_NAME_CONVERT='oradata/jssweb','oradata/jssrman'
*.db_name='jssweb'
*.db_recovery_file_dest='E:/oracle/product/10.2.0/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.DB_UNIQUE_NAME='jssrman'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=jsswebXDB)'
*.fal_client='standby'—用于校验不同步的日志
*.fal_server='PRIMARY'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(jssweb,jssrman)' –为DB_UNIQUE_NAME值
*.LOG_ARCHIVE_DEST_1='LOCATION=E:/rman/jssrman VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssrman'
--当指定了standby日志时时，这个作为standby 的归档日志路径位置即archive log list 参数值
*.log_archive_dest_2='service=primary lgwr async valid_for=(online_logfiles,primary_role) db_unique_name= jssrman'
--这个只当备服切成主服时才生效，在备服中无效
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.nls_language='SIMPLIFIED CHINESE'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=148897792
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=447741952
*.standby_archive_dest='E:/rman/jssrman/standby'
--接收归档的路径 当没有standby日志时，这里为RFS的归档路径，当开如实时应用时，这里也作为归
路径
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:/oracle/product/10.2.0/admin/jssrman/udump'
项目为大写关键字的是新增的内容，并将jssweb字符改jssman字符
主库参数文件配置
jssweb.__db_cache_size=285212672
jssweb.__java_pool_size=4194304
jssweb.__large_pool_size=4194304
jssweb.__shared_pool_size=150994944
jssweb.__streams_pool_size=0
*.audit_file_dest='E:/oracle/product/10.2.0/admin/jssweb/adump'
*.background_dump_dest='E:/oracle/product/10.2.0/admin/jssweb/bdump'
*.compatible='10.2.0.1.0'
*.control_files='E:/oracle/product/10.2.0/oradata/jssweb//control01.ctl','E:/oracle/product/10.2.0/oradata/jssweb//control02.ctl','E:/oracle/product/10.2.0/oradata/jssweb//control03.ctl'
*.core_dump_dest='E:/oracle/product/10.2.0/admin/jssweb/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='jssweb'
*.db_recovery_file_dest='E:/oracle/product/10.2.0/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=jsswebXDB)'
*.fal_client='primary'—tnsname里的值
*.fal_server='standby'—tnsname里的值
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(jssweb,jssrman)'—为db_unique_name值
*.log_archive_dest_2='service=standby lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=jssrman'
--这个只当备服切成主服时才生效，在备服中无效
—远程归档路径 指定lgw 说明采用是 lns与rfs进程通讯
如果没有指定，那么是归档进程与rfs进程通讯；
*.LOG_ARCHIVE_DEST_1='LOCATION=E:/rman/jssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb’
--
*.nls_language='SIMPLIFIED CHINESE'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=148897792
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=447741952
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:/oracle/product/10.2.0/admin/jssweb/udump'
2.1.3.2、创建standby的参数文件
standby的参数文件创建成功。
2.1.4、启动standby库到nomount状态
在启动前确认参数文件的目录是否都存在
启动成功说明，参数文件配置基本正确，因为这里启动时会检测参数配置路径，所以在启动前，必须将参数涉及到的目录全部要创建，不然启动会报错；
2.1.5、创建standby的密码文件
Orapwd file=E:/oracle/product/10.2.0/db_1/database/PWDjssrman.ora password=oracle entries=30
2.2、进行创建工作
2.2.1、连接primary 和standby(在执行前对primary进行一次全库备分)
2.2.2、创建standby控制文件
2.2.3、生成standby数据库
根据以上提示数据库恢复完成
2.3、后续工作
2.3.1、修改主库参数（primary）
2.3.2 增加standby日志组,在物理备份上做此操作
增加日志组，记得逻辑备份必须要创建Standby 日志文件，物理最高性能可以不用建，但还是建议大家建好standy。
2.3.3、打开备库的日志应用
打开日志应用前，确定数据库是否运行在standby 环境中，执行以下命令查看当前standby 库的运行
状况，如果数据库的打开模式为mounted，数据库模式为physical stanby 或logical stanby 说明运行正常。
上面查询结果说明standby 库运行正常，现在只要开启日志应用即可，执行下以下命令开启日志应用；
你如如果要开启实时应用日志，那么就行行以下命令，如果你以开启日志应用了，那么先关闭日志应用，
再开启实时日志应用如下图：
如果还没有开启日志应用，那么只要执行一条开启实时应用日志命令即可
注 ：Alter Database Recover Managed Standby Database Cancel命令并非象有些书上说的是停止日志
传送，其实是停止日志应用，日志是已传到standy log或者已归档，只是MRP或LSP进程处是非工作状态，不进行日志恢复；
2.3.4、验证归档成功与否
查看物理备库日志，从以下可以看出，当前日志序列号处于26；
查看主库日志，可以看出当前日志序列号也处于26，说明主库与备库他们的数据同步是一致的，至少可以说明他们通讯是没有问题的；
我们也可以再来手工验证一下，在主库中执行日志切换之后，分别在主库与备库查看日志序列号的变化，如果不相等说明配置有问题，那就得去重新检查相关的配置了。
在主库上执行下以下命令
查看主库当前的日志序列号
查看从库当前的日志序列号
两边的日志序列号一样，说明同步正常，当然你也可以建表,插入数来验证自已的成果。
哈哈。我们的物理DATAGRUD配置已完成，其实配置也很简单，但要理解它的工作原理，那就有点困难了，往往我们安装完成了，基本上我们还不知道这个DATAGURD倒底是怎么工作的。
2.3、数据流程图
2.3.1、最高性能--在没有创建standby日志时日志传输的流程图(归档进程)
2.3.2、最高性能--在创建standby日志时日志传输的流程图(归档进程)
当standby 没有成功接收一次日志时，就由fal进程同步日志，它同步时将不会使用stanby log日志文
件，直接由rfs进程归档，归档的路径也是由参数standby_arhcive_dest 决定
2.3.3、最高性能--保护模式（异步）
2.3.4、最高保护--保护模式（同步）
2.4、其它事项
2.4.1、相关内容:
select * from V$ARCHIVE_DEST 查询归档的情况，一般的错误这里都有可能知道
2.4.2、Rman 备份
(在备份时不要有清除日志归档文件的命令行，以免错误清除了需要的归档文件)
3、DATAGURD 创建（逻辑最大性能）
3.1、创建逻辑备份前的准备工作
在创建逻辑备份前,我们检查下主库是否具备建立逻辑备份的方法;不然到最后安装完成确不能使用，功亏一篑，费时又费神；
先检查下primary数据库的状态，确保primary数据库的做好了全部准备工作，比如归档是否启动了，
是否开启了forced logging 等；除了这些还得检查表的数据类型，为什么呢？
由于逻辑standyb 是通过sql应用来保持与primary数据库同步的。Sql应用与redo应用是很大的区别的，redo应和实际就是物理standby进行 recover ,sql应用则是分析redo文件，将基转换成为sql语句在逻辑standby 端执行，所以我们要注意：
3.1.1、检查主库表的字段类型
DATAGURD不支持的数据类型：NCLOB, LONG, LONG RAW, BFILE, ROWID, and UROWID,自定义类型等,太多了难以记得住,其实一条SQL就可以查出当前数据库中是否存在不支持的数据库类;
Select * from dba_logstdby_unsupported;
3.1.2、检查不支持的表和序列：
Tables and sequences in the SYS schema
Tables with unsupported datatypes
Tables used to support functional indexes
Tables used to support materialized views
Global temporary tables
3.1.3、检查主库每个表中是否有主键或唯一约束
Oracle 使用主键或唯一约束/索引补充记录来逻辑地标识在逻辑备份数据库中被更改的行，当允许数据据库范围的主键和唯一约束来补充记录时，每个UPDATE语句也写必要的列值到重日志，以在逻辑备数据库中唯一地标识被更改的行；
l 如果表定义了主键，则主键与被更改的列一起记录，作为UPDATE语句的一部份来标识更改的行。
l 如果没有主键，则最短的非空唯一约整/索引与更改的行一起记录，作为UPDATE语句的一部份来标识更改的行。
l 如果即没有主键也没有非空唯一约束/索引，则所有有界限大小的列，作为UPDATE语句的一部份记录，来标识更改的行。换一句话说，记录所有列除了：LONG、LOB、LOMG RAW、对象类型和集合。
Oracle 推荐你在主数据库中添加一个主键或非空一索引，确保SQL应用能有效地应用重做日志更新到逻辑备数据库。
在主数据库中找到没有唯一逻辑标识符的表：
查询DBA_LOGSTDBY_NOT_UNIQUE 视图来显示SQL应用可能无法唯一标识的表， 如：
select owner,table_name,bad_column from DBA_LOGSTDBY_NOT_UNIQUE where (owner,table_name) not in (select distinct owner,table_name from dba_logstdby_unsupported) and bad_column='Y'
3.1.4、逻辑STANDBY不支持的SQL语句操作：
ALTER DATABASE CREATE SCHEMA AUTHORIZATION
ALTER SESSION CREATE SNAPSHOT
ALTER SNAPSHOT CREATE SNAPSHOT LOG
ALTER SNAPSHOT LOG CREATE SPFILE FROM PFILE
ALTER SYSTEM SWITCH LOG CREATE TABLE AS SELECT FROM A CLUSTER TABLE
CREATE CONTROL FILE DROP DATABASE LINK
CREATE DATABASE DROP SNAPSHOT
CREATE DATABASE LINK DROP SNAPSHOT LOG
CREATE PFILE FROM SPFILE SET TRANSACTION
EXPLAIN LOCK TABLE
RENAME SET CONSTRAINTS
SET ROLE
如果以上情况你都看明白了，那么接下来我们就开始动手安装DATAGURD逻辑备份。
3.2、创建DATAGURD物理备份
嘿嘿，上面的我们创建步骤我们都讲了，不再讲了，略..。。。
3.3、在物理备份数据库上停止重做应用
在停止之前它们是可以工作的，可以应用日志，它就一个完整的物理备份方案，在转换成逻辑备份时，我们需要停止日志应用，如果是在RAC环境下，则在执行这个命令之前必须首先停止除了一个以外的所有RAC实例：
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3.4、为角色转换准备主数据库
要让主备能互相切换，我们必须设置多个备用角色初始化参数以在主数据库转换到物理或逻辑备份角色，则我们必须在主库上包含LOG_ARCHIVE_DEST_3目的地，如例4-1中所示，使角色转换之后不需要更改参数。这个参数只有当主库转换成备库时才起作用。
例4-1 主数据库：逻辑角色初始化参数
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='LOCATION=E:/rman/jssweb
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME= JSSWEB' SCOPE= both;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE SCOPE=both;
在开启LOG_ARCHIVE_DEST_3时确保你的LOG_ARCHIVE_DEST_1是本地归档路径,这时他的recover默认路径将不再使用;
3.5、在主数数据中建立字典
LogMiner 必须建立到主数据库，使得SQL应用的LogMiner 组件能正确地解释它，并去更改备库的行。作为建立LogMiner Multversioned Data Dictionalry 的一部分,追加的记录自动设置以记录主键和唯一约束/索引列。追加的记录信息确保每次更新包含足够的信息以逻辑地标识由语句更改的每一行。
要建立LogMiner 字典，执行下面语句：
l 在执行命令前我们要确保主库的归档路径是正确有效，不然命令执行会失败，徦如我们设了日志归档到备用数据库时，那么备用数据也必须以mouted打开到物理模式，使它可以有效地接收主库传来的日志，但我们必须关闭日志应用,主要是为了保证主数据与备数据库他们的日志应用是同步的；
l DBMS_LOGSTDBY_BUILD 过程须等待所有现有的事务完成。在主数据库上执行的长时间运行的事务将会影响这条命令的完成时间；
l DBMS_LOGSTDBY_BUILD 过程使用Flashback 查询来获得数据字典的一致性快照，然后数据字典记录到重做流中。Oracle推荐在主和逻辑数据库上设置UNDO_RETENTION的值为3600；
l DBMS_LOGSTDBY_BUILD 过程会自动启用primary数据库的补充日志（supplemental logging）功能（如果未启用的话）；
3.5、确保启用追加的日志(supplemental logging)
创建逻辑备用数据库前，在主数据库上必须启用supplemental logging。因为oracle只会对那些修改的列生成日志，这对唯一标识那些被修改的行时并不总是足够的，额外的信息(supplemental)必须被加到重做日志里。这些被加到联机日志里的supplemental信息能够帮助日志应用服务正确的标识逻辑备用数据库里的表和表里的行。
确定在主数据库上，supplemental logging是否被启用，可以查询v$database，如下：
SQL> select supplemental_log_data_pk,supplemental_log_data_ui from v$database;
如果为NO，则说明supplemental logging没有被启用。如果被启用，则转到3.6，否则如果没有被启用，则采用下面的方法来启用。
3.5.1 启用supplemental logging
在主数据库上，执行下面语句以便将主键和唯一索引信息添加到归档日志里：
SQL> alter database add supplemental log data(primary key,unique index) columns;
该语句在主数据库中向重做日志添加了唯一标识行的信息，从而日志应用服务可以在备用数据库里正确的标识相同的行了。
3.5.2 切换到一个新的重做日志
在主数据库上，执行以下语句：
SQL> alter system archive log current;
通过切换到一个新的日志文件，这样，你就可以保证当前重做日志既不含有supplemental日志数据也不含有nonsupplemental日志数据。逻辑备用数据库不能使用那些既含有supplemental日志数据又含有nonsupplemental日志数据的重做日志。
3.5.3 确保启用supplemental logging
SQL> select supplemental_log_data_pk as primaryKey,supplemental_log_data_ui as uniqueIndex from v$database;
如果都为yes则说明启动了。
如果在一个已经含有物理备用数据库的data guard配置中启用了supplemental logging的话，那么必须在每个物理备用数据库中分别执行alter database add supplemental log data，以便将来在switchover的时候能够正常工作。
3.6、转换物理STANDBY到逻辑STANDBY
执行下列语句,转换物理standby 为逻辑standby ;
关于DB_name即mxweb01,这可不是db_unique_name,不同于物理standby ,逻辑standby是一个全新数据库,因此建建议你指定一个唯一的名字与主库不同的名字,我们在建物理standby时没有指定这个值,物理standby参数的值还是主库的值,如果当前使用spfile,则数据库会自动修改其中的相关信息,发果是用pfile,则数据库会发出一条信息提示你在关闭数据后设置DB_NAME值;
提示:执行语句前务必确保已暂停了物理standby 日志应用,而转换也是单向的,只有物理standby 转到逻辑standby ,而不能由逻辑的standby 转到物理的,这不仅仅是db_name发生了变化,而是逻辑的只是数据与主库一致,其它如存储结构,scn等,dbid都不一相同;
在执行这个语句时,如果字典建立没能在主数据库上成功执行,这条命令将永远不会完成.你只能通过在另外的SQL会话中执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 语句来取消该SQL语句。
3.7重建逻辑standby 的密码文件
主要是我们转换操作修改了数据库名，所以逻辑standby密码文件也必须重建：
3.8调整逻辑standby 的初化参数
在逻辑standby数所据库上,关闭实例,执行startup mount语句来启动,并安装数据库,但不打开;例如:
命令执行完成之后,我们需要修改LOG_ARCHIVE_DEST_N参数,因为不像物理备数据库,逻辑备数据库是打开的数据库,生成重做数据并有多个日志文件(联机重做日志文件,归档重做日志文件,备重做日志文件).我们分别指定重做日志文件的路径,便于维护及查看:
存储由逻辑备数据库产生的重做数据的归档重做日志文件.例3-8-1中,配置LOG_ARCHIVE_DEST_1为它的路径;
存储从主数据库接收到的重做数据的归档重日志文件,此归档文件是由RFS接收的,直接写入归档路径或由归档进程归档的文件,路径由参数LOG_ARCHIVE_DEST_3来决定;
例子.例3-8-1为逻辑备数据库修改初始化参数
LOG_ARCHIVE_DEST_1= 'LOCATION= E:/rman/mxweb01/arconline
ALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME= JSSRMAN'
LOG_ARCHIVE_DEST_2='service=primary VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jssweb '
LOG_ARCHIVE_DEST_3= ' LOCATION= E:/rman/mxweb01/arcstand
VALID_FOR=(STANDBY_LOGFILES,STANDBY _ROLE) DB_UNIQUE_NAME= JSSRMAN'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
注：书写时注意配置里面的参数与参数值不能有空格
下面的表描述了由例子3-8-1中所示的初始化参数定义的归档过程
| 参数 | 当mxweb01运行在逻辑standby时 | 当mxweb01运行在主数据时 |
| LOG_ARCHIVE_DEST_1 | 由逻辑备重做在线日志生成的归档文件的路径 | 由主库重做在线日志生成的归档文件的路径 |
| LOG_ARCHIVE_DEST_2 | 被忽略；只有在主角色中才有效 | 指导主数据库重做日志到远程逻辑备数所原传输 |
| LOG_ARCHIVE_DEST_3 | 指导从主库接收到重做数据到本地归档的路径 | 被忽略；只有在standy角色中才有效 |
3.9打开逻辑数据库
由于逻辑standby 与primary数据库事务并不一致,因此第一次打开时必须指定resetlogs选择,如下:
然后可以通过执行下列sql命令实时应用redo数据:
或者:
SQL>alter database start logical standby apply;
如果想停止逻辑standby的sql就用,可以通过下列命令:
SQL>Alter database stop logical standby apply;
3.10 数据验证
在主库(primary)建表来验证数据同步的情况
在逻辑备库查询
在验证数据,不需要切换日志,他开启了实时日志应用服务
扫一扫
7223
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
