对于Oracle Data Guard中的Switchover一般是计划内的操作，自己其实也处理了不少的故障，也算是轻门熟路。
复杂的事情简单做，简单的事情重复做，重复的事情用心做，想必很多事情都是这个理吧。
发现很多事情虽然做了很多遍，但是每次都会有不同的体会，而这些积累下来的经验才让我们的经验更加宝贵。
一般来说Oracle的Switchover需要考虑的细节较多，大体有以下的流程。
1.在迁移之前明确目标服务器IP，发出维护公告
这个无需多说，本身就是跨部门，多部门的协调工作，说简单简单，说复杂复杂，技术层面的事情就是需要提供给各业务部门相关联的服务器信息，让他们提前准备。
2.设置zabbix的维护窗口
为了避免很多批量紧急的报警，我们需要一个明确的维护窗口，把主备库环境都纳入维护窗口，这样会避免很多不必要的报警短信和报警解释。
3.DG Broker的验证
在切换前，需要保证DG Broker一定是正常的状态，我们可以有一下几种验证方式。
把备库置于read-only状态，如果是11gADG，需要查看select open_mode from v$database一定需要时READ ONLY WITH APPLY,如果是10g版本，这个步骤尤其重要，如果切换之后，因为各种奇葩的原因，备库无法正常使用就歇菜了，备库的临时表空间，日志等问题需要提前检查好，因为这些对于备库来说都不会直接影响主从一致性，但是备库变主库就尤其重要。
查看主备库的延迟情况，这个在11g中可以通过show database verbose xxx的方式看出备库的延迟情况，而对于10g来说，这些属性还没有，我们可以查看主备库的SCN情况，甚至在主库做一个日志切换，在备库查看应用的情况。
4.停止数据库,释放连接
为了尽可能在维护的可控范围内，保证很多活跃会话的事务一致性，最好还是能够在switchover前重启一下数据库，释放数据库连接，当然很多应用有重连机制，我们可以停掉其它的监听端口，设定一个独立的端口留给Data Guard，当然这也是一把双刃剑，如果端口刚好被很多应用所用，你是没法完全控制的，可能处理不当，DG Broker都不能正常使用了，因小失大。
5.Switchover
切换是这个过程的核心，我们可以使用DG Broker来完成，这个过程本身就没有太多的技术亮点，但是最大的坎就是心灵压力了，我碰到过在Solaris下Failover网络连接超时的切换，切换时间极长，后台没有任何日志输出，这个过程只有经历了才会更懂，有些切换的时候可能检查没有做彻底，或多或少会碰到一些问题，这个时候我的建议是准备好两套方案，如果一旦DG Broker切换中出现任何问题，我们可以完全手工来接管。毕竟切换的过程就是转换数据库角色，一定要沉着冷静，当然沉着冷静这个是在不断的经历中锻炼出来的。
6.同步listener.ora,tnsnames.ora，/etc/hosts
主备库切换需要同步监听，tns,主机的信息，这些信息比较琐碎，可以提前准备好一个临时文件，到时候直接替换即可，特别注意需要保证主备库的监听端口是一致的。
7.防火墙同步
防火墙信息需要提前准备，需要提前告知相应的部门。我们在切换前就可以提前安排，把防火墙信息同步过来，需要注意网卡的名称是否一致，是否主备库有特殊的设定策略。
8.修改客户端的连接IP
有些服务器会通过服务端TNS来连接要切换的数据库，我们可以从防火墙中得到一个概要信息，哪些DB服务器中的tnsnames.ora里面包含了目标数据库，修改tnsnames.ora中的IP即可。
9.修改Database Link中的IP对应防火墙权限
比如目标数据库含有50个Database Link,可能会访问多个数据源，那么这个过程是运行时触发，在切换中是不会发现的，我们需要提前从db link对应的tns中进行过滤，查看那些服务器是否已经开启了防火墙权限，指定的端口已经开启。
10.crontab 修改
同步主备库的crontab的信息，保证主备库的这些JOB能够正常运行，有些JOB如果执行频度极高，需要考虑暂时在切换的过程中先禁用，保证在切换Release环境之后正常开启。
11.修改orabbix配置
主备库的IP发生改变，我们就需要重新配置Orabbix中的连接信息。
12.查看是否还有连接在备库存在
这个是一个持续性的过程，需要留意是否有计划外的会话依然在备库，可以使用netstat -nalp来得到一个基本的网络访问情况
13.留意观察Scheduler JOB运行正常
查看是否数据库内的Scheduler能够正常运行。
发现很多事情虽然做了很多遍，但是每次都会有不同的体会，而这些积累下来的经验才让我们的经验更加宝贵。
一般来说Oracle的Switchover需要考虑的细节较多，大体有以下的流程。
1.在迁移之前明确目标服务器IP，发出维护公告
这个无需多说，本身就是跨部门，多部门的协调工作，说简单简单，说复杂复杂，技术层面的事情就是需要提供给各业务部门相关联的服务器信息，让他们提前准备。
2.设置zabbix的维护窗口
为了避免很多批量紧急的报警，我们需要一个明确的维护窗口，把主备库环境都纳入维护窗口，这样会避免很多不必要的报警短信和报警解释。
3.DG Broker的验证
在切换前，需要保证DG Broker一定是正常的状态，我们可以有一下几种验证方式。
把备库置于read-only状态，如果是11gADG，需要查看select open_mode from v$database一定需要时READ ONLY WITH APPLY,如果是10g版本，这个步骤尤其重要，如果切换之后，因为各种奇葩的原因，备库无法正常使用就歇菜了，备库的临时表空间，日志等问题需要提前检查好，因为这些对于备库来说都不会直接影响主从一致性，但是备库变主库就尤其重要。
查看主备库的延迟情况，这个在11g中可以通过show database verbose xxx的方式看出备库的延迟情况，而对于10g来说，这些属性还没有，我们可以查看主备库的SCN情况，甚至在主库做一个日志切换，在备库查看应用的情况。
4.停止数据库,释放连接
为了尽可能在维护的可控范围内，保证很多活跃会话的事务一致性，最好还是能够在switchover前重启一下数据库，释放数据库连接，当然很多应用有重连机制，我们可以停掉其它的监听端口，设定一个独立的端口留给Data Guard，当然这也是一把双刃剑，如果端口刚好被很多应用所用，你是没法完全控制的，可能处理不当，DG Broker都不能正常使用了，因小失大。
5.Switchover
切换是这个过程的核心，我们可以使用DG Broker来完成，这个过程本身就没有太多的技术亮点，但是最大的坎就是心灵压力了，我碰到过在Solaris下Failover网络连接超时的切换，切换时间极长，后台没有任何日志输出，这个过程只有经历了才会更懂，有些切换的时候可能检查没有做彻底，或多或少会碰到一些问题，这个时候我的建议是准备好两套方案，如果一旦DG Broker切换中出现任何问题，我们可以完全手工来接管。毕竟切换的过程就是转换数据库角色，一定要沉着冷静，当然沉着冷静这个是在不断的经历中锻炼出来的。
6.同步listener.ora,tnsnames.ora，/etc/hosts
主备库切换需要同步监听，tns,主机的信息，这些信息比较琐碎，可以提前准备好一个临时文件，到时候直接替换即可，特别注意需要保证主备库的监听端口是一致的。
7.防火墙同步
防火墙信息需要提前准备，需要提前告知相应的部门。我们在切换前就可以提前安排，把防火墙信息同步过来，需要注意网卡的名称是否一致，是否主备库有特殊的设定策略。
8.修改客户端的连接IP
有些服务器会通过服务端TNS来连接要切换的数据库，我们可以从防火墙中得到一个概要信息，哪些DB服务器中的tnsnames.ora里面包含了目标数据库，修改tnsnames.ora中的IP即可。
9.修改Database Link中的IP对应防火墙权限
比如目标数据库含有50个Database Link,可能会访问多个数据源，那么这个过程是运行时触发，在切换中是不会发现的，我们需要提前从db link对应的tns中进行过滤，查看那些服务器是否已经开启了防火墙权限，指定的端口已经开启。
10.crontab 修改
同步主备库的crontab的信息，保证主备库的这些JOB能够正常运行，有些JOB如果执行频度极高，需要考虑暂时在切换的过程中先禁用，保证在切换Release环境之后正常开启。
11.修改orabbix配置
主备库的IP发生改变，我们就需要重新配置Orabbix中的连接信息。
12.查看是否还有连接在备库存在
这个是一个持续性的过程，需要留意是否有计划外的会话依然在备库，可以使用netstat -nalp来得到一个基本的网络访问情况
13.留意观察Scheduler JOB运行正常
查看是否数据库内的Scheduler能够正常运行。
