10M向小伙伴们咨询一个问题:11g搭建同实例名的dg，有部署过吗？
主库修改参数，fal_client，fal_server，db_unique_name，以及listener.ora，tnsnames.ora部分很容易混淆，网上看了下，貌似同实例不能active duplicate，只能用基于备份的duplicate。
1）第一个问题你的service_name可以查询数据库视图进行判断，根据v$session，service_name 看看应用使用的service_name;
2) 业务是否使用实例或者服务名绑定的问题，这个可以通过非技术手段，应用测试实现，不要所有的东西通过技术去挖掘，这个让应用连接dg进行测试就行了，DG又不是禁止业务连接，DG只是禁止写数据！ 让应用改下IP,服务名连接一下DG连接正常就出结果了！ 为什么费半天劲什么名字和主库一样，给自己带来运维的风险。
3)应用测试出结果在根据结果进行决策，是否需要创建一个和主库目前一样的service服务，scan ip，vip是否需要调整到和主库切换前一样的，一般最省事是业务调整。 前次是我们service配置和主库一样，我们改下scan ip。 这个都是可以提前进行测试
评论
有用 1
没测试过，但是原则上是没问题才对，但是什么名称都一样有个最大的风险就是你的tns指向的ip容易搞混。 出错就是灾难性的的。 不建议，但是原则上dg 只需要db_unique_name不一样，其它名字一样没关系才对。
评论 有用 0jdbc连接方式1- SID（即instance_name）2-service_names。
这个service_names是环境变量export ORACLE_SID的值生成的吗？
评论 有用 01、第一个问题：“11g搭建同实例名的dg，有部署过吗？”
adg主备库实例名可以一样，识别主备库角色主要在于db_unique_name。同步使用的是tnsname，到时候同步的时候使用可以区分主备库的tnsname就可以了。这个不必纠结。
2、第二个问题：“我这边使用dg迁移，切换备库为主库后，担心instance_name或者service_names跟代码层做了绑定，影响系统的正常使用。这种情况存在吗”
这个问题，其实跟实例名和主库一样不一样关系不大，可以确认下如果业务连接service_name，备库给添加一个的服务就行了，参考：
srvctl add service -d XXXXXXDB -s ordXX -r XXXXXXDB1 -a XXXXXXDB2 -P basic -e select -m basic -z 180 -w 5复制
评论 有用 1墨值悬赏