oracle dataguard主库不能用时，如何自动切换到备库

zergduan · 发表于 2015-7-23 12:05

本帖最后由 zergduan 于 2015-7-23 12:05 编辑

kuaileshizhe200 发表于 2015-7-23 11:25
说句实话，我怎么发现oracle提供的dg怎么有点像鸡肋，不怎么好用，弃之也有点可惜。

在虚拟化成熟出现之前，我反而觉得dg是容灾最好的选择

kuaileshizhe200 · 发表于 2015-7-23 16:53

zergduan 发表于 2015-7-23 12:05
在虚拟化成熟出现之前，我反而觉得dg是容灾最好的选择

备库切换为主库，我的提示15分钟，你经历的需要大概多长时间

zergduan · 发表于 2015-7-23 17:44

switchover？这决定于apply lag

Yong Huang · 发表于 2015-7-23 22:31

> 我找到了：）
> Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)

Thanks. That's indeed what you said.

To kuaileshizhe200:

As I said, we don't do automatic switchover/failover. We think that's a very high risk operation. There's so much coordination between various groups in such a disaster incident. So my scripts only do monitoring. If you need automatic failover, search the Web. There must be scripts already written by somebody.

kuaileshizhe200 · 发表于 2015-7-24 10:47

Yong Huang 发表于 2015-7-23 22:31
> 我找到了：）
> Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)

我个人认为，自动的角色切换也有一定的风险，不过暂时没有想到更好的方案。请问，想要实现两个数据库数据同步，而在主库故障时，另一个库也能让应用程序正常访问，你那边有什么好的方案？

kuaileshizhe200 · 发表于 2015-7-24 10:51

zergduan 发表于 2015-7-23 17:44
switchover？这决定于apply lag

你说的虚拟化技术，好像比较高大上，也不怎么了解，不知如何实现类似dg的功能

Yong Huang · 发表于 2015-7-25 00:15

> 在主库故障时，另一个库也能让应用程序正常访问，你那边有什么好的方案？

If the primary database is completely unusable (we've never had that disaster), many teams will work together and we'll bring up (which probably means failover i.e. activate) the standby. Since our primary is RAC, we always have at least one of the nodes available to the users. If you don't use RAC and your applications are fairly easy to change, you can consider automatic failover/switchover. But manual failover/switchover is not that hard anyway. Being automatic only saves you a little time. To us, it's not worth it. We DBAs are equiped with blackberry smart phones which have the SSH client that can connect to the servers. Even if we travel to the other side of the earth, we can login the database servers. So, saving a little response time is not a high priority and it comes with high risk.