oracle 9i exp導(dǎo)出的數(shù)據(jù)imp導(dǎo)入10g時(shí)大概70%多時(shí)停止了，請(qǐng)問(wèn)大家要怎么處理？

unixli

oracle 9i 企業(yè)版 (9.2.0.1.0）安裝在WINDOWS 2003 32位系統(tǒng)上。
在9I客戶(hù)端系統(tǒng)上用 exp user1/password file=user1.dmp log=user1.log 命令導(dǎo)出user1用戶(hù)數(shù)據(jù)。導(dǎo)出文件2.8G多，原表空間4.7G多。

目標(biāo)系統(tǒng)是AIX 6100-5，新安裝了oracle 10g (10.2.0.4，由10.2.0.1升級(jí)），系統(tǒng)和數(shù)據(jù)庫(kù)都是64位。同一臺(tái)機(jī)器上創(chuàng)建了4個(gè)實(shí)例，每個(gè)實(shí)例對(duì)應(yīng)一個(gè)應(yīng)用數(shù)據(jù)庫(kù)。
在10g客戶(hù)端系統(tǒng)OEMC上，新建了user1用戶(hù)和對(duì)應(yīng)的表空間(user1table，大小為10G)，增加DBA角色（原用戶(hù)也有）。
然后用
imp user1/password file=user1.dmp log=user1imp.log full=y
imp system/password file=user1.dmp log=user1imp.log fromuser=user1
imp user1/password file=user1.dmp log=user1imp.log buffer=2048000000 full=y
imp user1/password file=user1.dmp log=user1imp.log fromuser=user1 touser=user1
等命令參數(shù)導(dǎo)入，都是到了表空間大小被占3.5G或3.7G多的時(shí)候?qū)�入進(jìn)度就不動(dòng)了，幾次都是停在其它兩個(gè)表那。
停止前所有導(dǎo)入顯示正常導(dǎo)入，不動(dòng)也就沒(méi)有報(bào)錯(cuò)，強(qiáng)行中止導(dǎo)入進(jìn)程后，OEMC不可訪問(wèn)。
每次重新導(dǎo)入前，都把數(shù)據(jù)庫(kù)用備份的配置文件等恢復(fù)成導(dǎo)入前狀態(tài)。

后面先把卡的兩個(gè)表導(dǎo)入，成功；再導(dǎo)入整個(gè)數(shù)據(jù)文件，但都會(huì)在不同進(jìn)度下又停止不動(dòng)了。

導(dǎo)入也直接在AIX下試過(guò)，也一的結(jié)果。

9I和10G使用的字符集都是ZHS16GBK 和 AL16UTF16 NCHAR 。

但同一個(gè)數(shù)據(jù)文件，導(dǎo)入9I里又是正常的。

請(qǐng)大家?guī)兔Ψ治鲆幌拢�找找原因吧，多謝了！

unixli

大家有什么想法和建議都可以提提的，說(shuō)不定誰(shuí)說(shuō)了一句話就幫到我了

duolanshizhe

請(qǐng)注意使用低版本原則  在imp/exp時(shí)

既然是9i exp出來(lái)的，請(qǐng)用9i的imp  導(dǎo)入到10g環(huán)境中......

unixli

用9i的imp呀，這個(gè)我倒沒(méi)試
用10g的EXP 導(dǎo)出9I的倒試了，不行的。

unixli

用9I 的IMP導(dǎo)入也是一樣的問(wèn)題，到了其中一個(gè)表里還是停止不動(dòng)了，已經(jīng)過(guò)了快10個(gè)鐘了。
無(wú)解！

難道是我是安裝了10.2.0.4補(bǔ)丁的問(wèn)題？是我安裝錯(cuò)誤還是補(bǔ)丁包有問(wèn)題？

我安裝過(guò)程是這樣的：
1、檢查AIX環(huán)境包，修改系統(tǒng)參數(shù)，建ORACLE用戶(hù)并配環(huán)境。
2、安裝10.2.0.1,安裝時(shí)不建庫(kù)。因10.2.0.1在AIX 6100-5上沒(méi)有經(jīng)過(guò)認(rèn)證，所以安裝時(shí)會(huì)有錯(cuò)誤提示，忽略。
3、直接再安裝10.2.0.4補(bǔ)丁，這次系統(tǒng)版本沒(méi)錯(cuò)誤提示了。
4、DBCA建庫(kù)。
5、導(dǎo)入數(shù)據(jù)。

unixli

我昨晚在虛擬機(jī)2003上也安裝了ORACLE 10.2.0.4，直接在ORACLE 10G服務(wù)器上導(dǎo)入數(shù)據(jù)也是停止，不過(guò)這次是在另外一個(gè)表時(shí)停止。

duolanshizhe

如果是這樣的話  需要查看alert日志  看看數(shù)據(jù)庫(kù)到底為啥

是不是歸檔滿(mǎn)了  導(dǎo)致而成  

貼出日志

unixli

************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ARCH: Archival stopped, error occurred. Will continue retrying
Thu Oct 28 11:34:38 2010
ORACLE Instance pamora - Archival Error
Thu Oct 28 11:34:38 2010
ORA-16038: log 1 sequence# 199 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: '/data/app/oradata/pamora/redo01.log'
Thu Oct 28 11:34:38 2010
Errors in file /data/app/admin/pamora/bdump/pamora_arc0_10092886.trc:
ORA-16038: log 1 sequence# 199 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: '/data/app/oradata/pamora/redo01.log'
Thu Oct 28 11:35:38 2010
ARCH: Archival stopped, error occurred. Will continue retrying
Thu Oct 28 11:35:38 2010
ORACLE Instance pamora - Archival Error
Thu Oct 28 11:35:38 2010
ORA-16014: log 1 sequence# 199 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/data/app/oradata/pamora/redo01.log'
Thu Oct 28 11:35:38 2010
Errors in file /data/app/admin/pamora/bdump/pamora_arc1_6488466.trc:
ORA-16014: log 1 sequence# 199 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/data/app/oradata/pamora/redo01.log'
Thu Oct 28 11:40:38 2010
Errors in file /data/app/admin/pamora/bdump/pamora_arc0_10092886.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 8589934592 bytes is 100.00% used, and has 0 remaining bytes available.
Thu Oct 28 11:40:38 2010

LOG里基本都是同樣的內(nèi)容，是滿(mǎn)了。
db_recovery_file_dest_size 我建庫(kù)的時(shí)候只設(shè)了8G，又開(kāi)了自動(dòng)歸檔，但我記得大小可以自動(dòng)增加的吧？！
存儲(chǔ)大小是200G的，數(shù)據(jù)文件快5個(gè)G，那開(kāi)多大的db_recovery_file_dest_size合適？

unixli

閃回恢復(fù)區(qū)(Flash recovery area) 設(shè)得太小了

拿錢(qián)發(fā)帖死全家

設(shè)置一下即可