今天在琢磨几件事情，也是和工作相关。
数据灾难切换的几点认识：
在unix中可能会碰到在处理网络问题时，超时时间会远远高于linux的情况，这个时候如果尝试做failover是非常消耗时间的，而且日志没有任何输出，看不到进展，相比于linux的处理，我感觉要更简洁一些。
鉴于unix中的处理方式，我还是建议直接使用命令行来做failover,使用下面两个命令即可。
alter database recover managed standby database finish force;
alter database commit to switchover to primary;
其实也是switchover的其中一个环节。

在dg broker的配置中，如果出现了潜在的网络问题，dg broker的配置会一直卡在那里，当然时间非常宝贵，我们不能干等，也不能直接kill dmon进程，我们可设置dg_broker_start为false,然后在主备删除原有的配置，这样下次dmon启动校验元数据信息的时候就会重新生成。同步的时候也会有主备的几次通信，会逐步来同步dr的配置文件。

数据库切换之后的一个重要问题就是db link，如果处理不当，没有修改ip，或者防火墙权限没有开通完全，就会出现db time成百倍的提升，从这个也可以反应出系统中的依赖还是比较多，真有种蜘蛛网，盘丝洞的感觉。

备库重新加入dg环境
如果有一主多备的环境，如果主库failover到备库1，那么备库2基本都是需要重新搭建，这个时候其实感备库2还是挺冤的，没有什么特别需要注意的东西，就需要重新搭建，而如果搭建的数据库数据量比较大，那这种工作就非常耗人，而如果跨idc机房的网络不够好，那么瓶颈都会在网络传输上。所以重新搭建备库是一件挺痛苦的事情，当然有了闪回日志，还是能够带来一些转机，不过貌似目前的备库开启闪回的确实要少一些，如果把其中的一些关键信息抓出来，能够形成原理性的东西，避免这种重复的搭建工作，还是很有含量的一件事情。

跨平台的数据迁移
如果考虑做跨平台的数据迁移，目前想到了几个解决方案。
一种就是选择性的TTS,或者XTTS，当然难度会逐渐加大，对于TTS的考虑还是比较轻便，当然对于服务器之间的网络要求还是比较高。
如果表数目比较少，使用物化视图的prebuilt也是一个不错的选择，同步完成之后脱壳，就会蜕变成我们需要的表，这种方式有一些限定，当然用意也还是增量刷新。
使用逻辑的数据导入导出，exp/imp或者datapump，当然这种方式是能够想到的一种方式，完全可以跨平台，跨版本，不过速度也比较牵强。
我自己也写了外部表的方案，目前的实践测试效果是比datapump好，而且全面，不过表的数目太多，维护也确实有一些难度，一两百张表左右的大数据迁移还是合适。
还有就是全面的ogg,目前来说，ogg支持的场景确实比较多，异构，跨平台都不是问题，而且对于网络带宽要求不高。

db link的探针
如果数据库的环境中存在大量的db link，而且我们也不知道哪些db link可能是被废弃的，还是在使用的，哪些tns配置是否依然有效等，如果环境中的依赖太多，人工来分析还是很有难度，而且也没什么技术含量，所以计划使用脚本来分析，对于db link的使用还是不要太过于频繁，对于DBA来说，能够分析出数据流的情况，也能够给出更好的建议。