本文永久地址： https://www.askmac.cn/archives/time-spend-on-create-standby.html
- 通过多种手法，在以下的条件中制成物理standby，比较各自所花费的时间
- 数据库尺寸 57.2GB（已经使用的数据块总大小为52.8GB）
- 网络带宽40M（实际吞吐量为4.6MB左右）
- 在构建standby时，不会产生事务
验证环境
通过RMAN制成standby
模式１：从primary DB中直接制成拷贝
通过网络，直接向stand by 传送primary DB的数据文件，制成stand by DB
总计： 3:39:11
模式２：从primary DB的备份中制成（１）
获得primary DB的备份，储存备份，制成stand by DB
为了提高备份、复制的速度，可以使用多会话备份以及高速压缩功能（11gR1以后才可以使用）
总计: 1:12:26
模式３：从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的备份中制成（１） | • 压缩率较高，带宽较窄时有效。
•比（２）更快 •需要估算备份、存储的性能以及压缩率 • |
11gR1以后 |
| 从primary DB的备份中制成（２） | • 压缩率较高，带宽较窄时有效
•比（１）更慢 •需要估算备份、存储的性能以及压缩率 |
10gR1以后 |
Leave a Reply