當我們回顧Oracle產品工具發展歷程，不能不承認Exp/Imp的成功。從早期的版本到現在11g，Exp/Imp都是開發人員最常使用、也是最簡單使用的資料庫邏輯備份工具。

但是隨著Oracle產品的不斷髮展和現實環境中資料海量化，Exp/Imp已經不能滿足實際需要了。Oracle在10g版本中正式推出了資料泵（Data Pump），也就是Expdp/Impdp產品。在很多方面，Data Pump解決或者緩解了Exp/Imp的一些缺陷。

1、版本陷阱

經常使用Exp/Imp的朋友可能都有過這樣的經歷：將資料匯出到本地機器上，再匯入到一臺新伺服器上的時候，經常會報版本錯誤。不同的資料庫伺服器版本、不同的客戶端版本都會影響到我們匯出資料dump檔案，影響我們匯入操作的成功。

這樣情況的本質原因有兩個：一個是Exp/Imp是一個客戶端工具，工具程式是駐留在客戶端上的。不同版本的客戶端必然帶來不同的Exp/Imp操作行為，寫入的Dump檔案也必然有一定差異。這就考驗客戶端程式的相容性。

另一個方面的原因是資料庫伺服器的版本相容性。每一個版本中，Oracle推出的新特性和屬性，我們很難要求低版本伺服器來相容支援。Oracle可以做到向後相容，但是不能做到“預知未來”。

所以，在Exp/Imp的使用過程中，我們經常會討論的問題有兩個，一個是字符集的匹配，另一個就是版本匯出策略。

在Data Pump的使用過程中，也會有版本差異的問題。不過，Data Pump版本的架構特點決定了版本差異會得到一定程度的解決。

與Exp/Imp工具不同的是，Data Pump是一個服務端工具，只執行在資料庫伺服器端。這就讓Data Pump不受到客戶端版本的影響。同時，Oracle考慮到版本差異的影響，也給Data Pump進行了很多額外的配置。其中，version引數就是可以解決問題的方案。

2、實驗環境介紹

Data Pump從10g開始推出，所以最大版本間的差異存在於Oracle 10g與11g之間。筆者選擇兩個環境進行測試。

10g環境是Oracle Windows版本，建立Directory物件。

SQL> select * from v$version;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE 10.2.0.1.0 Production

TNS for 32-bit Windows: Version 10.2.0.1.0 - Production

NLSRTL Version 10.2.0.1.0 – Production

SQL> create directory verdmp as 'D:\verdmp';

Directory created

11g環境採用Linux版本。

SQL> select * from v$version;

BANNER

----------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE 11.2.0.1.0 Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 – Production

--建立Directory物件

[root@oracle11g /]# cd /verdmp/

[root@oracle11g verdmp]# pwd

/verdmp

SQL> create directory verdmp as '/verdmp';

Directory created.

3、從10g到11g

首先我們測試從10g到11g的情況。如果我們從10g中匯出Dump檔案，匯入到11g上，有沒有什麼問題呢？

我們先成10g上匯出dmp檔案。

C:\Documents and Settings\Administrator>expdp \"/ as sysdba\" directory=verdmp dumpfile=scottdmp.dmp schemas=scott

Export: Release 10.2.0.1.0 - Production on 星期六, 24 11月, 2012 16:08:43

連線到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

啟動 "SYS"."SYS_EXPORT_SCHEMA_01": "/******** AS SYSDBA" directory=verdmp dumpf

ile=scottdmp.dmp schemas=scott

正在使用 BLOCKS 方法進行估計...

（篇幅原因，有省略……）

. . 匯出了 "SCOTT"."BONUS" 0 KB 0 行

已成功載入/解除安裝了主表 "SYS"."SYS_EXPORT_SCHEMA_01"

******************************************************************************

SYS.SYS_EXPORT_SCHEMA_01 的轉儲檔案集為:

D:\VERDMP\SCOTTDMP.DMP

作業 "SYS"."SYS_EXPORT_SCHEMA_01" 已於 16:20:03 成功完成

目錄中存在匯出的檔案。

D:\verdmp 的目錄

2012-11-24 16:08

.

2012-11-24 16:08

..

2012-11-24 16:20 2,360 export.log

2012-11-24 16:20 69,062,656 SCOTTDMP.DMP

2 個檔案 69,065,016 位元組

2 個目錄 36,759,314,432 可用位元組

匯出成功，使用ftp傳導到Linux 11g環境。

[root@oracle11g verdmp]# ls -l

total 67520

-rw-r--r-- 1 root root 2360 Nov 24 08:14 export.log

-rw-r--r-- 1 root root 69062656 Nov 24 08:14 SCOTTDMP.DMP

[oracle@oracle11g ~]$ impdp userid=\'/ as sysdba\' directory=verdmp dumpfile=SCOTTDMP.DMP remap_schema=scott:test

Import: Release 11.2.0.1.0 - Production on Sat Nov 24 08:17:15 2012

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded

Starting "SYS"."SYS_IMPORT_FULL_01": userid="/******** AS SYSDBA" directory=verdmp dumpfile=SCOTTDMP.DMP remap_schema=scott:test

（篇幅原因，有省略……）

Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

Job "SYS"."SYS_IMPORT_FULL_01" completed with 2 error(s) at 08:17:39

匯入成功。我們得到了結論：在使用Data Pump時候，從低版本匯出的dmp檔案可以匯入到高版本的資料庫伺服器上。這個過程，不需要額外的配置。

4、11g到10g

下面嘗試將從11g轉移到10g版本。

[oracle@oracle11g ~]$ expdp userid=\'/ as sysdba\' directory=verdmp dumpfile=testdmp.dmp schemas=test reuse_dumpfiles=y

Export: Release 11.2.0.1.0 - Production on Sat Nov 24 08:24:01 2012

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Starting "SYS"."SYS_EXPORT_SCHEMA_01": userid="/******** AS SYSDBA" directory=verdmp dumpfile=testdmp.dmp schemas=test reuse_dumpfiles=y

Estimate in progress using BLOCKS method...

Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 85.25 MB

（篇幅原因，有省略……）

Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:

/verdmp/testdmp.dmp

Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at 08:24:43

匯出檔案成功，將dmp檔案傳輸到10g環境去匯入。

D:\verdmp>dir

驅動器 D 中的卷沒有標籤。

卷的序列號是 2294-1384

D:\verdmp 的目錄

2012-11-24 17:00

.

2012-11-24 17:00

..

2012-11-24 16:20 2,360 export.log

2012-11-24 16:20 69,062,656 SCOTTDMP.DMP

2012-11-24 17:00 69,103,616 testdmp.dmp

3 個檔案 138,168,632 位元組

2 個目錄 36,689,879,040 可用位元組

--匯入檔案

D:\verdmp>impdp \"/ as sysdba\" directory=verdmp dumpfile=testdmp.dmp

Import: Release 10.2.0.1.0 - Production on 星期六, 24 11月, 2012 17:02:19

連線到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

ORA-39001: 引數值無效

ORA-39000: 轉儲檔案說明錯誤

ORA-39142: 版本號 3.1 (在轉儲檔案 "D:\verdmp\testdmp.dmp" 中) 不相容

報錯，明顯是版本錯誤。解決問題的方法，就是在匯出expdp的時候，使用version引數限制dmp檔案的格式。官方的文件中，對version引數如下：

VERSION

Version of objects to export.

Valid keyword values are: [COMPATIBLE], LATEST or any valid database version.

我們重新匯出檔案。

[oracle@oracle11g ~]$ expdp userid=\'/ as sysdba\' directory=verdmp dumpfile=testdmp_10g.dmp schemas=test reuse_dumpfiles=y version=10.2.0.1.0

Export: Release 11.2.0.1.0 - Production on Sat Nov 24 08:32:34 2012

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Starting "SYS"."SYS_EXPORT_SCHEMA_01": userid="/******** AS SYSDBA" directory=verdmp dumpfile=testdmp_10g.dmp schemas=test reuse_dumpfiles=y version=10.2.0.1.0

Estimate in progress using BLOCKS method...

Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 85.25 MB

（篇幅原因，有省略……）

******************************************************************************

Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:

/verdmp/testdmp_10g.dmp

Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at 08:33:10

重新匯入檔案。

D:\verdmp>dir

驅動器 D 中的卷沒有標籤。

卷的序列號是 2294-1384

D:\verdmp 的目錄

2012-11-24 17:13

.

2012-11-24 17:13

..

2012-11-24 16:20 2,360 export.log

2012-11-24 17:02 378 import.log

2012-11-24 16:20 69,062,656 SCOTTDMP.DMP

2012-11-24 17:00 69,103,616 testdmp.dmp

2012-11-24 17:13 69,087,232 testdmp_10g.dmp

5 個檔案 207,256,242 位元組

2 個目錄 36,620,615,680 可用位元組

--重新匯入

D:\verdmp>impdp \"/ as sysdba\" directory=verdmp dumpfile=testdmp_10g.dmp remap_tablespace=test:tptest

Import: Release 10.2.0.1.0 - Production on 星期六, 24 11月, 2012 17:16:52

連線到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

已成功載入/解除安裝了主表 "SYS"."SYS_IMPORT_FULL_02"

啟動 "SYS"."SYS_IMPORT_FULL_02": "/******** AS SYSDBA" directory=verdmp dumpfil

e=testdmp_10g.dmp remap_tablespace=test:tptest

處理物件型別 SCHEMA_EXPORT/USER

處理物件型別 SCHEMA_EXPORT/SYSTEM_GRANT

處理物件型別 SCHEMA_EXPORT/ROLE_GRANT

處理物件型別 SCHEMA_EXPORT/DEFAULT_ROLE

處理物件型別 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

處理物件型別 SCHEMA_EXPORT/TYPE/TYPE_SPEC

ORA-39083: 物件型別 TYPE 建立失敗, 出現錯誤:

ORA-02304: 無效的物件識別符號文字

失敗的 sql 為:

CREATE TYPE "TEST"."T_INFO" OID '5F88C5F6877C43468A5C2CE5F53CEA48' is object (

id number);

ORA-39083: 物件型別 TYPE 建立失敗, 出現錯誤:

ORA-02304: 無效的物件識別符號文字

失敗的 sql 為:

CREATE TYPE "TEST"."T_INFOLIST" OID '49E54F26C4CC4134B65C15C1D91026FC' is tabl

e of t_info;

處理物件型別 SCHEMA_EXPORT/DB_LINK

處理物件型別 SCHEMA_EXPORT/SEQUENCE/SEQUENCE

（篇幅原因，有省略……）

處理物件型別 SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE

ORA-39082: 物件型別 ALTER_PROCEDURE:"TEST"."P_TEST_NC" 已建立, 但帶有編譯警告

處理物件型別 SCHEMA_EXPORT/VIEW/VIEW

ORA-39082: 物件型別 VIEW:"TEST"."V_T1" 已建立, 但帶有編譯警告

處理物件型別 SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY

處理物件型別 SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

處理物件型別 SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

作業 "SYS"."SYS_IMPORT_FULL_02" 已經完成, 但是有 4 個錯誤 (於 17:18:11 完成)

存在報錯，但是匯入的版本問題已經不存在了。這個問題筆者曾經解決過，詳細參見（http://space.itpub.net/17203031/viewspace-732501）。

我們透過transform引數來解決這個問題。

D:\verdmp>impdp \"/ as sysdba\" directory=verdmp dumpfile=testdmp_10g.dmp remap_tablespace=test:tptest transform=oid:n

Import: Release 10.2.0.1.0 - Production on 星期六, 24 11月, 2012 17:20:30

連線到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

已成功載入/解除安裝了主表 "SYS"."SYS_IMPORT_FULL_02"

啟動 "SYS"."SYS_IMPORT_FULL_02": "/******** AS SYSDBA" directory=verdmp dumpfile=testdmp_10g.dmp remap_tablespace=test:tptest transform=oid:n

（篇幅原因，有省略……）

處理物件型別 SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

作業 "SYS"."SYS_IMPORT_FULL_02" 已經完成, 但是有 2 個錯誤 (於 17:20:41 完成)

結論：當從高版本資料庫伺服器匯出，試圖匯入到低版本資料庫伺服器的時候，會存在版本衝突問題。解決的方法在匯出expdp過程中，使用version引數約定版本號。

注意，impdp程式也有version引數。但是對解決衝突不起作用。Impdp的version是用於生成相容性SQL語句的。

VERSION

Version of objects to import.

Valid keywords are: [COMPATIBLE], LATEST or any valid database version.

Only valid for NETWORK_LINK and SQLFILE.

即使我們在impdp中使用version，也不能起到相容性作用。

D:\verdmp>impdp \"/ as sysdba\" directory=verdmp dumpfile=testdmp.dmp remap_tablespace=test:tptest transform=oid:n version=10.2.0.1.0

Import: Release 10.2.0.1.0 - Production on 星期六, 24 11月, 2012 17:24:33

連線到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

ORA-39001: 引數值無效

ORA-39000: 轉儲檔案說明錯誤

ORA-39142: 版本號 3.1 (在轉儲檔案 "D:\verdmp\testdmp.dmp" 中) 不相容

5、結論

對Oracle Data Pump而言，版本問題較exp/imp容易的多了。目前Data Pump推出的版本只有10g和11g，相信隨著版本的不斷演進，資料泵跨版本移植的場景會越來越多。

使用version引數解決Oracle資料泵版本差異

相關文章