最近积累了几个问题，我就凑在一起做一个统一的答复，微信后台的留言回复超过24小时就无法回复了，有时候看到的时候已经过了时间点了，实在抱歉。
有时候有些朋友是通过qq或者微信来问我问题，有时候运气好能够马上定位，感觉非常侥幸。
今天回答5个小问题。
第一个问题是在昨天晚上准备睡觉前，一个微信好友的提问。说自己的DG备库上启动了两个一模一样的实例，感觉比较奇怪。
当时的截图如下。
一看这个问题，真是运气好，马上就知道原委了，我让他把当前环境变量的ORACLE_HOME提供给我。
然后找到两个PMON的进程的进程号，发给我。
稍作等待，就收到了相应的进程号为5261 5550，其实不一定选用PMON,SMON,LGWR这些进程都可以。
我提供了两个命令，让他把结果发给我。
cat /proc/5261/environ|xargs -0 -n1 |grep ORACLE_HOME
cat /proc/5550/environ|xargs -0 -n1 |grep ORACLE_HOME
收到的结果如下，
仔细看ORACLE_HOME的值就会发现唯一的差别就是末尾的斜杠。
至于原因也非常简单，在Unix,Linux系统中，SID和ORACLE_HOME在一起哈希后会得到一个唯一的值作为SGA的key。当oracle实例启动时，在操作系统上的fork进程会根据Oracle_SID来创建相关后台进程。
在这个例子里面，Oracle认为ORACLE_HOME是不同的，所以才可以启动到nomount状态，但是肯定启动不到mount状态，因为控制文件已经被占用了。
第二个问题是微信中的留言：
有个adg备库问题困扰我很久，正好请教一下，adg备库处于只读打开模式应用归档日志，我们在上面执行包含dblink的复杂查询，查询存在多个本地表和远程表关联，会报一个这是只读数据库的错，这好像是和通过dblink查远程表会启动一个事务有关，不知道你有没有遇到这样的问题(O_O)？
这个也是运气好，我还真碰到过。而且碰到的例子比他还特殊一些。
使用db link在备库查询，可能会触发这个问题，可以参见MOS 参考链接如下：
Dblink
on Physical standby - ORA-16000 (Doc ID 1296288.1)
ORA-16000
With A Semantic Query On A Read-only Database (Doc ID 1928638.1)
而我碰到的这个问题略微不同，是因为失效的对象导致的这类问题，可以参考我的博客。备库批量查询失败的原因分析 http://blog.itpub.net/23718752/viewspace-2052930/
第三个问题是微信中的留言
主键和唯一键索引必须是全局索引吧？如果原表存在怎么处理呢？去掉吗？还是做分区操作的时候update global indexes呢？另外分区是手动增加，还是写job自动增加呢？
几个字段组成唯一约束，请问约束的顺序和唯一索引的顺序可以不一样吗
我的回答：其实这个我也写过一篇文章做过一些解释，其实可以认为是独立的。不一定啊，默认是全局，不能这么干，大分区表一般都是先建约束，然后绑定本地索引。
可以参考我之前写的一篇 很多人比较纠结的约束和索引的关系 http://blog.itpub.net/23718752/viewspace-1975057/
第四个问题来自PUB的私信：
目前我在做一个数据迁移项目。由源系统历史数据需要全部迁移至目标系统，而两套系统的表结构是完全不同的。
目前我们即将进入数据对照阶段。麻烦我想问一下，这个阶段您有什么好的建议么。还有数据对照时候有什么模版或者好的工具能让数据对照工作有效进行。。非常渴望您的指导！另外，我们这次数据迁移的表中。有十几张千万条以上的大表，有些达到5000万条。麻烦问一下这些超大表在设计迁移脚本的时候一些需要注意的设计策略。以及是否可有工具辅助呢
这位朋友现在碰到的数据迁移应该算是异构增量数据迁移，应该是迁移里面比较折腾的一种。
我的回答如下：你说的这种方式的迁移物理迁移，普通的逻辑迁移都不可用，数据对照阶段你说的是比较表结构信息是吧，这种迁移应该是逻辑增量的方式吧，这种方式我的感觉还是推荐用外部表来迁移，优点非常明显就是数据可插拨，而且可以灵活的指定列映射关系，当然需要提前呢准备好映射关系的部分，我觉得对增量数据迁移来说，这个方案比较可行的是，可以在迁移前做到数据的比对，对于约束冲突，主键冲突的数据就可以提前预警。
第五个问题是今天的社群文章。原文可以参考 http://dbaplus.cn/news-10-340-1.html
有个群友留言提问：运维注重细节，如何提升价值和跟客户交流增加运维服务价值？
我觉得这个问题特别难得，其实这些细节有些看似不经意，不起眼，对于运维服务的价值来说，可以辩证的来看，首先碰到的一个看似简单的问题，正因为简单，很可能是一个通用的错误，彻底解决了一个问题，其它环境都有的同样问题都会引刃而解。很多历史问题，遗留问题，或者难题，其实拆分来看，都是因为这样那样的原因，归根接底都是很细小的问题导致的，解决了这类问题，本身就会解决已经存在的问题，规避即将发生的问题。这些问题还是在一定程度上坦诚和客户去沟通去互相了解，理解，这样我们解决的问题的意义就在于此，而不是有些时候藏着捂着。最后就是对个人的提升，对自己全方位都是一个锻炼，过程虽然痛苦，但是回想起来还是值得的。