故障描述: 主库异常下线,需要将备库强制启动为主库,切断日志时提示需要介质恢复,执行介质恢复后,再激活日志即可进行切换 1.  执行alter database recover managed standby database finish force; 发现需要恢复介质 2.  确认归档日志目录中是否存在最近的日志 检查发现该目录中只有最开始建立时的3个日志,没有1月22日调整时的日志,检查发现是因为计划任务中有删除归档日志这个任务导致,至少说明后面的日志都已应用 3.  确认归档日志文件是否

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

一.需求 疑问?Oracle最大保护模式下,dg备库出现问题,影响主库吗? 我们都知道Oracle最大保护模式的意思是oracle不允许数据丢失,1条记录都不行! 那么备库有问题? oracle主库还能读写吗? 二.测试 2.1 现有情况查询 --查询保护模式:最大保护 SQL> select name,dbid,database_role,protection_mode from v$database; NAME DBID DATABASE_ROLE PROTECTION_MODE -----

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与DG备库接受归档有什么关系? 1. 实验环境: 类别 主库 备库 软件版本 11.2.0.4.0 11.2.0.4.0 是否RAC 否 否 Db_name ENMO Db_unique_name ENMO dage Service_name ENMO dage Listener.ora 192.168

问题现象: XXXsdgebus-dg GAP手工注册归档 #出现GAP idle>select * from v$archive_gap; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1        140513         140513 一.备库查询: #查询DG架构中存在的UNIQUE_NAME log_archive_config                DG_CON

本篇文档学习,DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证 1.取消MRP进程 备库查询进程状态select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby;PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS--------- -------- ---------- ------------ ---------- -

我的最佳实践 ① 手动创建好初始化参数文件: *.audit_file_dest='E:\APP\XJXU\ADMIN\ORASTAND\ADUMP'*.control_files='E:\APP\XJXU\ORADATA\ORASTAND\CONTROL01.CTL','E:\APP\XJXU\FLASH_RECOVERY_AREA\ORASTAND\CONTROL02.CTL'*.core_dump_dest='e:\app\xjxu\diag\rdbms\orastand\orastand

环境是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

DG1是主库,DG2是备库:运行在最大可用模式. 实验一:未使用using current logfile参数时,备库在最大可用模式下,不能实时同步备库的更新 -此时需要等待主库进行归档---侧面证明备库应用的归档来恢复数据. BYS@dg1>show parameter log_archive_dest_2 NAME                                 TYPE        VALUE ------------------------------------ --

上周五去某客户那里做数据库巡检.是window 2008系统上10g的一套NC系统的库,已经配置了DG,可是巡检时发现数据库报错: Tue Nov 11 10:13:57 2014 LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2 Tue Nov 11 10:14:29 2014 Errors in file d:\oracle\product\10.2

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>

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. 启动和查看服务

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

Oracle DG 搭建1. 环境 OS IP hostname db_name DB_UNIQUE_NAME主库 RHEL 5.4 192.168.12.20 edgzrip1.oracle.com PROD1 PROD1备库 RHEL 5.4 192.168.12.30 edgzrip2.oracle.com PROD1 DG 2. 设置主库开启归档SQL> alter database archivelog;Database altered.3. 设置主库开启强制记录日志SQL> alt

select DEST_ID, APPLIED_SCN FROM v$archive_dest select * from v$dataguard_status; SELECT gvi.thread#, timestamp, message FROM gv$dataguard_status gvds, gv$instance gvi WHERE gvds.inst_id = gvi.inst_id AND severity in ('Error','Fatal') ORDER BY timest

概述: 一.环境      主库:       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

问题: 客户环境12.2 dg备库环境,定时清理归档脚本并未正常清理归档日志文件. 观察日志可以发现存在如下信息 RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process . 一般情况下,如果在备库环境或者主库环境,配置归档清理测量后,DG环境未应用归档将不允许删除. 本次排查RMAN清理归档策略默认,且无法删除的归档日志在DG视图v$archived_log 中ap

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

一.物理备库切换快照备库 1. 如果正在运行日志应用,先停止 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2. 确保数据库为MOUNTED状态 SHUTDOWN IMMEDIATE STARTUP MOUNT; 3. 确保已经配置快速恢复区,但不用开启闪回数据库功能 SHOW PARAMETER db_recovery_file_dest; #如何没有配置快速恢复区,请使用以下SQL语句配置: ALTER SYSTEM SET