RAC 解决单点故障和负载均衡，但是存储不冗余
data guard 通过冗余保护数据，主要通过日志同步机制保证冗余数据和主数据之间的同步，可以实时、延时、同步或异步，不能解决数据库性能问题
stream是oracle advance queue为基础的数据同步
data guard至少有2个数据，一个primary主数据库对外提供服务，另一个standby数据库处于recover状态，用户在primary上操作这些记录在联机日志文件和归档日志文件中，这些日志通过网络传递给standby database。这些日志会在standby上重演，从而实现primary database和standby database数据同步。
DG的保护模式
data guard 运行3中保护模式，分别是最大保护模式，最大可用和最大性能保护模式
1，最大保护模式（maximum proection)
这种模式能够确保绝无数据丢失，要实现这部有代价的，它要求所有的事物在提交前其REDO不仅要写入本地的online redo log，还要同时写入到standby 数据库的standby redo log，并确认redo数据至少在一个数据库中可用，然后才可以在primary数据库上提交，如果出现故障导致standby 数据库不可用的话，primary数据库就会关闭，防止数据丢失
这种方式要求standby database必须配置standby redo log，而primary database必须使用LGWR，SYNC，AFFIRM方式归档到Standby database;
2.最高可用性(maxunum availablity)
这种模式在不影响primary数据库的前提下，提供最高级别的数据保护策略。其实现方式和最大保护模式类似，也是要求本地事物在提交前必须写入至少一台standby数据库的standby redo log中，不过与最大保护模式不同的是，如果出现故障导致standby数据库无法访问，primary数据库并不会本shutdown，而是自动转换为最高性能模式，等standby 恢复正常后，primary数据库优惠自动转换成最高可用性模式。
这种方式虽然会尽量避免数据丢失，但不能保证数据完全一致，这种方式要求standby database必须配置standby redo log，而primary database 必须使用LGWR,SYNC,AFFIRM方式归档到standby database;
3.最高性能（maxinum performance)
缺省模式，不影响primary性能的前提下提供最高级别的数据保护策略，事物可以随时提交，当前primary数据库中的REDO数据至少需要写入一个standby数据库，这种写入可以是不同步的，如果网络条件理想的话，这种模式能够提供类似最高可用性的数据傲虎，而仅对primary数据库的性能有轻微影响。这是穿件standby数据库时，系统默认保护模式
这种方式可以使用lgwr async或者archs实现，standby database也不要求使用standby redo log；
data guard 通过冗余保护数据，主要通过日志同步机制保证冗余数据和主数据之间的同步，可以实时、延时、同步或异步，不能解决数据库性能问题
stream是oracle advance queue为基础的数据同步
data guard至少有2个数据，一个primary主数据库对外提供服务，另一个standby数据库处于recover状态，用户在primary上操作这些记录在联机日志文件和归档日志文件中，这些日志通过网络传递给standby database。这些日志会在standby上重演，从而实现primary database和standby database数据同步。
DG的保护模式
data guard 运行3中保护模式，分别是最大保护模式，最大可用和最大性能保护模式
1，最大保护模式（maximum proection)
这种模式能够确保绝无数据丢失，要实现这部有代价的，它要求所有的事物在提交前其REDO不仅要写入本地的online redo log，还要同时写入到standby 数据库的standby redo log，并确认redo数据至少在一个数据库中可用，然后才可以在primary数据库上提交，如果出现故障导致standby 数据库不可用的话，primary数据库就会关闭，防止数据丢失
这种方式要求standby database必须配置standby redo log，而primary database必须使用LGWR，SYNC，AFFIRM方式归档到Standby database;
2.最高可用性(maxunum availablity)
这种模式在不影响primary数据库的前提下，提供最高级别的数据保护策略。其实现方式和最大保护模式类似，也是要求本地事物在提交前必须写入至少一台standby数据库的standby redo log中，不过与最大保护模式不同的是，如果出现故障导致standby数据库无法访问，primary数据库并不会本shutdown，而是自动转换为最高性能模式，等standby 恢复正常后，primary数据库优惠自动转换成最高可用性模式。
这种方式虽然会尽量避免数据丢失，但不能保证数据完全一致，这种方式要求standby database必须配置standby redo log，而primary database 必须使用LGWR,SYNC,AFFIRM方式归档到standby database;
3.最高性能（maxinum performance)
缺省模式，不影响primary性能的前提下提供最高级别的数据保护策略，事物可以随时提交，当前primary数据库中的REDO数据至少需要写入一个standby数据库，这种写入可以是不同步的，如果网络条件理想的话，这种模式能够提供类似最高可用性的数据傲虎，而仅对primary数据库的性能有轻微影响。这是穿件standby数据库时，系统默认保护模式
这种方式可以使用lgwr async或者archs实现，standby database也不要求使用standby redo log；
DG架构
按功能分为:
1.日志发送（redo send)
2.日志接收（redo receive)
3.日志应用(redo apply)
日志发送：
primary会不间断产生日志，这些日志需要发送到standby databse,这个动作有primary database的LGWR和ARCH进程完成，进程不同队数据保护能力和系统可用性有很大区别
arch进程
1）primary database不断产生redo log，这些log被lgwr进程写的联机日志
2）当一组联机日志写满后，会发生log switch,并且会触发本地归档
3）完成本地归档后，联机日志可以被重用
4）arch进程通过NET将归档日志发送给standby database的RFS进程
5）standby database的RFS进程把接收的日志写到归档日志
6）standby database 的MRP进程（redo apply)或者LSP进程（SQL APPLY）在standby database 上应用这些日志，进而同步数据。
arch模式传输不写standby redologs,直接保存在standby端归档文件；
说明：
逻辑standby接收后将其转换成Sql语句，在standby数据库上执行Sql语句实现同步，这种叫SQL Apply
物理standby接收完primary数据库生成的REDO数据后，以介质恢复的方式实现，产生同步，叫做redo Apply
arch方式问题：primary 端的redo只有在归档发生时才会发发送到Standby端，如果primary数据库异常宕机，联机日志中的redo内容就会丢失，因此使用arch进程无法避免数据丢失的问题，要想避免数据丢失，就必须采用LGWR,而lgwr又分为SYNC和async两种
缺省方式就是采用arch进程
lgwr进程同步
1）primary database产生的redo日志要同时写到日志文件和网络，就是LGWR进程把日志写到本地的同时还要发送给本地的LNS(lgwr Network server process)，再由LNSn进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程并行工作
2）LGWR必须等待写日本地日志文件操作和通过LNSn进程的网络传递都成功，primary database上的事物才提交，这也是SYNC的含义
3）standby端的RFS进程把接收到的日志写入到standby redo log日志中
4）primary database的日志切换也会触发standby database 上的日志切换，及standby database 对standby redo log的归档，然后触发standby database上的mrp或者lsp进程恢复归档
因为primary database传递redo是实时的，所以有2钟方法恢复：
实时恢复（real-time apply)：只要RFS把日志写入standby redo log就会立即进行恢复；
归档恢复:完成对standby redo log归档才触发恢复
LGWR ASYNC方式
使用lgwr进程必须明确指出，使用lgwr sync时，可以同时用net_timeout，指定多少秒网络发发送没有响应，LGWR会跑出错误，这种方式比呼叫苛刻，所以引入一步模式：
1）priamry database一端产生redo日志后，LGWR吧日志同时传递给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等到LNSn进程的网络传送成功
2）LNSn进程异步的把日志内容发送到standby database,多个LNSn进程可以并发发送
3）primary database 的online redo log写满后发生log switch,触发归档操作，也触发standby database对standby redo log的归档，然后触发mrp或者LSP进程恢复归档日志
第二阶段 日志接收
stadby databse的RFS进程收到日志后，就把日志写到standby redo log或者archived log中，具体些入哪个文件，取决于primary日志的传送方式和standby database位置，如果写到standby redo log文件中，则当primary database 发生日志切换时也会触发standby databvase 上的redo log的日志切换，并把这个standby redo log归档。如果写到的是archive log 那么这个动作本身也是归档操作。
日志接收，需要注意的是归档日志会被放在什么位置：
1）如果配置了standby_archive_dest参数，则使用该参数指定的目录
2）如果log_archive_dest_n参数明确定义了valid_for=（standby_logfile,*)这使用该目录
3）如果数据库的compatible参数大于等于10.0,则取任意log_archive_dest_n的值
4）如果standdby_archive_dest和log_archive_dest_n参数都没有配置，使用缺省的standby_archive_dest
第三部分日志应用
日志应用服务是在standby databse端重演primary database日志。从而实现同步。根据重演日志方式不同，可以分为物理standby和逻辑standby.
physical standby使用的media recovery技术，在数据块级别进行恢复，这种方式灭有数据类型的限制，可以保证2个库完全一致。physical standby只能在mount状态下恢复。也可以以只读方式打开，但是不能执行恢复操作。
logical standby使用的是logmnr技术，通过吧日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logmnr standby不支持的数据类型可以在dba_logstdby_unsupported中查看，使用使用了这些类型，则不能保证数据库完全一致，逻辑standby database可以在恢复时同时进行读写操作。
standby数据库的相关进程读取接收到的REDO数据，在讲起写入stnadby数据库，保存之后通过2中方式生成数据:物理standby 通过Redo应用，逻辑stadby通过SQL应用
根据redo apply发生的时间可以分成两种：
一种是实时应用，这种方式必须standby redo log,每当日志被写入standby redi log就会触发恢复，使用这种方式的好处在于可以减少数据库切换时间，因为切换时间主要用在剩余日志的恢复时间上。
另一种书归档实时应用，这种在primary database发生日志切换，触发standby database归档操作，归档完成后触发恢复，这种事默认恢复方式
physical stadnby使用如下命令启动real-time:
alter database recover managed standby database using current logfile;
logical standby，使用如下方式启动：
alter database start logical stadby apply immediate;
使用lgwr进程必须明确指出，使用lgwr sync时，可以同时用net_timeout，指定多少秒网络发发送没有响应，LGWR会跑出错误，这种方式比呼叫苛刻，所以引入一步模式：
1）priamry database一端产生redo日志后，LGWR吧日志同时传递给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等到LNSn进程的网络传送成功
2）LNSn进程异步的把日志内容发送到standby database,多个LNSn进程可以并发发送
3）primary database 的online redo log写满后发生log switch,触发归档操作，也触发standby database对standby redo log的归档，然后触发mrp或者LSP进程恢复归档日志
第二阶段 日志接收
stadby databse的RFS进程收到日志后，就把日志写到standby redo log或者archived log中，具体些入哪个文件，取决于primary日志的传送方式和standby database位置，如果写到standby redo log文件中，则当primary database 发生日志切换时也会触发standby databvase 上的redo log的日志切换，并把这个standby redo log归档。如果写到的是archive log 那么这个动作本身也是归档操作。
日志接收，需要注意的是归档日志会被放在什么位置：
1）如果配置了standby_archive_dest参数，则使用该参数指定的目录
2）如果log_archive_dest_n参数明确定义了valid_for=（standby_logfile,*)这使用该目录
3）如果数据库的compatible参数大于等于10.0,则取任意log_archive_dest_n的值
4）如果standdby_archive_dest和log_archive_dest_n参数都没有配置，使用缺省的standby_archive_dest
第三部分日志应用
日志应用服务是在standby databse端重演primary database日志。从而实现同步。根据重演日志方式不同，可以分为物理standby和逻辑standby.
physical standby使用的media recovery技术，在数据块级别进行恢复，这种方式灭有数据类型的限制，可以保证2个库完全一致。physical standby只能在mount状态下恢复。也可以以只读方式打开，但是不能执行恢复操作。
logical standby使用的是logmnr技术，通过吧日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logmnr standby不支持的数据类型可以在dba_logstdby_unsupported中查看，使用使用了这些类型，则不能保证数据库完全一致，逻辑standby database可以在恢复时同时进行读写操作。
standby数据库的相关进程读取接收到的REDO数据，在讲起写入stnadby数据库，保存之后通过2中方式生成数据:物理standby 通过Redo应用，逻辑stadby通过SQL应用
根据redo apply发生的时间可以分成两种：
一种是实时应用，这种方式必须standby redo log,每当日志被写入standby redi log就会触发恢复，使用这种方式的好处在于可以减少数据库切换时间，因为切换时间主要用在剩余日志的恢复时间上。
另一种书归档实时应用，这种在primary database发生日志切换，触发standby database归档操作，归档完成后触发恢复，这种事默认恢复方式
physical stadnby使用如下命令启动real-time:
alter database recover managed standby database using current logfile;
logical standby，使用如下方式启动：
alter database start logical stadby apply immediate;