DataGuard总体结构

一、DataGuard总体结构

总体目标

1、   描述计划和非计划停机的不同因数

2、   DataGuard的主要组件

3、   物理以及逻辑DataGuard的异同

4、   建立DataGuard的好处

5、   在高可用环境下HA的用处

数据损失原因

1、   硬件与系统故障

2、   人为错误

3、   计算机病毒

4、   软件故障

5、   自然灾难

       具调查表明，目前一般情况下，数据损失的主要原因是硬件故障和人为的原因而不是自然灾害等。

系统当机

计划当机

1、   系统维护：硬件、操作系统升级

2、   数据维护：表的在线重定义或者是重建索引

非计划当机

1、   系统失败：断电、系统故障

2、   人为错误： 误删除表

3、   数据失败和灾难：数据块损坏、地震

DataGuard

 

HA&DG

 

SwitchOver&FailOver

1、   不会被自动调用，一般情况下通过调用SQL语句执行

2、   Switchover

计划中角色转换

主要用于操作系统和硬件的维护

        备库切换成主库，而主库切换成备库，在切换完成后，这个过程没有任何的数据丢失和损失。

3、   failover

非计划中的角色转换

在紧急情况下使用

根据数据的保护模式的不同，只有少量的或者是很少的数据损失

备用数据库类型

1、   物理备用数据库

基于数据块级别和主数据库一致。

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

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

2、   逻辑备用数据库

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

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

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

REDO APPLY

 

物理备用数据库的redo apply主要构架如下：

        一个主数据库，最多有九个同样的备用数据库，他们都是对主数据库一个同样的拷贝。备用数据库的个数受log_archive_dest_n限制，其中一个是用于归档日志目录，另外几个可用于备用数据库。主节点数据库是打开并且可读写的，而备用数据库要么处于恢复模式或者只读打开模式。

         备用数据库自动的获取和应用从主库传送过来的归档日志，日志传输的时机为：日志在主库产生的时候，日志在主库归档的时候。当日志在主库产生的时候传输那么就需要在备库创建备用数据库日志文件。

        在备库中使用标准的oracle恢复技术应用日志。

        在计划停机中，可以切换主库到备用数据库。

        当主节点down机时，可以失败切换到其他备用节点。

         物理备用数据库可以用来作为对主数据库的备份。

SQL APPLY

 

        当日志传输到备用数据库时，它并不是立即应用日志，而是通过logmnr将日志文件转化成SQL语句，然后再在备库应用。逻辑备用数据库可以以read write形式打开。

SQL Apply 引擎构架

 

       物理备用数据库和逻辑备用数据库的最大的区别在于应用引擎，也就是所说log apply service。在逻辑备用数据库环境下，如下进程参与了应用引擎工作。

        LSP0：该进程是一个协调进程，用于协调并行执行的mining process和apply process。

       PX：由lsp0进程同时产生两组px进程，一组用于挖掘从主节点传送过来的归档日志，将其转化为sql,另外一组PX进程用于应用这些日志到逻辑备用数据库。需要主要的是挖掘和应用的两组进程是同时执行，并且由lsp0进程进行同步以维持数据库比较高的性能。

DG service

DataGuard提供了三种类型的服务：

Log transport service：

控制从主库到多个备库节点的日志文件的自动传输。

Log apply service

控制何时、如何应用日志到备用数据库

Role management services

一个数据库只能工作在两个互斥的任一角色下：primary/standby。Role management service、log transport service,log apply service一起工作可以动态的改变数据库的运行角色。改变角色时通常为switch over/failover。

数据保护模式

        Oracle提供了三种数据库保护模式，我们可以根据成本，可用性，性能，事务保护等去配置何种模式。

最大保护

Maximum protection：

        最大保护模式是最高级别的数据保护模式，它在灾难恢复时可以零数据损失。

当工作在最大性能保护模式时，重做日志被同步传输到备用数据库。而对事务而言，至少该事务在其中一个备用数据库节点被确认完成，该事务才能提交。该种模式下一般至少需要两个备用数据库。该种方式只对物理备用数据库有效。

最大可用性

Max availability

        在正常情况下同最大保护模式。但是当某一个备库网络有问题，那么该备库就临时与主库有数据分歧了。而当该备库再次可用后，会自动同步相应的日志，这时也无数据损失。该种模式可用于逻辑备用数据库和物理备用数据库。

最大性能

Maximum performance

        该种保护模式是数据库默认的保护模式，它提供最少的数据保护，但是提供最大的性能模式。该种模式下的事务以及日志数据都是被异步的传输到备库。可以通过lgwr或者arch进程进行传输。事务并不会等待备库的确认就可以在主库直接完成。如果备库某个节点不可用，对主库没有任何的影响，提供了主库的最大的可用性与最大性能。

       当主节点down机后，可能会有部分事务在主节点已经完成，但是日志还没有传输到备库节点。如果直接切换会有数据丢失的。

RAC&DG

相互补充，可以同时使用。

二、理解DataGuard构架

DG整体构架

       Oracle dataguard为了灾难恢复和高可用性通过使用多个进程达到自动控制的目的。对于物理备用数据库而言，备用联机日志是可选的。除非备库运行在最大性能模式，该模式需要数据库运行在物理备用数据库模式，并且含有备用联机重做日志。逻辑备用数据库并不使用备用联机重做日志。

 

Log Transport Service

主节点上，日志传输服务主要使用如下几个进程：

1、   LGWR

        LGWR搜集事务日志，并且更新联机日志。在同步模式下，LGWR直接将redo信息直接传送到备库中的RFS进程，主库在继续进行处理前需要等待备库的确认。在非同步情况下，也是直接将日志信息传递到备库的RFS进程，但是不等待备库的确认信息主库进程可以继续运行处理。

2、   ARCH

       ARCHn或者是一个SQL session执行了一个归档操作，为了恢复的需要，创建了一个联机日志的拷贝。Archn进程可以在归档的同时，传递日志流到备库的RFS进程。该进程还用于前瞻性检测和解决备库的日志不连续问题(GAP)。

3、   FAL

Fetch archive log 只有物理备库才有该进程。

       FAL进程提供了一个client/server的机制，用来解决检测在主库产生的连续的归档日志，而在备库接受的归档日志不连续的问题。

       该进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。

       我们可以设置通过LGWR，ARCH进程去传递日志到备库，但是不能两个进程同时传送。

该进程是如何交互的呢？fal_client,fal_server参数的。

Log Apply Service

备库节点上，日志应用进程主要使用如下的进程。

1、   RFS

        Rfs进程主要用来接受从主库传送过来的日志信息。对于物理备用数据库而言，RFS进程可以直接将日志写进备用重做日志，也可以直接将日志信息写到归档日志中。为了使用备库重做日志，我们必须创建他们，一般和主库的联机日志大小以及组一样。

2、   arch

        只对物理备库，arch进程归档备库重做日志，这些日志以后将被MPR进程应用到备库。

3、   MRP

Managed recovery process。

       该进程只针对物理备库。该进程应用归档日志到备库。如果我们使用SQL语句启用该进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE，那么前台进程将会做恢复。如果加上disconnect语句，那么恢复过程将在后台进程，发出该语句的进程可以继续做其他的事情。

4、   LSP

Logical standby process。

只有逻辑备库才会有该进程。LSP进程控制着应用归档日志到逻辑备用数据库。

DataGuard环境要求

1、   主库必须运行在归档模式

2、   主备库数据库版本需要一致

3、   主备库操作系统一致，但是操作系统的realese小版本号可以不一致。备库可以与主库的目录结构不一致。

4、   主备库的硬件结构必须一致

5、   每个主备库必须有他们自己的控制文件

6、   如果主备库在同一台服务器上，那么部分操作系统可能不允许在同台主机上打开两个相同数据库名的实例。那么有些数据库的参数需要另外配置的。

7、   为了防止部分直接路径插入而不记录日志的部分信息不能够传递到备库，在备份数据库到备库前，启用主库force logging属性。在备库运行期间，保证主库的force logging属性。

备库状态

我们可以维护备库为如下的数据库状态

1、   物理备库

 

Managed recovery state

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

 

Read only state

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

 

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

1)       物理备库用于报表模式

2)       为了灾难的保护，检查数据是否正常的传递到了备库

2、   逻辑备库

Open read write mode

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

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

三、用SQL创建物理备库

学习完本章节，我们可以使用SQL创建物理备库。

总体

1、启用force logging

2、备份主库

3、copy文件到备库

4、设置备库的参数文件

5、启动备库

6、配置oracle net

7、配置主库的参数文件

8、启动日志传输

启用force logging

1、建议启用该属性，以保证数据的一致性

2、启用该属性后，即使执行了nologging操作，也会产生相应日志。

3、临时表空间和临时段的信息不会被记录

4、建议在物理和逻辑备库上启用这些信息

5、alter database force logging

      Alter database no force logging

 

        设置该特性后，覆盖了所有的基于表空间以及某个对象设置的log属性。该特性必须在所有的unlogging的进程完成后才能启用。

       Noforce logging则禁用了该功能。对应的数据库的字段为v$database.force_logging,该操作可以在数据库打开或者mount阶段执行，但是建议在mount阶段做。

备份主库

1、主库必须在归档模式

       Mount:alter database archivelog;

       同时必须保证log_archive_start=true

2、做一个主库的备份

      可以做一个冷备份，也可以做一个联机备份

3、创建备库的控制文件

       ALTER DATABASE CREATE STANDBY CONTROLFILE

       AS 'file_name' [REUSE];

拷贝文件到备库

1、拷贝如下文件到备库

      数据文件，备库控制文件，参数文件

3、   如果主节点与备用节点的目录结构一致，则不需要如下参数，如果目录结构不一致的话，则需要如下参数，并且需要在备库控制文件中修改相关文件的路径。

 

DB_FILE_NAME_CONVERT:主库到备库相关目录的路径映射

LOG_FILE_NAME_CONVERT：主库到备库日志文件路径映射

STANDBY_FILE_MANAGEMENT：当该参数设置为auto时，在主节点增减或者删除文件，在备份节点也会同样的执行。

这些参数都是在物理备用数据库中的参数文件设置的，但是最好在主库的参数文件中也需要设置。

设置备库参数文件

当参数文件从主库拷贝到备库后，需要在物理备库下修改如下参数文件

1、DB_FILE_NAME_CONVERT

       当主备库目录结构不一致的时候需要在物理备库设置该参数。

       允许多个文件对。

       当在物理备库下，该参数应用于数据库。

       db_file_name_convert =

                  ('/oracle1/dba/','/ora1/stby_dba/','/oracle2/dba/','/ora2/stby_dba/')

       字符串成对出现，第一个为主库文件路径，接下来的是备库中对应的文件路径。

2、LOG_FILE_NAME_CONVERT

      与DB_FILE_NAME_CONVERT参数类似

      只有当备库变为主库的时候才需要联机日志

      log_file_name_convert = ('/oracle1/logs/, '/ora1/stby_logs/')

3、LOG_ARCHIVE_FORMAT

        指出日志文件的格式名字

        %t：线程号

       %T：以0补充的线程号

        %s/S:日志序号

        %d/D:数据库ID

       %a/A：数据库激活号(数据库第一次打开时产生)

       默认的日志格式为：log_archive_format = %d_%t_%s.arc，补0一般默认是8位。

   

      在如下路径下生成日志LOG_ARCHIVE_DEST_n,STANDBY_ARCHIVE_DEST。

4、STANDBY_FILE_MANAGEMENT

      当在主库上增加或者是删除数据文件的时候可以维持主备库的一致性。

       默认值为：manual必须在备库上手工增加或者是删除文件。

                            Auto：在备库的数据文件的增加或者删除是自动执行的

       该参数在主备库都起作用。

      参数的设置方法：standby_file_management = auto，主备库都设置。

 

     当参数设置为auto时，在备库的如下操作是不允许的：

     1)ALTER DATABASE RENAME

     2)ALTER DATABASE ADD/DROP LOGFILE [MEMBER]

     3)ALTER DATABASE CREATE DATAFILE AS ...

     但是ALTER DATABASE ADD/DROP STANDBY LOGFILE操作仍然是允许的。

    

     当我们在主库节点增加一个日志文件的时候，而我们想在备库中也增加一个日志文件，那么我们需要做如下的操作：需要手工去操作。

5、STANDBY_ARCHIVE_DEST

       定义在备用数据库上生成归档日志的地址。

       在物理备库上被RFS进程所使用。

       standby_archive_dest = '/standby/arc_dest/'

       standby_archive_dest = 'LOCATION=/standby/arc_dest/'

       上述参数与该参数一起使用log_archive_dest_n=’service=standby’。

6、LOG_ARCHIVE_START

      自动归档已经填满的日志。

      当该参数设置为false时，可能需要管理员手工去归档需要归档的日志。

      该参数只有在归档模式下才能生效，如果在非归档模式设置该参数无效。

      为了便于切换，一般需要设置此参数为true，该参数在使用standby redo logs和fal_server支持时需要设置此参数为true。

7、REMOTE_ARCHIVE_ENABLE

      对日志的发送和接受的控制。

      该参数的经常设置的值如下：

      该参数在主备库中都需要设置。

      TRUE - Allows both sending and receiving to and from remote sites. This is the default。

      FALSE - Prevents both sending and receiving to/from remote sites。

      SEND - Allows only sending to remote sites。

      RECEIVE - Allows only receiving from remote sites。

      RAC每个节点中该参数的设置必须相同。

      该参数的值同v$database.remote_archieve

物理备库参数文件

compatible='9.2.0'

control_files='D:\USER01\ORADATAB\U01\control01.ctl'

db_file_name_convert=

       'D:\USER01\ORADATAA\U01','D:\USER01\ORADATAB\U01',

       'D:\USER01\ORADATAA\U02','D:\USER01\ORADATAB\U02'

db_name='TESTA'

lock_name_space='testb'

log_file_name_convert=

        'D:\USER01\ORADATAA\U03','D:\USER01\ORADATAB\U03'

remote_archive_enable='TRUE'

remote_login_passwordfile='exclusive'

standby_archive_dest='D:\USER01\ORADATAB\U04'

standby_file_management='auto'

启动物理备库

启动到mount阶段

STARTUP MOUNT PFILE=STBY_INIT.ORA

创建备库日志文件

ALTER DATABASE ADD STANDBY LOGFILE

('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo')

SIZE 500K;

启动MPR进程

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT  (From Session);

     

    物理备库日志文件是一组日志，RFS进程可以将日志写进备库日志文件，然后由归档进程进行归档，RFS进程也可以直接将日志写进归档日志中。Standby redo log在最大保护模式和最大可用模式下是必须的，但是在最大性能模式下是可选的，但是也建议建立备库归档日志。

配置Oracle网络

配置网络，需要使主备库能够相互通信。

配置备库的监听

重启主备库的监听

设置主库参数

LOG_ARCHIVE_DEST

LOG_ARCHIVE_STATE

ARCHIVE_LAG_TARGET

 

Log_archive_dest_n

至少包括2个该参数，参数中必须包含location,server

Location指定一个有效的路径名，本地的日志归档地址。

Service指定一个有效的网络服务名，该服务名指向：

        A standby database：就是一个备用数据库，可以为物理的，也可以为逻辑的。

        An archive log repository：归档知识库，允许远程归档数据库。归档知识库是通过备库的控制文件创建，启动到mount状态，该知识库不包含任何的数据文件。

        A cross-instance archival database：交叉的归档库可以是主库也可以是备库。

比如：

log_archive_dest_1='LOCATION=D:\ARC'

log_archive_dest_2='SERVICE=standby'

 

MANDATORY和OPTIONAL属性

OPTIONAL为失败做准备，允许主库重写

MANDATORY,除非归档日志已经归档到该地址，否则日志不允许覆盖。

通常情况下，某一个地址将被设置为强制的。默认值为可选择的。

相关设置如下：

log_archive_dest_1='LOCATION=D:\ARC'

log_archive_dest_2='SERVICE=standby MANDATORY'

log_archive_dest_3='SERVICE=o9i1 OPTIONAL'

LOG_ARCHIVE_DEST_STATE_n

 

定义了目前归档地址的状态。可以应用于主备库。

1、enable默认值，就是该地址是有效的归档地址。

2、defer：预留相关参数的地址和属性，但是该地址在目前不做为归档地址，除非该地址再次enabled。

3、reset：与defer一样，但是会清除该参数指定的地址的相关错误

4、alternate：当一个归档地址失败的时候，另外一个地址作为备用地址。

   log_archive_dest _3='SERVICE=stby1_path1 NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_4'

   log_archive_dest _4='SERVICE=stby1_path2 NOREOPEN OPTIONAL'

   log_archive_dest_state_3=ENABLE

   log_archive_dest_state_4=ALTERNATE

ARCHIVE_LAG_TARGET

1、在主库设置

2、设置的单位为秒，在主库上即使日志没满，过了这么长时间后日志必须切换。

3、设置备库等待处理日志的最大时间

4、默认设置为0，不使用该功能

5、该参数范围值为：60—7200，建议值为30分钟

6、该值设置太小，可能会导致主库的日志的频繁切换。一般情况下要等主库的日志完成后才能应用到备库。比如日志为100M，而目前日志已经写为80M，而此时主库失败，那么必须在该80M日志在备库应用后，才能无数据损失的切换。

LOG_ARCHIVE_TRACE

1、该参数是可选的作为诊断用

2、设置该参数为一个整数，用来查看想备库地址归档日志的进度。

3、在主库上记录主库向备库传递日志的trace记录，而在备库记录备库接受到主库的trace记录。该trace信息记录在user_dump_dest下。

4、在主库上设置该参数，需要重新启动数据库。

      数据库在open或者mount时

     ALTER SYSTEM SET LOG_ARCHIVE_TRACE=trace_level

主库参数文件

archive_lag_target=0

compatible='9.2.0'

db_name='TESTA'

log_archive_dest_1='LOCATION=D:\USER01\ORADATAA\ARCHIVE1'

log_archive_dest_state_1='ENABLE'

log_archive_dest_2='service=TESTB'

log_archive_dest_state_2='ENABLE'

log_archive_format='testa_%s.arc'

log_archive_max_processes=3

log_archive_start=TRUE

log_archive_trace=0

log_parallelism=1

remote_archive_enable='TRUE'

remote_login_passwordfile='exclusive'

standby_archive_dest='D:\USER01\ORADATAA\ARCHIVE2'

standby_file_management='MANUAL'

开始日志传输服务

Alter system log archive current;

归档当前日志，并且备库的RFS服务将开始接受日志。

主备库在同一主机

1、在备库设置LOCK_NAME_SPACE参数

2、备库数据库文件必须与主库在不同的地址

3、该参数允许在一台机器上同时打开两个数据库名字一样的数据库。

     否则会出现：ORA-01102 “cannot mount database in EXCLUSIVE mode.”

 

四、保护模式和传输服务

目标

创建备用重做日志

描述不同的保护模式

改变不同的保护模式

修改日志传输服务为我们需求服务

备用重做日志

 

     备用重做日志一般在最大保护和最大可用模式下需要，但是一般建议在最大性能模式下也建议使用备用重做日志。

     备用重做日志必须在归档后才能被应用到备库。备用归档是自动执行的。

     逻辑备库可以创建备用重做日志，但是逻辑备库不支持使用备库重做日志。

备库重做日志配置

当创建备库时我们必须创建与主库的日志组数和大小一致。如果我们使用不同的大小的联机日志，那么RFS将会自动调整备库的日志到一样的大小。

在如下情况，RFS进程不会写备用重做日志，而会归档日志：

1、备库无备用重做日志

2、在备库中找不到与主库中大小一样的日志文件

3、所有正确大小的备库重做日志都没有被归档

备库联机日志数量

在create database的如下参数会影响redo log文件的数量。

Maxlogfiles：每个数据库备用重做日志和联机重最日志的最大组数。

Maxlogmembers：每个组中最大的成员数。

        修改上述两个参数的唯一方法就是重新创建控制文件。而如果我们重新创建了主库控制文件，那么我们必须重新创建备库的控制文件。在重新创建控制文件前我们必须确保所有的日志都已经应用到备库中。简单的说，我们应该停止备库的恢复管理模式，在主库上创建一个新的备用控制文件，将该文件拷贝到备库节点，然后mount备库后，再次将备库置于恢复管理模式。

使用SQL增加备用联机日志

ALTER DATABASE ADD STANDBY LOGFILE

 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 500K;

 

ALTER DATABASE ADD STANDBY LOGFILE MEMBER

'/oracle/dbs/log2b.rdo' TO GROUP 2;

 

SELECT * FROM V$LOGFILE

WHERE TYPE = 'STANDBY';  ----type有两个值：online/standby

 

        虽然备用日志文件只是在物理备用数据库环境下才使用，但是oracle建议在主节点仍然应该建立备用日志文件，这样方便灾难切换，而不需要DBA的任何干预。

        查询standby redo log方法：

        V$standby_log(active/unused)

        V$logfile(type=online/standby)

传输方法和保护模式

        一种特定的保护模式应该需要一种特定的日志传输方法。

       仅仅传输方法不能决定日志传输模式。

      

       当我们定义从主库传输到备库(物理或者是逻辑备库)的日志传输方法的时候，我们必须设置该传输方法应该能够支持特定的保护模式。但是仅仅靠传输方法无法决定保护模式。

       通常一旦定义了某种传输方法，那么必须和某种保护模式配合使用。然后就是oracle的内部机制确保主备库正常运行。

LOG_ARCHIVE_DEST_n参数属性

ARCH/LGWR

设置是archiver还是lgwr进程去负责从主库传输日志到备库节点，默认是archiver进程。

 

        Arch含义就是在归档期间对日志进行传输。充当传输服务功能的可以是后台的归档进程，也可以是前台手工归档的一条SQL。

       LGWR含义就是当LGWR写联机日志的时候，同时将日志写进备库重做日志。LGWR就是日志传输服务进程。当LGWR传输日志到远程地点的时候，LGWR同远程数据库实例建立一个连接，如果建立连接失败，那么会自动启用归档进程，直到能够成功建立连接。

 

SYNC/ASYNC

当使用LGWR进程去传递日志的时候，网络IO同步还是异步的。

默认是同步的，并且有并行属性。

 

        SYNC含义就是网络IO与目的地是同步的。也就是说每当启动一个IO时，LGWR会等待该IO完成才能继续处理。当需要建立无数据损失的环境的时候，需要指定Sync属性，因为该属性可以保证日志信息准确的传输到了备库节点。

       当使用LGWR传输日志的时候，如果有多个备库节点，当设置SYNC=NOPARALLE，那么LGWR必须等待一个目的地址的IO完成才能写下一个IO地址，也就是每个地址是顺序写的。如果指定SYNC=PARALLE，其实IO就是异步的，也就是多个目的地址可以同时进行IO操作，但是同样，LGWR也需要等待每个目的地的IO完成后才能继续处理。

 

      ASYNC[=blocks] (默认值是2048，块的个数)，指定为每个地址异步执行IO。LGWR不检查本次IO操作是否完成，直接可以继续处理下一个IO请求。使用异步IO可以使备库的环境对主库性能影响最小。2048是指在SGA中网络缓冲的大小。

AFFIRM/NOAFFIRM

        保证重做日志被写进物理备用数据库。默认是NOAFFIRM。

       Affirm是保证日志已经写到备库地址。当使用lgwr,sync,affirm属性的时候需要直到IO全部完成事务才能提交。该参数对数据库性能是有影响的。

        Noaffirm就是说LGWR的IO操作是异步的，该参数是默认值。

备用联机日志

        物理备库的最大保护和最大可用性需要使用备库，但是最大性能是建议建立备用重做日志。而逻辑备用数据库不使用备用重做日志。

保护模式

1、决定使用何种保护模式

2、使用最大保护和最大可用性需要使用备用重做日志

3、如果保护模式需要备用重做日志，那么使用sync,async日志传输模式

4、最大保护模式至少需要一个备库点使用sysnc传输模式，建议使用两个

5、最大可用性也至少需要一个备库点使用sysnc传输模式

6、最大性能至少一组需要使用async或者是arch

SQL改变保护模式

在主库上执行如下脚本，可以改变数据库的运行保护模式

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

最大保护模式

保证无数据损失

最高级别的数据保护

必须使用sync传输方法

必须使用备用重做日志

如果没有可用的备用重做日志，那么主库将down机

 

 

该模式最高级别的数据保护模式，当以sysnc配置日志传输方法时，一个事务至少等待相关日志被写进至少一个备库点时，事务才能完成。当强制force logging属性时，如果日志无法写到任何一个备库，那么主库将关闭。

最大可用性

无数据损失

第二级别的数据保护模式

必须使用sysnc传输方法

对物理备库而言，必须使用备用重做日志

如果无可用备库，那么主库不会down掉。

 

        基本同最大保护模式，但是当备库全部不可用时，主库将自动切换到最大性能模式，直到备用节点可用，再次运行在最大可用模式。

最大性能模式

默认的数据保护模式

可以使用SYNC, ASYNC, ARCH模式

可以使用备库重做日志

当事务提交的时候没必须想备库写日志信息

 无可用备库时，备库不会down机，并且该模式可能会有数据丢失。

 

注意：如果使用sysnc的传输方法，那么主库的性能可能会受到影响。

延迟日志应用

Nodelay

Delay=30分钟

当日志在备库节点归档后，是立即应用到备用数据库还是等待一段时间后才应用该归档日志。

在最大保护模式，该参数设置无效。

延迟日志应用可以防止主库的错误操作立即应用到备库中去。

其他影响备库的参数

ALTERNATE, NOALTERNATE

1、可以为某一个目的地指定另外一个目的地。

2、允许一个失败的目的地去改变目的地

    比如：一个地址磁盘满了，而转移到另外一个磁盘

     Oracle的网络服务断了，需要转移到另外一个网络服务

3、需要指定noreopen或者maxfailure参数

4、参数设置

   log_archive_dest_3='SERVICE=stby1_path1 NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_4'

   log_archive_dest_4='SERVICE=stby1_path2 NOREOPEN OPTIONAL'

   log_archive_dest_state_3=ENABLE

   log_archive_dest_state_4=ALTERNATE

 

    一个归档地址只能有一个替代的归档地址。当原归档地址传输日志失败时，会启用替代的归档地址。替代地址不能是自己。替代地址的状态为alternate，当原地址失败的时候会自动激活该地址。

 

DEPENDENCY, NODEPENDENCY

   定义了一个目的地址依赖于另外一个地址的成功传输成功。

   指向同一系统的两个目的地只需要一份日志的拷贝。

   默认值是非依赖的。

   设置参数如下：

   log_archive_dest_2='SERVICE=o9i2 LGWR SYNC AFFIRM'

   log_archive_dest_3='SERVICE=o9i1 ARCH DEPENDENCY= LOG_ARCHIVE_DEST_2'

   应用场合：主备库在同一个主机上，备库直接可以获取主库的归档日志，那么就不需要额外存放第二份归档了。

 

MAX_FAILURE, NOMAX_FAILURE

    日志传输尝试与该地址尝试建立连接的次数。

    需要reopen参数

    没有默认的次数

    当max_failure=0就是设置了nomax_failure，默认值就是nomax_failure

 

    当我们设置了max_failure数值时，传输进程当一次连接失败时，不会立即打开，而需要设置reopen, 设定重新打开归档地址的时间间隔。

    当同时设置reopen与max_failure次数为非0值时，那么系统会以max_failure参数为准，同时我们可以查看相关视图：V$ARCHIVE_DEST下的FAILURE_COUNT字段与REOPEN_SECS。

 

NET_TIMEOUT, NONET_TIMEOUT

可以避免LGWR进程网络超时

参数值从15到1200

      该值可以覆盖操作系统设置的默认的网络超时。要小心设置该参数值，不合理的参数设置可能会导致主库当机。

 

REOPEN, NOREOPEN

       默认值为5分钟

       在再次尝试重新连接失败的目的地前需要等待的秒数。

       失败的原因可以是网络失败，配额问题，磁盘满等等。

 

       如果设置为reopen那么，那么失败的地址将会标记为不可用，除非：

1、   手工重新启动目的地

2、   使用alter语句设置reopen属性

3、   实例重启

TEMPLATE, NOTEMPLATE

指定每个目的地存放归档日志的路径

覆盖备库的参数设置

五、Switchover&Failover

目标

解释数据库的角色概念

执行角色转换

执行失败切换

角色

Oracle 数据库中含有2种角色

用户角色：定义了一组权限的集合，该角色可以分配给用户，也可以分配给其它角色。

数据库角色：在备库中数据库扮演什么样的角色，primary还是standby。

v$database.DATABASE_ROLE标识了数据库的运行角色。

 

处于备库环境中，数据库有两种类型，phsical standby,logical standby。

角色管理服务

一个数据库运行在如下互相排斥的角色中：

Primary role：一个数据库运行在primary role，那么log transport services传递重做日志到备库。

Standby role：一个数据库运行在standby role，那么log apply services应用归档日志到备库。

角色管理服务允许我们动态的进行在主备库中进行角色切换。

 

我们可以使用角色管理服务，进行主备库的计划中的角色切换，这个叫switchover。或者是非计划中的角色切换，叫failover。

Switchover&Failover

       切换都不是自动被调用的。我们必须使用SQL语句去执行角色切换。不要想使用switchover进行软件的滚段升级，这个是不支持的。

 

Switchover

计划中的角色转换

用户操作系统和硬件的维护

 

Failover

非计划中的角色切换

在紧急情况下使用

根据保护模式的不同，可能会没有或者很少的数据损失

角色转换决策树

 

        角色转换(switchover&failover)的最终目的是尽快的使主库在线，而同时尽量减少数据损失或者是无数据损失。尽量选择down机时间最短，同时数据损失最小的策略。总之在失败切换前，我们应该先考虑修复主数据库或者进行无数据损失的角色转换。

      即使使用无数据损失的备库方案，修复主库可能会比切换到备库更快点。如果修复了主库，那么就不需要修改客户端的连接。但是如果修复工作导致了任何的数据损失，那么我们可能需要重新创建所有的备用数据库。

     通常情况下，最合适切换的备库为：已经应用了最多的归档日志的备用数据库。

Switchover

       Switchover操作转换了主和被节点的角色，有如下特点

1、   无数据损失

2、   新主节点数据库不需要重新设置联机日志

       如果切换操作涉及的是物理备库，那么两个都需要关闭和重启，但是其他没有角色切换的备库节点是不需要重新启动的。如果切换的备库是逻辑备用数据库，那么主备节点都不需要重启，就可以直接切换。

切换前

 

Switchover工作只能在主库节点发起，而不会在备库节点发起切换工作。

切换后

 

        切换后南京的用户需要重新配置才能进行数据库的再次连接。备用数据库的切换不会自动从一个数据库到另外一个数据库切换进程。

Switchover&Standby Redo Logs

        备库重做日志最好在主库上创建以方便switchover。

        备库重做日志最好在主备节点上都创建，即使备用重做日志在主节点并不使用，这样做主要是为了方便switchover。

准备switchover

建立好初始化文件

建立好主备库连接的网络

将被切换到主库的备库必须处于归档模式

关闭所有连接到主库的连接

 

         一般情况下主备库都需要维持2组参数文件，这样非常方便角色切换。最好能够将所有的备库都置于归档模式，这样在切换的时候，任何备库都可以作为切换到主库。

切换到物理备库SQL

1、确信可以执行切换操作。查询v$database.SWITCHOVER_STATUS字段，正常时该值为session active，当查询的值为to standby时表示该库可以从主库切换到备库。

2、从主库触发切换操作。

     ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN WAIT;

   加上wait操作就是等待操作完成后，返回控制权。

3、关闭重新启动数据库

   SQL> SHUTDOWN IMMEDIATE;

   SQL> STARTUP NOMOUNT;

   SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

4、启动MRP进程

   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

5、确定切换成功

   查询v$database.switchover_status值应该为SWITCHOVER PENDING

6、切换物理备库到主库

   ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN WAIT;

7、关闭重新启动新的主库

   SQL> SHUTDOWN;

   SQL> STARTUP;

8、开始向备库归档日志

   在新的主库上执行如下语句，如果备库的归档地址disable了，那么先启用该地址。

   SQL> ALTER SYSTEM ARCHIVE LOG START;

   SQL> ALTER SYSTEM SWITCH LOGFILE;

切换到逻辑备库SQL

1、为了切换主库到逻辑备库，在主库执行如下操作

ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

该语句执行后，等待主库已经执行的事务完成，而阻止新的更新操作。它同时还在日志文件做了一个备库同步的标记。

建议在做此操作的时候，主库上没有活动的会话。

2、在新的逻辑备库上延迟归档日志 deffer.

      新的逻辑备库就是原来的主库，因为现在主库已经是备库，那么现在也不需要从该库传送日志到其他数据库了，因此将该归档地址延迟使用。

     ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

3、将逻辑备库切换到主库

      ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

4、启用归档日志到新的逻辑备库

      SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

5、在备库启用sql apply操作

      ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY dblink;

      为了在逻辑备库启用 sql apply，在备库必须有一个database link,该dblink的账号在主库上必须权限访问系统视图，也就是该账号需要有LOGSTDBY_ADMINISTRATOR或者SELECT_CATALOG_ROLE角色。该数据库连接一般在出事配置逻辑备库的时候就已经创建好了。典型地每个逻辑都有一个数据库链接连接到备库。

6、确信所有的逻辑备库节点都能够顺利接受日志了。

      SQL> ALTER SYSTEM ARCHIVE LOG START;

      SQL> ALTER SYSTEM SWITCH LOGFILE;

 

        当我们切换到逻辑备库的时候，我们不需要中断任何连接到主备库的连接，因为在任何的切换过程，都没有重新启动数据库。但是当切换成功后，连接到原来主库的进程可能会连接失败。当逻辑备库启动后，数据保护会阻止任何对其数据改变。

      当对逻辑备库实行切换后，任何已经配置好的物理备库将永远变得不可用。

不可switchover场景

如下是switchover不可执行的

1、归档日志丢失。如果在备库节点上少了部分归档日志，那么将不能进行主备库切换。

2、需要基于时间点的恢复。切换只能切换到当前的时间点，而不会切换到之前的某一个时间状态。

3、生产库没有打开或者是不能打开。因为切换操作是在主库在打开状态下发起的，如果主库无法打开，那么将无法进行切换操作。

 

Failover

       当灾难性故障发生，且主库无法修复的时候才需要进行失败切换。在失败切换期间，原主库从dataguard环境中除去，而其中一个备库将切换为主库模式。一般情况下只有紧急情况才会使用失败切换，而恢复主库可能会比失败切换来的更加方便。

      在failover的时候：

      原来主库是丢失的，我们可以在failover后，重新将原来的主库切换成备库。

      在failover 时，备库是在线的，但是没有参与角色转换；也没有必要去关闭和再启动。

 

      原来的主库不再是dataguard环境的一部分。

      有可能有数据损失。

      只有在紧急情况下才可以使用。

      特列：备库的激活。

     

切换种类：

Graceful failover：完美切换，备库尽量恢复应用数据

Forced failover：强制切换。

      After a graceful failover, you must re-create the original primary database and any other logical standby databases. In addition, any other physical standby databases that could not be brought along (and were therefore permanently disabled during the failover operation) must also be re-created before they can serve as standby sites to the new primary site。

 

      After a forced failover operation, you must re-create the original primary instance and all other standbys before they can serve as standby sites to the new primary site。

 

      当failover到逻辑备用数据库的时候，任何dg环境中的物理备库都将不可用，需要重新创建。

Failover到物理备库

1、failover操作需要在物理备库上操作。

      如果在主库上发生了故障，那么在备库上允许尽量应用不完整的备库重做日志，使用如下的SQL语句：

     SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

2、转换物理备库到主库

      SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

3、注册丢失的归档日志

      一般归档的备用联机日志被接受并且在所有的节点上被应用，那么所有备库节点将准备接受从新的主库传输过来的归档日志。

     注册备份过来的归档日志，需要使用如下语句：

     ALTER DATABASE REGISTER LOGFILE '/standby/arch_dest/arch_1_101.arc';

Failover到逻辑备库

1、拷贝所有的日志到逻辑备库

     如果主库中的日志文件还没有应用到备库中，那么就需要拷贝这些日志文件到备库中。

2、注册丢失的日志文件，这些文件已经从主库拷贝到备库

ALTER DATABASE REGISTER LOGICAL LOGFILE 'filespec';

3、是否存在只写了部分的归档日志，如果有，那么该归档日志应该比已经注册的归档日志序号大1，如果存在该归档日志，那么需要注册该日志文件。

4、确保所有的日志文件都被应用到主库，查询DBA_LOGSTDBY_PROGRESS视图中APPLIED_SCN,NEWEST_SCN两个字段，如果相等则表示日志全部应用。

5、激活新的主库

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

停止SQL的应用日志，激活备库到主库模式

6、激活远程归档地址

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

当数据库处在主库模式时，我们必须启用归档到远程地址功能，而同时在备库中我们必须禁止归档到远程地址功能。

7、在所有的逻辑备库节点，启用开启SQL应用进程

ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY dblink;

 

注意任何在备库中的数据信息比主库还要靠前的，都必须重新创建，这样备库才能正常运作。

激活备库

激活备库必须使用如下的语句之一：

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

执行上述语句后，将使备库运行到主库模式下。

注意：当备库重做日志文件在使用的时候，我们是无法进行角色切换，除非在执行上述语句的时候指定

FINISH SKIP STANDBY LOGFILE 挑过恢复当前的备用重做日志文件。

六、SQL应用构架

目标

了解SQL应用的好处

解释何时去应用备库

创建一个逻辑备库

SQL应用好处

1、更加有效的使用系统资源

打开独立活动的生产库

额外的物化视图、索引可以创建以提高性能

2、减轻主库的工作压力

主库上可以不做统计查询等工作了，这些在备库上做

3、   数据保护

主库的损坏不会传播到备库

4、   灾难恢复

Switchover和failover切换能力

最小化计划和非计划当机时间

 

逻辑备用数据库应用的是SQL，其实他使用的是logmnr挖掘技术。

      逻辑备用数据库就是一个独立的，活跃的生产库，它允许用户对主库上不在更新的表，进行事务操作。当这些表在主库上被更新的时候，同时这些表将变为只读的表。因为在逻辑备库上可以有不同的物理结构，因此我们可以创建额外的索引等，以满足特定的查询需求。

使逻辑备库更加安全

ALTER DATABASE GUARD command命令。

All：阻止任何用户对数据库任何数据的改变

Standby：不允许用户修改正在应用sql的表。

None：正常的安全模式

v$database.GUARD_STATUS为保护模式的状态，该设置对所有用户但是除了sys用户外。

 

默认情况下安全模式是all,因此只有sys用户才能修改数据。

一般手工创建数据库时，需要设置ALTER DATABASE GUARD ALL。

准备创建逻辑备库

在创建逻辑备库前需要对主库进行可行性检查：

1、检查不支持的数据类型

2、清楚不支持的DDL操作

3、确保行的唯一性

4、确保主库运行在归档模式

5、打开supplemental logging功能

6、为在线备份启动资源管理

7、为逻辑备库创建一个替代的表空间(可选)

 

       检查视图DBA_LOGSTDBY_UNSUPPORTED，查询逻辑备用数据库不支持的数据类型。这些表将不会被逻辑备用数据库所维持。因为不会在这些表上做任何的DML操作。在主库上查询该表可以确保关键应用的表不在这个视图中。

       如果关键应用的表在逻辑备用数据库不支持的视图的列表中，建议使用物理备用数据库。

       该视图中不包含sys用户下的表，因为在逻辑备库中不会应用sys模式下的对象。

       不支持的数据类型如下：

       NCLOB, LONG, LONG RAW, BFILE, ROWID and UROWID，user-defined types (including object types, REFs, varrays, and nested tables)

       其它不支持的数据库对象

       Tables and sequences in the SYS schema

       Tables with unsupported data types

       Tables used to support functional indexes

       Tables used to support materialized views

       Global temporary tables

       Index Organized Tables (IOTs)

       在上述视图不会列举所有不支持的数据类型，如果NCLOB类型，但是含有该列的表在逻辑备库中应用时将失败，因此需要在逻辑备库上执行DBMS_LOGSTDBY.SKIP('DML','MYSCHEMA','MYTABWITHNCLOB');使日志应用在涉及该表时跳过。

       已经被压缩的数据段在备库中也是不支持的。

 

    如下是不支持的DDL操作

    并不是所有的DDL操作都是从主库应用到备库的。如果在逻辑备库环境下，在主库执行如下的DDL操作，将不会在被库执行，我们需要在备库也相应的执行才能维持主备库的一致性。

ALTER DATABASE

CREATE DATABASE

ALTER SESSION

ALTER SNAPSHOT

CREATE SNAPSHOT

DROP SNAPSHOT

ALTER SNAPSHOT LOG

CREATE SNAPSHOT LOG

DROP SNAPSHOT LOG

ALTER SYSTEM SWITCH LOG

CREATE CONTROL FILE

CREATE DATABASE LINK

DROP DATABASE LINK

CREATE PFILE FROM SPFILE

CREATE SPFILE FROM PFILE

CREATE SCHEMA AUTHORIZATION

CREATE TABLE AS SELECT FROM A CLUSTER TABLE

EXPLAIN PLAN

LOCK TABLE

RENAME

SET CONSTRAINTS

SET ROLE

SET TRANSACTION

特别说明的是create table as 是从一个簇表中创建另外一个表时不支持。

Rename是指不支持修改表视图序列私有同义词。Alter table/tablespace的rename语句是支持的。

 

唯一行标识

       如果该DBA_LOGSTDBY_NOT_UNIQUE视图返回某张表的相关数据，那么必须向该张表添加主键或者是唯一性约束。如果该视图的bad_column列为Y的话，那么说明该表没有主键或者唯一性约束，或者是有一个非常大的列，比如long。如果为N也说明该表没有主键或者唯一性约束，但是有足够信息能够在备库维持。但是如果在这些表上加上主键或者是唯一性约束，那么日志应用、传输程序将运行的更加有效率。

不启用的依赖约束

加入hr.employee表中没有主键

ALTER TABLE hr.employees ADD PRIMARY KEY (employee_id, last_name) RELY DISABLE;

这个约束的键，在表中是生成主键的。因此如果选中的列不能唯一标识该表的每一行，那么日志应用将失败。

追加日志

有三种等级的追加日志(supplymental logging)

FULL

      SQL应用必须的

      在数据库范围内对更新的前镜像或者是唯一性约束进行记录。这样在备库中可以根据这些主键或者唯一性约束对记录高效的更新而不是根据rowid。

Minimal

      只需要很少的信息logmnr就可以识别相关的DML操作。

None

       不需要额外的信息添加到redo stream中。

为了能够让逻辑备库工作正常，必须含有足够的数据库日志去让逻辑备库去正常创建。因此我们需要全追加日志的方式。

      在正常情况下，我们需要minal logging就可以了：ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

，在oracle9i r1中默认的是minal logging，r2中默认的是none。

      在创建备库前，应用全日志的模式：

     SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

     SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

     查询v$database下的几个视图的列为yes

     SUPPLEMENTAL_LOG_DATA_MIN

     SUPPLEMENTAL_LOG_DATA_PK

     SUPPLEMENTAL_LOG_DATA_UI

     每列的含义如下：

      SUPPLEMENTAL_LOG_DATA_MIN – LogMiner will have sufficient information to support chained rows and various storage arrangements. But this is not enough for the SQL Apply service.

      SUPPLEMENTAL_LOG_DATA_PK - All columns of the primary key are placed into the redo log whenever there is an update.

      SUPPLEMENTAL_LOG_DATA_UI - If any unique key columns are modified, all other columns belonging to the unique key are also logged.

     如果我们在主库设置了完全的追加日志的方式并且也创建了备库，那么需要在备库中也执行完全追加日志的操作，这样才会正确的swithover。

资源管理

1、   如果逻辑备库是从一个在线的备份中创建的，那么就需要资源管理。为了支持联机创建备库，即使参数RESOURCE_MANAGER_PLAN是动态管理的，那么在系统启动的时候就需要设置该参数。

2、   当联机备份的时候，备份方法是一个备份一个文件，先置表空间为备份模式，然后再结束备份模式。这样在最后一个文件备份结束的时候，记录下当时的系统SCN。在建立逻辑备库的时候，需要停止一切活动的事务。ALTER SYSTEM QUIESCE RESTRICTED停止事务，ALTER SYSTEM UNQUIESCE结束这种停顿状态。当还原逻辑备库后RECOVER UNTIL CHANGE恢复后，就可以启动sql应用进程了。

3、   因为创建备库需要用到logmnr工具，因此单独创建一个表空间，用于存放dataguard的数据字典。

SQL> CREATE TABLESPACE logmnrts$ DATAFILE

 '/usr/prod1/dbs/logmnrts.dbf'

  SIZE 25M AUTOEXTEND ON MAXSIZE UNLIMITED;

SQL> EXEC

 DBMS_LOGMNR_D.SET_TABLESPACE('logmnrts$');

初始化参数

PARALLEL_MAX_SERVERS一般至少为5，该参数用于在备库并行的用户应用日志的进程。

LOG_PARALLELISM：该值必须为1，如果修改了可能导致备库上logmnr上无法读取日志信息

SHARED_POOL_SIZE：在生产库上至少160M，测试环境可以小点，但是生产库太小，可能会导致性能的严重低下。