Pepsi sau CocaCola? Samsung ori Apple? AMD versus NVidia? DataPump ori tradiționalul export/import? Alb ori negru? va mărturisesc ca dintotdeauna am fost un fan al polemicilor, pentru mine acest lucru nu semnifica o cearta ba dimpotrivă este un schimb de idei constructive care încurajează concurenta și totodată evoluția. Totuși exista ceva în comparația de mai sus cu care nu pot fi de acord, datapump nu înlocuiește utilitarele clasice de export și import și nici invers.De-a lungul timpului am folosit ambele utilitare și pot spune ca ambele și-au îndeplinit scopul în funcție de situația pentru care le-am folosit. Principala diferența intre cele doua tehnologi este următoarea: datapump rulează pe server pornind un job în baza de date în schimb tradiționalul export/import este executat client side. Pornind de la aceasta diferența exista mai multe avantaje și dezavantaje dintre care voi enumera câteva:
- DataPump poate fi paralelizat, mai exact un job poate scrie ori citi în mai multe fișiere în același timp
- tradiționalul export va genera fișierul dump pe stația client pe când expdp-ul va genera dump-ul pe server necesitând în prealabil sa fie creat un director Oracle
- la datapump se poate face detach iar job-ul va rula în continuare, ori se poate opri iar la reconectare se face „attach” și se începe de la unde a rămas, asta deoarece în timpul exportului ori importului este monitorizat progresul într-o tabela care este creata în schema cu care este pornit procesul
- DataPump ofera posibilitatea în timpul importului de a remapa scheme, tablespace-uri, datafile-uri, tabele ori date
In următoarele rânduri voi descrie câțiva parametri pe care i-am folosit.
Primul exemplu se refera la situația în care tabela „customer” din schema hr a unei instante Oracle se dorește să fie importata pe o alta instanta dar într-o alta schema oe. Exportul este deja făcut iar tot ce ar mai trebui este sa se ruleze următoarea comanda:
$ impdp oe@orcl DIRECTORY=IMP_DIR DUMPFILE=customer.dmp TABLES=customer CONTENT=data_only REMAP_SCHEMA=hr:oe
și totuși:
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production
With the Partitioning and Automatic Storage Management options
ORA-39002: invalid operation
ORA-39166: Object OE.CUSTOMER was not found.
Mesajul ar putea fi suficient de intuitiv cu privire la eroare dar situația se aplica la un caz general de aceea voi rula din nou procesul de import dar de data aceasta voi adăuga parametrul din coada comenzii care va genera un fișier de trace.
$ impdp oe@orcl DIRECTORY=IMP_DIR DUMPFILE=customer.dmp TABLES=customer CONTENT=data_only REMAP_SCHEMA=hr:oe TRACE=480300
In fișierul de trace îmi atrage atenția următoarele linii:
KUPW:17:45:12.729: 1: Value – (((original_object_schema, original_object_name) IN (SELECT object_schema, object_name FROM „OE”.”SYS_IMPORT_TABLE_01″ WHERE process_order = -56 AND duplicate BETWEEN 1 AND 1)))
KUPW:17:45:12.729: 1: Object – TABLE
KUPW:17:45:12.729: 1: 2 Name – SCHEMA_EXPR
KUPW:17:45:12.729: 1: Value – IN (SELECT UNIQUE object_schema FROM „OE”.”SYS_IMPORT_TABLE_01″ WHERE process_order = -56 AND duplicate BETWEEN 1 AND 1)
Rulez din nou importul, de data aceasta fără erori:
impdp oe@orcl DIRECTORY=IMP_DIR DUMPFILE=customer.dmp TABLES=hr.customer CONTENT=data_only REMAP_SCHEMA=hr:oe
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported „OE”.”CUSTOMER” 215.9 KB 4751 rows
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
In cel de-al doilea exemplu arat cum se realizează un import folosind db-link:
SQL>create public database link impdbl connect to hr identified by welcome01 using ‘hrdb’;
impdp oe@orcl directory=DPUMP LOGFILE=impdp_edw.log TABLES=hr.customer network_link=impdbl REMAP_SCHEMA=hr:oe
Si în cele din urma în ultimul exemplu voi estima dimensiunea fișierului dump fără a fi nevoie sa generez nici un fișier:
expdp \”/ as sysdba\” tables=HR.MSGLOB ESTIMATE_ONLY=y
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
Starting „SYS”.”SYS_EXPORT_TABLE_01″: „/******** AS SYSDBA” tables=HR.MSGLOB ESTIMATE_ONLY=y
Estimate in progress using BLOCKS method…
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. estimated „HR”.”MSGLOB” 2.878 GB
Total estimation using BLOCKS method: 2.878 GB
Deși exista o limitare în cazul în care se folosește compresia:
expdp \”/ as sysdba\” tables=HR.MSGLOB ESTIMATE_ONLY=y compression=all
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
Starting „SYS”.”SYS_EXPORT_TABLE_01″: „/******** AS SYSDBA” tables=HR.MSGLOB ESTIMATE_ONLY=y compression=all
Estimate in progress using BLOCKS method…
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. estimated „HR”.”MSGLOB” 2.878 GB
Total estimation using BLOCKS method: 2.878 GB
oradbaro 