环境:RHEL 6.4 + Oracle 11.2.0.4 一.主备手工切换 1.1 主库,切换成备库并启动到mount 1.2 备库,切换成主库并启动到open 1.3 新的备库启动日志应用 二.重命名数据文件 2.1 主库,对应的数据文件或者表空间offline 2.2 主库,操作系统层面重命名数据文件 2.3 主库,重命名数据文件,表空间online 2.4 备库,停止redo应用 2.5 备库,关闭数据库 2.6 备库,操作系统层面重命名数据文件 2.7 备库,启动到mount状态 2.…

环境:RHEL 6.5 + Oracle 11.2.0.4 三.监控DG的状态 3.1监控DG备库的状态 3.2监控主库传输日志链路的状态 四.备库切换为snapshot standby 4.1备库切换为snapshot standby后测试 4.2开始读写测试 五.备库还原为physical standby 5.1备库还原为physical standby 5.2验证数据还原到切换前状态 三.监控DG的状态 3.1 监控DG备库的状态 在备库查询v$dataguard_stats视图信息: -…

一.切换前检查1.检查备库已经全部接收到主库的redo如果是最大可用性.最大保护性模式,可以在primary端查看v$archive_dest_status,确认是否所有的redo已经传送到备库#在主库执行 SQL> select db_unique_name,protection_mode,synchronization_status,synchronized from v$archive_dest_status; DB_UNIQUE_NAME PROTECTION_MODE SYNCHRON…

Oracle 10g/11g下如何将物理Standby库临时激活用于测试 在实际运营环境中, 我们经常碰到类似这样的需求: 譬如想不影响现网业务评估DB补丁在现网环境中运行的时间, 或者是想在做DB切换前想连接Standby DB做实际业务运行的测试. 如果在9i版本的时候, 想做到这样, 在不搭建新测试环境的前提下, 可以将Standby DB激活后进行测试, 但是激活后的Standby DB将不能再用于容灾, 必须重建Standby DB; 在10g以及11g之后, 可以利用新特性很好的解决…

1.failover前检查 #如果有多个standby数据库,查看哪个standby接收的redo最新. SQL> select * from v$archive_dest_status: #查看standby库接收到的最新的SCN SQL> select thread#,sequence#,last_change#,last_time from v$standby_log; THREAD# SEQUENCE# LAST_CHANGE# LAST_TIME ---------- -------…

环境: 主库A机:在线生产环境,RHEL 6.4 + Oracle 11.2.0.3 备库B机:新增备机,RHEL 6.4 需求: 对生产环境最小影响前提下配置DG备库. 目录: 一.B机安装相同版本Oracle软件 二.A机,B机配置网络连接 2.1 配置listener.ora 2.2 配置tnsnames.ora 2.3 生成密码文件 三.配置主库A机,需要重启A机数据库 四.duplicate主库到备机 4.1 B机确定以下目录存在且赋予正确权限 4.2 B机数据库启动到nomount模…

Oracle 11g是Data Guard的重要里程碑版本.在11g中,Active DataGuard.Advanced Compression等特性大大丰富了Data Guard的功能和在实践领域应用的广度.其中,除了传统的Physical Standby和Logical Standby,11g推出了新的Standby类型——Snapshot Standby. Standby的实质是“同步更新”,无论是Physical Standby还是Logical Standby,都是依照主库Prima…

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

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…

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…