突然发现最近忙里偷闲也回答了一些微信好友的问题。有的在公众号提问，有的私信给我。简单整理了一下。
问题1：
之前使用expdp和impdp导出导入数据库statistics时遇到一个bug，无法impdp导入，后来只能不导入statistics，待导入数据后自己收集对象统计信息，但问题是收集的统计信息和原来有些差异，特别是直方图信息有差异，导致sql执行计划有变化，不知到杨总有没有遇到过？又该怎么处理呢？
答：
报错是因为跨版本了吧，有的时候有这种情况，我们生产是不用直方图的。容易有偏差。
尽管他没有提供截图，但是我想起之前有朋友提过一个类似的问题，解决方法也是类似的。
错误原因应该是10g的数据导入11g同时导入统计信息，看错误应该是 impdp的时候的统计信息的影响。加EXCLUDE=STATISTICS试试。参考mos文档 ID 878626.1有更详细的解释。
第二个问题源自我帮助一个网友解决的一个问题，可以参考 远程协助解决重建索引的危机问题 http://blog.itpub.net/23718752/viewspace-2088227/
问题2：
跟我之前的系统现象一样一样的，都是大表重建索引，导致执行计划走全表，io和cpu秒升，系统无响应。生产系统的操作一定要谨慎啊！一个小的疏忽可能造成几个小时系统无响应！ 我还有个问题，为什么文中说在读比较多的时候online创建索引效率提升不大呢？
答：
online这样的操作本身是ddl，看起来高可用，也是在后台维护数据和数据字典信息，对查询本身没有什么提升和影响，而且online有个比较麻烦的地方就是，一旦后台维护，你就不能随便终止了。在10g里面可能得重启库，11g里面有个包可以临时解决。
我所说的读比较多，online创建索引主要是基于当时的环境，当时的会话都是查询语句在运行，online操作还是有一定的风险，因为当时系统的负载极高，担心会有宕机的风险。
引用一个微信朋友的留言：非常典型的一个案例，有时经常会有这种生产系统重建索引或是新增一个有默认值但没有NOT NULL约束的操作，不清楚原理，就不清楚这种操作带来的风险，两者相辅相成。
问题3：
请问如何判断建索引的时间呢
答：如果执行时间很长，一种比较上手的方法就是写个脚本，执行几秒钟在这个过程中抓取v$session中的sql_id，然后在cursor里面查看对应的执行计划
创建索引的语句不难，但是如果评估不出一个基本的时间点，这个过程就会很没底。
问题4：、
如果导出public的db link,密码忘了
答：
一种快捷的办法就是，直接全库导出结果 full=y,rows=n,用strings命令可以看到dump里的内容，搜索DATABASE LINK就看到所有的了，话说db link里面的加密串真是够长的。
问题5：
抛开我的低端存储，就io性能问题，杨老师给点可行的思路，我先来一个，优化物理读sql，
答：
优化物理读是一方面，比如IO方面做一个基本的平衡，数据分区，分区表数据做IO分离。启用大页，减少碎片级的IO造成swap过多争用。
如果深入sql层面，还是执行效率优良的sql语句。
问题6：
你好，有个问题哈，小白点，我这有几套库的主机要升级，可能对库的影响是什么？或者还需要同时升级哪些组件？我现在只觉得一起升级asmlib就成，这样理解对么？另外如果安装了新的asmlib旧的也就不能回滚了，对吧？一般情况下，是不是很少对db的主机进行patch操作？
答：
操作系统升级，有些数据库参数也有影响，比如filesystem_option, 说实话asmlib我生产还没用过，是和内核版本绑定的，可以借这个机会弄成udev方式，这种升级可以考虑switchover，替换ip,然后原来的主就成备了，如果库不大，直接初始化，搭建
群友反应这样做工程太大了，他们的要求是从安全角度出发，才要patch的，并不是db角度，一般db都在内网，所以被攻击的可能很小。我是否可从这个角度顺服他们不升级？一般情况下，是不是db 主机也很少做patch的动作？
答：
很少有主动在线上打patch的，风险不可控