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>

搭建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

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

今天在测试12c的temp_undo的时候,准备在备库上测试一下,突然发现备库使用TNS连接竟然失败. 抛出的错误如下: $ sqlplus sys/oracle@testdb as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 8 15:30:10 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. ERROR: ORA-12514: TNS:listene

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

背景 在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

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: ============================================

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

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

1.先查找备库控制文件路径 先在备库上找出控制文件的路径,通过和主库一样,不过为了以防万一,还是check为好. SQL>  select name from v$controlfile; NAME -------------------------------------------------------------------------------- /Oracle/app/oracle/oradata/powerdes/control01.ctl /oracle/app/oracle/

在创建逻辑备库之前,必须得先创建物理备库,关于如何创建物理备库,请参考<Data Guard 系列(4) - 在不停主库的情况下创建物理备库>. 1. 在物理备库上停止日志应用服务 SYS@jkka> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered. 2. 重新设置主库为将来的角色转换做准备(switchover) 逻辑备库和物理备库不一样,在进行SQL应用的时候还会产生日志,即逻辑备库的在

通过合理的设置,对于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

切换顺序: 先主库后备库 --查看主库可切换状态: 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,则切

在物理DG主备库切换时遇到ORA-16139: media recovery required错误 SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY * ERROR at line 1: ORA-16139: media recovery required 解决办法: --如果报ORA-16139: media recovery required,

非常抱歉!今天 12:03-12:52 ,由于数据库连接数异常突增超过1万,达到了阿里云RDS的最大连接数限制,影响了全站的正常访问.由此给您带来麻烦,请您谅解. 在发现数据库连接数突增的问题后,我们一开始怀疑可能是我们的某些应用中产生太多ADO.NET连接引起的,但是对嫌疑的应用们进行重启后,连接数依然高居不下. 后来,我们回想起去年9月份遇到的一次数据库问题,当时很多数据库查询超时,IOPS突增达到RDS的最大限制.开始我们也是从应用层面下手,但怎么也解决不了,后来实在没办法,试了试主备库切

--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

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

    备库搭建后,进入备库报错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)