分区表跨数据库移动数据惨重的教训

前几天,在移动分区表的数据时经历一次惨重的教训,先分享给大家,以便大家不要犯类似错误,并研究其原因.
环境:

ADB: oracle 8.1.7.4 , table name : component,  分区: M2,M3….M12

BDB: oracle 10.2.0.1 ,table name: component,  分区: M2,M3….M12

目的: 将ADB的 COMPONENT partition m2 的数据移动到 BDB的COMPONENT partition m2内

ADB的COMPONENT PARTITION M2大小为1536M

时间: 2007/3/11 星期日 上午 11:00 ,产线下午三点备线

经验: 上次移动数据库时,500M的table 需要移动30分钟

估计: 3个小时可以完成

    因为BDB 的UNDO是系统管理的,ADB的RBS 6G,没有人使用ADB,故在ADB上建立了DB LINK 名为tonew，为了速度，停止了原来转移数据的存储过程，改用一句SQL一次性转，ＳＱＬ如下：

　　　Insert into component@ibm select * from component partition(m2)

时间：　１５：００　仍然没有完成

时间：　１６：００　仍然没有完成，ＡＤＢ的Ｍ２　partition 1536m M3 partition 3600M,此时　BDB的Ｍ２已经　1536M ,BDB的Ｍ３ 1200M

时间：　１８：００　仍然没有完成, BDB的Ｍ２　1536M , BDB的Ｍ３ 1600M

    从16:00开始，因虚拟内存耗尽，系统无法运作，监听器停止，Server上键盘，鼠标均无法操作，用toad看，用户session已经全部停止，为何M3的数据量仍在增加。这说明数据库执行的是Insert into component@tonew select * from component。连到ADB,发现执行的语句的确是Insert into component@ibm select * from component partition(m2),而BDB执行的却是INSERT INTO COMPONENT SELECT  * FROM " COMPONENT"@! "A2"   

　　为了让产线立刻work起来，决定停止insert操作，因为如果要将Ｍ３的数据insert完，估计要到１０点。

　　因键盘鼠标失效，直接按电源开关，开机后系统正常起动，只是系统需要ＵＮＤＯ。

　　以上，是我昨天遇到的一个问题，希望能够给大家一个经验，也希望大家能提供一个原因，因为我感到很疑惑。