dg原理结构 oracle_oracle dg原理 - CSDN
精华内容
参与话题
  • Oracle 11g DG概念与进程详解

    万次阅读 2017-06-22 21:16:22
    RAC, Data Gurad, Stream 是Oracle 高可用性体系中的三种工具,每个工具即可以独立应用,也可以相互配合。 他们各自的侧重点不同,适用场景也不同。 RAC 它的强项在于解决单点故障和负载均衡,因此RAC ...

    RAC,Data Gurad,Stream 是Oracle 高可用性体系中的三种工具,每个工具即可以独立应用,也可以相互配合。他们各自的侧重点不同,适用场景也不同。

    RAC它的强项在于解决单点故障和负载均衡,因此RAC方案常用于7*24的核心系统,但RAC方案中的数据只有一份,尽管可以通过RAID等机制可以避免存储故障,但是数据本身是没有冗余的,容易形成单点故障。

    Data Gurad通过冗余数据来提供数据保护,Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步,这种同步可以是实时,延时,同步,异步多种形式。Data Gurad常用于异地容灾和小企业的高可用性方案,虽然可以在Standby机器上执行只读查询,从而分散Primary数据库的性能压力,但是Data Gurad决不是性能解决方案。

    Stream是以oracle Advanced Queue为基础实现的数据同步,提供了多种级别的灵活配置,并且Oracle提供了丰富的API等开发支持,Stream更适用在应用层面的数据共享。

     

    一. Data Guard 架构

    DG架构可以按照功能分成3个部分:

    1) 日志发送(Redo Send)

    2) 日志接收(Redo Receive)

    3) 日志应用(Redo Apply)

     

    1. 日志发送(Redo Send)

    Primary Database运行过程中,会源源不断地产生Redo日志,这些日志需要发送到Standy Database。这个发送动作可以由Primary Database的LGWR或者ARCH进程完成,不同的归档目的地可以使用不同的方法,但是对于一个目的地,只能选用一种方法。选择哪个进程对数据保护能力和系统可用性有很大区别。 

     

    1.1 使用ARCH 进程

    1)Primary Database不断产生Redo Log,这些日志被LGWR进程写到联机日志。

    2)当一组联机日志被写满后,会发生日志切换(Log Switch)并且会触发本地归档,本地归档位置是采用LOG_ARCHIVE_DEST_1='LOCATION=/path'这种格式定义的。

    如:alter system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;

    3)完成本地归档后,联机日志就可以被覆盖重用。

    4)ARCH 进程通过Net把归档日志发送给Standby Database的RFS(Remote File Server)进程。

    5)Standby Database端的RFS进程把接收的日志写入到归档日志。

    6)Standby Database端的MRP(Managed Recovery Process)进程Redo Apply)或者LSP 进程SQL Apply)在Standby Database上应用这些日志,进而同步数据。

     

    用ARCH模式传输不写入备机的重做日志(Standby Redologs),直接保存成归档文件存放于Standby端

     

    说明:

    逻辑Standby接收后将其转换成SQL语句,在Standby数据库上执行SQL语句实现同步,这种方式叫SQL Apply

    物理Standby接收完Primary数据库生成的REDO数据后,以介质恢复的方式实现同步,这种方式也叫Redo Apply

     

    注意:创建逻辑Standby数据库先创建一个物理Standby数据库,然后再将其转换成逻辑Standby数据库

     

     

    使用ARCH进程传递最大问题在于: Primary Database只有在发生归档时才会发送日志到Standby Database。如果Primary Database异常宕机,联机日志中的Redo内容就会丢失,因此使用ARCH进程无法避免数据丢失的问题,要想避免数据丢失,就必须使用LGWR,而使用LGWR 又分SYNC(同步)和ASYNC(异步)两种方式。

     

    在缺省方式下,Primary Database使用的是ARCH进程,参数设置如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

     

    1.2 使用LGWR 进程的SYNC 方式

    1)Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程(LGWR Network Server Process,再由LNSn(LGWR Network Server process进程把日志通过网络发送给远程的目的地,每个远程目的地对应一个LNS进程,多个LNS进程能够并行工作。

    2)LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功,Primary Database上的事务才能提交,这也是SYNC的含义所在。

    3)Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。

    4)Primary Database的日志切换也会触发Standby Database上的日志切换,即Standby Database对Standby RedoLog的归档,然后触发Standby Database的MRP或者LSP进程恢复归档日志。

     

    因为Primary Database 的Redo是实时传递的,于是Standby Database端可以使用两种恢复方法: 

    实时恢复(Real-Time Apply):只要RFS把日志写入Standby Redo Log就会立即进行恢复;

    归档恢复:在完成对Standby RedoLog归档才触发恢复。

     

      Primary Database默认使用ARCH进程,如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时,可以同时使用NET_TIMEOUT参数,这个参数单位是秒,代表如果多长时间内网络发送没有响应,LGWR 进程会抛出错误。示例如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  SYNC  NET_TIMEOUT=30' scope=both;

     

    1.3 使用LGWR进程的ASYNC 方式

    使用LGWR SYNC方法的可能问题在于,如果日志发送给Standby Database过程失败,LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况,有时这种要求可能过于苛刻,这时就可以使用LGWR ASYNC方式。 它的工作机制如下:

    1) Primary Database 一段产生Redo 日志后,LGWR 把日志同时提交给日志文件和本地LNS 进程,但是LGWR进程只需成功写入日志文件就可以,不必等待LNSn进程的网络传送成功。

    2) LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。

    3) Primary Database的Online Redo Log 写满后发生Log Switch触发归档操作,也触发Standby Database对Standby Redo Log 的归档;然后触发MRP或者LSP 进程恢复归档日志。

     

    因为LGWR进程不会等待LNSn进程的响应结果,所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  ASYNC ' scope=both;

     

    2. 日志接收(Redo Receive)

    Standby Database的RFS(Remote File Server进程接收到日志后,就把日志写到Standby Redo Log或者Archived Log文件中,具体写入哪个文件,取决于Primary的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中,则当Primary Database发生日志切换时,也会触发Standby Database上的Standby Redo Log的日志切换,并把这个Standby Redo Log归档。如果是写到Archived Log,那么这个动作本身也可以看作是个归档操作。


    在日志接收中,需要注意的是归档日志会被放在什么位置:

    1) 如果配置了STANDBY_ARCHIVE_DEST参数,则使用该参数指定的目录。

    2) 如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项,则使用这个参数指定的目录。

    3) 如果数据库的COMPATIBLE参数大于等于10.0,则选取任意一个LOG_ARCHIVE_DEST_n的值。

    4) 如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n参数都没有配置,使用缺省的STANDBY_ARCHIVE_DEST参数值缺省值是$ORACLE_HOME/dbs/arc.

     

    3. 日志应用(Redo Apply)

    日志应用服务,就是在Standby Database上重演Primary Database日志,从而实现两个数据库的数据同步。根据Standby Database重演日志方式的不同,可分为物理Standby(Physical Standby)逻辑Standby(Logical Standby)


    Physical Standby使用的是Media Recovery 技术,在数据块级别进行恢复,这种方式没有数据类型的限制,可以保证两个数据库完全一致。Physical Standby数据库只能在Mount 状态下进行恢复,也可以是打开,但只能已只读方式打开,并且打开时不能执行恢复操作。


    Logical Standby 使用的是Logminer 技术,通过把日志内容还原成SQL 语句,然后SQL引擎执行这些语句,Logminer Standby不支持所有数据类型,可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。Logical Standby数据库可以在恢复的同时进行读写操作

     

    Standby数据库的相关进程读取接收到的REDO数据(可能来自于Standby端的归档文件,也可能来自于Standby Redologs),再将其写入Standby数据库。保存之后数据又是怎么生成的呢?两种方式:物理Standby通过REDO应用逻辑Standby通过SQL应用

     

    根据Redo Apply发生的时间可以分成两种: 

    一种是实时应用(Real-Time Apply), 这种方式必须Standby Redo Log,每当日志被写入Standby Redo Log时,就会触发恢复,使用这种方式的好处在与可以减少数据库切换(Switchover 或者Failover)的时间,因为切换时间主要用在剩余日志的恢复上。 

    另一种是归档时应用,这种方式在Primary Database发生日志切换,触发Standby Database 归档操作,归档完成后触发恢复。 这也是默认的恢复方式。

     

    如果是Physical Standby,可以使用下面命令启用Real-Time:

    Alter database recover managed standby database using current logfile;

     

    如果是Logical Standby,可以使用下面命令启用Real-Time:

    Alter database start logical standby apply immediate;

     

    查看是否使用Real-Time apply:

    Select recovery_mode from v$archive_dest_status;

     

     

    SQL> set wrap off
    SQL> select process,status,thread#,sequence#,client_pid from v$managed_standby;

    PROCESS   STATUS          THREAD#  SEQUENCE#      CLIENT_PID
    --------- ---------------------   ----------   -----------------------              ------------

    ARCH      CONNECTED             0          0                                240
    ARCH      CONNECTED             0          0                               196
    ARCH      CONNECTED             0          0                              1944
    ARCH      CONNECTED             0          0                               3956
    MRP0      WAIT_FOR_LOG        1      30843                          N/A
    RFS       RECEIVING                   1      30838                       2620
    RFS       RECEIVING                   1      30837                       2612
    RFS       RECEIVING                   1      30833                       2652
    RFS       ATTACHED                   1      30841                        2628
    RFS       ATTACHED                   1      30835                        2604
    RFS       ATTACHED                   1      30842                       2608

    已选择11行。 

     

     

    二. 数据保护模式

    Data Guard 允许定义3钟数据保护模式,分别是最大保护(Maximum Protection),最大可用(Maximum Availability)和 最大性能(Maximum Performance)。

     

    1. 最大保护(Maximum Protection)

    这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs,还要同时写入到Standby数据库的Standby Redologs,并确认REDO数据至少在一个Standby数据库中可用(如果有多个的话),然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话(比如网络中断),Primary数据库会被Shutdown,以防止数据丢失。

    使用这种方式要求Standby Database必须配置Standby RedoLog,而Primary Database必须使用LGWR,SYNC,AFFIRM方式归档到Standby Database.

     

    2. 最高可用性(Maximum availability)

    这种模式在不影响Primary数据库可用前提下,提供最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中,不过与最大保护模式不同的是,如果出现故障导致Standby数据库无法访问,Primary数据库并不会被Shutdown,而是自动转为最高性能模式,等Standby数据库恢复正常之后,Primary数据库又会自动转换成最高可用性模式。

    这种方式虽然会尽量避免数据丢失,但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby Redo Log,而Primary Database必须使用LGWR,SYNC,AFFIRM 方式归档到Standby Database.

     

    3. 最高性能(Maximum performance)

    缺省模式。 这种模式在不影响Primary数据库性能前提下,提供最高级别的数据保护策略。事务可以随时提交,当前Primary数据库的REDO数据至少需要写入一个Standby数据库,不过这种写入可以是不同步的。如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护,而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时,系统的默认保护模式。

    这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现,Standby Database也不要求使用Standby Redo Log。

     

    4. 修改数据保护模式步骤

    1)关闭数据库,重启到Mount 状态,如果是RAC,需要关闭所有实例,然后只启动一个实例到mount状态。

    2)修改模式:

    语法:ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; 

    如:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

    3) 打开数据库: alter database open;

    4) 确认修改数据保护模式:

    SQL>select protection_mode,protection_level from v$database; 

     

     

     

    三. 自动裂缝检测和解决

    当Primary Database的某些日志没有成功发送到Standby Database,这时候发生了归档裂缝(Archive Gap)。

    缺失的这些日志就是裂缝(Gap)。Data Guard能够自动检测,解决归档裂缝,不需要DBA的介入。这需要配置FAL_CLIENTFAL_SERVER 这两个参数(FAL: Fetch Archive Log)。


    从FAL 这个名字可以看出,这个过程是Standby Database主动发起的“取”日志的过程,Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap, 10g中,这个FAL_SERVER可以是Primary Database, 也可以是其他的Standby Database。

    如:FAL_SERVER='PR1,ST1,ST2';

    FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。FAL_CLIENT 通过网络向FAL_SERVER发送请求,FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时,会携带FAL_CLIENT参数值,用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name,这个Name是在FAL_SERVER上定义的,用来指向FAL_CLIENT.

     

    当然,除了自动地日志缺失解决,DBA 也可以手工解决。 具体操作步骤如下:

     

    1) 查看是否有日志GAP: 

    SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; 

     

    SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 

    2) 如果有,则拷贝过来

    3) 手工的注册这些日志: 

    SQL> ALTER DATABASE REGISTER LOGFILE '路径'; 

     

     

     

     

    四. 指定日志发送对象

     

    1.VALID_FOR属性指定传输及接收对象

    LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性,用来指定传输的内容。从字面理解VALID_FOR就是基于那谁有效,该属性有两个参数值需要指定:REDO_LOG_TYPE和DATABASE_ROLE,我们基本上可以将其理解为:发送指定角色生成的指定类型的日志文件,该参数的主要目的是为了确保,一旦发生角色切换操作后数据库的正常运转

    其中,REDO_LOG_TYPE和DATABASE_ROLE两个参数可供选择的参数值如下:

    REDO_LOG_TYPE:可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。  

    DATABASE_ROLE:可设置为PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。 

     

    注意VALID_FOR参数默认值VALID_FOR=(ALL_LOGFILES,ALL_ROLES)。 

     

    推荐手动设置该参数而不要使用默认值,在某些情况下默认的参数值不一定合适,如逻辑Standby在默认情况下就处于OPEN READ WRITE模式,不仅有REDO数据而且还包含多种日志文件(Online Redologs、Archived Redologs及Standby Redologs)。

    默认情况下,逻辑Standby数据库生成的归档文件和接收到的归档文件在相同的路径下,这既不便于管理,也极有可能带来一些隐患。建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。

     

    2.通过DB_UNIQUE_NAME属性指定数据库

    DB_UNIQUE_NAME属性是10g版本新增加的一个关键字,在之前版本并没有这一说法。该属性的作用是指定唯一的Oracle数据库名称,也正因有了DB_UNIQUE_NAME,REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。

    当然要确保REDO数据被传输到指定服务器,除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外,还有一个初始化参数LOG_ARCHIVE_CONFIG也需要进行正确的配置。该参数除了指定Data Guard环境中的唯一数据库名外,还包括几个属性,用来控制REDO数据的传输和接收:

    SEND:允许数据库发送数据到远端。

    RECEIVE:允许Standby接收来自其他数据库的数据。

    NOSEND,NORECEIVE:自然就是禁止喽。

     

    例如,设置Primary数据库不接收任何归档数据,可以做如下的设置:

    LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG= (PRI,ST) ' 

    如果做了如上的设置,如果该服务器发生了角色切换,那它也没有接收REDO数据的能力。

     

     

    五. Data Guard环境应配置的初始化参数

     

     

       下列参数为Primary角色相关的初始化参数


      DB_NAME

    注意保持同一个Data Guard中所有数据库DB_NAME相同

    例如:DB_NAME=Dave


      DB_UNIQUE_NAME

    为每一个数据库指定一个唯一的名称,该参数一经指定不会再发生变化,除非DBA主动修改它

    例如:DB_UNIQUE_NAME=DavePre



      LOG_ARCHIVE_CONFIG

    该参数用来控制从远端数据库接收或发送REDO数据,通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含Primary数据库和Standby数据库),以逗号分隔,SEND/NOSEND属性控制是否可以发送,RECEIVE/NORECEIVE属性控制是否能够接收

    例如:LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'



      LOG_ARCHIVE_DEST_n

    归档文件的生成路径。该参数非常重要,并且属性和子参数也特别多(可以直接查询Oracle官方文档。Data Guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如:

    LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'



     LOG_ARCHIVE_DEST_STATE_n

    是否允许REDO传输服务传输REDO数据到指定的路径。该参数共拥有4个属性值,功能各不相同。



     REMOTE_LOGIN_PASSWORDFILE

    推荐设置参数值为EXCLUSIVE或者SHARED,注意保证相同Data Guard配置中所有DB服务器SYS密码相同



      以下参数为与Standby角色相关的参数(建议在Primary数据库的初始化参数中也进行设置,这样即使发  生角色切换,新的Standby也能直接正常运行)


      FAL_SERVER

    指定一个Net服务名,该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时,如果发现存在归档中断的情况,该参数用来指定获取中断的归档文件的服务器

    例如:FAL_SERVER=DavePre

    提示:FAL是Fetch Archived Log的缩写

    FAL_SERVER参数支持多个参数值的哟,相互间以逗号分隔



      FAL_CLIENT

    又指定一个Net服务名,该参数对应数据库应为Standby角色。当本地数据库以Primary角色运行时,向参数值中指定的站点发送中断的归档文件

    例如:FAL_CLIENT=DaveDG

    FAL_CLIENT参数也支持多个参数值,相互间以逗号分隔。




      DB_FILE_NAME_CONVERT

    Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时,可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现,前面的值表示转换前的形式,后面的值表示转换后的形式

    例如:DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'



      LOG_FILE_NAME_CONVERT

      使用方式与上相同,只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径

    例如:

    LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'



      STANDBY_FILE_MANAGEMENT

    如果Primary数据库数据文件发生修改(如新建、重命名等)则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理

    例如:STANDBY_FILE_MANAGEMENT=AUTO

     

     

    对于归档失败的处理,LOG_ARCHIVE_DEST_n参数有几个属性,可以用来控制归档过程中出现故障时应该采取的措施。


    1.REOPEN 指定时间后再次尝试归档

    使用REOPEN=seconds(默认为300秒)属性,在指定时间重复尝试向归档目的地进行归档操作,如果该参数值设置为0,则一旦失败就不会再尝试重新连接并发送,直到下次REDO数据再被归档时会重新尝试。

    例如,设置REOPEN为100秒:

    LOG_ARCHIVE_DEST_2='SERVICE=DavePrimary LGWR ASYNC REOPEN=100' 

    2.ALTERNATE 指定替补的归档目的地


    ALTERNATE属性定义一个替补的归档目的地,所谓替补就是一旦主归档目的地因各种原因无法使用,则临时向ALTERNATE属性中指定的路径写。

    例如:

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2' 

    LOG_ARCHIVE_DEST_STATE_1=ENABLE  

    LOG_ARCHIVE_DEST_2='LOCATION=/disk2' 

    LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 


    上述参数设置归档路径为/disk1,当/disk1路径下无法成功归档时,自动尝试向/disk2路径下归档文件。

    从功能上来看,REOPEN与ALTERNATE是有一定重复的,不过需要注意一点,REOPEN属性比ALTERNATE属性的优先级要高,如果你指定REOPEN属性的值>0,则LGWR(或ARCn)进程会首先尝试向主归档目的地写入,直到达到最大重试次数,如果仍然写入失败,才会向ALTERNATE属性指定的路径写。

     

    3.MAX_FAILURE 控制失败尝试次数

    用REOPEN指定失败后重新尝试的时间周期,MAX_FAILURE则控制失败尝试的次数。

    例如,设置LOG_ARCHIVE_DEST_1在本地归档文件时,如果遇到错误,则每隔100秒尝试一次,共尝试不超过3次,设置如下:

    LOG_ARCHIVE_DEST_1='LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3'  

     

     

    六. 物理Standby 和逻辑Standby 的区别

    Standby数据库类型分为两类:物理Standby和逻辑Standby。

     

    1.物理Standby

    我们知道物理Standby与Primary数据库完全一模一样,DG通过REDO应用来维护物理Standby数据库。

    通常在物理Standby没有执行REDO应用操作的时候,可以将物理Standby数据库以READ ONLY模式打开,如果数据库中指定了Flashback Area的话,甚至还可以被临时性的置为READ WRITE模式,操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态,以便继续接收Primary端发送的REDO并应用。

    REDO应用。物理Standby通过REDO应用来保持与Primary数据库的一致性,所谓的REDO应用,实质是通过Oracle的恢复机制,应用归档文件(或Standby Redologs文件)中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作,Oracle数据库就不能被Open。


    READ ONLY模式打开。以READ ONLY模式打开后,可以在Standby数据库执行查询或备份等操作(变相减轻Primary数据库压力)。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据,不过并不会应用,直到Standby数据库重新恢复REDO应用。

    也就是说在READ ONLY模式下不能执行REDO应用,REDO应用时数据库肯定处于未打开状态。如果需要的话,你可以在两种状态间转换,如先应用REDO,然后将数据库置为READ ONLY状态,需要与Primary同步时再次执行REDO应用命令,切换回REDO应用状态。

     

    提 示 Oracle 11g版本中增强物理Standby的应用功能,在11g版本中,物理Standby可以在OPEN READ ONLY模式下继续应用REDO数据,这就极大地提升了物理Standby数据库的应用场合。

     

    READ WRITE模式打开。如果以READ WRITE模式打开,那么Standby数据库将暂停从Primary数据库接收REDO数据,并且暂时失去灾难保护的功能。当然,以READ WRITE模式打开也并非一无是处,如你可能需要临时调试一些数据,但又不方便在正式库中操作,那就可以临时将Standby数据库置为READ WRITE模式,操作完之后将数据库闪回到操作前的状态(闪回之后,Data Guard会自动同步,不需要重建物理Standby,不过如果从另一个方向看,没有启动闪回,那就回不到READ WRITE前的状态了)。

     

    物理Standby特点如下:

    (1)灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复,以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。

    (2)数据保护。使用物理Standby数据库,DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制,因此与对象、语句无关,Primary数据库上有什么,物理Standby数据库端也会有什么。

    (3)分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库,可以有效节省Primary数据库的CPU及I/O资源。

    (4)提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制,这种机制能够绕过SQL级代码层,因此效率最高。

     

     

    2.逻辑Standby

    逻辑Standby也要通过Primary数据库(或其备份,或其复制库,如物理Standby)创建,因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据,因此逻辑Standby的物理文件结构,甚至数据的逻辑结构都可以与Primary不一致。

    与物理Standby不同,逻辑Standby正常情况下是以READ WRITE模式打开,用户可以在任何时候访问逻辑Standby数据库,就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊,由于SQL应用自身特点,逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。

    逻辑Standby 的读写打开可以使它做报表系统,这样减轻系统的压力。

     

    除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外,逻辑Standby还有下列一些特点:

    (1)有效地利用备机的硬件资源。除灾难恢复外,逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要;又如创建新的SCHEMA(该SCHEMA在Primary数据库端并不存在),然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。

    (2)分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态,这使得逻辑Standby数据库能够同时用于数据保护和报表操作,从而将主数据库从报表和查询任务中解脱出来,节约宝贵的 CPU和I/O资源。

    (3)平滑升级。可以通过逻辑Standby来实现如跨版本升级,为数据库打补丁等操作。应该说应用的空间很大,而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作,但如果跨平台的话恐怕就力不从心了,所以此项没有作为物理Standby的特点列出),我个人认为这是一种值得可行的在线的滚动的平滑的升级方式,如果你的应用支持创建逻辑Standby的话。

     

    七. Log应用服务(Log Apply Services)


    Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性,在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式:

    REDO应用:物理Standby数据库专用,通过介质恢复的方式保持与Primary数据库的同步。

    SQL应用:逻辑Standby数据库专用,核心是通过LogMiner分析出SQL语句在Standby端执行。

     

    因此物理Standby在应用REDO数据时必须是MOUNT状态,而逻辑Standby则是以READ WRITE模式打开并应用REDO数据,不过被维护的对象默认处于只读状态,无法在逻辑Standby端直接修改。

     

    7.1  Log应用服务配置选项

    默认情况下,Log应用服务会等待单个归档文件全部接收之后再启动应用,如果Standby数据库配置了Standby Redologs,就可以打开实时应用(Real-Time Apply),这样Data Guard就不需要再等待接收完归档文件,只要RFS进程将REDO数据写入Standby Redologs,即可通过MRP/LSP实时写向Standby数据库。

     

    7.1.1.REDO数据实时应用

    启动实时应用的优势在于,REDO数据不需要等待归档完成,接收到即可被应用,这样执行角色切换时,操作能够执行得更快,因为日志是被即时应用的。

    要启动实时应用也简单,前提是Standby数据库端配置了Standby Redologs

     

    物理Standby要启用实时应用,要在启动REDO应用的语句后附加USING CURRENT LOGFIE子句,例如:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE ; 

     

    逻辑Standby要启用实时应用,只需要在启动REDO应用的语句后附加IMMEDIATE子句即可,例如:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

     

    7.1.2.REDO数据延迟应用

    有实时就有延迟,某些情况下你可能不希望Standby数据库与Primary太过同步,那就可以在Primary数据库端发送REDO数据的相应LOG_ARCHIVE_DEST_n参数中指定DELAY属性(单位为分钟如果指定了DELAY属性,但没有指定值,则默认是30分钟)。

     

    注意该属性并不是说延迟发送REDO数据到Standby,而是指明归档到Standby后,开始应用的时间。

     

    例如:设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟:

    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DavePrimary ARCH VALID_ FOR=  

    (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15'; 

     

    不过,如果DBA在启动REDO应用时指定了实时应用,那么即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性,Standby数据库也会忽略DELAY属性

     

    另外,Standby端还可以在启动REDO应用时,通过附加NODELAY子句的方式,取消延迟应用。

     

    物理Standby可以通过下列语句取消延迟应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 

     

    逻辑Standby可以通过下列语句取消延迟应用:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; 

     

    一般设置延迟应用的需求都是基于容错方面的考虑,如Primary数据库端由于误操作,数据被意外修改或删除,只要Standby数据库尚未应用这些修改,你就可以快速从Standby数据库中恢复这部分数据。不过自Oracle从9i版本开始提供FLASHBACK特性之后,对于误操作使用FLASHBACK特性进行恢复,显然更加方便快捷,因此DELAY方式延迟应用已经非常少见了。

     

    7.2  应用REDO数据到Standby数据库

     

    7.2.1.物理Standby应用REDO数据

    物理Standby启动REDO应用,数据库要处于MOUNT状态或是OPEN READ ONLY状态,启动REDO应用的命令相信大家已经非常熟悉了。

    前台应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 

    语句执行完成后,不会将控制权返回到命令行窗口,除非你手动中止应用。在这种情况下如果还需要对数据库进行操作,只能新开一个命令行连接,在Oracle 8i刚推出Standby特性时(那时不叫Data Guard),只提供了这种方式。

     

    后台应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 

    这是现在比较通用的方式,语句执行完后,控制权自动返回到当前的命令行模式,REDO应用以后台进程运行。

     

    启动实时应用,附加USING CURRENT LOGFILE子句即可:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; 

     

    如果要停止REDO应用,执行下列语句即可:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

     

    7.2.2.逻辑Standby应用REDO数据

    SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行,因此逻辑Standby需要启动至OPEN状态。

    (1)启动SQL应用。逻辑Standby数据库启动SQL应用没有前、后台运行之说,语句执行完之后,控制权就会自动返回当前命令行窗口。

    要启动SQL应用,直接执行下列语句即可:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 

    如果要启动实时应用,附加IMMEDIATE子句即可,例如:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

    (2)停止SQL应用,如:

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

    由于是执行SQL语句的方式应用REDO数据,因此上述语句的执行需要等待当前执行的SQL触发的事务结束,才能真正停止REDO应用的状态。

    如果不考虑事务执行情况,马上停止REDO应用,可以通过下列的语句来完成:

    SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY; 


    --核心进程介绍

    RFS:remote file server。
    该进程是standby库接受来自primary库lgwr进程触发的redo信息并且写入到standby redo log中。RFS进程无疑是要和其他进程配合的,也就是传输的进程。那这里就需要上篇的知识了,我们知道触发同步可能由ARCH或者是LGWR进程触发的,两者是不同的。如果是LGWR进程触发,那10g前的话也是由LGWR进程负责传输redo信息,RFS进程负责接收redo信息写入standby redo log中,10g之后则由LNSn进程完成;如果是ARCH进程触发,也就是归档日志传输的话,那就是由ARCH进程负责传输,RFS进程负责接收,然后写入指定的归档位置,然后再应用的。那这里不同的设置也决定了参数LOG_ARCHIVE_DEST_n的不同设置。详细见下。


    LNSn:LGWR触发以后真正负责传输的进程,包括初始化网络I/O等一些列功能。


    MRP:managed recovery process,简单来说就是物理standby是通过这个进程来实现数据的同步的,直接通过standby redo log或者是归档日志(取决于模式不同)来进行的一个数据恢复。


    LSP:logical standby process:逻辑standby的方式,和上面的一样,只不过当中多了一步将redo信息转换成sql语句再恢复。也可以从这里看出逻辑standby和物理standby的不同。


    参考来源于http://blog.csdn.net/lmocm/article/details/42971799,http://blog.csdn.net/qq_21127313/article/details/50792223感谢原作者。

    展开全文
  • DGDG概念原理详解

    2019-03-25 13:56:03
    DGDG概念原理详解 RAC,DataGurad,Stre...
        

    【DG】DG概念原理详解




    RAC, Data Gurad, Stream 是Oracle 高可用性体系中的三种工具,每个工具即可以独立应用,也可以相互配合。 他们各自的侧重点不同,适用场景也不同。

    RAC 它的强项在于解决单点故障和负载均衡,因此RAC 方案常用于7*24 的核心系统,但RAC 方案中的数据只有一份,尽管可以通过RAID 等机制可以避免存储故障,但是数据本身是没有冗余的,容易形成单点故障。

    Data Gurad 通过冗余数据来提供数据保护,Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步,这种同步可以是实时,延时,同步,异步多种形式。Data Gurad 常用于异地容灾和小企业的高可用性方案,虽然可以在Standby 机器上执行只读查询,从而分散Primary 数据库的性能压力,但是Data Gurad 决不是性能解决方案。

    Stream 是以Oracle Advanced Queue为基础实现的数据同步,提供了多种级别的灵活配置,并且Oracle 提供了丰富的API等开发支持,Stream 更适用在应用层面的数据共享。

     

     

    在Data Gurad 环境中,至少有两个数据库,一个处于Open 状态对外提供服务,这个数据库叫作Primary Database。 第二个处于恢复状态,叫作Standby Database。 运行时primary Database 对外提供服务,用户在Primary Database 上进行操作,操作被记录在联机日志和归档日志中,这些日志通过网络传递给Standby Database。 这个日志会在Standby Database 上重演,从而实现Primary Database 和Standby Database 的数据同步。

    Oracle Data Gurad 对这一过程进一步的优化设计,使得日志的传递,恢复工作更加自动化,智能化,并且提供一系列参数和命令简化了DBA工作。

    如果是可预见因素需要关闭Primary Database,比如软硬件升级,可以把Standby Database 切换为Primary Database 继续对外服务,这样即减少了服务停止时间,并且数据不会丢失。如果异常原因导致Primary Database 不可用,也可以把Standby Database 强制切换为Primary Database继续对外服务,这时数据损失成都和配置的数据保护级别有关系。因此Primary 和Standby 只是一个角色概念,并不固定在某个数据库中。

      

    一. Data Guard 架构

    DG架构可以按照功能分成3个部分:

    1) 日志发送(Redo Send)

    2) 日志接收(Redo Receive)

    3) 日志应用(Redo Apply)

     

    1. 日志发送(Redo Send)

     Primary Database 运行过程中,会源源不断地产生Redo 日志,这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成, 不同的归档目的地可以使用不同的方法,但是对于一个目的地,只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。 

     

    1.1 使用ARCH 进程

    1)Primary Database 不断产生Redo Log,这些日志被LGWR 进程写到联机日志。

    2)当一组联机日志被写满后,会发生日志切换(Log Switch),并且会触发本地归档,本地归档位置是采用 LOG_ARCHIVE_DEST_1='LOCATION=/path' 这种格式定义的。

    如:alter system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;

    3)完成本地归档后,联机日志就可以被覆盖重用。

    4)ARCH 进程通过Net 把归档日志发送给Standby Database的RFS(Remote File Server)进程。

    5)Standby Database 端的RFS 进程把接收的日志写入到归档日志。

    6)Standby Database 端的MRP(Managed Recovery Process)进程Redo Apply)或者LSP 进程SQL Apply)在Standby Database上应用这些日志,进而同步数据。

     

    用ARCH模式传输不写入备机的重做日志(Standby Redologs),直接保存成归档文件存放于Standby端

     

    说明:

    逻辑Standby接收后将其转换成SQL语句,在Standby数据库上执行SQL语句实现同步,这种方式叫SQL Apply

    物理Standby接收完Primary数据库生成的REDO数据后,以介质恢复的方式实现同步,这种方式也叫Redo Apply

     

    注意:创建逻辑Standby数据库先创建一个物理Standby数据库,然后再将其转换成逻辑Standby数据库

     

     

    使用ARCH进程传递最大问题在于: Primary Database 只有在发生归档时才会发送日志到Standby Database。 如果Primary Database 异常宕机,联机日志中的Redo 内容就会丢失,因此使用ARCH 进程无法避免数据丢失的问题,要想避免数据丢失,就必须使用LGWR,而使用LGWR 又分SYNC(同步)和ASYNC(异步)两种方式。

     

    在缺省方式下,Primary Database使用的是ARCH进程,参数设置如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

     

    1.2 使用LGWR 进程的SYNC 方式

    1)Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程(LGWR Network Server Process,再由LNSn(LGWR Network Server process进程把日志通过网络发送给远程的目的地,每个远程目的地对应一个LNS进程,多个LNS进程能够并行工作。

    2)LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功,Primary Database 上的事务才能提交,这也是SYNC的含义所在。

    3)Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。

    4)Primary Database的日志切换也会触发Standby Database 上的日志切换,即Standby Database 对Standby Redo Log的归档,然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。

     

    因为Primary Database 的Redo 是实时传递的,于是Standby Database 端可以使用两种恢复方法: 

    实时恢复(Real-Time Apply): 只要RFS把日志写入Standby Redo Log 就会立即进行恢复;

    归档恢复: 在完成对Standby Redo Log 归档才触发恢复。

     

      Primary Database默认使用ARCH进程,如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时,可以同时使用NET_TIMEOUT参数,这个参数单位是秒,代表如果多长时间内网络发送没有响应,LGWR 进程会抛出错误。 示例如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  SYNC  NET_TIMEOUT=30' scope=both;

     

    1.3 使用LGWR进程的ASYNC 方式

    使用LGWR SYNC方法的可能问题在于,如果日志发送给Standby Database过程失败,LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况,有时这种要求可能过于苛刻,这时就可以使用LGWR ASYNC方式。 它的工作机制如下:

    1) Primary Database 一段产生Redo 日志后,LGWR 把日志同时提交给日志文件和本地LNS 进程,但是LGWR进程只需成功写入日志文件就可以,不必等待LNSn进程的网络传送成功。

    2) LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。

    3) Primary Database的Online Redo Log 写满后发生Log Switch,触发归档操作,也触发Standby Database对Standby Redo Log 的归档;然后触发MRP或者LSP 进程恢复归档日志。

     

    因为LGWR进程不会等待LNSn进程的响应结果,所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下:

    alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  ASYNC ' scope=both;

     

    2. 日志接收(Redo Receive)

    Standby Database 的RFS(Remote File Server进程接收到日志后,就把日志写到Standby Redo Log或者Archived Log文件中,具体写入哪个文件,取决于Primary 的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中,则当Primary Database发生日志切换时,也会触发Standby Database上的Standby Redo Log 的日志切换,并把这个Standby Redo Log 归档。 如果是写到Archived Log,那么这个动作本身也可以看作是个归档操作。


    在日志接收中,需要注意的是归档日志会被放在什么位置:

    1) 如果配置了STANDBY_ARCHIVE_DEST 参数,则使用该参数指定的目录。

    2) 如果某个LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项,则使用这个参数指定的目录。

    3) 如果数据库的COMPATIBLE参数大于等于10.0,则选取任意一个LOG_ARCHIVE_DEST_n的值。

    4) 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置,使用缺省的STANDBY_ARCHIVE_DEST参数值,这个缺省值是$ORACLE_HOME/dbs/arc.

     

    3. 日志应用(Redo Apply)

    日志应用服务,就是在Standby Database上重演Primary Database日志,从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同,可分为物理Standby(Physical Standby) 和 逻辑Standby(Logical Standby)


    Physical Standby 使用的是Media Recovery 技术,在数据块级别进行恢复,这种方式没有数据类型的限制,可以保证两个数据库完全一致。 Physical Standby数据库只能在Mount 状态下进行恢复,也可以是打开,但只能已只读方式打开,并且打开时不能执行恢复操作。


    Logical Standby 使用的是Logminer 技术,通过把日志内容还原成SQL 语句,然后SQL引擎执行这些语句,Logminer Standby不支持所有数据类型,可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。 Logical Standby数据库可以在恢复的同时进行读写操作

     

    Standby数据库的相关进程读取接收到的REDO数据(可能来自于Standby端的归档文件,也可能来自于Standby Redologs),再将其写入Standby数据库。保存之后数据又是怎么生成的呢?两种方式:物理Standby通过REDO应用逻辑Standby通过SQL应用

     

    根据Redo Apply发生的时间可以分成两种: 

    一种是实时应用(Real-Time Apply), 这种方式必须Standby Redo Log,每当日志被写入Standby Redo Log时,就会触发恢复,使用这种方式的好处在与可以减少数据库切换(Switchover 或者Failover)的时间,因为切换时间主要用在剩余日志的恢复上。 

    另一种是归档时应用,这种方式在Primary Database发生日志切换,触发Standby Database 归档操作,归档完成后触发恢复。 这也是默认的恢复方式。

     

    如果是Physical Standby,可以使用下面命令启用Real-Time:

    Alter database recover managed standby database using current logfile;

     

    如果是Logical Standby,可以使用下面命令启用Real-Time:

    Alter database start logical standby apply immediate;

     

    查看是否使用Real-Time apply:

    Select recovery_mode from v$archive_dest_status;

     

     

    SQL> set wrap off
    SQL> select process,status,thread#,sequence#,client_pid from v$managed_standby;

    PROCESS   STATUS          THREAD#  SEQUENCE#      CLIENT_PID
    --------- ---------------------   ----------   -----------------------              ------------

    ARCH      CONNECTED             0          0                                240
    ARCH      CONNECTED             0          0                               196
    ARCH      CONNECTED             0          0                              1944
    ARCH      CONNECTED             0          0                               3956
    MRP0      WAIT_FOR_LOG        1      30843                          N/A
    RFS       RECEIVING                   1      30838                       2620
    RFS       RECEIVING                   1      30837                       2612
    RFS       RECEIVING                   1      30833                       2652
    RFS       ATTACHED                   1      30841                        2628
    RFS       ATTACHED                   1      30835                        2604
    RFS       ATTACHED                   1      30842                       2608

    已选择11行。 

     

     

    二. 数据保护模式

    Data Guard 允许定义3钟数据保护模式,分别是最大保护(Maximum Protection),最大可用(Maximum Availability)和 最大性能(Maximum Performance)。

     

    1. 最大保护(Maximum Protection)

    这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs,还要同时写入到Standby数据库的Standby Redologs,并确认REDO数据至少在一个Standby数据库中可用(如果有多个的话),然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话(比如网络中断),Primary数据库会被Shutdown,以防止数据丢失。

    使用这种方式要求Standby Database 必须配置Standby Redo Log,而Primary Database必须使用LGWR,SYNC,AFFIRM 方式归档到Standby Database.

     

    2. 最高可用性(Maximum availability)

    这种模式在不影响Primary数据库可用前提下,提供最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中,不过与最大保护模式不同的是,如果出现故障导致Standby数据库无法访问,Primary数据库并不会被Shutdown,而是自动转为最高性能模式,等Standby数据库恢复正常之后,Primary数据库又会自动转换成最高可用性模式。

    这种方式虽然会尽量避免数据丢失,但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby Redo Log,而Primary Database必须使用LGWR,SYNC,AFFIRM 方式归档到Standby Database.

     

    3. 最高性能(Maximum performance)

    缺省模式。 这种模式在不影响Primary数据库性能前提下,提供最高级别的数据保护策略。事务可以随时提交,当前Primary数据库的REDO数据至少需要写入一个Standby数据库,不过这种写入可以是不同步的。如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护,而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时,系统的默认保护模式。

    这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现,Standby Database也不要求使用Standby Redo Log。

     

    4. 修改数据保护模式步骤

    1)关闭数据库,重启到Mount 状态,如果是RAC,需要关闭所有实例,然后只启动一个实例到mount状态。

    2)修改模式:

    语法:ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; 

    如:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

    3) 打开数据库: alter database open;

    4) 确认修改数据保护模式:

    SQL>select protection_mode,protection_level from v$database; 

     

     

     

    三. 自动裂缝检测和解决

     

          当Primary Database的某些日志没有成功发送到Standby Database, 这时候发生了归档裂缝(Archive Gap)。

    缺失的这些日志就是裂缝(Gap)。 Data Guard能够自动检测,解决归档裂缝,不需要DBA的介入。这需要配置FAL_CLIENT FAL_SERVER 这两个参数(FAL: Fetch Archive Log)。


    从FAL 这个名字可以看出,这个过程是Standby Database主动发起的“取”日志的过程,Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap, 10g中,这个FAL_SERVER可以是Primary Database, 也可以是其他的Standby Database。

    如:FAL_SERVER='PR1,ST1,ST2';

    FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。 FAL_CLIENT 通过网络向FAL_SERVER发送请求,FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时,会携带FAL_CLIENT参数值,用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name,这个Name是在FAL_SERVER上定义的,用来指向FAL_CLIENT.

     

    当然,除了自动地日志缺失解决,DBA 也可以手工解决。 具体操作步骤如下:

     

    1) 查看是否有日志GAP: 

        SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; 

     

      SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 

       2) 如果有,则拷贝过来

    3) 手工的注册这些日志: 

    SQL> ALTER DATABASE REGISTER LOGFILE '路径'; 

     

     

     

     

    四. 指定日志发送对象

     

    1.VALID_FOR属性指定传输及接收对象

    LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性,用来指定传输的内容。从字面理解VALID_FOR就是基于那谁有效,该属性有两个参数值需要指定:REDO_LOG_TYPE和DATABASE_ROLE,我们基本上可以将其理解为:发送指定角色生成的指定类型的日志文件,该参数的主要目的是为了确保,一旦发生角色切换操作后数据库的正常运转

    其中,REDO_LOG_TYPE和DATABASE_ROLE两个参数可供选择的参数值如下:

    REDO_LOG_TYPE:可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。  

    DATABASE_ROLE:可设置为PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。 

     

    注意VALID_FOR参数默认值VALID_FOR=(ALL_LOGFILES,ALL_ROLES)。 

     

    推荐手动设置该参数而不要使用默认值,在某些情况下默认的参数值不一定合适,如逻辑Standby在默认情况下就处于OPEN READ WRITE模式,不仅有REDO数据而且还包含多种日志文件(Online Redologs、Archived Redologs及Standby Redologs)。

    默认情况下,逻辑Standby数据库生成的归档文件和接收到的归档文件在相同的路径下,这既不便于管理,也极有可能带来一些隐患。建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。

     

    2.通过DB_UNIQUE_NAME属性指定数据库

    DB_UNIQUE_NAME属性是10g版本新增加的一个关键字,在之前版本并没有这一说法。该属性的作用是指定唯一的Oracle数据库名称,也正因有了DB_UNIQUE_NAME,REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。

    当然要确保REDO数据被传输到指定服务器,除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外,还有一个初始化参数LOG_ARCHIVE_CONFIG也需要进行正确的配置。该参数除了指定Data Guard环境中的唯一数据库名外,还包括几个属性,用来控制REDO数据的传输和接收:

    SEND:允许数据库发送数据到远端。

    RECEIVE:允许Standby接收来自其他数据库的数据。

    NOSEND,NORECEIVE:自然就是禁止喽。

     

    例如,设置Primary数据库不接收任何归档数据,可以做如下的设置:

    LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG= (PRI,ST) ' 

    如果做了如上的设置,如果该服务器发生了角色切换,那它也没有接收REDO数据的能力。

     

     

    五. Data Guard环境应配置的初始化参数

     

     

       下列参数为Primary角色相关的初始化参数


      DB_NAME

    注意保持同一个Data Guard中所有数据库DB_NAME相同

    例如:DB_NAME=Dave


      DB_UNIQUE_NAME

    为每一个数据库指定一个唯一的名称,该参数一经指定不会再发生变化,除非DBA主动修改它

    例如:DB_UNIQUE_NAME=DavePre



      LOG_ARCHIVE_CONFIG

    该参数用来控制从远端数据库接收或发送REDO数据,通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含Primary数据库和Standby数据库),以逗号分隔,SEND/NOSEND属性控制是否可以发送,RECEIVE/NORECEIVE属性控制是否能够接收

    例如:LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'



      LOG_ARCHIVE_DEST_n

    归档文件的生成路径。该参数非常重要,并且属性和子参数也特别多(可以直接查询Oracle官方文档。Data Guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如:

    LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'



     LOG_ARCHIVE_DEST_STATE_n

    是否允许REDO传输服务传输REDO数据到指定的路径。该参数共拥有4个属性值,功能各不相同。



     REMOTE_LOGIN_PASSWORDFILE

    推荐设置参数值为EXCLUSIVE或者SHARED,注意保证相同Data Guard配置中所有DB服务器SYS密码相同



      以下参数为与Standby角色相关的参数(建议在Primary数据库的初始化参数中也进行设置,这样即使发  生角色切换,新的Standby也能直接正常运行)


      FAL_SERVER

    指定一个Net服务名,该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时,如果发现存在归档中断的情况,该参数用来指定获取中断的归档文件的服务器

    例如:FAL_SERVER=DavePre

    提示:FAL是Fetch Archived Log的缩写

    FAL_SERVER参数支持多个参数值的哟,相互间以逗号分隔



      FAL_CLIENT

    又指定一个Net服务名,该参数对应数据库应为Standby角色。当本地数据库以Primary角色运行时,向参数值中指定的站点发送中断的归档文件

    例如:FAL_CLIENT=DaveDG

    FAL_CLIENT参数也支持多个参数值,相互间以逗号分隔。




      DB_FILE_NAME_CONVERT

    Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时,可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现,前面的值表示转换前的形式,后面的值表示转换后的形式

    例如:DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'



      LOG_FILE_NAME_CONVERT

      使用方式与上相同,只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径

    例如:

    LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'



      STANDBY_FILE_MANAGEMENT

    如果Primary数据库数据文件发生修改(如新建、重命名等)则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理

    例如:STANDBY_FILE_MANAGEMENT=AUTO

     

     

    对于归档失败的处理,LOG_ARCHIVE_DEST_n参数有几个属性,可以用来控制归档过程中出现故障时应该采取的措施。


    1.REOPEN 指定时间后再次尝试归档

    使用REOPEN=seconds(默认为300秒)属性,在指定时间重复尝试向归档目的地进行归档操作,如果该参数值设置为0,则一旦失败就不会再尝试重新连接并发送,直到下次REDO数据再被归档时会重新尝试。

    例如,设置REOPEN为100秒:

    LOG_ARCHIVE_DEST_2='SERVICE=DavePrimary LGWR ASYNC REOPEN=100' 

    2.ALTERNATE 指定替补的归档目的地


    ALTERNATE属性定义一个替补的归档目的地,所谓替补就是一旦主归档目的地因各种原因无法使用,则临时向ALTERNATE属性中指定的路径写。

    例如:

    LOG_ARCHIVE_DEST_1='LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2' 

    LOG_ARCHIVE_DEST_STATE_1=ENABLE  

    LOG_ARCHIVE_DEST_2='LOCATION=/disk2' 

    LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 


    上述参数设置归档路径为/disk1,当/disk1路径下无法成功归档时,自动尝试向/disk2路径下归档文件。

    从功能上来看,REOPEN与ALTERNATE是有一定重复的,不过需要注意一点,REOPEN属性比ALTERNATE属性的优先级要高,如果你指定REOPEN属性的值>0,则LGWR(或ARCn)进程会首先尝试向主归档目的地写入,直到达到最大重试次数,如果仍然写入失败,才会向ALTERNATE属性指定的路径写。

     

    3.MAX_FAILURE 控制失败尝试次数

    用REOPEN指定失败后重新尝试的时间周期,MAX_FAILURE则控制失败尝试的次数。

    例如,设置LOG_ARCHIVE_DEST_1在本地归档文件时,如果遇到错误,则每隔100秒尝试一次,共尝试不超过3次,设置如下:

    LOG_ARCHIVE_DEST_1='LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3'  

     

     

    六. 物理Standby 和逻辑Standby 的区别

    Standby数据库类型分为两类:物理Standby和逻辑Standby。

     

    1.物理Standby

    我们知道物理Standby与Primary数据库完全一模一样,DG通过REDO应用来维护物理Standby数据库。

    通常在物理Standby没有执行REDO应用操作的时候,可以将物理Standby数据库以READ ONLY模式打开,如果数据库中指定了Flashback Area的话,甚至还可以被临时性的置为READ WRITE模式,操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态,以便继续接收Primary端发送的REDO并应用。

    REDO应用。物理Standby通过REDO应用来保持与Primary数据库的一致性,所谓的REDO应用,实质是通过Oracle的恢复机制,应用归档文件(或Standby Redologs文件)中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作,Oracle数据库就不能被Open。


    READ ONLY模式打开。以READ ONLY模式打开后,可以在Standby数据库执行查询或备份等操作(变相减轻Primary数据库压力)。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据,不过并不会应用,直到Standby数据库重新恢复REDO应用。

    也就是说在READ ONLY模式下不能执行REDO应用,REDO应用时数据库肯定处于未打开状态。如果需要的话,你可以在两种状态间转换,如先应用REDO,然后将数据库置为READ ONLY状态,需要与Primary同步时再次执行REDO应用命令,切换回REDO应用状态。

     

    提 示 Oracle 11g版本中增强物理Standby的应用功能,在11g版本中,物理Standby可以在OPEN READ ONLY模式下继续应用REDO数据,这就极大地提升了物理Standby数据库的应用场合。

     

    READ WRITE模式打开。如果以READ WRITE模式打开,那么Standby数据库将暂停从Primary数据库接收REDO数据,并且暂时失去灾难保护的功能。当然,以READ WRITE模式打开也并非一无是处,如你可能需要临时调试一些数据,但又不方便在正式库中操作,那就可以临时将Standby数据库置为READ WRITE模式,操作完之后将数据库闪回到操作前的状态(闪回之后,Data Guard会自动同步,不需要重建物理Standby,不过如果从另一个方向看,没有启动闪回,那就回不到READ WRITE前的状态了)。

     

    物理Standby特点如下:

    (1)灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复,以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。

    (2)数据保护。使用物理Standby数据库,DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制,因此与对象、语句无关,Primary数据库上有什么,物理Standby数据库端也会有什么。

    (3)分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库,可以有效节省Primary数据库的CPU及I/O资源。

    (4)提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制,这种机制能够绕过SQL级代码层,因此效率最高。

     

     

    2.逻辑Standby

    逻辑Standby也要通过Primary数据库(或其备份,或其复制库,如物理Standby)创建,因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据,因此逻辑Standby的物理文件结构,甚至数据的逻辑结构都可以与Primary不一致。

    与物理Standby不同,逻辑Standby正常情况下是以READ WRITE模式打开,用户可以在任何时候访问逻辑Standby数据库,就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊,由于SQL应用自身特点,逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。

        逻辑Standby 的读写打开可以使它做报表系统,这样减轻系统的压力。

     

    除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外,逻辑Standby还有下列一些特点:

    (1)有效地利用备机的硬件资源。除灾难恢复外,逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要;又如创建新的SCHEMA(该SCHEMA在Primary数据库端并不存在),然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。

    (2)分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态,这使得逻辑Standby数据库能够同时用于数据保护和报表操作,从而将主数据库从报表和查询任务中解脱出来,节约宝贵的 CPU和I/O资源。

    (3)平滑升级。可以通过逻辑Standby来实现如跨版本升级,为数据库打补丁等操作。应该说应用的空间很大,而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作,但如果跨平台的话恐怕就力不从心了,所以此项没有作为物理Standby的特点列出),我个人认为这是一种值得可行的在线的滚动的平滑的升级方式,如果你的应用支持创建逻辑Standby的话。

     

    七. Log应用服务(Log Apply Services)


    Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性,在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式:

    REDO应用:物理Standby数据库专用,通过介质恢复的方式保持与Primary数据库的同步。

    SQL应用:逻辑Standby数据库专用,核心是通过LogMiner分析出SQL语句在Standby端执行。

     

    因此物理Standby在应用REDO数据时必须是MOUNT状态,而逻辑Standby则是以READ WRITE模式打开并应用REDO数据,不过被维护的对象默认处于只读状态,无法在逻辑Standby端直接修改。

     

    7.1  Log应用服务配置选项

    默认情况下,Log应用服务会等待单个归档文件全部接收之后再启动应用,如果Standby数据库配置了Standby Redologs,就可以打开实时应用(Real-Time Apply),这样Data Guard就不需要再等待接收完归档文件,只要RFS进程将REDO数据写入Standby Redologs,即可通过MRP/LSP实时写向Standby数据库。

     

    7.1.1.REDO数据实时应用

    启动实时应用的优势在于,REDO数据不需要等待归档完成,接收到即可被应用,这样执行角色切换时,操作能够执行得更快,因为日志是被即时应用的。

    要启动实时应用也简单,前提是Standby数据库端配置了Standby Redologs

     

    物理Standby要启用实时应用,要在启动REDO应用的语句后附加USING CURRENT LOGFIE子句,例如:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE ; 

     

    逻辑Standby要启用实时应用,只需要在启动REDO应用的语句后附加IMMEDIATE子句即可,例如:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

     

    7.1.2.REDO数据延迟应用

    有实时就有延迟,某些情况下你可能不希望Standby数据库与Primary太过同步,那就可以在Primary数据库端发送REDO数据的相应LOG_ARCHIVE_DEST_n参数中指定DELAY属性(单位为分钟如果指定了DELAY属性,但没有指定值,则默认是30分钟)。

     

    注意该属性并不是说延迟发送REDO数据到Standby,而是指明归档到Standby后,开始应用的时间。

     

    例如:设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟:

    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DavePrimary ARCH VALID_ FOR=  

    (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15'; 

     

    不过,如果DBA在启动REDO应用时指定了实时应用,那么即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性,Standby数据库也会忽略DELAY属性

     

    另外,Standby端还可以在启动REDO应用时,通过附加NODELAY子句的方式,取消延迟应用。

     

    物理Standby可以通过下列语句取消延迟应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 

     

    逻辑Standby可以通过下列语句取消延迟应用:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; 

     

    一般设置延迟应用的需求都是基于容错方面的考虑,如Primary数据库端由于误操作,数据被意外修改或删除,只要Standby数据库尚未应用这些修改,你就可以快速从Standby数据库中恢复这部分数据。不过自Oracle从9i版本开始提供FLASHBACK特性之后,对于误操作使用FLASHBACK特性进行恢复,显然更加方便快捷,因此DELAY方式延迟应用已经非常少见了。

     

    7.2  应用REDO数据到Standby数据库

     

    7.2.1.物理Standby应用REDO数据

    物理Standby启动REDO应用,数据库要处于MOUNT状态或是OPEN READ ONLY状态,启动REDO应用的命令相信大家已经非常熟悉了。

    前台应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 

    语句执行完成后,不会将控制权返回到命令行窗口,除非你手动中止应用。在这种情况下如果还需要对数据库进行操作,只能新开一个命令行连接,在Oracle 8i刚推出Standby特性时(那时不叫Data Guard),只提供了这种方式。

     

    后台应用:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 

    这是现在比较通用的方式,语句执行完后,控制权自动返回到当前的命令行模式,REDO应用以后台进程运行。

     

    启动实时应用,附加USING CURRENT LOGFILE子句即可:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; 

     

    如果要停止REDO应用,执行下列语句即可:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

     

    7.2.2.逻辑Standby应用REDO数据

    SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行,因此逻辑Standby需要启动至OPEN状态。

     

    (1)启动SQL应用。逻辑Standby数据库启动SQL应用没有前、后台运行之说,语句执行完之后,控制权就会自动返回当前命令行窗口。

     

    要启动SQL应用,直接执行下列语句即可:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 

     

    如果要启动实时应用,附加IMMEDIATE子句即可,例如:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

     

    (2)停止SQL应用,如:

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

     

    由于是执行SQL语句的方式应用REDO数据,因此上述语句的执行需要等待当前执行的SQL触发的事务结束,才能真正停止REDO应用的状态。

     

    如果不考虑事务执行情况,马上停止REDO应用,可以通过下列的语句来完成:

    SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY; 





    DG : 参数文件配置:  (官方文档 10g )  

    主:

    DB_NAME=chicago

    DB_UNIQUE_NAME=chicago

    LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

    CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl' 

    LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' 

    LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' 

    LOG_ARCHIVE_DEST_STATE_1=ENABLE

    LOG_ARCHIVE_DEST_STATE_2=ENABLE

    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

    LOG_ARCHIVE_MAX_PROCESSES=30


    主数据库:备角色初始化参数

    FAL_SERVER=boston

    FAL_CLIENT=chicago

    DB_FILE_NAME_CONVERT='boston','chicago'

    LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chica go/' 

    STANDBY_FILE_MANAGEMENT=AUTO


    备:

    DB_NAME=chicago

    DB_UNIQUE_NAME=boston

    LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

    CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl' 

    DB_FILE_NAME_CONVERT='chicago','boston'

    LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/','/arch2/ chicago/','/arch2/boston/'

    LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

    LOG_ARCHIVE_DEST_1'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' 

    LOG_ARCHIVE_DEST_2'SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' 

    LOG_ARCHIVE_DEST_STATE_1=ENABLE

    LOG_ARCHIVE_DEST_STATE_2=ENABLE

    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

    STANDBY_FILE_MANAGEMENT=AUTO

    FAL_SERVER=chicago

    FAL_CLIENT=boston






    About Me

    ...............................................................................................................................

    ● 本文整理自网络

    ● 本文在itpub(http://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号(xiaomaimiaolhr)上有同步更新

    ● 本文itpub地址:http://blog.itpub.net/26736162/abstract/1/

    ● 本文博客园地址:http://www.cnblogs.com/lhrbest

    ● 本文pdf版及小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/

    ● 数据库笔试面试题库及解答:http://blog.itpub.net/26736162/viewspace-2134706/

    ● QQ群:230161599     微信群:私聊

    ● 联系我请加QQ好友(646634621),注明添加缘由

    ● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

    ● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

    ● 版权所有,欢迎分享本文,转载请保留出处

    ...............................................................................................................................

    拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号:xiaomaimiaolhr,扫描右边的二维码加入小麦苗的QQ群,学习最实用的数据库技术。

    ico_mailme_02.png
    DBA笔试面试讲解
    欢迎与我联系

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

    展开全文
  • ORACLE DG概念及切换

    万次阅读 2019-01-15 16:02:46
    DG原理DG分为物理standy,逻辑standy 物理standy: 物理STANDBY提供与主数据库完全一样的拷贝(块到块),数据库SCHEMA,包括索引都是一样的。它是直接应用REDO实现同步的。 逻辑standy: 逻辑STANDBY则不是...

    DG的原理:

    DG分为物理standy,逻辑standy

    物理standy:

    物理STANDBY提供与主数据库完全一样的拷贝(块到块),数据库SCHEMA,包括索引都是一样的。它是直接应用REDO实现同步的。

    逻辑standy:

    逻辑STANDBY则不是这样,在逻辑STANDBY中,逻辑信息是相同的,但物理组织和数据结构可以不同,它和主库保持同步的方法是将接收的REDO转换成SQL语句,然后在STANDBY上执行SQL语句。逻辑STANDBY除灾难恢复外还有其它用途,比如用于用户进行查询和报表。

    DG三种模式:

    最大保护模式(Maximum protection)  --性能不佳

    alter database set standby database to maximize protection;

    Primary Database上的每个事务的Redo日志必须在本地和Standby Database上都写入日志文件后才能提交,如果不能写入到Standby Database,Primary Database就会自动关闭(挂起)以防止数据丢失。

    最大可用性(Maximum Availability)

    Primary Database每个事务的Redo日志要写到本地和Standby Database中才能提交。

    这个和最大保护模式不同的是,如果写入到Standby Database失败,Primary Database不会自动关闭。这时Primary Database会自动转换为Maximum Performance模式,等待问题解决并且Standby Database再次和Primary Database同步之后,Primary Database会自动的转换为Maximum Availability。

    这种模式要求Standby Database必须配置Standby Redo log,而Primary Database必须配置为LGWR、SYNC、AFFIRM方式归档。

    最大性能(Maximum Performance)

    这个模式是缺省模式,他更加侧重对Primary Database的可用性不造成任何影响。

    Primary Database上的事务的Redo日志只要写到本地日志文件就可以提交,不必等待到Standby Database的传递完成。

    Primary Database的Redo流可以异步的发送到Standby Database。

    这种模式通过LGWR ASYNC或者ARCH实现,Standby Database也不要求使用Standby Redo Log。

    一、检查DG是否正常的四个方法

    1.看备库的告警日志,正在恢复的日志号是否对应得上

    2.看三个进程是否都已经启动

    SQL>select process from v$managed_standby

    主库中显示:

    PROCESS

    ---------

    ARCH

    ARCH

    ARCH

    ARCH

    备库中显示:ARCH、MRPO和RFS 表示正常

    3.先切换一次日志,再进到归档目录里,看两边的归档文件号是否对得上

    4.用命令查看两边归档是否对得上

    SQL> select max(sequence#) from v$archived_log where applied='YES';

    二、切换DG步骤

    关闭:先主库,后备机,开启的时候先开备库启动备库监听,再开主库

    1.先将主库切换成备库,然后将原主库启动到物理库的状态

    SQL> Alter database commit to switchover to physical standby with session shutdown;

    2.关闭主库

    SQL> shutdown immediate

    3.打开数据库nomount

    SQL> startup nomount

    4.更改主库为备库

    SQL> alter database mount standby database;

    SQL> alter database recover managed standby database disconnect from session;

    如果配置了 standby redo log 并需要启用实时同步则执行以下代码

    SQL>alter database recover managed standby database using current logfile disconnect from session;

    5.将备库切换成主库

    SQL> select switchover_status from v$database;

    SQL> select * from v$version where rownum<2;

    SQL> alter database commit to switchover to primary with session shutdown;

    如果备库还有未应用的日志则执行

    SQL>alter database recover managed standby database disconnect from session;

    SQL> shutdown immediate

    SQL> startup

    切换日志进行检查

    SQL> select max(sequence#) from v$log;

    SQL>select sequence#,applied from v$archived_log;

    SQL> alter system switch logfile;

     

    展开全文
  • Oracle DataGuard是Oracle自带的数据同步功能,基本原理是将日志文件从原数据库传输到目标数据库,然后在目标数据库上应用这些日志文件,从而使目标数据库与源数据库保持同步,是一种数据库级别的高可用性方案。...

    2014-06-03 Created By BaoXinjian

     一、摘要


    Oracle DataGuard是Oracle自带的数据同步功能,基本原理是将日志文件从原数据库传输到目标数据库,然后在目标数据库上应用这些日志文件,从而使目标数据库与源数据库保持同步,是一种数据库级别的高可用性方案。

    DataGuard可以提供Oracle数据库的冗灾、数据保护、故障恢复等,实现数据库快速切换与灾难性恢复。

    在生产数据库的保证"事务一致性"时,使用生产库的物理全备份创建备库,备库会通过生产库传输过来的归档日志或重做条目自动维护备用数据库。

    DataGuard数据同步技术有以下优势:

    1. Oracle数据库自身内置的功能,与每个Oracle新版本的新特性都完全兼容,且不需要另外付费。

    2. 配置管理较简单,不需要熟悉其他第三方的软件产品。

    3. 物理Standby数据库支持任何类型的数据对象和数据类型。

    4. 逻辑Standby数据库处于打开状态,可以在保持数据同步的同时执行查询等操作。

    5. 在最大保护模式下,可确保数据的零丢失。

     

    二、架构


    Oracle DataGuard由一个Primary数据库(生产数据库)及一个或多个Standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接,并且有可以分布于不同地域。

    只要各库之间可以相互通信,它们的物理位置并没有什么限制,不受操作系统的限制。

    1. Primary 数据库

    DataGuard包含一个Primary数据库即被大部分应用访问的生产数据库,该库既可以是单实例数据库,也可以是RAC。

    2. Standby 数据库

    Standby数据库是Primary数据库的复制(事务上一致)。在同一个Data Guard中可以最多创建9个standby数据库,一旦创建完成,Data Guard通过应用Primary数据库的redo自动维护每一个Standby数据库。

    Standby数据库同样即可以是单实例数据库,也可以是RAC结构。

    3. 结构图

     

    三、Standby数据库类型


    Standby数据库通常分两类:逻辑standby和物理standby。

    1. 逻辑standby 

    a. 逻辑standby是通过接收primary数据库的redo log并转换成sql语句,然后在standby数据库上执行SQL语句实现同步;

    b. 与主库共享同样的模式定义;

    c. 通过应用SQL(sql apply)与主库保持一致;

    d. 当从主库接受到日志后,逻辑备用数据库是通过logmnr将日志转换成sql,在逻辑备库的表中,表可以同时用于恢复,报表查询功能;

    2. 物理standby

    a. 物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式实现同步,不仅文件的物理结构相同,连块在磁盘上的存储位置都是一模一样的;

    b. 基于数据块级别和主数据库一致;

    c. 通过应用日志(redo apply)与主库保持同步;

    d. 在mount standby阶段进行应用日志恢复,而同时也可以open read only提供报表查询;

     

    四、备份库状态


    1. 物理备库

    (1). Managed recovery state

    该模式下log transport service归档日志到备库,log apply service 自动应用这些日志。数据库不处于mount状态,任何读都不允许。

    (2). Read only state

    如果我们想做备库为报表功能,那么在备库环境中,我们以read only形式打开数据库。在备库log apply service将不能够应用归档日志到备库,但是主库的log transport service可以继续传递归档日志到备库。

    我们可以非产轻松的在上述两种运行下进程切换,一般情况下我们会在如下的场景下进程切换:

    a. 物理备库用于报表模式

    b. 为了灾难的保护,检查数据是否正常的传递到了备库

    2. 逻辑备库

    Open read write mode

    该种模式,备库仍然可以不断的应用归档日志,但是该备库同时可以提供报表查询功能。

    当log apply service正在更新一张表时,该表仍然可以查询,但是在该表上无法做任何的DML操作。如果其他模式下的对象没有被log apply service所维护,那么我们可以更新该模式下的那些对象。

     

    五、服务


    1. 重做传输服务(Redo Transport Services) 

    控制redo数据的传输到一个或多个归档目的地。

    2. 日志应用服务(Log Apply Services) 

    应用redo数据到standby数据库,以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取,也可直接应用备用日志文件读取。

    3. 角色转换服务(Role Transitions) 

    DataGuard中有两种角色:primary和standby。角色转换就是让数据库在这两个角色中切换,

    4. 切换分两种:switchover和failover  

    (1). switchover:

    a. 转换primary数据库与standby数据库。

    b. switchover可以确保不会丢失数据。

    c. 计划中角色转换,主要用于操作系统和硬件的维护,备库切换成主库,而主库切换成备库,在切换完成后,这个过程没有任何的数据丢失和损失。

    (2). failover:

    a. 当primary数据库出现故障并且不能被及时恢复时,会调用failover将一个standby数据库转换为新的primary数据库。

    b. 在最大保护模式或最高可用性模式下,failover可以保证不会丢失数据。

    c. 非计划中的角色转换,在紧急情况下使用,根据数据的保护模式的不同,只有少量的或者是很少的数据损失

     

    六、保护模式


    1. 最大保护

    这种模式是默认的数据保护模式,在不影响源数据库性能的条件下提供尽可能高的数据保护等级。

    在该种模式下,一旦日志数据写到源数据库的联机日志文件,事务即可提交,不必等待日志写到目标数据库,如果网络带宽充足,该种模式可提供类似于最大可用模式的数据保护等级。

    2. 最大可用性

    这种模式和"最大保护"基本上差不多。正常情况下,主备库之间是同步的。

    当网络或者备库出现问题时,不会影响到主库的当机,主库会自动转换库"最大性能"模式,等待备库可用时,将归档传输到备库做恢复。

    3. 最大性能

    这种模式保证主库性能最大化,主备库之间数据是异步传输的。

    即,主备日志归档以后才会传输到备用库,在备库上使用归档日志文件做恢复操作。

     

    七、安装条件


    运行DataGuard需要具备以下几个条件:

    1. 在主库和从库的所有机器上必须安装同一个版本的Oracle企业版。

    2. 主库必须运行在归档模式下。

    3. 主库和从库的操作系统必须一样(允许版本不同),从库可以使用与主库不同的目录结构。

    4. 主从库硬件系统的体系结构必须相同。比如:主库运行在64位的Sun Sparc系统上,如果从库是32位的Linux Intel系统就不允许。主从库硬件的配置可以不同,比如:CPU数量、内存大小、存储配置等。

     

    Thanks and Regards

    参考:百度文库 - http://wenku.baidu.com/

    参考:Anpiter - http://blog.chinaunix.net/uid-14877370-id-2782040.html

    转载于:https://www.cnblogs.com/eastsea/p/4226957.html

    展开全文
  • Oracle学习路线图

    千次阅读 2015-11-03 02:10:02
    一、目前学习Oracle的两派人 二、Oracle的重要性 三、学习前提 学习Oracle的前提是:熟悉Linux操作系统、Unix操作系统、存储、带库。主要是管理和操作系统原理 四、学习方法 1、sql、pl/sql(网上有很多的视频...
  • dg和ogg的区别--oracle数据库

    万次阅读 2018-12-04 15:42:21
    ADG和OGG的新特性,目前越来越多的客户重视灾备数据站点的建设,由于存储级灾备和操作系统级灾备的局限性(主要是带宽高及事务完整性不容易保证),因此在选择甲骨文的应用...Oracle DataGuard 11g的新特性 ~~~~~~ ...
  • Oracle学习路线与方法

    万次阅读 多人点赞 2013-08-03 08:45:24
    Oracle学习路线与方法
  • 不同Oracle数据库之间的数据同步

    万次阅读 2017-04-19 15:11:55
    Oracle快照原理及实现总结 Oracle数据库的快照是一个表,它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。对于中大型数据库,业务数据库里所有的数据同步到另外一个处理服务器上最佳的选择还是...
  • Oracle GoldenGate 详解

    万次阅读 2019-06-21 10:18:42
    一、Oracle GoldenGate介绍  GoldenGate软件是一种基于日志的结构化数据复制软件。GoldenGate 能够实现大量交易数据的实时捕捉、变换和投递,实现源数据库与目标数据库的数据同步,保持亚秒级的数据延迟。 1、...
  • ORACLE rac集群概念和原理

    万次阅读 2019-04-17 15:21:35
    Oracle集群概念和原理 Oracle的三种高可用集群方案 1 RAC(Real Application Clusters) 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败...
  • Oracle学习路线图、11g OCA OCP学习之路

    千次阅读 2018-02-02 14:03:29
    11gOCAOCP学习之路,1Z0-051,1Z0-052和1Z0-053顺序调整: 阶段一【入门】:共13章  1Z0-052 第2章 安装软件  1Z0-052 第3章 建库 ...阶段二【读一致性和体系结构】:共12章  1Z0-052 第9章 锁  1Z0-052 第
  • 所谓的异构就是说他们是不同的产品,例如: Oracle Database, MS SQL Server, IBM DB2, Sybase ASE, MySQL, Postgre SQL, Excel, XML, Txt或者CSV等用于存放数据的产品或者文件。 那么假设我们需要这些异构的数据源...
  • 11g搭建DataGuard的步骤

    千次阅读 2017-12-06 17:44:24
    概要原理 DataGuard是通过建立一个PRIMARY和STANDBY组来确立其参照关系;STANDBY一旦创建,DataGuard就会通过将主数据库(PRIMARY)的REDO传递给STANDBY数据库,然后在STANDBY中应用REDO实现数据库的同步。有两种...
  • DataGuard和GoldenGate灾备方案对比

    千次阅读 2015-04-13 09:59:15
    目前越来越多的客户重视灾备数据站点的建设,由于存储级灾备和操作系统级灾备的局限性(主要是带宽高及事务完整性不容易保证),因此在选择甲骨文的 应用级灾备时,...Oracle DataGuard 11g的新特性 ~~~~~~  物
  • 数据库笔试面试题库(Oracle、MySQL等) ⊙ 【DB笔试面试67】在Oracle中,关于表分区下列描述不正确的是() ⊙ 【DB笔试面试65】在Oracle中,哪一种表分区方式建议的分区数是2的幂(2、4、8等),以获得最平均的...
  • 1.1 Oracle DataGuard技术 注:因为Logical Standby受支持数据类型,以及日志分析效率等影响很少用于实际应用,所以这里不做比较。以下比较的均为Physical Standby(1)DataGuard 的异步模式是将Archived Redo Log...
  • 自动存储管理ASM日常维护(一)

    千次阅读 2009-11-30 01:07:00
    author:skatetime:2009/11/30 oracle10g自动存储管理(ASM) 在常规的文件管理中,我们都要指定文件的名称和路径,操作每一个文件,都需要数据库管理员指出具体的文件路径和名称,而且在磁盘的优化也需要数据库...
  • oracle11g DG 基本配置

    千次阅读 2019-04-10 17:48:51
    网络上关于dataguard的配置文章很多,但是很多打着oracle11g的文章实际都是只能在9 10 上运行,比如FAL_CLIENT在11g中已经废弃,但是现在网络上的文章都是没有标注这一点。而且对于具体含义语焉不详对于新手只能知...
  • 由于毕业论文的需要,半个月前,本人开始研究oralce与其他数据库的异构连接。这次从机器选择开始到软件配置,基本是自己一条龙包办了。本人用的是旧的IBM x445服务器,磁盘柜也是旧的IBM EXP...本次的oracle数据库主要
  • 对于数据库的稳定性,高可用,跨平台以及海量数据库的处理,Oracle 数据库通常是大型数据库和大企业的首选。尽管如此,仍然不乏很多中小企业想要品尝一下Oracle腥味,因此在Oracle环境中也有不少中小型数据库。出于...
1 2 3 4 5 ... 20
收藏数 820
精华内容 328
关键字:

dg原理结构 oracle