RAC架构

RAC（Real Application Clusters）：应用集群架构，底层由CRS（Cluster Ready Service）实现。其根本目的是为了实现实例的冗余。

Oracle由两部分组成：

• 动态部分

  由内存和进程组成的实例instance

• 静态部分

  数据文件、日志文件、控制文件等组成的database

单节点数据库：一个数据库实例操作数据文件。

RAC架构数据库：多个数据库实例组成集群操作数据文件。

RAC是实例级别的容错：一般会把实例和数据文件分开放置在不同的服务器上，当一个实例服务器掉电后，数据文件不会损坏，其他实例依然可以正常工作。

实例和数据库之间使用SAN网络连接，实例和实例之间由私网连接做数据交互（Cache Fusion）。

RAC的作用：

• 提供实例级别的冗余
• 提供更多的系统资源
• 增加更多的并行处理，可以进行业务分割

缺点：

• 内存共享与资源争用（Cache Fusion）
• 底层技术复杂，对DBA技术要求高

RAC架构的oracle，使用 ps -ef | grep crs 可以看到相关的CRS进程（RAC底层由CRS实现）。

查看RAC相关信息：

# -t参数可以将信息以表格样式展示
crs_stat -t

返回信息：

例如搭建的RAC名称为 rac3、rac4

在RAC下，就可以使用gv$开头的相关视图查看集群下所有实例。

rac下，每个实例都有自己的redo log。

rac下，每个实例可以用自己的spfile，但是建议公用一个spfile，避免不一致。asm为共享存储，spfile放到asm即可公用。

使用oracle自带的命令 asmcmd 可以进入asmcmd中进行操作：

例如：

# 查看asm共享存储的大小等信息
lsdg
# 可以像操作linux一样浏览asm中的文件
ls
# 进入DATA文件夹
# 这些文件和文件夹直接在linux中看不到。控制文件、配置文件、数据文件也都存储在asm共享存储中，无法通过操作系统复制出去，只能使用Rman的方式备份出去
cd DATA
# 其他命令
exit # 退出asm
help # 查看帮助
mkdir
mkalias
pwd

Data Guard

Data Guard是数据库的数据一种冗余保护，通过oracle的redo归档日志实现。

运行流程：

1. 主数据库的reodo数据写入redo归档日志文件
2. 灾备数据库接收redo归档日志文件
3. standby灾备数据库通过数据库恢复操作，将redo日志的数据写入灾备数据库（灾备数据库可以有多个）

Data Guard的使用范围：

• 是一个容错方案，使用于数据量不大的数据库，对于OLTP非常适合
• OLAP数据量太大，只能选择关键数据创建DG。常规数据选择其他方式备份
• 可以实现本地、全国异地的容灾

通过查询v$database可以查看数据库是否主数据库、Data Guard状态、保护模式等信息：

select database_role, guard_status, protection_mode from v$database;

返回结果：

在启用了Data Guard的数据库中，归档日志路径也不同：

show parameter log_archive_dest;

普通归档日志路径指向本地的目录，Data Guard的归档日志路径指向一个服务（也可以指向本地）：

# 指向db_phystdby的服务
SERVICE=db_phystdby LGWR ASYNC

db_phystdby配置在tns中，oracle可以通过这个服务连接到备份数据库中。

可以使用oracle自带的 tnsping 查看和该服务的网络是否能ping通：

tnsping db_phystdby

可以使用sqlplus连接这个远程数据库：

sqlplus sys/tiger@db_phystdby as sysdba

Standby灾备数据库平时的状态应该为 MOUNTED， 不是 OPEN，因为 open 的数据库不能做恢复。

redo归档日志从主数据库发送给备份数据库之后，备份数据库的alert日志中会显示对应信息，可以通过查看备份数据库的alert日志观察灾备的过程。

如果有个归档日志没有正常传给备份服务器，会在alert日志中显示一个GAP：

# 拉取38号归档日志出错
Media Recovery Waiting for thread 1 sequence 38
Fetching gap sequence in thread 1, gap sequence 38-38
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 38-38
 DBID ........
FAL[client]: All defined FAL servers have ben attempted;

Data Guard会有自动重试机制，接收归档出错后会重试获取。

Data Guard的保护模式

Data Guard的保护模式：

• 最高数据保护模式（最大保护模式）
• 最高性能模式
• 最高可用性模式

最大保护模式：

这是Data Guard三种保护模式中最安全的一种，它保证在任何时候数据都不会丢失。为了保证主、备数据库中的数据实时保持一致，Oracle要保证当事务提交时，日志必须同时写到主数据库和至少一个 Standby 数据库上，只有这样，才能保证主、备上的数据实时一致。

这种保护模式带来的一个问题就是，当日志无法同步地写到至少一个 Standby 数据库时，主数据库将会被强制Shutdown。这样做的目的是，如果 Standby 数据库无法写入日志，则主数据库就不可以发生任何改变，否则就会导致主、备数据库的数据不一致。

最大保护模式损害了系统的可用性。当主服务器的网络有波动时，有可能导致主数据库被迫重启。

最大性能模式：

它是对数据库性能影响最小的，所以被称为最高性能模式，这也是Data Guard默认的保护模式。

它区别于最大数据保护模式的地方是，它并不需要日志信息实时的传递到 Standby 数据库上。比如，当主数据库上的日志信息无法传递到 Standby 数据库上时，主数据库并不会收到任何影响，相关的服务会不断的尝试向Standby实例传递日志信息，直到成功为止。

最大性能模式损害了系统的数据安全性。

最高可用性模式：

正常情况下，它的工作机制和最大数据保护模式一样。

唯一的区别是，当redo日志无法写入到 Standby 数据库上时，并不会导致主数据库 shutdown。此时，Data Guard阿博湖模式将自动切换到最高性能模式，这样主数据库依然可以继续使用，直到故障恢复。当所有的日志全部都传递到 Standby 数据库上后，Data Guard 又自动将保护模式切换回最高可用性模式。

是最大保护模式和最大性能模式的折中方案。

选择DG的保护模式：

Data Guard中Standby数据库类型

Standby数据库类型：

• 物理Standby数据库（Physical Standby Databases）
• 逻辑Standby数据库（Logical Standby Databases）

物理灾备数据库执行流程：主数据库发送 redo归档日志，备数据库处于 Mounted 状态，使用数据库介质恢复的方式将redo日志写入数据库。

逻辑Standby数据库：主数据库将该redo归档日志还原成SQL语句，把SQL语句发送给备数据库上进行执行。所以此种方式需要备数据库处于 open状态。

选择：

如果备份数据库仅仅只做数据文件的备份，则使用物理Standby数据库的方式更好，因为此种方式的效率性能更高一些。

如果要实现读写分离，在备数据库上做查询报表等操作，或者需要在备份数据库上新建一些表和主数据库上表做关联查询，此时需要数据库处于open状态，应该选择使用逻辑Standby数据库实现。

RAC + DG

使用 Rac 对数据库的实例做冗余保护。

使用 Data Guard 对数据库做冗余保护。