搭建oracle 级联DG 现有架构:physical standby 一主二备,在此基础上,在主库下新建备库standby3.级联备库cascade 数据库版本 11.2.0.4 db_name=prod db为主库,dg1为备库,dg2为级联备库:DB_UNIQUE_NAME DATABASE_ROLEdb primary 10.100.12.10 dg1 standby1 10.100.12.11 dg2 standby2 10.100.12.12 三个库的LOG_FILE_NAME_CO…

DG架构图如下: 计划,切换之后的架构图: DG切换: 主备切换:这里所有的数据库数据文件.日志文件的路径是一致的 [旧主库]主库primarydb切换为备库standby3主库检查switchover_status列的状态,是否支持switchover操作:如果该列值为"TO STANDBY"则表示primary 数据库支持转换为standby 角色prod> select switchover_status from v$database;SWITCHOVER_STATUS-…

oracle 利用flashback将备库激活为read wirte(10g 及上) 环境: OS: CENTOS 6.5 X64 DB: ORACLE 10.2.0.5 主库操作: SQL> alter system switch logfile; System altered. SQL> 备库操作 取消归档应用 SQL> alter database recover managed standby database cancel; Database altered. SQL>…

    备库搭建后,进入备库报错psql: FATAL:  the database system is starting up  原因:备库配置文件没有hot_standby = on   master -bash-4.1$ ps aux |grep post postgres  89707  0.0  0.0 43196188 2872 ?       Ss   00:15   0:27 postgres: wal sender process rep 10.40.55.69(26717)…

linux下oracle11G DG搭建(三):环绕备库搭建操作 环境 名称 主库 备库 主机名 bjsrv shsrv 软件版本号 RedHat Enterprise5.5.Oracle 11g 11.2.0.1 RedHat Enterprise5.5.Oracle 11g 11.2.0.1 三.环绕备库操作: 1.备库-改动初始化參数文件 $cd$ORACLE_HOME/dbs $df -h $vi initshdb.ora 改动简要说明: *.audit_file_dest='/u01/…

主库: 一:强制force logging: alter database force logging; 二:开启主库的归档模式 三:主库添加standby redo log,比redo日志组多一组: ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/data/app/oracle/oradata/PROD/redo04_1.log','/data/app/oracle/oradata/PROD/redo04_2.log') size 1024M; AL…

在实际运营环境中,我们经常碰到类似这样的需求,譬如想不影响现网业务评估DB补丁在现网环境中运行的时间,或者是想在做DB切换前想连接Standby DB做实际业务运行的测试,如果在9i版本的时候,想做到这样,在不搭建新测试环境的前提下,可以将Standby DB激活后进行测试,但是激活后的Standby DB将不能再用于容灾,必须重建Standby DB.在10g以及11g之后,可以利用新特性很好的解决这个问题,激活的Standby DB可以闪回到激活前的状态,继续参与容灾,而不需要重建. 下面简…

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

以以下keyword眼为例: 1 物理备库健康检查根据: Tue Apr 22 16:44:51 CST 2014Media Recovery Log /data/CMS/arch_log/1_58334_722210153_58334arch.dbfMedia Recovery Waiting for thread 1 sequence 58335 (in transit) 2 逻辑备库健康检查根据:Tue Apr 22 16:44:48 CST 2014LOGMINER: Begin min…

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;确认下是否存在日志间隙,发现gap现象,说明failover不会有数据损失情况.在standby端,关闭apply和结束应用动作 SQL> alter database recover managed standby database cancel;数据库已更改. SQL> alter database recover managed standby…