oracle9i升级oracle10g

进行oracle数据库版本升级的时候会有2种方式

1.通过dbua(database upgrade assistant)

2.exp/imp

通过dbua来升级的话由于不涉及到数据文件的改变，所以速度会比较快，但是如果dbua一旦在升级的过程中出现问题可能会导致原来的库不可用。

而通过exp/imp虽然对原来的库不会有影响，但是如果数据库比较大的话那么升级的时间将会是不可接受的（尤其对24*7）的应用来说。

 

针对这个问题,可以利用dataguard和transport tablespace功能来实现最短时间内的安全升级。

 

具体的实现方法是这样的

1.先为主库建立一个dataguard数据库(可以在线做)

2.在dataguard库上安装10g软件(可以在线做)

3.整理一些不能通过transport tablespace搞定的东西，比如sequence,synonyms,grants......

4.停止主库这边所有write的应用，提供read的服务(写入停止，提供查询)

5.强制归档主库redo log并传到dataguard恢复(写入停止，提供查询)

6.利用transport tablespace来转换数据库版本，并创建sequencee,synonyms,grants等(写入停止，提供查询)。

7.验证新环境的过程，在验证过程中如果发现有问题，则可以切换会原来的系统(写入停止，提供查询)。

8.切换应用到10g数据库（提供服务）

我们再从技术上验证一下transport tablespace可以运用在版本升级


在9i的库上创建一个test tablespace 


create tablespace test
datafile '/opt/oracle/test.dbf' size 10m
extent management local autoallocate;


创建一张表在test表空间上 


create table test1(a number) tablespace test;


insert into test1 values(1);
commit;


SQL 9i>select * from test1;


         A
----------
         1






把test表空间置为read only模式




alter tablespace test read only;


到处test tablespace的metadata


exp /'sys/sys as sysdba/'  transport_tablespace=y tablespaces=(TEST)  file=test.dmp log=test.log


传输dmp文件和数据文件（在amadeus的案例里面由于10g的库和9i的库在同一台机器上，所以避免了拷贝数据文件的时间，这也是整个方案的重点之一）到远程


scp test.dmp [email protected]:/opt/oracle/


scp /opt/oracle/test.dbf [email protected]:/opt/oracle/






在目标库上导入metadata数据


imp /'sys/sys as sysdba/' transport_tablespace=y tablespaces=(TEST) file='/opt/oracle/test.dmp' datafiles=


('/opt/oracle/test.dbf') tts_owners=test fromuser=test touser=test log=tts_i.log






查看test1表，发现数据一致




SQL 10G>select * from test1;


         A
----------
         1


把test表空间置为read write模式


alter tablespace test read write;


insert into test1 values(2);




SQL 10G>select * from test1;


         A
----------
         1
         2


一切正常，测试完毕


这个测试简单的模仿了transport tablespace升级数据库的可能性，当然在实际过程中我们要校验是否自包含表空间，是否需要创建sequence等，但是总体来说这种方案能提供最短时间内的数据库版本升级。