在版本升级上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博客 ” ,链接:http://blog.itpub.net/16573/viewspace-441869/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/16573/viewspace-441869/