Dataguard原理

2023-10-12 10:52:34

1.DataGuard概要

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

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

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

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

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

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

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

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

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

2.DataGuard架构

DataGuard结构图：

Dataguard原理

​ Oracle DataGuard由一个Primary数据库(生产数据库)及一个或多个Standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可以分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，不受操作系统的限制。

2.1DataGuard运行原理

DataGuard运行原理非常简单：传输日志、应用日志

Dataguard原理

  1. 日志传输服务将主库产生的日志数据传到从库。
  2. 应用服务（Apply Service）验证日志数据，并且更新从库的数据文件。
  3. 主数据库的写进程更新数据文件，并不依赖于DataGuard架构。
  4. 当网络或者从库故障恢复时，DG自动重传已经被主库归档的日志数据。

2.2Primary 数据库

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

2.3Standby数据库

Dataguard原理

​ DataGuard提供了两种不同的方法应用日志到standby数据库：物理standby （Redo Apply）、逻辑standby（SQL Apply）。

​ Standby数据库是Primary数据库的复制(事务上一致)。在同一个Data Guard中可以最多创建9个standby数据库，一旦创建完成，Data Guard通过应用Primary数据库的redo自动维护每一个Standby数据库。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。

1.物理standby

​ 物理standby使用Redo Apply介质恢复的方法，从SRL中读出redo record放在内存中，然后直接应用change vectors恢复从库数据。主库和从库之间是块对块的物理复制品。介质恢复可以并发的对数据进行恢复，以提供更高的性能。在11g之间，物理备库的恢复只能在mount状态下进行，所以物理备库无法提供查询功能。11g引入了Active DataGuard 。使用数据库可以在应用日志的情况下，只读打开数据库。为业务提供只读查询。DG不但能保护数据，还能提供只读查询，从而提高了系统使用的效率。

Dataguard原理

物理standby特点：

  • 通过应用日志(redo apply)与主库保持同步；
  • 物理备库在mount状态下应用日志恢复，也可以打开到open的read only状态查询数据。
  • 物理备用数据库进行的是主数据库数据块的备份恢复，所以在存储位置的数据块上都是一致的。

2.逻辑standby

​ 将主库传过来的redo数据，通过LogMiner，将日志中的信息转换成SQL语句。然后应用到数据库中。逻辑备库需要更多的进程、内存、CPU、IO等资源。SQL APPLY并发支持所有的数据类型比如XML对象、Oracle Spatial、Oracle Text等。

Dataguard原理

逻辑standby 详细流程：

Dataguard原理

逻辑standby 特点：

  • 主库通过日志挖掘将redo log传输到备库，逻辑备库在转换正SQL语句通过应用SQL(SQL apply)与主库保持同步；
  • 逻辑备库在mount状态下应用日志恢复，也可以打开到open的read write状态对数据修改。
  • 如果逻辑备库开启read write状态后，需要修改数据必须开启闪回，开启闪回之后备库停止应用SQL，当修改完成后还需要闪回到开启闪回前一刻；相当于没有修改数据，所以一般不会配置这种备库。

3.后台进程

  • RFS进程
  • LNSn进程
  • MRP进程
  • LSP进程
  • FAL进程

3.1RFS进程

RFS（Remote File Server）进程主要是用来接收从主库传送过来的日志信息。对于物理备份库而言，RFS进程可以直接将日志写入Standby Redo logs，也可以直接将日志信息写到归档日志中。一般可以在主库的告警日志中看到相关信息。

3.2LNSn进程

LNSn（LGWR Network Server ）进程，DG可以使用ARCn、LGWR来传输日志，但它们都是把日志发送给本地的LNSn（如果是多个目标备库，那么会启动相应数量的LNSn进程，同时发送数据）进程，然后备库的RFS进程接收数据，接收到的数据可以存储在备库的备用Redo日志文件中或备库的归档日志中，然后再应用到备库。

一般情况下，主库切换（alter system switch logfile），日志可以启动LNSn进程。

需要注意的是，若在Oracle 10g中采用LGWR传输日志的时候，则进程表现为LNSn，但在Oracle 11g中，若采用LGWR ASYNC（异步方式）来传输日志的时候，则进程表现为nsa，若采用LGWR SYNC（同步方式）来传输日志的话，则进程表现为nss。且通过视图GV$MANAGED_STANDBY查询的结果不尽相同。

3.3MRP进程

Managed Recovery Process，该进程只针对物理备库，作用为应用从主库传递过来的Redo日志到物理备库，称为Redo Apply。如果使用SQL语句“ALTER DATABASE RECOVER MANAGED STANDBY DATABASE”启动该进程，那么前台进程将会做恢复。如果加上DISCONNECT语句，那么恢复过程将在后台进行，发出该语句的进程可以继续做其他的事情。

3.4LSP进程

Logical Standby Process，只有逻辑备库才会有该进程。LSP（SQL Apply）进程应用Redo日志到逻辑备库。

3.5FAL进程

Fetch Archive Log，从FAL名称就可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database是FAL_CLIENT，但是Standby Database从哪里取这些日志呢？这个哪里就是FAL_SERVER。

4.DG的保护模式

Dataguard原理

  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修改保护模式

修改数据保护模式步骤

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

（2）修改模式：

语法：

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

如：

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

（3) 打开数据库：

 alter database open;

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

select protection_mode,protection_level from v$database;

5.日志传输

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

Dataguard原理

5.1ARCH传输

Dataguard原理

（1）Primary Database不断产生Redo Log，当一组联机日志被写满后，会发生日志切换（Log Switch）并且会触发本地归档，完成本地归档后，联机日志就可以被覆盖重用。

（2）ARCH 进程通过Oracle Net把归档日志发送给Standby Database的RFS（Remote File Server）进程。

（3）Standby Database端的RFS进程把接收的日志写入到归档日志。

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

ARCH传输缺点：

​ 使用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;

5.2LGWR传输

Redo Transport Services协调主从库之间的日志传输。当主库LGWR写日志时，Log Network Server (LNS)程序从Log buffer cache中读取日志数据，通过Oracle Net Services将数据传输到从库上。从库上的Remote File Server (RFS)接收传过来的日志。RFS将接收到的日志写到standby redo log file (SRL).在多从库环境下，主库为每个从库都启用一个独立的LNS进程，用来传输日志数据。

​ 使用LNS进程，DataGuard支持两种日志传输方式：SYNC同步、ASYNC异步。

​ 同步日志传输Synchronous Redo Transport

1.SYNC同步方式传输

Dataguard原理

使用LGWR进程的SYNC方式

  • LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程，再由LNSn进程把日志通过网络发送给远程目的地

  • 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary 数据库上的事务才能提交，这就是SYNC。

  • Standby数据库的RFS进程把接收到的日志写入到Standby Redo Log日志中。

  • Primary 数据库的日志切换也会触发Standby数据库上的日志切换，即Standby数据库对Standby Redo Log的归档。

  • Standby数据库可以使两种恢复方式：

    （1）实时恢复（Real Time Apply），只要RFS把日志写入Standby Redo Log日志中就会立即进行恢复；

    （2）归档时恢复，在完成对Standby Redo Log的归档后才恢复

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

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

2.ASYNC异步方式传输

Dataguard原理

使用LGWR进程的ASYNC方式

  • LGWR负责把日志写入本地日志文件；不必等待LNS进程的网络传送成功。
  • LNSn进程异步的将日志发送到Standby数据库
  • Primary 数据库的日志切换也会触发Standby数据库上的日志切换，即Standby数据库对Standby Redo Log的归档。
  • MRP或LSP 进程恢复归档日志

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

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

6.日志接收应用

6.1日志接收

​ 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.

6.2日志应用

​ 日志应用服务，就是在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;

7.自动裂缝检测解决

​ 当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.

​ 除了自动地日志缺失也可以手工解决。 具体操作步骤如下：

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 '路径';

8.初始化参数

下面仅列举常用的参数，具体详细的参数介绍可以到官方文档中查询

8.1 主库相关参数

1.DB_NAME

所有主备库的DB_NAME都相同，该参数的值是为了使数据库节点都存在同一个Data Guard中

例如：DB_NAME=dg

2.DB_UNIQUE_NAME

该参数是数据库指定一个唯一的名称，一经指定不会再发生变化，再主备库上设置的值是不一样的

例如：DB_UNIQUE_NAME=dg1或DB_UNIQUE_NAME=dg2

3.LOG_ARCHIVE_CONFIG

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

4.LOG_ARCHIVE_DEST_n

主库的日志发送是由log_archive_dest_n参数设置（注意：同时还有一个和它相对应的开关参数log_archive_dest_state_n，用于指定该参数是否有效），下面简单介绍下该参数各个属性的含义：

#SERVICE（必须）：指定备库的网络连接名；
#SYNC/ASYNC（默认为ASYNC）：指定日志的传输模式（同步/异步）；
#NET_TIMEOUT：指定当采用SYNC传输模式时，超过多少秒则表示网路超时（默认为30s），在使用SNYC模式时，强烈建议设置改参数；
#AFFIRM/NOAFFIRM：AFFIRM表示只有当日志写入Standby重做日志后才算日志传输成功，NOAFFIRM则没有这个要求；
#DB_UNIQUE_NAME：指定备库的DB_UNIQUE_NAME；
#VALID_FOR：格式为(redo_log_type,database_role)，只有这两个条件全部符合，才会发送日志；其中redo_log_type有如下取值：ONLINE_LOGFILE, STANDBY_LOGFILE, ALL_LOGFILES,database_role有如下取值：PRIMARY_ROLE, STANDBY_ROLE, ALL_ROLES
#REOPEN：指定当连接错误发生时，多少秒之后重试；
#COMPRESSION：指定是否对日志进行压缩，已提高网络传输性能。

例如：LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dg1'

5.REMOTE_LOGIN_PASSWORDFILE

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

例如：REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'

8.2备库相关参数

1.FAL_SERVER

指定一个Net服务名，该参数值对应的数据库应为Primary角色。当本地数据库为Standby 角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器
例如：FAL_SERVER='dg1'
提示：FAL是Fetch Archived Log的缩写FAL_SERVER参数支持多个参数值的哟，相互间以逗号分隔

2.FAL_CLIENT

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

例如：FAL_CLIENT='dg2'

3.DB_FILE_NAME_CONVERT

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

例如：DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/dg1','/oracle/datafile/dg2'

4.LOG_FILE_NAME_CONVERT

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

例如：LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/dg1','/oracle/datafile/dg2'

5.STANDBY_FILE_MANAGEMENT

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

例如：STANDBY_FILE_MANAGEMENT='AUTO'

上一篇：OneZero第三周第五次站立会议（2016.4.8）


下一篇：OneZero第三周第一次站立会议（2016.4.4）