第一天晚上就卡在这里，经过1个小时之后，凌晨4点，觉得进行回退，以免影响应用。
昨晚继续进行升级操作，最开始怀疑或许pfile中内存相关参数设置太小了，跑之前我sga和pga分别调整到8G,3G；
另外通过查询mos发现运行cataupgrd.sql在xdb组件更新慢的情况很可能是bug 10368698, 于是运行脚本之前我也
将该patch打上，不过最后发现仍然效果一样。
通过查看alert发现仍然花了2.5小时左右，而且仍然运行到上面的insert语句时，停止不动了，过了30分钟，客户
建议取消，放弃该方案。
迫于无奈之下，通过top可以看到目前基本上消耗集中在一个cpu上，而且消耗了99%，但是不是user，而且sys消耗，
这有些怪异。
突发奇想，想看看这个session进程目前是什么情况，于是使用oradebug对该进行操作了下，过了不到10s，居然奇迹
出现insert执行ok了，然后随后差不多30分钟完成了cataupgrd.sql脚本的运行，检查日志也没有发现任何错误。
怪事2：
做完升级以及TDE加密，应用测试也ok以后，将11gR2 oracle home进行tar包传到备机，安装相关的os patch以后，
进行tar xvf解压，然后relink all，发现relink.log有错误，运行sqlplus报错。
看错误是找不到一些lib文件，进行对比，发现tar的包少文件，接着重新tar了一次，传到备机上解压后分布对比
主和备上的product目录(oracle home), 发现居然文件总数不一样，怪了。而且更奇怪的是，我第一次的tar包，
由于原oracle base目录空间不足，只能在临时目录解压然后mv(cp)过去，发现mv（cp）过去以后的product和以前
的product文件总数也不相同。
最后无奈之下，xxx公司的人用NBU直接备份主机上的ORACLE_HOME到备机上，然后就ok了
作者 www.killdb.com