--DB2 HADR备库归档问题 --------------------------------2013/10/29 我们注意到在Oracle DataGuard中,备机中依然会设置LOG_ARCHIVE_DEST_1和LOG_ARCHIVE_DEST_2,备机接受的日志会和主机一样进行归档,在这一点上DB2的机制是不一样的. DB2的HADR的备库是不进行日志归档的. 参考讨论的贴: http://www.db2china.net/club/thread-30241-1-1.html

01.问题描述 备库的归档日志没有增加,一直等待一个 查询问题: SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- select name ,sequence# from v$archived_log; NAME SEQUENCE# -----------------------------------------------

WAL是Write Ahead Log的简写,和Oracle的redo日志类似,在R3版本存放在data/sys_log中,R6版本以后在data/sys_wal目录,在数据库访问过程中,任何对数据块的修改都会记录到wal日志,并写入到wal文件保存到磁盘,wal日志可用于数据库的实例恢复和数据恢复. 如果开启了归档,在目录archive_status下会有一些文件,以ready结尾的,表示可以归档但还没有归档,done结尾的表示已经归档.开启了归档后,只有归档成功的sys_wal文件才会被清除

报错如下,原因是存放传过来的归档的目录+HWAREDODG满了,MRP进程无法应用归档,我在手动传了几个归档之后发现不是GAP,select * from V$ARCHIVE_GAP 显示没有GAP.于是就把HWAREDODG下已经应用的归档删掉, rman target / rman>select 'run{' from dual union all select 'delete noprompt archivelog until sequence '||max(sequence#)||' t

上周五去某客户那里做数据库巡检.是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

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

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

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

问题现象: 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

案例说明: 1.对于集群中的wal日志,除了需要在备库执行recovery外,在集群主备切换(switchover或failover)时,sys_rewind都要读取wal日志,将数据库恢复到一致性状态. 2.对于集群主备库中的wal日志,在清理时,经过测试,理论上在checkpoint所在的wal日志之前的都可以清理,但这是比较理想的状态,在生产环境中,建议保留3天到一个星期的wal日志,避免因为主备延迟,导致在集群切换时,因为缺少wal日志失败. 3.对于KingbaseES V8R6的集群

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

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

一.需求 疑问?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 -----

案例说明: KingbaseES R3的后期版本支持通过sys_backup.sh执行sys_rman的物理备份,实际上是调用了sys_rman_v6的工具做物理备份.本案例是在备库上执行集群的备份,repo目录在备库上,采用cluster模式备份. 数据库版本: TEST=# select version(); VERSION ------------------------------------------------------------------------------------

切换顺序: 先主库后备库 --查看主库可切换状态: 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从备份集中抓出归档日志方法 在大连医院遇到这个问题,数据库为归档状态,但归档完成后rman通过crontab自己主动备走归档日志并删除存在系统上的归档日志文件.在RealSync程序停止一段时间后,须要应用归档日志来解决日志丢失问题. 问题是: 数据库中的控制文件里关于备份的元数据已经丢失,但备份集存在.这时候我们開始调用oracle的一个内部非公开的函数包:dbms_backup_restore 来从备份集中抽取归档日志到指定的系统文件夹.以满足我们的需求. 语句例如以下: dec

文档操作依据来自官方网址:https://docs.oracle.com/cd/E11882_01/server.112/e41134/scenarios.htm#SBYDB4888 闪回FAILOVER失败的物理备库的前提: 1.物理备库FAILOVER前设置db_recovery_file_dest_size足够大 2.物理备库AILOVER前设置db_recovery_file_dest路径 3.开启物理备库闪回数据库 The following steps assume that a f

一.开启归档 1.查看归档信息 SQL> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online 当前数据库未开启归档 2.设置归档目录 oracle默认使用闪回恢复区DB_RECOVERY_FILE_DEST作为归档路径 SQL> show parameter DB_REC

[20170825]11G备库启用DRCP连接3.txt --//昨天测试了11G备库启用DRCP连接,要设置alter system set audit_trail=none scope=spfile ; --//参考链接http://blog.itpub.net/267265/viewspace-2144036/.--//在测试过程中我遇到1个奇怪问题,就是如果主库没有打开drcp,备库执行exec dbms_connection_pool.start_pool();失败.--//今天分析看

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致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/