目录
2.1.1 Physical Standby Database 4
2.1.2 Logical Standby Database 4
2.1.3 Snapshot Standby Database 4
2.3 三种保护模式（Data Guard Protection Modes） 4
2.4 了解两种redo transport modes 5
2.5.6 LOG_ARCHIVE_DEST_STATE_n 6
2.5.7 REMOTE_LOGIN_PASSWORDFILE 6
2.5.9 LOG_ARCHIVE_MAX_PROCESSES 6
2.5.12 LOG_FILE_NAME_CONVERT 7
2.5.13 STANDBY_FILE_MANAGEMENT 7
说明
本文档主要是学习数据库性能相关的内容，按该文档的拟定的大纲和提示，完善该文档。
【说明】
该学习文档的结构只是为了便于引导下学习的思路，在个人学习的过程中，可以对该文档的组织结构进行调整，不约束个人的学习思路和创作。
文档结构只是列出了部分过程，更多内容需要学习者自行完善。
整个学习过程，建议以官方文档（Database High Availability Best Practices、Data Guard Concepts and Administration等）和mos为主要参考来源。
以ORACLE 11g或则12c为学习的版本，操作系统建议Red Hat Linux或则Oracle Linuxe。
基础知识
Standby Database的类型
【说明】
了解一下三种类型的DG
DG根据备库（Standby Database）重演日志方式的不同，可以分为物理DG（Physical DG）、逻辑DG（Logical DG）和快照DG（Snapshot DG），它们对应的数据库分别可以称为Physical Standby、Logical Standby和Snapshot Standby。
通过V$DATABASE视图的DATABASE_ROLE列可以查询DG的类型
Physical Standby Database
物理DG使用的是Media Recovery技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。在Oracle 11g之前的物理DG只能在MOUNT状态下进行恢复，虽然可以以只读方式打开备库，但是不能应用日志，而到了Oracle 11g时备库可以在打开的情况下执行恢复操作了，这称为ADG（Active Data Guard）。物理DG实时应用进程为MRP进程。需要注意的是，主库在开启闪回数据库功能后，物理备库并不会开启闪回数据库的功能。
Logical Standby Database
逻辑DG使用的是LogMiner技术，通过把日志内容还原成SQL语句，然后通过SQL引擎执行这些SQL语句。逻辑DG不支持所有的数据类型，这些不支持的数据类型可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看。如果使用了这些数据类型，那么不能保证主备库完全一致。Logical Standby可以在恢复的同时进行读写操作。逻辑DG实时应用进程为LSP进程。需要注意的是，在逻辑DG中，SYS用户下的对象不会同步。要想创建一个逻辑备库需要先创建一个物理备库，然后再将其转换成逻辑备库。
Snapshot Standby Database
当Physical Standby转换为Snapshot Standby时，它是一个完全可更新的Standby数据库。Snapshot Standby依然会接收来自主库的归档文件，但是它不会应用。当Snapshot Standby转换为Physical Standby时，所有在Snapshot Standby数据库的操作被丢弃之后，Physical Standby数据库才会应用Primary数据库的Redo数据。
三种保护模式（Data Guard Protection Modes）
【说明】
了解一下三种保护模式
Maximum protection
最大保护模式
1）这种模式提供了最高级别的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库会自动关闭，防止未受保护的数据出现；
4）优点：该模式可以保证备库没有数据丢失；
5）缺点：主库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会因此受到非常大的冲击。
Maximum performance
最大性能模式（Maximum Performance）
1）该模式是默认模式，可以保证主数据库的最高可用性；
2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；
4）优点：避免了备库对主数据库的性能和可用性影响；
5）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失。
Maximum availability
1.最大可用性模式（Maximum Availability）
1）该模式提供了仅次于“最大保护模式”的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理；
4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；
5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。
了解两种redo transport modes
Synchronous--同步传送
同步日志传送模式会与事务提交保持一致。 只有当所有的日志都被成功的传送到了目标后，本地的事务才能commit。
Asynchronous--异步传送
异步传送日志采用异步的传送事务信息。 主库的事务可以提交，不用等待日志同时成功写入目标库。 而是采用异步的方式来传送归档。 这种方式灵活性就增加很多。
相关参数
【说明】
描述以下相关参数的作用
DB_NAME
数据库名字，需要保持同一个Data Guard中所有数据库DB_NAME相同。
DB_UNIQUE_NAME
为每一个数据库指定一个唯一的名称。
LOG_ARCHIVE_CONFIG
该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗号分隔。
CONTROL_FILES
控制文件位置说明，注意要修改到具体的控制文件位置。
LOG_ARCHIVE_DEST_n
LOG_ARCHIVE_DEST_n = {LOCATION=path_name| SERVICE=service_name, attribute, attribute, ... }
归档文件的生成路径，location代表本地机上，service指明在另一台机器上。
LOG_ARCHIVE_DEST_STATE_n
REMOTE_LOGIN_PASSWORDFILE
LOG_ARCHIVE_FORMAT
指定归档文件格式，这里在主备端应保持一样的格式。LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
%t -thread number
%s -log sequence number
%r -resetlogs ID
LOG_ARCHIVE_MAX_PROCESSES
指定归档进程的数量(1-30)，默认值通常是4。
LOG_ARCHIVE_MAX_PROCESSES =integer
FAL_SERVER
COMPATIBLE = release_number.
主数据库和备用数据库的Oracle兼容版本信息，主备设置必须保证一致。
DB_FILE_NAME_CONVERT
DB_FILE_NAME_CONVERT = ('location_of_primary_database_datafile' , 'location_of_standby_database_datafile_name' , '...'
主数据库和备数据库的数据文件转换目录对映(如果两数据库的目录结构不一样)，如果有多个对应关系，需逐一给出。
LOG_FILE_NAME_CONVERT
LOG_FILE_NAME_CONVERT='location_of_primary_database_redo_logs', 'location_of_standby_database_redo_logs'
指明主数据库和备用数据库的log文件转换目录对应关系。
STANDBY_FILE_MANAGEMENT
STANDBY_FILE_MANAGEMENT = {AUTO|MANUAL}
如果主数据库数据文件发生修改(如新建，重命名等)则按照本参数的设置在备库中做相应修改。设为AUTO 表示自动管理；设为MANUAL表示需要手工管理。
什么是ADG
ADG 是 Oracle 的一种容灾架构，指的是多个数据库可以拥有相同的数据，一旦某个数据库发生故障，可快速切换到另一个数据库。同时也可以实现读写分离，主库写入，从库读取等等。Oracle adg可配置多个备库，可以是一主一从，或者一主多从的方式构成。从而可以确保在主站点（往往使用RAC架构）出现异常时，应急处置切换到备用 ADG 站点继续提供服务。
什么是MAA
Oracle最大可用性体系结构（MAA）的原则，并通过使用Data Guard和/或Oracle Streams / GoldenGate将RAC数据库复制到故障转移RAC数据库的物理远程站点上的被动故障转移安装扩展了级别3。 。MAA包括针对关键基础架构组件（包括服务器，存储和网络）的最佳实践，并提供最全面的体系结构以减少计划内和计划外停机的停机时间。
DG配置和管理
配置DG
1、首先将源库设置为强制归档模式：
通过sqlplus / as sysdba进入数据库
4、DG Broker查看logfile（每个为500M）和创建standby_logfile
5、Rman备份整个源库，备份完成后将备份文件复制到源库对应目录
6、创建standby库的pfile，（该过程从源库中备份过去并进行相关的修改）
如何监控DG运行状态
相关视图及命令
select * from v$archive_gap;
1、检查主备两边的序号
select max(sequence#) from v$log; ---检查发现一致
2、备库执行，查看是否有数据未应用
select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;
select SEQUENCE#,FIRST_TIME,NEXT_TIME ,APPLIED from v$archived_log order by 1;
3、检查备库是否开启实时应用
select recovery_mode from v$archive_dest_status where dest_id=2;
4、检查备库状态
select switchover_status from v$database; --发现状态not allowed
3、看看进程MRP是否存在
ps aux|grep mrp --发现进程不存在
4、如果不存在执行以下：
alter database recover managed standby database using current logfile disconnect;
alter database recover managed standby database disconnect from session; --后台执行
alter database recover managed standby database --前台执行，执行这个可以看到报错的情况
如果有报错，查看alert日志和log.xml日志
5、验证是否正常
select process,status from v$managed_standby;
select process,status,sequence# from v$managed_standby;
如果看到mrp0正常
6、以上步骤处理好后，如果数据还不正常，接着处理
关闭备库，接着处理：
把主库上 undotbs01.dbf 文件，物理的重拷到备库机上以前undotbs01.dbf 所在目录下；
$scp /data/oracle/oradata/voip/undotbs01.dbf 192.168.122.204:/data/oracle/oradata/voip
再在主库上重新生成一个standby control file ，拷到备库机上相应目录下，
alter database create standby controlfile as '/data/oracle/oradata/voip/qyqdg01.ctl'
$scp /data/oracle/oradata/voip/qyqdg01.ctl 192.168.122.204:/data/oracle/oradata/voip
$ mv qyqdg01.ctl control01.ctl
$ cp control01.ctl /data/oracle/flash_recovery_area/qyq/
$cd /data/oracle/flash_recovery_area/qyq/
$ mv control01.ctl control02.ctl
GAP
什么是GAP
当主库的某些日志没有成功传送到备库，那么这时候就发生了归档裂缝（Archive Gap）。目前Oracle提供了两种日志GAP的检测和处理机制，分别是自动GAP处理（Automatic Gap Resolution）和FAL进程GAP处理（FAL Gap Resolution）
如何处理GAP
（一）物理DG手动解决GAP (二）逻辑DG手动解决GAP
DG切换
Switch
1. 查看switchover_status：
SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, FORCE_LOGGING, DATAGUARD_BROKER, GUARD_STATUS FROM V$DATABASE;
2. 切换为备库
alter database commit to switchover to physical standby WITH SESSION SHUTDOWN;
alter database commit to switchover to physical standby;
注意：如果上一步的SWITCH_STATUS参数值为"TO STANDBY"，则 WITH SESSION SHUTDOWN 可以省略。
3. 启动mount
SQL> SHUTDOWN ABORT
SQL> STARTUP MOUNT
注意：11.2.0.4版本及其以上版本不需要执行"SHUTDOWN ABORT"，因为数据库已经在切换命令中关闭了。
4. 数据库状态
set line 600\
1. 备库状态
SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, FORCE_LOGGING, DATAGUARD_BROKER, GUARD_STATUS FROM V$DATABASE;
注意：需要检查SWITCH_STATUS参数，如果值为"SESSION ACTIVE"或"TO PRIMARY"，则备库可以切换为主库。
3. 提升主库
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
注意：如果上一步的SWITCH_STATUS参数值为"TO PRIMARY"，则 WITH SESSION SHUTDOWN 可以省略。
4. 状态查看
SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, FORCE_LOGGING, DATAGUARD_BROKER, GUARD_STATUS FROM V$DATABASE;
SELECT DB_UNIQUE_NAME,DATABASE_ROLE,PROTECTION_MODE, SWI
12c中DG新特性
参考文档
【说明】
以下列举了一些MOS的文章，可以在MOS上搜索Dataguard等关键字。该章学习期间，阅读或则模拟大量MOS文章中的内容和操作。
Step-By-Step Guide To Create Physical Standby On Normal File System For ASM Primary using RMAN (文档 ID 838828.1)
Step By Step Guide To Create Physical Standby Database Using RMAN Backup and Restore (文档 ID 469493.1)
Step By Step Guide On Creating Physical Standby Using RMAN Backup based Duplicate In ASM For ASM Primary (文档 ID 837102.1)
Step By Step Guide On How To Recreate Standby Control File When Datafiles Are On ASM And Using Oracle Managed Files (文档 ID 734862.1)
Data Guard Gap Detection and Resolution Possibilities (文档 ID 1537316.1)
Steps to perform for Rolling forward a standby database using RMAN Incremental Backup. (文档 ID 836986.1)
Data Guard Gap Detection and Resolution Possibilities (文档 ID 1537316.1)
11.2 Data Guard Physical Standby Switchover Best Practices using SQL*Plus (文档 ID 1304939.1)
11gR2 RAC DB switchover using DG broker (文档 ID 880017.1)
11.2 Data Guard Physical Standby Switchover Best Practices using the Broker (文档 ID 1305019.1)
