网站浏览量怎么查看,罗湖网站建设哪家好,小红书推广策略,高德地图导航下载一、DataGuard架构介绍
1、基本介绍
在DG环境中#xff0c;至少会有两个数据库#xff0c;一个数据库处于Open状态#xff0c;对外提供服务#xff0c;这个数据库叫做primary Database。第二个数据库处于恢复状态#xff0c;叫做Standby Database。运行时Primay Databas…一、DataGuard架构介绍
1、基本介绍
在DG环境中至少会有两个数据库一个数据库处于Open状态对外提供服务这个数据库叫做primary Database。第二个数据库处于恢复状态叫做Standby Database。运行时Primay Database对外提供服务用户在Primary Database上进行操作操作被记录在日志文件中。这些日志通过网络传送到Standby Database。这些日志会在Standby Database上重演从而实现了数据的同步。
Oracle 的DG对这个过程进一步的优化设计使得日志的传送、恢复工作更加自动化、智能化。如果是可预见因素需要关闭Primay Database例如软硬件的升级可以把Standby Database切换为Primary Database继续对外提供服务并且数据不会丢失。 如果是因为异常原因导致Primary Database不可用也可以把Standby Database强制切换为Primary Database继续对外提供服务这时数据损失程度和配置的数据保护级别有关系。
上面一大段话可以总结为以下三点 1primary Database上产生日志 2primary Database将日志传给Standby Database 3Standby Database根据接受到的日志进行重演 下面附上一张DG架构图咱们就能更清晰的了解内部机制。 图中的data guard其实分为两种结构
通过LGWR发送日志和通过ARCH发送日志。 通过ARCH则不必要非常好的网络资源但数据实时性也大打折扣。 通过LGWR也就意味着具有更高的实时性数据丢失率较低。但也非常依赖网络资源同样也受数据保护模式的影响。
2、DG相关的后台进程
ARCH (archiver) 心跳检测探测对方
LNS (log-write network-server) log传送
RFS (remote file server) 远程接数据
FAL (Fetch Archive Log ) 解决Redo的间隔Gap
MRP (Managed Recovery Process) :日志被应用恢复的过程
LSP (Logical Standby Process)逻辑数据库的后台进程SQL转换FAL介绍 FALFetch Archive Log是 Oracle Data Guard 中的一个关键特性它的作用是在备用数据库Standby Database上自动检测并解决归档日志的间隔Gap问题。这个过程确保了备用数据库能够持续与主数据库Primary Database保持同步即使在归档日志传输过程中出现丢失或延迟的情况。 FAL 工作原理 归档裂缝Archive Gap当主数据库上的事务日志Redo Logs由于某些原因未能及时传输到备用数据库时就会在备用数据库上形成归档裂缝。这可能是由于网络问题、磁盘空间不足或其他原因导致的。裂缝检测备用数据库会定期检测归档日志的完整性一旦发现裂缝即日志序列中断就会触发 FAL 进程。日志请求作为 FAL_CLIENT 的备用数据库会向配置为 FAL_SERVER 的主数据库或其他备用数据库发送请求以获取缺失的归档日志。日志传输FAL_SERVER 接收到请求后会从其归档日志存储中检索出缺失的日志并通过网络发送给 FAL_CLIENT。日志应用备用数据库上的 FAL_CLIENT 接收到缺失的归档日志后会将其传输给负责日志应用的进程如 RFS - Redo File Services这些进程将日志写入备用数据库的归档日志或在线重做日志中。数据同步随后备用数据库上的 MRPManaged Recovery Process或 LSPLog Writer Process进程会应用这些日志以确保备用数据库的数据与主数据库保持一致。 FAL 的重要性 数据一致性通过自动解决归档裂缝FAL 确保了备用数据库的数据与主数据库保持同步这对于数据保护和灾难恢复至关重要。 高可用性FAL 减少了人为干预的需求提高了系统的自动化程度从而增强了整个系统的可用性。 减少停机时间在主数据库发生故障时由于备用数据库始终保持最新状态可以快速切换到备用数据库最小化业务中断时间。 3、功能划分
相关服务按功能区分
日志发送 redo send Primary Database 运行过程中会源源不断地产生Redo 日志这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成 不同的归档目的地可以使用不同的方法但是对于一个目的地只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。日志接收 redo recieve Standby Database 的RFSRemote File Server进程接收到日志后就把日志写到Standby Redo Log或者Archived Log文件中具体写入哪个文件取决于Primary 的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中则当Primary Database发生日志切换时也会触发Standby Database上的Standby Redo Log 的日志切换并把这个Standby Redo Log 归档。 如果是写到Archived Log那么这个动作本身也可以看作是个归档操作。日志应用 redo apply 日志应用服务就是在Standby Database上重演Primary Database日志从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同可分为物理StandbyPhysical Standby 和 逻辑StandbyLogical Standby。
4、DATA GUARD的三种数据保护模式
所谓数据保护模式是指在Standby Database和Primary Database之间数据同步的程度。Data Guard允许定义三种数据保护模式分别是最大保护maxmium protection、最大可用maxmium availability、最大性能maxmium performance。 最大保护模式maxmium Production 这个级别保证Standby Database和Primary Database的数据是完全同步的即使Primary Database突然宕机在Standby Database上不会有任何数据丢失。 这种模式下Primary Database上的每个事务的Redo日志必须在本地和Standby Database上都写入日志文件后才能提交如果不能写入到Standby DatabasePrimary Database就会自动关闭以防止数据丢失。 这种方式要求Standby Database必须配置Standby Redo log而Primary Database必须使用LGWR、SYNC、AFFIRM方式归档到Standby Database。AFFIRM,磁盘io控制保证主备库日志同时写完 最大性能Maxmium Performance 这个模式是缺省模式他更加侧重对Primary Database的可用性不造成任何影响。 Primary Database上的事务的Redo日志只要写到本地日志文件就可以提交不必等待到Standby Database的传递完成。 Primary Database的Redo流可以异步的发送到Standby Database。 这种模式通过LGWR ASYNC或者ARCH实现Standby Database也不要求使用Standby Redo Log。 最大可用性Maxmium Availability 这种模式会尽量避免数据丢失Primary Database每个事务的Redo日志要写到本地和Standby Database中才能提交。 这个和最大保护模式不同的是如果写入到Standby Database失败Primary Database不会自动关闭。这时Primary Database会自动转换为Maxmium Performance模式等待问题解决并且Standby Database再次和Primary Database同步之后Primary Database会自动的转换为Maxmium Availability。 这种模式会尽量的避免数据丢失但不能绝对保证数据完全一致。 这种模式要求Standby Database必须配置Standby Redo log而Primary Database必须配置为LGWR、SYNC、AFFIRM方式归档。 如果要修改数据保护模式则可以按照以下操作进行。
shutdown immediate;
startup mount;
# 修改模式这里以最大可用性为例
alter database set standby database to maxmium availability;
# 打开数据库
alter database open;
# 确认模式已经修改
select protection_mode,protection_level from v$database;二、DG原理
tipARCH的结构和LGWR的结构均为日志发送 redo send内容
1、ARCH的结构 1、Primary Database不断的产生Redo Log这些日志被LGWR进程写到联机日志 2、联机日志写满以后发生日志切换触发ARC0完成本地归档 归档位置采用LOG_ARCHIVE_DEST_1‘LOCATION/path’ 3、完成本地归档以后联机日志可以被覆盖重用 4、ARCH1进程通过Net把归档日志发送给Standby Database的RFS进程 5、Standby Database端的RFS(Remote File Server)进程把接受到的日志写入到归档日志 6、Standby Database端的MRP(media recover process)进程Redo Apply或者LSP进程SQL Apply在Standby Database上应用这些日志进而同步数据 这种方式最大的问题是 Primary Database只有在发生归档时才会发送日志到Standby Database如果Primary Database异常宕机联机日志中的Redo内容会丢失因此这种方式没法避免数据丢失的问题。 要想避免数据丢失就必须使用LGWR而使用LGWR又有SYNC和ASYNC两种方式。
2、LGWR的结构 LGWR又分为同步SYNC和异步ASYNC两种方式下面分别介绍一下这两种方式
LGWR SYNC 同步方式 1、Primary Database产生的Redo日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发给本地的LNSn进程Network Server Process再由LNSn进程把日志通过网络发送到远程目的地每个远程目的地对应一个LNS进程多个LNS进程能够并行工作。 2、LGWR必须等待写入本地日志文件的操作和通过LNSn进程的网络传送都成功Primary Database上的事务才能够提交这也是SYNC的含义所在。 3、Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中 4、Primary Database的日志切换也会触发Standby Database上的日志切换即Standby Database对Standby Redo Log的归档然后触发Standby Database的MRP或者LSP进程恢复归档日志 因为Primary Database的Redo是实时传送的于是Standby Database端可以使用两种恢复方式 实时恢复Real-Time Apply只要RFS把日志写入Standby Redo Log就会立即进行恢复 归档时恢复在完成对Standby Redo Log归档才触发恢复。 Primary Database默认使用ARCHN进程如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时可以同时使用NET_TIMEOUT参数这个参数单位是秒代表如果多长时间内网络发送没有响应LGWR进程就会抛出错误。
LOG_ARCHIVE_DEST_2‘SERVICEST LGWR SYNC NET_TIMEOUT30’使用LGWR SYNC方法的可能问题在于如果日志发送给Standby Database过程失败LGWR进程就会出错也就是说Primary Database进程依赖于网络状况。一般也可以使用异步的LGWR模式也就是LGWR ASYNC。
LGWR ASYNC 异步方式 1、Primary Database一端产生Redo日志后LGWR把日志同时提交给日志文件和本地LNS进程但是LGWR进程只需要成功写入日志文件即可不必等待LNSn进程的网络传送成功。 2、LNSn进程异步地把日志内容发送到Standby Database多个LNSn进程可以并发发送 3、Primary Database的Online Redo Log写满后发生Log Switch触发归档操作也触发Standby Database对Stand Redo Log的归档然后触发MRP或LSP进程恢复归档日志 因为LGWR进程不会等待LNSn进程的响应结果所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数
LOG_ARCHIVE_DEST_2‘SERVICEboston LGWR ASYNC’3、日志接收Redo Receive
Standby Database的RFS进程接收到日志后就把日志写到Standby Redo Log或者Archived Log文件中具体写入哪种文件取决于Primary的日志传送方式和Standby Database的配置。 如果是写到Standby Redo Log文件中则当Primary Database发生日志切换时也会触发Standby Database上的Standby Redo Log的日志切换并把这个Standby Redo Log归档。 在日志接收中需要注意的是归档日志被放在什么位置Standby Database选择归档目录的算法如下。
1、如果配置了STANDBY_ARCHIVE_DEST参数则使用这个参数指定的目录 2、如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR(STANDBY_LOGFILE,*)选项则使用这个参数指定的目录 3、如果数据库的COMPATIBLE参数大于等于10.0则选取任意一个LOG_ARCHIVE_DEST_n的值 4、如果STANDBY_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_n参数都没有配置使用缺省的STANDBY_ARCHIVE_DEST参数这个缺省值是$ORACLE_HOME/dbs/arch
4、日志应用redo apply)
日志应用服务就是在Standby Database上重演Primary Database的日志从而实现两个数据库的数据同步。
根据应用方式划分
根据Standby Database重演日志方式的不同可分为物理StandbyPhysical Standby和逻辑StandbyLogical Standby两种类型。 Physical Standby使用的是Media Recovery技术MRP)在数据块级别上进行恢复这种方式没有数据类型的限制可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复也可以打开但是只能以只读方式打开并且打开时不能进行恢复操作。 Logical Standby使用的是Logminer技术(LSP)通过把日志内容还原成SQL语句然后SQL引擎执行这些语句Logical Standby不支持所有数据类型可以在视图dba_logstdby_unsupported中查看不支持的数据类型。如果使用了这种数据类型则不能保证数据完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。 Physical Standby的SCN号和主库保持一致而Logical Standby仅保持数据层面的一致。一般在应用过程中BUG会较多建议使用Physical Standby。
根据发生时间划分
根据Redo Apply发生的时间又可以分成两种
一种是实时应用Real-Time Apply这种方式必须使用Standby Redo Log。每当日志被写入到Standby Redo Log时就会触发恢复使用这种方式的好处在于可以减少数据库切换的时间Switchover或Failover因为切换时间主要用在剩余日志内容的恢复上。 另一种是归档应用这种方式是在Primary Database发生日志切换触发了Standby Database的归档操作归档完成后会触发恢复这也是缺省的恢复方式。 如果是Physical Standby可以使用下面的命令启用Real-Time alter database recover managed standby database using current logfile;如果是Logical Standby可以使用下面的命令启用Real-Time alter database start logical standby apply immediate;查看是否使用Real-Time Apply
select recovery_mode from v$archive_dest_status;5、自动裂缝检测和解决
当Primary Database的某些日志没有成功发送到Standby Database这时候发生了归档裂缝Archive Gap。 缺失的这些日志就是裂缝Gap。Data Guard能够自动检测解决归档裂缝不需要DBA的介入。这需要配置FAL_CLIENTFAL_SERVER 这两个参数FAL: Fetch Archive Log。
从FAL 这个名字可以看出这个过程是Standby Database主动发起的“取”日志的过程Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap 10g中这个FAL_SERVER可以是Primary Database 也可以是其他的Standby Database。 如FAL_SERVER‘PR1,ST1,ST2’; FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。FAL_CLIENT 通过网络向FAL_SERVER发送请求FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时会携带FAL_CLIENT参数值用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name这个Name是在FAL_SERVER上定义的用来指向FAL_CLIENT.
当然除了自动地日志缺失解决DBA 也可以手工解决。 具体操作步骤如下
1 查看是否有日志GAP
SQL SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; SQL SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
2 如果有则拷贝过来
3 手工的注册这些日志
SQL ALTER DATABASE REGISTER LOGFILE 路径;
