花了大概一周时间完成了一套11i系统(到12.1.1)的升级，之所以耗费如此多时间，简单归纳了一下大致有以下原因： 历史遗留的配置问题（比如用中文做关键词），此类问题导致数据转换错误。 客户化（索引，物化视图等）导致升级错误。 测试机性能差，耗时颇巨。期间多次由于内存的原因，导致java程序出错。 很多R12本身的升级过程中的bug需要处理。 部分业务数据升级时出错，可能是旧数据完整性被破坏所致。 一些前期工作跳过没错，这本来可以缩短升级过程的一部分排错时间。 其他的一些可在升级之前就预先解决的问题。 整体上说，机器的性能问题很关键，有些步骤运行动辄数个小时，有些是升级程序有优化余地而事先没有发现，这些一般都在metalink上有了解决办法。对于升级，很多人第一反应就是克隆环境升级，然后导入最新数据并进行主备切换，其实这种方案对于多数企业而言很难，因为升级过程中会修改大量的表结构，甚至很多应用级别的调整，我很怀疑有哪家公司能够做到对Oracle EBS的数据结构了解的如此洞彻明晰，至少国内没有。这是我第一次对11i进行升级，积累了一些经验，在此分享。 升级前的准备 升级前的准备包括三方面，一个是应用本身的准备工作，这个在升级手册里已经详细说明；另一个就是对服务器性能做一个充分的评估，确保整个升级过程不会跳到deadline之外；还有一个，就是将所有能提前做的工作都做好，比如invalid objects，韩语分词补丁，OLAP升级等等，这些在数据库升级阶段不是必须的，但是EBS升级时却是无法直接忽略的步骤，此外可靠的网络连接也很重要，patching过程中断线后虽然可以继续，但是光启动就要花不少时间。 升级过程中的注意事项 这里依旧按照升级步骤来进行说明。 Disable AOL Audit Trail (conditional) 关闭所有审计功能，包括标准功能提供的，以及客户自行在DB级别上添加的。 Shut down application tier listeners and concurrent managers (required) Migrate database to at least Oracle10g Release 2 (conditional) 这一步之前已经做了，考虑到停机时间，分两步走是比较合适的方案。 Update init.ora with upgrade parameters (required) 同上，升级数据库时已经基本做好了。 Disable custom triggers, constraints, and indexes (conditional) 注意：最好将所有直接关联到标准表的客户化索引和Materialized [...]
