本文永久地址: https://www.askmac.cn/archives/time-spend-on-create-standby.html
- 通过多种手法,在以下的条件中制成物理standby,比较各自所花费的时间
- 数据库尺寸 57.2GB(已经使用的数据块总大小为52.8GB)
- 网络带宽40M(实际吞吐量为4.6MB左右)
- 在构建standby时,不会产生事务
验证环境
通过RMAN制成standby
模式1:从primary DB中直接制成拷贝
通过网络,直接向stand by 传送primary DB的数据文件,制成stand by DB
总计: 3:39:11
模式2:从primary DB的备份中制成(1)
获得primary DB的备份,储存备份,制成stand by DB
为了提高备份、复制的速度,可以使用多会话备份以及高速压缩功能(11gR1以后才可以使用)
总计: 1:12:26
模式3:从primary DB的备份中制成(2)
获得primary DB的备份,通过SCP复制到stand by中,储存备份,制成stand by DB。
因为我们假设使用的是10g,所以只能使用标准压缩功能
总计:1:40:37
验证結果
从primary DB中开始的直接复制(模式1),比以备份为基础的,11gR1开始的新功能(高速压缩、多会话备份)要慢得多
本文永久地址: https://www.askmac.cn/archives/time-spend-on-create-standby.html
验证结果详表
处理内容 | 模式1 | 模式2 | 模式3 | |
Backup | 获得primary DB的备份 | N/A | 0:18:24 | 0:32:28 |
SCP | 向stand by DB服务器传送备份 | N/A | 0:29:11 | 0:26:23 |
Nomount | 启动stand by DB实例 | 0:00:04 | 0:00:04 | 0:00:06 |
Duplicate | 制成DB存储以及REDO日志文件 | 3:39:01 | 0:24:40 | 0:41:33 |
StartMRP | 启动stand byDB的恢复进程 | 0:00:06 | 0:00:07 | 0:00:07 |
总计 | 3:39:11 | 1:12:26 | 1:40:37 |
重要的性能数值
- 文件传送性能
- 依赖于网络性能
- 本次验证中为4.6MB/s
- 依赖于网络性能
- 备份、存储性能
- 依赖于存储I/O 性能与压缩率
- 本验证中,压缩效果较好
- 模式2 : 备份尺寸 7.9GB
- 模式3 : 备份尺寸 7.1GB
- (参考)RMAN的压缩功能
- 压缩未使用的块:数据块会被跳过
- 二进制压缩 :输出备份时,会使用压缩算法
(参考)制成stand by的步骤概要
1.设定primary DB
- Force logging / 归档日志模式
2.设定初始化参数
3.将数据文件复制到stand by中
- 备份/存储 or 网络传送
4.制成REDO日志
5.开始管理恢复进程
本验证中,假设1、2都已经设定完成,以多种手法执行3、4、5,比较时间
通过RMAN制成stand by的区别
手法 | 使用要点 | 可以使用的版本 |
通过从primary DB中直接复制来制成 | •在网络带宽较广时有效
•无法保证备份用的区域时也是有效的 •可以估算DB尺寸、带宽 •在正式文件中可能发生较长时间的访问 |
11gR1以后 |
从primary DB的备份中制成(1) | • 压缩率较高,带宽较窄时有效。
•比(2)更快 •需要估算备份、存储的性能以及压缩率 • |
11gR1以后 |
从primary DB的备份中制成(2) | • 压缩率较高,带宽较窄时有效
•比(1)更慢 •需要估算备份、存储的性能以及压缩率 |
10gR1以后 |
Leave a Reply