Data Guard
作用
- 为 Oracle 数据提供的灾难恢复解决方案
- 实现数据保护
- Oracle 数据库企业版 (EE) 的特性
- 自动创建和维护生产数据库（或主数据库）的一个或多个事务一致的副本（备用数据库）
- 如果主数据库（因灾难、维护）不可用，那么可以激活一个备用数据库并使之承担主数据库的角色
- 要求主服务器和备用服务器上的 Oracle 数据库和操作系统的版本相同
Oracle Data Guard 旨在满足企业非常重要的业务连续性需要。它提供一套广泛的数据保护和灾难恢复 (DR) 特性，帮助企业从可能给Oracle 数据库造成不利影响的灾难、人为错误和毁坏中幸免。
Oracle Data Guard 创建、维护和监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。 Data Guard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时，Data Guard 可以将任意备用数据库切换到生产角色，从而使与中断相关的停机时间减到最少，并防止任何数据丢失。
Data Guard 结构
Oracle Data Guard 包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。Data Guard 利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。通过 Data Guard，还将重做数据传输到备用站点上，并应用到备用数据库中，从而使备用数据库与主数据库保持同步。Data Guard 允许管理员选择将重做数据同步还是异步地发送到备用站点上。
备用数据库的底层技术是 Data Guard 重做应用（物理备用数据库）和 Data Guard SQL 应用（逻辑备用数据库）。
Data Guard 提供了两种方法将这些重做数据应用到备用数据库中，并使之与主数据库在事务上保持一致。这些方法与 Data Guard 支持的两种类型的备用数据库对应：
• 重做应用，用于物理备用数据库 物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库结构，并且使用 Oracle 介质恢复进行更新。
• SQL 应用，用于逻辑备用数据库 逻辑备用数据库是一个独立数据库，它与主数据库包含相同的数据。它使用 SQL 语句进行更新，其相对优势是能够并行用于恢复以及诸如报表、查询等其他任务。
请注意，就从主数据库进行的数据传输而言，这两种类型的备用数据库之间没有差别。一旦重做数据到达备用服务器，这两种类型的备用数据库在将重做数据应用到备用数据库的方式上就存在差异了。
备用数据库最初是从主数据库的一个备份副本创建的。一旦创建了备用数据库，Data Guard 自动将主数据库重做数据传输给备用系统，然后将重做数据应用到备用数据库中，从而使备用数据库保持为与主数据库在事务上一致的副本。
一个 Data Guard 配置包括一个主数据库和最多九个备用数据库。
主数据库和备用数据库可以运行在单个节点上或一个真正应用集群 (RAC) 环境中。
备用数据库使用 Oracle 网络服务通过基于 TCP/IP 的标准网络（如局域网 (LAN)、城域网 (MAN)、广域网 (WAN)）连接到主数据库。
对数据库所处位置没有限制，只要它们能互相通信就行。不过，对于灾难恢复，建议将备用数据库装载在地理上与主站点隔开的站点上。 Data Guard 要求主系统和备用系统上的操作系统结构相同。因此，如果主数据库是在 Intel 结构上运行 Linux 操作系统，则其所有备用数据库也必须在 Intel 结构上运行 Linux 操作系统 — 例如，它们不能是 Windows 系统。此外，必须在一个 Data Guard 配置中的主数据库和所有备用数据库上安装相同版本的 Oracle 数据库企业版。
可通过命令行方式管理primary或standby库，也可通过Dataguard Broker提供的专用命令行界面(DGMGRL)，或通过OEM图形化界面管理。
Data Guard 流程
在主数据库上，Oracle Data Guard 使用日志写入器进程 (LGWR) 或归档器进程 (ARCH) 收集事务重做数据redo数据，并将其传输到备用数据库中；默认情况下，redo传输服务使用ARCn进程。不过ARCn归档进程只支持最大性能保护模式。如果standby数据库处于其它类型的保护模式，则必须使用LGWR传输redo数据。
使用LGWR与使用ARCn明显不同，LGWR无须等待日志切换及完成归档。一旦primary数据库有redo数据产生，视LOG_ARCHIVE_DEST_n初始化参数中sync或async属性设置，以同步或非同步方式传输到standby数据库。
SYNC：LGWR->LNSn->RFS->MRP(LSP)。在primary数据库，LGWR提交redo数据到LNSn进程，LNSn启动网络传输。
ASYNC方式，对于异步传输，即使网络出现故障造成primary与standby之间通信中断，也并不影响primary数据库的提交。
使用获取存档日志进程 (FAL) 提供一个客户服务器机制，用于在主数据库和备用数据库之间出现通信中断之后将存档日志发送到备用数据库中，以实现自动填充间隔和重新同步。
在备用数据库上，Oracle Data Guard 使用远程文件服务器 (RFS) 进程从主数据库接收重做记录；
RFS进程轮流将redo数据写入standby redo log，再由standby数据库中的ARCn进程将其写入归档；
同时，通过REDO应用或SQL应用将数据应用到standby数据库：
使用管理恢复进程 (MRP) 将重做信息应用到物理备用数据库中；
使用逻辑备用进程 (LSP) 将经过 SQL 转换的重做信息应用到逻辑备用数据库中。
利用 Oracle 数据库 10g 中的 Data Guard 的实时应用新特性，可以在将重做数据一写到备用重做日志 (SRL) 中时，就将重做数据应用到备用数据库中（无论采用重做应用还是 或 SQL 应用）。Data Guard 的早期版本要求，先在备用数据库中归档重做数据，才能以存档日志的形式应用重做数据。
Data Guard 重做应用
通过使用 Oracle 介质恢复应用从主数据库接收到的重做数据，物理备用数据库与主数据库保持同步。
它在物理上与主数据库逐块相同，因而数据库模式（包括索引）是相同的。
主数据库上的一个日志切换将触发备用数据库上的一个日志切换，从而使主数据库上的归档器进程将当前的备用重做日志文件归档到备用数据库上的一个存档日志中。随后，Data Guard 重做应用使用一个专用进程（称为管理的恢复进程 (MRP)）读取存档日志，并将重做数据应用到物理备用数据库中。
如果启用了 Oracle Database 10g 中的 Oracle Data Guard 的新功能—实时应用，则 MRP 将在 RFS 进程写满当前的备用重做日志文件时直接从其中读取重做数据。
物理备用数据库可以以只读方式打开，并且可以在其打开时对其运行查询，但无法在其以只读方式打开的同时运行恢复。在备用数据库以只读方式打开时，传送给它的重做数据将在备用站点上累积而不应用。不过，可以随时在物理备用数据库上恢复操作，并自动应用累积的重做数据。这允许物理备用数据库以一个序列运行，这个序列可能包括在恢复中运行一段时间，然后以只读方式打开来运行报表，接着重新运行恢复来应用尚未应用的重做数据。
primary和standby数据库几乎完全一样。 应用物理standby数据库，Dataguard能够确保即使面对无法预料的灾害也能够不丢失数据。物理standby是基于块对块的复制，因此对象、语句统统无关，primary数据库上有什么，物理standby也会有什么。 能不丢失数据的进行Switchover/Failover切换。
Data Guard SQL 应用
尽管数据的物理组织和结构可能不同，但逻辑备用数据库包含与主数据库相同的逻辑信息。
SQL 应用技术将从主数据库接收到的重做数据转换成 SQL 语句，将块更改转换成表更改或逻辑更改记录 (LCR)，然后在备用数据库上执行 SQL 语句，以使逻辑备用数据库与主数据库保持同步。
从而，在将 SQL 应用到逻辑备用数据库上的同时，可以访问逻辑备用数据库来进行查询和报表操作。
由于使用 SQL 语句更新逻辑备用数据库，因此它保持以读写模式打开，而从主数据库中更新的表可以同时用于诸如报表、合计、查询等其他任务如。.还可通过在维护的表上创建额外的索引和物化视图来优化这些任务。
逻辑备用数据库对数据类型、表的类型以及 DDL 和 DML 操作的类型有一些限制。
转换和故障切换
主数据库和备用数据库角色的转换
转换（Switchover）
- 计划的角色转换，正常切换primary数据库与standby数据库
- 无需将数据库重新实例化
- 用于维护操作系统和硬件
- Switchover可确保数据无丢失
如果在故障恢复之前在原来的主数据库上启用了 Oracle Database 10g 的闪回数据库功能，并且打算将原来的主数据库恢复为 Data Guard 配置中的一个新的备用数据库，则可以在故障恢复之后使用此功能。
如果在故障切换之前没有启用闪回数据库，而需要在故障切换之后将原来的主数据库恢复为一个备用数据库，则必须从新主数据库的一个备份副本重新创建该备用数据库。 转换选项是主数据库和备用数据库之间计划的角色转换，用于处理主数据库上的计划维护。
转换操作和故障切换操作之间的主要差异是：
转换是在主数据库仍然可用时进行，且不需要闪回或重新安装原来的主数据库。这允许原来的主数据库几乎立即承担起备用数据库的角色。因而，可以更轻松、更频繁地执行计划维护。例如，当主站点上升级硬件时，转换功能通过将所有数据库客户机转换到备用站点，以在主站点上执行升级。 有时，术语“转回”(switchback) 也可在 Data Guard 角色管理范围中使用。转回操作只不过是将角色恢复到其原来状态的后续转换操作。 转换操作始终确保在转换期间不会丢失数据。
如果 Data Guard 运行在最大保护模式或最高可用性模式下，故障切换操作确保在故障切换时不会丢失数据。
应当强调的是，为了避免在出现临时系统故障或网络故障的情况下进行错误的故障恢复/转换，Data Guard 转换和故障恢复操作不是自动进行的，而必须由管理员明确启动。一旦启动，Data Guard 就自动运行相关的进程。
有Switchover和Failover两种切换方式 Switchover：正常切换primary数据库与standby数据库。Switchover可确保数据无丢失。
Failover：当primary数据库出现故障并且不能被及时恢复时，会调用Failover将一个standby数据库切换为新的primary数据库。在最大保护模式或最高可用模式下，Failover可以保证不会丢失数据。
数据保护模式
Oracle Data Guard 提供三种高水平的数据保护模式来平衡成本、可用性、性能和事务保护。 最高保护 最大保护模式为主数据库提供了最高水平的数据保护，从而确保了一个全面的零数据丢失灾难恢复解决方案。
当在最大保护模式下运行时，重做记录由日志写入器进程从主数据库同步地传输到备用数据库，并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时，才在主数据库上提交事务。
由于重做传输的同步特性，这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。 最高可用性 最高可用性模式拥有仅次于最高水平的主数据库数据可用性，并提供零数据丢失和防止单组件故障。
如同最大保护模式一样，重做数据由日志写入器进程从主数据库同步地传输到备用数据库，直到确认事务数据在备用服务器的磁盘上可用时，事务才在主数据库上完成。
不过，在这种模式下（与最大保护模式不同），当备用数据库变为不可用 — 例如由于网络连接问题，处理将在主数据库上继续进行。
备用数据库与主数据库相比，可能暂时落在后面，但当它再次变为可用时，备用数据库将自动同步，而不会丢失数据。 由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。
最高性能 最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。
在这种模式下，当主数据库处理事务时，重做数据由日志写入器进程异步传输到备用数据库上。
另外，也可以将主数据库上的归档器进程配置为在这种模式下传输重做数据。
在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。
如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。
在主数据库出现故障的情况下，可能有一些在主数据库上提交了的事务没有传输到备用数据库中。如果网络有足够的吞吐量来跟上重做流量高峰，则丢失的事务将非常少或者为零。
自动重新同步
可能出现网络连接问题
Data Guard 在网络连接恢复后自动重新同步备用数据库
-隐式
主数据库上空闲的 ARCH 进程定期 ‘ping’ 所有的备用数据库，以查看它们是否丢失了任何重做数据
如果丢失，则把丢失的重做数据发送给它们
-显式
应用过程期间在物理备用数据库中发现数据丢失
根据 FAL_SERVER 和 FAL_CLIENT 设置，通知主数据库，然后发送丢失的重做数据
Oracle Data Guard 可以顺畅地处理将备用（物理或逻辑）数据库与主数据库暂时断开的网络连接问题。 当备用数据库变为不可用时（除非这个备用数据库是最大保护模式下的最后一个可用的备用数据库，在这种情况下主数据库将关闭），则在主数据库本地捕获事务。
当重新建立与备用数据库的连接时，将自动传输累积的存档日志，并将其应用到备用数据库中，直到备用数据库已经与主数据库重新同步。
这个过程不需要任何管理干预。
现有站点恢复的权衡
Data Guard 和 RAC
Data Guard 和真正应用集群是互补的，应一起使用以实现最高可用性结构 真正应用集群提供了高可用性
能够快速和自动地从节点故障或一个实例崩溃中恢复过来
提供了增强的可伸缩性 Data Guard 提供了灾难保护并防止数据丢失
维护主数据库的几个事务一致的副本
防止灾难、数据损坏和用户错误
无需昂贵且复杂的 HW/SW 镜像
Oracle Data Guard 和 Oracle 真正应用集群 (RAC) 彼此互补。
RAC 解决系统或例程故障。它提供不影响数据的故障（如节点故障或例程崩溃）的快速和自动恢复。
它还为应用程序提供增强的可伸缩性。 另一方面，Data Guard 通过使用在事务上一致的主数据库和备用数据库 — 它们既不共享磁盘也不运行在锁步模式下 — 提供数据保护。
这使得从站点灾难或数据损坏中恢复成为可能。
Data Guard 还生来就与 RAC 集成 — 例如，一些或所有主/备用（物理或逻辑）数据库可以是 RAC 数据库。
把 Oracle Data Guard 和真正应用集群结合使用来获得数据级和系统级保护的好处。
ASM
概念
自动存储管理 Automatic Storage Management
Oracle 10g版本后引入的新存储概念
自动管理磁盘，提供数据冗余、均衡及优化
ASM会以单独实例的形式存在，单独操作系统用户管理
• 是可移植的高性能集群文件系统
• 可管理Oracle 数据库文件
• 仅支持Oracle 数据库文件
数据中心要求的11g数据库存储管理模式。
组成
直接管理磁盘，而不是文件
一组磁盘作为一个逻辑单元，组成ASM磁盘组
所有的磁盘空间被划分为统一的管理单元
ASM 把文件均匀的分布在所有的磁盘上
• 可将数据分布到各个磁盘中以平衡负载
• 可镜像数据 ASM以单独的实例存在，数据库实例需要访问ASM实例。通过操作系统grid用户进行实例管理，此操作系统用户与oracle用户分别管理两个不同实例。
ASM由ASM磁盘组(DISKGROUPs)组成，磁盘组由>=1个磁盘组成，磁盘不需要进行传统的VG，LV划分，直接把空磁盘加入DG即可。
ASM可方便实现在线物理磁盘的添加、替换和删除操作，所变更磁盘的数据会有后台进程进行自动数据平衡
以文件创建过程为例，说明数据库实例与ASM之间的交互:
1.数据库实例发起请求，创建文件.
2. ASM实例的后台进程会创建一个 Continuing Operation Directory (COD) 条目，并在磁盘组中为这个新的文件分配相应的空间.
3. 数据库的ASMB进程接收到ASM实例发来的extent map区映射表.
4. 数据库进程直接在ASM存储中打开文件、初始化该文件.
5. 初始化之后，数据库进程发出请求，提交文件创建的操作. 这个步骤会引发ASM后台进程去清理COD条目，并标记文件已创建.
6. ASM实例针对提交请求返回ACK，并关闭该文件.对于后续的IO操作，数据库实例需要再次打开文件.
特性
内置的高性能集群文件系统和卷管理 （专门针对 Oracle 数据文件）
有效的分散数据到所有的存储设备上，实现负载均衡，达到最优性能和资源利用
集成的 Mirroring 和 Strip 功能，实现高可靠性和高性能
提供联机磁盘重新配置和动态重新平衡功能Online Rebalance
简化存储管理的复杂性
条带化文件而不是逻辑卷 在示例中，新建文件的第一个1 MB extent会占据磁盘组中8块磁盘的8个不用的AU，占据AU的前128 KB
因此，对于1M的数据访问，会分散到8块不同的磁盘上，而不是一块. 下一个1 MB的extent同样会分散到相同AU的下一个128KB的空间.
这种分配模式会继续，一直到第一组AU被占满，ASM会分配下一个AU.
ASM：Mirroring
在 Extent 级进行 Mirroring
把主数据和镜像数据放在不同的FailGroup中
不需要冗余磁盘
失败的磁盘负载均衡到剩下的磁盘上
维护平衡的 I/O 负载
ASM Mirroring 提供三种磁盘组的容错级别
External: 使用硬件的 Mirroring
Normal: 2-way mirroring
High: 3-way mirroring
ASM：online rebalance
动态的联机的数据分布重新平衡（online rebalance） 当存储的配置变化时
只把相关比例的数据移动到添加的硬盘上
不需要任何手工的 I/O 调优
asm_power_limit=[1-11]
Rebalance不会阻塞数据库操作
影响系统、存储交换机I/O资源
将磁盘添加到磁盘组时，ASM 实例可确保磁盘可寻址且可用。然后格式化磁盘。完成后，磁盘组将自动重新平衡。重新平衡过程非常耗时，因为它会将扩展数据块从每个文件移动到新磁盘上。 再平衡速率由owm_power_limit参数控制
注： 重新平衡不会阻止任何数据库操作。重新平衡的主要影响是系统上的 I/O 负载。重新平衡的功率越高，它给系统带来的 I/O 负载就越大，因此可用于数据库 I/O 的 I/O 带宽就越少。
除非显式命名磁盘，否则您需要在删除时提供 ASM 分配的磁盘名称，而不是"/dev/raw/raw9"（或其他）名称
可以在再平衡期间改变再平衡功率
优势
简化命名
扩容方便
避免新加物理盘进行操作系统层划分
ASM支持更多的物理磁盘
可满足冗余和条带化，提供更好的性能
在新建ASM磁盘组时，可根据实际情况选择不同的冗余度（HIGH、NORMAL、EXTERNAL），在多份存储的情况下，提供更好的存储保护
条带化由后台进程(rbal)自动管理，进行磁盘数据整理和负载均衡，由参数asm_power_limit控制，默认值为1，可设置值[0-11]，当设置为0时，关闭ASM自动重新分布数据的功能
管理ASM
Sqlplus / as sysasm
asmcmd工具
部分常用ASMCMD命令列表：
du：显示指定ASM目录下ASM文件占用的所有磁盘空间大小；
ls：列出ASM目录下的内容及其属性;
lsct：列出当前ASM客户端的信息；
lsdg：列出当前ASM磁盘组的属性、可用空间大小及总大小等；
lsdsk：列出当前ASM中对应的磁盘属性信息；
mkalias：为系统生成的文件名创建别名；
help：查看其他相关参数；
命令行工具asmcmd，提供管理员更为方便的浏览和管理ASM磁盘组中的文件和目录，可以通过此工具列出磁盘组的内容，执行搜索，创建或删除目录及别名，显示空间利用率等。 在11g之后，还提供了更实用的copy命令，可以将ASM管理的文件copy到一般的文件系统，也可以将某个数据文件直接cp到ASM管理的磁盘中，还可以实现远程copy，操作与操作系统层一致。 运行asmcmd时，需要export到ASM所在实例及grid用户的$ORACLE_HOME，直接命令行执行asmcmd即可。
