企业官网建设流程全解析

网站建设相关图片,建设vip视频解析网站违法吗,如何给公司做自己的网站,湖南网站优化代运营为了不错过每一期干货#xff0c;强烈建议关注我 写技术文章#xff0c;纯属“为爱发电”#xff1b;更新不易#xff0c;希望大家能够多多支持 1️⃣ 点赞的人#xff0c;今年都升职加薪了 2️⃣ 点在看人#xff0c;今年一定会发财 3️⃣ 评论区交流技术#xff0c;每…为了不错过每一期干货强烈建议关注我写技术文章纯属“为爱发电”更新不易希望大家能够多多支持1️⃣ 点赞的人今年都升职加薪了2️⃣ 点在看人今年一定会发财3️⃣ 评论区交流技术每条留言都会回复如何估算 GoldenGate Extract 重做处理速度问题描述有时候我们想估算 OGG Extract 性能的一个常用标准是其处理 Oracle 重做日志/归档日志的速度。本文介绍一种估算该速度的方法。适用范围Oracle GoldenGate 版本 10.4.0.0 及更高版本估算方法通过执行send extract ext, status命令可以查看 Extract 当前的读取位置。该位置可能与当前检查点不同因为检查点仅定期更新。因此这种方法比通过info extract ext估算更为准确。如果获取两个时间点的读取位置其差值即为 Extract 处理的字节数。将该差值除以两次快照的时间间隔即可得到处理速度。第一次快照基于一个 2 节点 RAC 数据库GGSCI (wewin1) 7 send extract ext_act1, status Current read positions: Redo thread #: 1 Sequence #: 1266 RBA: 134567004 Redo thread #: 2 Sequence #: 1063 RBA: 260113712第二次快照2分钟后GGSCI (wewin1) 8 send extract ext_act1, status Current read positions: Redo thread #: 1 Sequence #: 1268 RBA: 176425880 Redo thread #: 2 Sequence #: 1064 RBA: 265242016归档日志文件大小arch_1_1266.arc: 300 MBarch_1_1267.arc: 200 MBarch_1_1268.arc: 800 MBarch_2_1063.arc: 334 MBarch_2_1064.arc: 1000 MB计算处理的字节数线程 1(300 MB - 134567004/1024/1024) 200 MB 176425880/1024/1024 540 MB线程 2(334 MB - 260113712/1024/1024) 265242016/1024/1024 339 MBExtract 在 2 分钟内处理了 540 MB 339 MB 879 MB约为26.4 GB/小时。进一步估算假设未处理的归档/重做日志总大小为 60 GB重做日志生成速度为 10 GB/小时处理现有日志所需时间60GB / 26.4 约等于 2小时16分钟Extract 追平延迟lag0所需时间60/(26.4-10) 约等于 3小时40分钟限制说明当 Extract 挂起或处理极慢时send extract ext, status命令可能会超时。本文示例仅适用于 Oracle 数据库。对于其他数据库如果检查点可转换为文件 RBA也可采用类似思路估算。其他方法在版本 11 中可使用活动日志跟踪功能在读取切换重做/归档日志时写入日志。可参考文档 1204284.1 中的“trace redo log switch similar as old parameter LOGSWITCHMSG”。在版本 10 中可使用参数tranlogoptions LOGSWITCHMSG。由于日志不显示当前读取的 RBA计算时应排除第一个和最后一个序列。参考资料MOS 文档 ID1356524.1