So sánh exp/imp với expdp/impdp

Thực tế, chúng ta phải thực hiện rất nhiều công việc import, export data, thậm chí có thể coi đó là công việc hằng ngày. Có rất nhiều scenario xảy ra khi làm task này, trong đó scenario thông thường là, chuyển các object từ 1 user sử dụng tablespace này sang một user sử dụng 1 tablespace khác. Sẽ có 2 case trong scenario này:
Case 1: Với object ( cụ thể ở đây là các Tables ) có trường không thuộc kiểu CLOB, BLOB
Case 2: Với object ( cụ thể ở đây là các Tables ) có trường thuộc kiểu CLOB, BLOB
Với các case trên nếu ta dùng kiểu exp/imp truyền thống thì chỉ có thể imp đc các object thuộc case 1, còn object thuộc case 2 sẽ không imp được, các lỗi đại loại như IMP-00003, IMP-00017, ORA-01536, ORA-00959 có thể sẽ gặp, nguyên nhân lỗi đại loại như không tìm thấy tablespace ( ORA-00959: tablespace ‘CIC2008′ does not exist ), hay không gian cấp đối với tablespace đã bị vượt quá (ORA-01536: space quota exceeded for tablespace ‘ICT24H’ )
Vậy câu hỏi được đặt ra là tại sao với case 1, công cụ imp lại import đc, trong khi case 2 lại không import đc, đáp án là trường có kiểu là CLOB hay BLOB sẽ đc giấu trong 1 tablespace khác ( nested tables ). Cụ thể với case 1, công cụ imp đã import thành công cho dù tablespace đã được xác định trong quá trình export. Lúc này IMP sẽ lấy tablespace mặc định of user hiện hành nếu tablespace gốc không thể đc sử dụng. ( Oracle sẽ đoán rằng ko tồn tại tablespace hoặc đã vượt quá hạn mức cấp quota đối với tablespace đó). Còn với case 2 Oralce sẽ không thể xác định đc tablespace đối với trường CLOB do nguyên nhân trên.
Ví dụ cụ thể:
1. Tạo 2 bảng
Code:
CREATE TABLE “NO_OK” (
“ID” NUMBER(9, 0),
“IMAGE” BLOB)
TABLESPACE ” TS_GOC “
LOB (“IMAGE”) STORE AS (TABLESPACE “TS_GOC”)
/
CREATE TABLE “OK” (
“ID” NUMBER(9, 0),
“NAME” VARCHAR2(50))
TABLESPACE ” TS_GOC “
/
2. Với exp/imp truyền thống
Code:
Ø    exp uid1/pwd1@sid file=”c:/test.dm” tables=(OK, NO_OK)
Ø    imp uid2/pwd2@xe file=”c:/test.dmp” tables=(OK, NO_OK)
–> Lỗi phát sinh:
Code:
IMP-00003: ORACLE error 1536 encountered
ORA-01536: space quota exceeded for tablespace ‘YOCOYA’
3. Với expdp/impdp ( ver Oracle 10g )
Code:
Ø    expdp uid1/pwd1@sid tables=(OK, NO_OK) dumpfile=”c:/testdp.dmp” nologfile=Y
Ø    impdp uid2/pwd2@sid remap_schema=uid1:uid2 REMAP_TABLESPACE=uid1_tspace:uid2_tspace
dumpfile=”c:/testdp.dmp” logfile=”c:/test.log”
4. Sau đây là thông tin so sánh giữa 2 công cụ này (http://download-east.oracle.com/docs…w.htm#sthref48 )
· Data Pump Export and Import operate on a group of files called a dump file set rather than on a single sequential dump file.
· Data Pump Export and Import access files on the server rather than on the client. This results in improved performance. It also means that directory objects are required when you specify file locations.
· The Data Pump Export and Import modes operate symmetrically, whereas original export and import did not always exhibit this behavior.
For example, suppose you perform an export with FULL=Y, followed by an import using SCHEMAS=HR. This will produce the same results as if you performed an export with SCHEMAS=HR, followed by an import with FULL=Y.
· Data Pump Export and Import use parallel execution rather than a single stream of execution, for improved performance. This means that the order of data within dump file sets and the information in the log files is more variable.
· Data Pump Export and Import represent metadata in the dump file set as XML documents rather than as DDL commands. This provides improved flexibility for transforming the metadata at import time.
· Data Pump Export and Import are self-tuning utilities. Tuning parameters that were used in original Export and Import, such as BUFFER and RECORDLENGTH, are neither required nor supported by Data Pump Export and Import.
· At import time there is no option to perform interim commits during the restoration of a partition. This was provided by the COMMIT parameter in original Import.
· There is no option to merge extents when you re-create tables. In original Import, this was provided by the COMPRESS parameter. Instead, extents are reallocated according to storage parameters for the target table.
· Sequential media, such as tapes and pipes, are not supported.
· The Data Pump method for moving data between different database versions is different than the method used by original Export/Import. With original Export, you had to run an older version of Export (exp) to produce a dump file that was compatible with an older database version. With Data Pump, you can use the current Export (expdp) version and simply use the VERSION parameter to specify the target database version. See Moving Data Between Different Database Versions.
· When you are importing data into an existing table using either APPEND or TRUNCATE, if any row violates an active constraint, the load is discontinued and no data is loaded. This is different from original Import, which logs any rows that are in violation and continues with the load.
· Data Pump Export and Import consume more undo tablespace than original Export and Import. This is due to additional metadata queries during export and some relatively long-running master table queries during import. As a result, for databases with large amounts of metadata, you may receive an ORA-01555: snapshot too old error. To avoid this, consider adding additional undo tablespace or increasing the value of the UNDO_RETENTION initialization parameter for the database.
· If a table has compression enabled, Data Pump Import attempts to compress the data being loaded. Whereas, the original Import utility loaded data in such a way that if a even table had compression enabled, the data was not compressed upon import.
· Data Pump supports character set conversion for both direct path and external tables. Most of the restrictions that exist for character set conversions in the original Import utility do not apply to Data Pump. The one case in which character set conversions are not supported under the Data Pump is when using transportable tablespaces.

Thực tế, chúng ta phải thực hiện rất nhiều công việc import, export data, thậm chí có thể coi đó là công việc hằng ngày. Có rất nhiều scenario xảy ra khi làm task này, trong đó scenario thông thường là, chuyển các object từ 1 user sử dụng tablespace này sang một user sử dụng 1 tablespace khác. Sẽ có 2 case trong scenario này:Case 1: Với object ( cụ thể ở đây là các Tables ) có trường không thuộc kiểu CLOB, BLOBCase 2: Với object ( cụ thể ở đây là các Tables ) có trường thuộc kiểu CLOB, BLOBVới các case trên nếu ta dùng kiểu exp/imp truyền thống thì chỉ có thể imp đc các object thuộc case 1, còn object thuộc case 2 sẽ không imp được, các lỗi đại loại như IMP-00003, IMP-00017, ORA-01536, ORA-00959 có thể sẽ gặp, nguyên nhân lỗi đại loại như không tìm thấy tablespace ( ORA-00959: tablespace ‘CIC2008′ does not exist ), hay không gian cấp đối với tablespace đã bị vượt quá (ORA-01536: space quota exceeded for tablespace ‘ICT24H’ )Vậy câu hỏi được đặt ra là tại sao với case 1, công cụ imp lại import đc, trong khi case 2 lại không import đc, đáp án là trường có kiểu là CLOB hay BLOB sẽ đc giấu trong 1 tablespace khác ( nested tables ). Cụ thể với case 1, công cụ imp đã import thành công cho dù tablespace đã được xác định trong quá trình export. Lúc này IMP sẽ lấy tablespace mặc định of user hiện hành nếu tablespace gốc không thể đc sử dụng. ( Oracle sẽ đoán rằng ko tồn tại tablespace hoặc đã vượt quá hạn mức cấp quota đối với tablespace đó). Còn với case 2 Oralce sẽ không thể xác định đc tablespace đối với trường CLOB do nguyên nhân trên.
Ví dụ cụ thể:1. Tạo 2 bảngCode:CREATE TABLE “NO_OK” (“ID” NUMBER(9, 0),“IMAGE” BLOB)TABLESPACE ” TS_GOC “LOB (“IMAGE”) STORE AS (TABLESPACE “TS_GOC”)/CREATE TABLE “OK” (“ID” NUMBER(9, 0),“NAME” VARCHAR2(50))TABLESPACE ” TS_GOC “/2. Với exp/imp truyền thốngCode:Ø    exp uid1/pwd1@sid file=”c:/test.dm” tables=(OK, NO_OK)Ø    imp uid2/pwd2@xe file=”c:/test.dmp” tables=(OK, NO_OK)–> Lỗi phát sinh:Code:IMP-00003: ORACLE error 1536 encounteredORA-01536: space quota exceeded for tablespace ‘YOCOYA’3. Với expdp/impdp ( ver Oracle 10g )Code:Ø    expdp uid1/pwd1@sid tables=(OK, NO_OK) dumpfile=”c:/testdp.dmp” nologfile=YØ    impdp uid2/pwd2@sid remap_schema=uid1:uid2 REMAP_TABLESPACE=uid1_tspace:uid2_tspacedumpfile=”c:/testdp.dmp” logfile=”c:/test.log”4. Sau đây là thông tin so sánh giữa 2 công cụ này (http://download-east.oracle.com/docs…w.htm#sthref48 )· Data Pump Export and Import operate on a group of files called a dump file set rather than on a single sequential dump file.· Data Pump Export and Import access files on the server rather than on the client. This results in improved performance. It also means that directory objects are required when you specify file locations.· The Data Pump Export and Import modes operate symmetrically, whereas original export and import did not always exhibit this behavior.For example, suppose you perform an export with FULL=Y, followed by an import using SCHEMAS=HR. This will produce the same results as if you performed an export with SCHEMAS=HR, followed by an import with FULL=Y.· Data Pump Export and Import use parallel execution rather than a single stream of execution, for improved performance. This means that the order of data within dump file sets and the information in the log files is more variable.· Data Pump Export and Import represent metadata in the dump file set as XML documents rather than as DDL commands. This provides improved flexibility for transforming the metadata at import time.· Data Pump Export and Import are self-tuning utilities. Tuning parameters that were used in original Export and Import, such as BUFFER and RECORDLENGTH, are neither required nor supported by Data Pump Export and Import.· At import time there is no option to perform interim commits during the restoration of a partition. This was provided by the COMMIT parameter in original Import.· There is no option to merge extents when you re-create tables. In original Import, this was provided by the COMPRESS parameter. Instead, extents are reallocated according to storage parameters for the target table.· Sequential media, such as tapes and pipes, are not supported.· The Data Pump method for moving data between different database versions is different than the method used by original Export/Import. With original Export, you had to run an older version of Export (exp) to produce a dump file that was compatible with an older database version. With Data Pump, you can use the current Export (expdp) version and simply use the VERSION parameter to specify the target database version. See Moving Data Between Different Database Versions.· When you are importing data into an existing table using either APPEND or TRUNCATE, if any row violates an active constraint, the load is discontinued and no data is loaded. This is different from original Import, which logs any rows that are in violation and continues with the load.· Data Pump Export and Import consume more undo tablespace than original Export and Import. This is due to additional metadata queries during export and some relatively long-running master table queries during import. As a result, for databases with large amounts of metadata, you may receive an ORA-01555: snapshot too old error. To avoid this, consider adding additional undo tablespace or increasing the value of the UNDO_RETENTION initialization parameter for the database.· If a table has compression enabled, Data Pump Import attempts to compress the data being loaded. Whereas, the original Import utility loaded data in such a way that if a even table had compression enabled, the data was not compressed upon import.· Data Pump supports character set conversion for both direct path and external tables. Most of the restrictions that exist for character set conversions in the original Import utility do not apply to Data Pump. The one case in which character set conversions are not supported under the Data Pump is when using transportable tablespaces.

(Nguồn: http://www.ict24h.net)
Advertisements

Posted on November 22, 2009, in Tin học. Bookmark the permalink. 1 Comment.

  1. Lots of folks talk about this matter but you wrote down really true words!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: