本文永久地址: https://www.askmaclean.com/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.askmaclean.com/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 |
重要的性能数值
- 文件传送性能
- 备份、存储性能
- 依赖于存储I/O 性能与压缩率
- 本验证中,压缩效果较好
- 模式2 : 备份尺寸 7.9GB
- 模式3 : 备份尺寸 7.1GB
- (参考)RMAN的压缩功能
- 压缩未使用的块:数据块会被跳过
- 二进制压缩 :输出备份时,会使用压缩算法
(参考)制成stand by的步骤概要
1.设定primary DB
2.设定初始化参数
3.将数据文件复制到stand by中
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以后 |