数据库Standby中的几个概念 - LGWR, ARCH,ASYNC,SYNC,AFFIRM

原文地址：https://blog.csdn.net/sopost/article/details/5860241

一 、双机热备

　从广义上讲，双机热备（双机容错）就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务　双机热备由备用的服务器解决了在主服务器故障时服务不中断的问题。但在实际应用中，可能会出现多台服务器的情况，即服务器集群　双机热备一般情况下需要有共享的存储设备。但某些情况下也可以使用两台独立的服务器　实现双机热备，需要通过专业的集群软件或双机软件

　从狭义上讲，双机热备特指基于active/standby方式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过双机软件的诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用.

所以，像VCS (VERITAS Cluster Manager)等软件实现的Oracle Cluster Server以及Oracle Standby ,Oracle RAC(Real Application Cluster),高级复制(Advanced Replication), Streams等技术都能认为是双机热备。

 

二．Physical Standby，Logical Standby (物理Standby及逻辑Standby)

Physical standby直接从主库接受archived log，然后直接做基于block的物理恢复（更新或调整变化的block），所以physical standby在物理文件一级完全都等同于主库。physical standby恢复只是底层的block apply, OS层面的工作,数据库SCHEMA，包括索引都是一样的。它是直接应用REDO或归档实现同步的 。不会涉及temp ,undo等。物理STANDBY可能的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）。

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

在9i R2之前，data guard的服务器只能运行在read only或者recover模式， 一个physical standby database在物理上完全等同主库，当physical standby database正在做恢复的时候，不能打开用作其他用途。 而logical standby database只是在logical上等同需要恢复的schema， 所以在恢复的时候，可以同时打开做report(做查询动作)，也可以用户和主库不一样的 数据对象等等，极大了提高了备用库的利用率。

 

三．Dataguard

都是Standby。在Oracle 9i之前称为Standby，9i或之后的Standby被改名为Data guard。不过功能上也有了很多的改进和区别 。

四．Standby下LGWR / ARCH传输

查看数据库保护模式：

SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

1.最大性能(maximize performance):这是data guard默认的保护模式。primay上的事务commit前不需要从standby上收到反馈信息（主数据库的提交操作不等待STANDBY），该模式在primary故障时可能丢失数据，但standby对primary的性能影响最小。 可以使用LGWR ASYNC或者ARCH两种传输模式。

ARCH传输模式：Primary DB上的online redo log写满或其他条件引起redo log写归档的时候，redo log生成的archived log file写到本地归档目录的同时，写入了Standby归档目录。只是Primary db上的online redo log切换不必等Standby上的写归档动作结束。

2.最大可用(maximize availability):在正常情况下，最大可用模式和最大保护模式一样；在standby不可用时，最大可用模式会自动降低成最大性能模式，所以standby故障不会导致primay不可用。在问题纠正之后，Standby和主数据库进行再同步，至少有一个standby可用的情况下，即使primary down机，也能保证不丢失数据。(不过当问题修复，再同步之前有必要FAILOVER,那么有些数据可能会丢失)。最大可用性模式Standby必须配置Standby Redo log，Oracle推荐最大可用模式使用LGWR ASYNC（异步）模式传输。

采用最大可用的data guard模式，主库往备库传递在线日志(online redo log)信息，在线日志信息写入备用库的standby redo log,这些standby redo log归档后，备用库应用归档日志。

LGWR还分为LGWR ASYNC(异步)和LGWR SYNC(同步)两种。

	最大保护	最大可用	最大性能
进程	LGWR	LGWR	LGWR或ARCH
网络传输模式	SYNC	SYNC	LGWR时设置ASYNC
磁盘写操作	AFFIRM	AFFIRM	NOAFFIRM
备用日志	YES	物理备用需要	LGWR和物理备用时需要
备用库类型	物理Standby	物理或逻辑	物理或逻辑

 

最大保护(maximize protection):最高级别的保护模式。primay上的事务在commit前必须确认redo已经传递到至少一个standby上，如果所有standby不可用，则primary会挂起。该模式能保证零数据丢失。对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC模式传输。

 

LGWR ASYNC: ------------

Asynchronously archiving with the LGWR process in
conjunction with SSH port forwarding showed the following characteristics when
compared to the baseline: - Significant reduction in network traffic -
Slight increase in primary database throughput - Minimal increase in cpu usage
When using LGWR to remotely archive in ASYNC mode, the LGWR process does not
wait for each network I/O to complete before proceeding. This behavior. is made
possible by the use of an intermediate process, known as a LGWR network server
process (LNS), that performs the actual network I/O and waits for each network
I/O to complete. Each LNS has a user configurable buffer that is used to
accept outbound redo data from the LGWR. This is configured by specifying the
size in 512 byte blocks on the ASYNC attribute in the archivelog destination
parameter. For example ASYNC=2048 indicates a 1Mb buffer. As long as the
LNS process is able to empty this buffer faster than the LGWR can fill it, the
LGWR will never stall. If the LNS cannot keep up, then the buffer will become
full and the LGWR will stall until either sufficient buffer space is freed up
by a successful network transmission or a timeout occurs. Reducing network
traffic in a network with high round trip times (RTT) reduces network server
timeouts due to buffer full conditions, thus reducing the impact to the
primary database throughput. ASYNC can improve the primary database throughput
due to the fact that by compressing the redo traffic, the transfer (in 1 MB
chunks) is quicker and thus the ASYNC buffer doesn't reach full capacity as
often, thereby avoiding the wait that can occur when the buffer is full。