概述: 一.环境      主库:       ip地址:192.168.122.203       oracle根目录:/data/db/oracle       SID:qyq       数据文件路径/data/db/oracle/oradata/qyq       归档文件路径:/data/db/oracle/archive'      备库:       ip地址:192.168.122.204       oracle根目录:/data/app/oracle       SID:qy

导读: 最近数据库经常出现会话阻塞的报警,过一会又会自动消失,昨天晚上恰好发生了一次,于是赶紧进行了查看,不看不知道,一看吓一跳,发现是由dataguard引起的log file sync等待.我们知道,通常log file sync等待都是由频繁写日志造成的,这次居然是由DG环境引起的. (一)问题描述 数据库:Oracle 11.2.0.4,单机版,有Dataguard环境 操作系统:centos 7.4 通过zabbix监控到的会话阻塞信息如下图,这里是自定义的监控,解释如下: 用户use

问题现象 在使用shutdown abort停DataGuard备库后.备库不能open,报ORA-01196错误. 详细例如以下: 发现一备库不能应用日志.查看备库日志没发现报错.怀疑是备库应用日志服务停止,于是尝试重新启动备库. 可能由于备库是读业务比較繁忙,在shutdown immediate关闭备库时等时间过长,于是使用了shutdown abort命令: 但后面在启动备库时发生报错,造成数据文件损坏,控制文件和数据文件的scn号不一致. --启动备库时报错 SQL> startup

今天遇到一个数据库同步问题,主库被关闭,重启主库后,备库不能正常同步主库数据.只有当手动切换归档日志的时候,备库才能和主库一致. 这个问题的解决方法: 重启备库,重新应用归档日志. 操作步骤如下: //关闭备库监听器 lsnrctl stop //关闭备库 sqlplus / as sysdba alter database recover managed standby database cancel; shutdown immediate; //启动备库 startup nomount; a

环境是12.2.0.1 version, Oracle Data Guard备库近段时间一直报错,但是备库主库同步一致,数据一致. 2019-03-06T23:42:22.184048+08:00 Errors in file /u01/app/oracle/diag/rdbms/ccdb/ccdb/trace/ccdb_m000_129832.trc: ORA-01110: data file 7: '/u01/app/oracle/oradata/ccdb/users01.dbf' 2019

结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备库和主库的延迟时间能够控制在毫秒级.物理复制只能复制整个实例. 逻辑复制也成为选择性复制,可以做到基于表级别的复制,选择需要逻辑复制的表,而不是复制实例上的所有数据库的表,10版本不支持内置的逻辑复制,通常使用第三方逻辑复制. WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,但

DG搭建时,官方文档手册有明确提到要设置数据库为force_logging,防止有nologging操作日志记录不全导致备库应用时出现问题. 虽然是老生常谈的安装规范,但现实中总会遇到不遵守规范的场景,最近就在某客户现场遇到一则这样的案例,因为DG主库设置force_logging晚于DG搭建,导致备库出现坏块,使用dbv检查就表现为DBV-201错误. 下面我们来模拟下这个场景,同时演示下具体修复过程: 1.准备实验环境 2.构造故障场景 3.解决故障 1.准备实验环境 主库确认没有开启for

OGG 从Oracle备库同步数据至kafka Table of Contents 1. 目的 2. 环境及规划 3. 安装配置JDK 3.1. 安装jdk 3.2. 配置环境变量 4. 安装Dataguard 4.1. 安装备库软件 4.2. 配置dataguard 4.2.1. 主库 4.2.2. 备库 4.3. 完成操作 4.4. 启动实时复制 5. zookeeper集群 5.1. 上传并解压 5.2. 配置 5.3. 创建myid文件 5.4. 配置环境变量 5.5. 启动和查看服务

Oracle 11.2.4.0 ADG 单实例安装(COPY创建备库) 规划: 主: OS: Linux Centos 6.5 X64 hostname:ORA11G-DG1 ipaddress:192.168.213.199 db_unique_name=netdata_pd db_name=netdata 备: OS: Linux Centos 6.5 X64 hostname:ORA11G-DG2 ipaddress:192.168.213.200 db_unique_name=netda

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE

环境: OS: CentOS 6.5 X64 DB: oracle 10.2.0.5 故障:之前由于错误激活备库主写导致主备日志同步,重建备库 1.关闭备库,删除数据文件及控制文件,redo文件 rm -rf *.log rm -rf *.ctl rm -rf *.dbf 2.主库备库 channel ORA_DISK_1: starting piece 1 at 13-SEP-14 RMAN-00571: ============================================

http://blog.itpub.net/29477587/viewspace-1331121/ 前段时间做了一次主备库的切换,大体写下操作步骤和记录,分享下. 环境:           db version:11.2.0.3           主库:两节点的RAC          备库:两节点的RAC        是异地灾备,网络质量不太好. 步骤: 1.检查日志应用情况 standby database(备库检查): SQL> select thread#,SEQUENCE#,FI

切换顺序: 先主库后备库 --查看主库可切换状态: SQL> select switchover_status from v$database; SWITCHOVER_STATUS -------------------- TO STANDBY --执行切换命令转换primary到physical standby: SQL>alter database commit to switchover to physical standby; 如果查询到的可转换状态为SESSION ACTIVE,则切

本文主要描述Oracle备库日志与主库日志之间有gap,切主库这部分gap的归档日志已经删除或丢失,如何在不重建备库的情况下,恢复备库. 欢迎转载,请注明作者.出处. 作者:张正 blog:http://space.itpub.net/26355921  QQ:176036317 如有疑问,欢迎联系. 在dataguard环境中,由于主库archivelog丢失,且尚未同步到standby,问如何在避免 重建standby的情况下来将standby恢复成功的. 下面是我的测试过程,供参考! —-

简介 ORA-10458: standby database requires recovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1: 'XXXXXXXXXXXXXXXXXX\XXXXX1.DBF' 一个项目做了Oracle主从数据库同步,通过Dataguard实现,从库服务器宕机,再开机的时候,从库无法启动,报"ORA-01196: 文件 1 由于介质恢复会话失败而不一致"这个错误,具体日志信息如下: ORA-10458:

一.参数说明 [1] db_file_name_convert db_file_name_convert 主数据库和备用数据库的数据文件转换目录对映(如果两数据库的目录结构不一样),如果有多个对映,逐一指明对映关系. 格式: *.db_file_name_convert= 主数据库数据文件目录,备用数据库数据文件目录 [2] log_file_name_convert 指明主数据库和备用数据库的log文件转换目录对映. 格式: *. log_file_name_convert=主数据库log目录

背景 在mysql主备环境下,主备同步过程如下,主库更新产生binlog, 备库io线程拉取主库binlog生成relay log.备库sql线程执行relay log从而保持和主库同步. 理论上主库有更新时,备库都存在延迟,且延迟时间为备库执行时间+网络传输时间即t4-t2. 那么mysql是怎么来计算备库延迟的? 先来看show slave status中的一些信息 io线程拉取主库binlog的位置 Master_Log_File: mysql-bin.000001 Read_Master

  演练包括被动切换和主动切换两部分.被动切换是主库宕机,主动切换是人工手动触发.   演练步骤大致如下:       1 先停掉主库,模拟主库宕机     2 mha将vip切到备库,备库变成主库,应用可以正常读写数据库     3 重新启动宕机的原主库     4 在原主库上建立同步关系(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始)     5 mha手动切换主库,还原到最初状态,应用可以正常读写数据库     6 演练结束     演练过程问题总结:   1 mha

通过合理的设置,对于Primary的绝大数操作,都是可以传递到Physical Standby,datafile的操作是通过STANDBY_FILE_MANAGEMENT参数来控制的,但是即使STANDBY_FILE_MANAGEMENT设置为auto,对于rename操作,standby还是忽略的. If you do not rename the corresponding datafile at the standby system, and then try torefresh the

DG之主库.备库切换 一．开库与关库顺序 开库顺序 先启备库,再启主库(启动监听.打开告警日志) 关库顺序 先关主库,再关备库 二．主备库切换 1.操作过程一览 步骤1:启动备库.监听.告警: 步骤2:启动主库.监听.告警: 步骤3:主库(bj)查询信息 SQL>selectname,dbid,database_role,protection_mode from v$database; 步骤4:备库(sh)上做recover SQL>recovermanaged standby databas