在版本升级上SQL Server提供了更加简单而强大的工具，帮助我们来升级数据库，如Best Practices Analyzer for Microsoft SQL Server，Upgrade Advisor，Migration Test Toolkit等等。而Oracle的版本升级，却是通过DBA的考量来决定是否可以升级；而且升级过程中是否会出现什么问题，也是由DBA在升级过程中边发现边修改，无法事先预知旧版本迁移至新版本可能会出现什么新问题。
因此每当我们需要从Oralce的早期版本升级到某个新版本的时候，都是对新版本相对旧版本改进的功能清单研究再三，而且很多时候，都是当Oracle推出10g一段日子之后，大家才考虑将原来的8.1.7升级到9i，我敢断言目前很多公司的Oracle仍然在使用9i版本，至于用Oracle 11g的公司只是很小一部分。
虽然大家有希望等Oracle某个版本稳定之后再升级的想法，但是为什么我们不马上将公司内部测试数据库先升级呢，这其中有一个很大的问题，作为一个DBA怎么能够保证新版本就没有问题，而且系统在迁移后会出现什么问题，很多DBA的上司对数据库也就一知半解，Oracle DBA又无法给出一份满意的升级报告，谁知道新版本会对旧系统造成什么影响。。。。。。
总而言之，没有最好，只有更好，所以说合适就好，合适万岁。
哎，Oracle没赶上Microsoft去做这一步，不让Oracle DBA们省心啊。
现在Oracle 9i的最终PSR版本已发布，至少说明Oracle公司认为Oracle 9i已经非常完善了，大家有钱又有升级想法的话不妨考虑一试。
Oracle补丁的安装是件非常头疼的事情，某个补丁是否需要安装？要安装的话什么时候安装？
我们可以在metalink上查看该补丁的优缺点，然后确认是否需要安装补丁；另外CPU补丁，不要被Oracle给吓住了，有些风险度不高的可以暂时不考虑，自己把握吧。
本人推荐的补丁策略：
1、查看metalink关于该补丁的详细信息以及优缺点。
2、决定是否更新补丁。
3、下载补丁，模拟一个测试数据库环境，安装补丁
4、查看是否出错，如果有错误则解决之
5、检查相关bug是否已经修正
6、检查相关缺点是否会影响系统，交付测试人员测试，可给定时间一个月。
7、在确认补丁的缺点不会影响系统之后，再等待一个月，观察Metalink或一些论坛查看该补丁是否还有其它的缺点。
8、考虑正式投放
9、备份生产环境数据库软件和数据库数据
10、。。。。。。
大家看看还有遗漏的吗？
做DBA怎么这么辛苦。(Oracle说了，11g开始大家可以online update了，靠，为啥10年前就不能像微软那样提供online update，无语。。。。。。)
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/16573/viewspace-441869/ ，如需转载，请注明出处，否则将追究法律责任。
