oracle11gr2 active data guard,Oracle11gR2 Aactive DataGuard(手动)装配部署及维护文档(三)之升级及rman...
Oracle11gR2 Aactive DataGuard(手动)安装部署及维护文档(三)之升级及rman
l 第六部分: dataguard其它管理问题
一.滚动升级DG
升级概要:
1. 升级备用数据库。
2. 将应用程序转移至备用数据库。
3. 升级主数据库。
4. 将应用程序转移回原来的主数据库。
逻辑、物理DG具体升级过程:
逻辑DG滚动升级过程:
1. 停止恢复逻辑备库。
2. 升级逻辑备库。
3. 备库断续恢复完成”弥补”
4. 将备用库转换为主数据库。
5. 将原始的主库转换为备库,然后进行升级。
6. 升级完成后,最后再次角色反转,原来的主库作为新的主库。
物理DG滚动升级过程:
1. 将物理备库转换成临时的逻辑备库。
SQL> alter database recover to logical standby keep identity;
Database altered.
2. 停止恢复逻辑备库。
3. 升级逻辑备库。
4. 备库断续恢复完成”弥补”
5. 将备用库转换为主数据库。
6. 将原始的主库转换为备库,然后进行升级。
7. 升级完成后,然后再次角色反转,原来的主库作为新的主库。
8. 最后把此时的逻辑备库转为物理备库。
注意:通过上面的步骤可以看出,升级物理DG的操作只是多了一步把逻辑备库转换成主物理备库,然后的步骤和升级逻辑DG相同。升级完成后再把逻辑备库转换成物理备库。
详细信息见:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/rollup.htm#BABGHIGF
二.11g其它DG特性
1. 网络超时
Data Guard 环境的工具原理是:连接备用服务器端的数据库实例,向备用服务器发送重做数据。如果实
例没有及时响应,日志传输服务将等待指定的超时值,然后放弃。可以在 Oracle 数据库中使用
net_timeout 参数设置超时值。在最大限度的保护模式下,日志传输服务将尝试 20 次后放弃。
但首选您要知道日志传输中当前的延迟。新视图 v$redo_dest_resp_histogram 以直方图形式表示了该时
间值:
SQL> desc v$redo_dest_resp_histogram
Name Null? Type
---------------------- ------- --------------
DEST_ID NUMBER
TIME VARCHAR2(20)
DURATION NUMBER
FREQUENCY NUMBER
该视图在给定圆柱中向您显示了传输花费时间中的次数。如果运行几天后再查看此视图,您可以清楚要设
置的超时时间。然后可使用以下命令设置超时时间:
alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'
这还是来自于上面的示例。注意参数值中的子句“net_timeout=20”。
2. 可动态修改的参数
在运行逻辑备用数据库环境的过程中,您需要调整该过程并修改一些参数值。在 Oracle 数据库 11g 中,
这些参数中的大部分可以在线更新。您可以通过查询视图 dba_logstdby_parameters 来查看这些参数。
col name format a30
col value format a10
col unit format a10
col setting a6
col setting format a6
col dynamic format a7
select *
from dba_logstdby_parameters
order by name
/
NAME VALUE UNIT SETTIN DYNAMIC
------------------------------ ---------- ---------- ------ -------
APPLY_SERVERS 5 SYSTEM YES
EVENT_LOG_DEST DEST_EVENT SYSTEM YES
S_TABLE
LOG_AUTO_DELETE TRUE SYSTEM YES
LOG_AUTO_DEL_RETENTION_TARGET 1440 MINUTE SYSTEM YES
MAX_EVENTS_RECORDED 10000 SYSTEM YES
MAX_SERVERS 9 SYSTEM YES
MAX_SGA 30 MEGABYTE SYSTEM YES
PREPARE_SERVERS 1 SYSTEM YES
PRESERVE_COMMIT_ORDER TRUE SYSTEM NO
RECORD_APPLIED_DDL FALSE SYSTEM YES
RECORD_SKIP_DDL TRUE SYSTEM YES
RECORD_SKIP_ERRORS TRUE SYSTEM YES
RECORD_UNSUPPORTED_OPERATIONS FALSE SYSTEM YES
注意列 DYNAMIC,其中显示了值是否可动态修改。几乎所有的参数都是动态的。例如,要更改参数
APPLY_SERVERS 同时不停止备用数据库,您可以使用:
SQL> begin
2 dbms_logstdby.apply_set('APPLY_SERVERS',2);
3 end;
4 /
这会将 apply_servers 设置为 2,从而无需关闭备用数据库即可完成这一任务。
3. SQL 应用事件表
在 Oracle 数据库 10g 中,与 SQL Apply 相关的事件将写入到警报日志中,这没有很大的用处,因为您可
能想编写脚本检查它们,用于警报或报告。在 Oracle 数据库 11g 中,默认将事件写入 SYSTEM 模式下的
新表 LOGSTDBY$EVENTS。下面是一个查询示例:
select event_time, error
from system.logstdby$events
order by 1;
EVENT_TIME ERROR
----------------------------- -------------------------------------------------
13-JAN-08 11.24.14.296807 PM ORA-16111: log mining and apply setting up
13-JAN-08 11.24.14.320487 PM Apply LWM 2677727, HWM 2677727, SCN 2677727
14-JAN-08 07.22.10.057673 PM APPLY_SET: APPLY_SERVERS changed to 2
14-JAN-08 07.22.11.034029 PM APPLY_SERVERS changed to 2
14-JAN-08 07.45.15.579761 PM APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
14-JAN-08 07.45.16.430027 PM EVENT_LOG_DEST changed to DEST_ALL
将事件保存在表中非常有用,原因众多,其中之一就是操作和报告更加方便。但有时将它们保存在警报日
志中也很有用,特别是当使用一些监视工具来扫描警报日志以获取错误和消息时。您可以将逻辑备用数据
库应用参数“event_log_dest”设置为“DEST_ALL”来达到这一目的:
begin
dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');
end;
该任务可以动态完成,现在事件将同时传输到表和警报日志中。执行这一命令后,您可以检查警报日志,
除可能的大量的 SQL Apply 事件外,它至少还更改了这两行:
LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL
三.在data guard环境用RMAN
1. ORACLE推荐使用的RMAN和DB配置
1) 配置假定说明:
下面配置步骤假设满足下面环境的情况
standy库是一个物理的备库,而且仅在standby库进行备份
使用recovery catalog进行备份,以便在一个服务器上的备份能恢复到另一个服务器上,而且recovery catalog有足够空间存储rman的备份信息;catalog备份服务器能从物理上隔离主库和备,当灾难发生后,不影响很久之前备份的恢复,所以oracle推荐使用recovery catalog方法做备份
数据库配置环境是oracle 11gR1
使用oracle 安全备份软件和第三方介质管理软件配置RMAN备份到磁带上
2) 主库和备库的环境配置
在DG环境中,下面的配置是被推荐使用在每个主库和备库。
配置一个FRA(快速闪回区)在本地位置,配置下面的参数
DB_RECOVERY_FILE_DEST =
DB_RECOVERY_FILE_DEST_SIZE =
使用Spfile参数文件,以便rman能备份spfile参数文件。
开启数据库闪回功能,以便能闪回数据库到比较早的时点。
3) 在主库的RMAN配置
下面是在主库被推荐使用的rman配置
A. 用RMAN连接主库和recovery catalog
B. 配置备份保存策略,如下
RMAN>CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
RMAN>CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF DAYS;
C. 配置归档删除策略
如果是设置日志传送完成后删除归档如下:
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
如果是设置日志应用完成后删除归档如下:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED TO ALL STANDBY;
D. 配置连接串在主和备库,配置RMAN的主备库DB_UNIQUE_NAM参数:
当使用下面的命令时所用到RESYNC CATALOG FROM DB_UNIQUE_NAME。配置方法如下:
CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';
注意:主备库密码文件的sysdba密码必需相同,'boston_conn_str'是在主库配置备库的的tns连接服务别名。
RMAN> CONFIGURE DB_UNIQUE_NAME 'HTDB2' CONNECT IDENTIFIER 'htdb2_242';
RMAN> CONFIGURE DB_UNIQUE_NAME 'HTDB3' CONNECT IDENTIFIER 'htdb3_243';
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
数据库列表
数据库关键字 数据库名称 数据库 ID 数据库角色 Db_unique_name
------- ------- ----------------- --------------- ------------------
1 HTDB2 1139129460 PRIMARY HTDB1
1 HTDB2 1139129460 STANDBY HTDB3
1 HTDB2 1139129460 STANDBY HTDB2
RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME 'HTDB2';
从 DB_UNIQUE_NAME 为 HTDB2 的数据库进行重新同步
在执行完上面的resync语句后,主库的CONFIGURE就会同步到备。可以分别用show all查看主备库配置。
4) 在备库执行备份的RMAN配置
在standby库上做备份的库上,下面的RMAN配置是推荐使用的。
A. 使用rman连接目标备库和recovery catalog.
B. 启用controlfile和spfile文件自动备份
CONFIGURE CONTROLFILE AUTOBACKUP ON;
C. 跳过在已经存在的末发变化有效的数据文件备份
CONFIGURE BACKUP OPTIMIZATION ON;
D. 使用介质管理软件配置磁带备份通道
CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '';
E. 配置归档删除策略,如:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
注意:因为在standby库执行了日志备份,建议再进行配置BACKED UP选项为日志删除策略。如:
backup as compressed BACKUPSET archivelog all not backed up delete all input;
5) 在备库未执行备份的RMAN配置
在未执行备份的备库上,下面的RMAN配置是建议使用的
A. 使用rman连接目标备库和recovery catalog.
B. 启动归档自动删除策略。
如果在备库配置了下面的参数,在备库归档被应用之后,备库会根据FRA的存储空间自动删除归档日志
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
oracle11gr2 active data guard,Oracle11gR2 Aactive DataGuard(手动)装配部署及维护文档(三)之升级及rman...相关推荐
- oracle adg维护,Oracle11gR2 Aactive DataGuard(手动)装配部署及维护文档(三)之升级及rman...
Oracle11gR2 Aactive DataGuard(手动)安装部署及维护文档(三)之升级及rman l 第六部分: dataguard其它管理问题 一.滚动升级DG 升级概要 ...
- oracle查效能,【DataGuard】Oracle 11g物理Active Data Guard实时查询(Real-time query)特性...
在Oracle 11g以前版本中的的Data Guard物理备用数据库,可以以只读的方式打开数据库,但此时Media Recovery利用日志进行数据同步的过程就停止了,如果物理备用数据库处于恢复的过 ...
- Steps to configure Oracle 11g Data Guard Physical Standby – Active Data Guard Part-I
2019独角兽企业重金招聘Python工程师标准>>> Steps to configure Oracle 11g Data Guard Physical Standby – Act ...
- Oracle Livelabs实验: Setting Up Active Data Guard For On-Premises
本文是Oracle LiveLabs实验:Setting Up Active Data Guard For On-Premises 的过程记录. 实验步骤请参考这里. 因为是利用你自己的OCI云环境搭 ...
- oracle active data guard概述
Oracle Active Data Guard 每个 I.T. 组织都面临在提高服务质量的同时降低成本和复杂性的挑战.要使关键业务事务实现一致的高性能,一个方法就是将附加工作卸载到生产数据库的副本. ...
- 体验一下Oracle 11g物理Active Data Guard实时查询(Real-time query)
以下为[高可用] 课后一则实验日志: --------------------------------------------------------------------------------- ...
- oracle查效能,Oracle 11g物理Active Data Guard实时查询(Real-time query)特性
table t (x varchar2(8)); Table created. secooler@ora11g> insert into t values ('Secooler'); 1 row ...
- ORACLE 11G DATA GUARD配置之Dataguard简介
Oracle DataGuard是Oracle自带的数据同步功能,基本原理是将日志文件从原数据库传输到目标数据库,然后在目标数据库上应用这些日志文件,从而使目标数据库与源数据库保持同步,是一种数据库级 ...
- [置顶] Oracle 11.2.0.3.0 Active Data Guard 遇 ORA-10458、ORA-01152、ORA-01110 错误
今天第一次配 Oracle 11g R2 Active Data Guard,在用 RMAN 创建好 physical standby database 后, 尝试将 standby 以 read o ...
最新文章
- exist not exist 分析
- MTM:matlab实现2参数解析
- 无表头单链表的总结----删除节点
- 集水井盖板图集07fj02_【干货】住宅通病详细图集(图文详解)
- Unity 分析器(仅专业版) Profiler (Pro only)
- 个人量化交易初探之一(数据的爬取)
- 变频器RS485通讯协议
- 什么是Power BI?
- OrCAD+PADS联合绘制PCB的总结
- 台达PLC无线通讯方案
- R语言如何向向量中追加一个元素?
- MySQL第七讲 MySQL的高可用方案
- 游戏平台推广怎么做?
- 如何申请域名和购买服务器?
- ex2 ex3_他甩了我后,我Ex了我的前任
- 老司机 iOS 周报 #26 | 2018-07-09
- 天梯赛7-3 A-B
- 使用 JavaScript 在网站上实现计数功能
- 语义分割看这一篇就够了!
- 图片标签和多媒体标签的使用