Oracle Data Pump: expdp ও impdp দিয়ে Export, Import ও মাইগ্রেশনের সম্পূর্ণ গাইড

আপনাকে প্রোডাকশন থেকে একটি schema টেস্ট সার্ভারে কপি করতে হবে। একটি ডেটাবেজ নতুন হার্ডওয়্যারে সরাতে হবে। কোনো ভেন্ডরকে পুরো ডেটাবেজ না দিয়ে শুধু একটি table হাতে তুলে দিতে হবে। এই সবকিছুর জন্যই Oracle Data Pump হলো সেই টুল - এবং যুক্তিসঙ্গত কারণেই এটি নীরবে পুরনো exp/imp ইউটিলিটিকে চিরতরে প্রতিস্থাপন করেছে। এই গাইডে Data Pump-কে গোড়া থেকে শেষ পর্যন্ত দেখানো হয়েছে: এটি আসলে কীভাবে কাজ করে, প্রতি সপ্তাহে আপনি যেসব export ও import চালান, কোনো dump file ছাড়াই দুটি ডেটাবেজের মধ্যে সরাসরি ডেটা সরানো, parallel পারফরম্যান্স, এবং প্রথমবার প্রায় সবাইকে বিপদে ফেলে দেয় এমন কয়েকটি error।

১. Data Pump কী - এবং কেন এটি exp/imp-কে প্রতিস্থাপন করল

Data Pump Oracle 10g-তে চালু হয় এবং এখন এটি Oracle ডেটাবেজে logical ডেটা আনা-নেওয়ার আদর্শ উপায়। কমান্ড-লাইনের দুটি টুল হলো expdp (export) ও impdp (import)। এগুলো দেখতে পুরনো exp/imp-এর মতোই, কিন্তু ভেতরে এরা সম্পূর্ণ ভিন্ন, সার্ভার-সাইড আর্কিটেকচার।

মূল পার্থক্য: পুরনো টুলগুলো ক্লায়েন্টে চলত এবং প্রতিটি row নেটওয়ার্কের উপর দিয়ে সেখানে স্ট্রিম করত যেখানে আপনি সেগুলো চালাতেন। Data Pump ডেটাবেজের ভেতরে চলে, DBMS_DATAPUMP ইঞ্জিনের মাধ্যমে, এমন সার্ভার প্রসেস ব্যবহার করে যারা ডেটাবেজ সার্ভারেই ফাইল পড়ে ও লেখে। এই কারণেই এটি নাটকীয়ভাবে দ্রুত, parallel-এ চলতে পারে এবং থামিয়ে আবার চালু করা যায়।

একটি পরিণতি মানুষকে বিপদে ফেলে: পুরনো exp দিয়ে তৈরি dump file impdp পড়তে পারে না, আর Data Pump-এর dump পুরনো imp পড়তে পারে না। এরা আলাদা ফরম্যাট। কোনো প্রাচীন সিস্টেম থেকে যদি পুরনো একটি .dmp উত্তরাধিকারসূত্রে পান, সেটি পড়তে হলে আপনার সংশ্লিষ্ট পুরনো টুলটিই দরকার।

২. যে ধারণাটি আপনাকে প্রথমেই সেট করতে হবে: Directory Object

যেহেতু Data Pump সার্ভারে লেখে, এটি আপনার কমান্ড-লাইনে কোনো operating-system path গ্রহণ করে না। বদলে এটি একটি Oracle directory object-এ লেখে - একটি নামযুক্ত ডেটাবেজ অবজেক্ট যা সার্ভারের একটি প্রকৃত ফোল্ডারের দিকে নির্দেশ করে, যেখানে Oracle সফটওয়্যার owner অবশ্যই লিখতে পারবে।

-- As a DBA, create the directory object and grant access
CREATE OR REPLACE DIRECTORY dp_dir AS '/u01/dpdump';
GRANT READ, WRITE ON DIRECTORY dp_dir TO hr;

-- Confirm it and check the OS folder exists and is writable by the oracle user
SELECT directory_name, directory_path FROM dba_directories
WHERE directory_name = 'DP_DIR';

এই ধাপটি ভুলে যাওয়াই প্রথম export ব্যর্থ হওয়ার এক নম্বর কারণ। ফোল্ডারটি অবশ্যই বাস্তবে থাকতে হবে এবং যে OS ইউজার Oracle প্রসেসের মালিক তার দ্বারা লেখার যোগ্য হতে হবে - আপনার দ্বারা নয়।

৩. আপনার নিত্যদিনের Export: একটি একক Schema

সবচেয়ে সাধারণ কাজটি হলো একটি schema export করা - কোনো ঝুঁকিপূর্ণ পরিবর্তনের আগে ব্যাকআপের জন্য, অথবা অন্য কোথাও কপি করার জন্য।

expdp hr/password@ORCL \
  directory=dp_dir \
  dumpfile=hr_%U.dmp \
  logfile=hr_export.log \
  schemas=hr

এখানে কয়েকটি জিনিস জানা দরকার। %U হলো একটি প্রতিস্থাপন wildcard - আপনি যখন parallel-এ export করবেন, Data Pump hr_01.dmp, hr_02.dmp এভাবে ফাইল তৈরি করবে। সবসময় একটি logfile লিখুন এবং সেটি পড়ুন; নিচের summary আপনাকে ঠিক ঠিক বলে দেবে কী export হয়েছে আর কী হয়নি।

৩.১ Full Database ও Table-লেভেল Export

-- Whole database (needs DATAPUMP_EXP_FULL_DATABASE role)
expdp system/password directory=dp_dir dumpfile=full_%U.dmp \
  logfile=full_exp.log full=y parallel=4

-- Just two tables
expdp hr/password directory=dp_dir dumpfile=emp_dept.dmp \
  tables=hr.employees,hr.departments

-- Metadata only - structure, no rows (great for building an empty copy)
expdp hr/password directory=dp_dir dumpfile=hr_meta.dmp \
  schemas=hr content=metadata_only

content প্যারামিটারটি কম ব্যবহৃত হয়: metadata_only আপনাকে ডেটা ছাড়া সব অবজেক্ট দেয়, data_only দেয় DDL ছাড়া row, আর ডিফল্ট all দুটোই দেয়।

৪. Import - এবং যেসব প্যারামিটার একে কাজের করে তোলে

সাধারণ একটি import সবকিছু যেখান থেকে এসেছিল সেখানেই ফিরিয়ে দেয়। impdp-এর আসল শক্তি হলো remapping, যা আপনাকে ডেটা ভিন্ন কোথাও নামাতে দেয়।

-- Import the HR schema INTO a different schema called HR_TEST,
-- and move its objects into a different tablespace
impdp system/password directory=dp_dir dumpfile=hr_%U.dmp \
  logfile=hr_imp.log \
  remap_schema=hr:hr_test \
  remap_tablespace=users:test_data \
  table_exists_action=replace

মূলটিকে না মুছে প্রোডাকশন থেকে একটি টেস্ট schema রিফ্রেশ করতে আপনি REMAP_SCHEMA ব্যবহার করেন। প্রোডাকশন থেকে টেস্টের storage ভিন্নভাবে সাজানো - এই সাধারণ পরিস্থিতি REMAP_TABLESPACE সামলায়। আর TABLE_EXISTS_ACTION ঠিক করে কোনো table ইতিমধ্যে থাকলে কী হবে - skip, append, truncate, নাকি replace। সচেতনভাবে এটি বেছে নিলে বাজে চমক এড়ানো যায়।

যদি কেবল দেখতে চান একটি import কী করত, তাহলে এটি না চালিয়ে sqlfile দিয়ে DDL তৈরি করুন:

impdp system/password directory=dp_dir dumpfile=hr_%U.dmp \
  sqlfile=hr_ddl.sql schemas=hr
-- Writes all the CREATE statements to hr_ddl.sql, imports nothing.

৫. দুটি ডেটাবেজের মধ্যে সরাসরি মাইগ্রেশন - কোনো Dump File ছাড়া

যখন আপনি একটি schema পুরনো সার্ভার থেকে নতুন সার্ভারে সরাচ্ছেন, তখন আপনাকে ডিস্কে export করে, ফাইল কপি করে, তারপর import করতে হয় না। Data Pump NETWORK_LINK দিয়ে একটি database link-এর মধ্য দিয়ে সরাসরি ডেটা টেনে আনতে পারে। এতে প্রায়ই ঘণ্টার পর ঘণ্টা এবং প্রচুর ডিস্ক সাশ্রয় হয়।

-- On the TARGET database: create a link back to the SOURCE
CREATE DATABASE LINK src_db
  CONNECT TO hr IDENTIFIED BY password USING 'SOURCE_TNS';

-- Then import directly - no dumpfile parameter at all
impdp system/password directory=dp_dir \
  logfile=net_imp.log \
  network_link=src_db \
  remap_schema=hr:hr \
  parallel=4

নতুন হার্ডওয়্যারে মাইগ্রেট করা বা একটি schema-কে একটি multitenant pluggable database-এ একত্র করার সবচেয়ে পরিচ্ছন্ন উপায়গুলোর একটি এটি। এটি ভার্সনের মধ্যেও কাজ করে, পুরনো রিলিজ থেকে নতুনে সরাতে দেয়, যা একটি পরিকল্পিত 19c থেকে 26ai আপগ্রেড-এর সঙ্গে ভালো মেলে।

৬. পারফরম্যান্স: বড় Export যেন সময়ের মধ্যে শেষ হয়

বড় একটি ডেটাবেজের জন্য যে জব রাতারাতি শেষ হয় আর যেটি সময় ছাড়িয়ে যায় - এদের পার্থক্য সাধারণত parallelism। যখন আপনি Data Pump-কে একাধিক worker ও একাধিক ফাইল দেন, এটি ভালো স্কেল করে।

• PARALLEL: এটি প্রায় উপলব্ধ CPU core-সংখ্যার সমান সেট করুন, এবং সবসময় একটি %U dumpfile-এর সঙ্গে জুড়ে দিন যাতে প্রতিটি worker নিজের ফাইল লেখে। একটি ফাইল আর parallel একসঙ্গে আত্মঘাতী।
• COMPRESSION: compression=all dump-কে যথেষ্ট ছোট করে, CPU-এর বিনিময়ে অনেক কম I/O ও ডিস্ক - আধুনিক সার্ভারে সাধারণত লাভজনক।
• EXCLUDE: যা দরকার নেই তা বাদ দিন। statistics বাদ দেওয়া (exclude=statistics) এবং import-এর পর সেগুলো আবার gather করা প্রায়ই dump-এ বহন করার চেয়ে দ্রুত।
• ESTIMATE: শুরুর আগে জবের আকার বুঝতে এবং যথেষ্ট ডিস্ক স্থান আছে কিনা নিশ্চিত হতে প্রথমে estimate_only=y চালান।

expdp system/password directory=dp_dir dumpfile=big_%U.dmp \
  logfile=big_exp.log full=y \
  parallel=8 compression=all exclude=statistics

Data Pump জব restartable-ও বটে। কোনো জব মারা গেলে আপনি attach=JOB_NAME দিয়ে নাম ধরে সেটিতে পুনরায় যুক্ত হয়ে চালিয়ে যেতে পারেন, নতুন করে শুরু করার বদলে।

৭. যেসব Error সবাই প্রথমে ধাক্কা খায় - এবং আসল সমাধান

Data Pump বেশিরভাগ সমস্যাকে একটি সাধারণ ORA-39002: invalid operation-এ মুড়ে রাখে, যা নিজে থেকে কিছুই জানায় না। কাজের বার্তাটি সবসময় এর নিচের লাইনে থাকে। প্রচলিত কারণগুলো:

• ORA-39070 / cannot open logfile: directory object নেই, অথবা OS ফোল্ডার হারিয়ে গেছে বা oracle ইউজারের দ্বারা লেখার যোগ্য নয়। directory grant ও ফোল্ডার পারমিশন ঠিক করুন।
• Source-এর চেয়ে পুরনো Target ভার্সন: নতুন ডেটাবেজ থেকে নেওয়া dump পুরনো ডেটাবেজে import হবে না, যদি না export-এ version= দিয়ে নিম্ন রিলিজকে target করা হয়। target পুরনো জেনে থাকলে export-এর সময় version সেট করুন।
• ORA-31626 / insufficient privileges: full export ও import-এর জন্য DATAPUMP_EXP_FULL_DATABASE ও DATAPUMP_IMP_FULL_DATABASE role দরকার। schema-লেভেলের কাজে directory grant লাগে।
• জবের মাঝপথে স্থান ফুরিয়ে যাওয়া: dump গন্তব্য ভরে গেছে, অথবা target tablespace বাড়তে পারেনি। এ কারণেই আগে estimate_only চালানো একটি ভালো অভ্যাস।

৮. একটি বাস্তব মাইগ্রেশন: এক সপ্তাহান্তে ৪০০ GB নতুন হার্ডওয়্যারে

একটি ম্যানুফ্যাকচারিং ক্লায়েন্টের তাদের ERP ডেটাবেজ ন্যূনতম ডাউনটাইমে নতুন সার্ভারে সরানো দরকার ছিল। dump-এবং-কপি পদ্ধতিতে ৪০০ GB ডিস্কে export করা, নেটওয়ার্কের উপর দিয়ে কপি করা এবং import করা লাগত - সপ্তাহান্তের সময়ের জন্য বড্ড ধীর।

আমরা যা করেছি: target-এ আগেভাগে schema ও tablespace তৈরি করে নিয়ে, তারপর parallel=8 ও exclude=statistics দিয়ে একটি NETWORK_LINK import চালিয়েছি, পুরনো ডেটাবেজ থেকে সরাসরি টেনে। লোডের পর statistics নতুন করে gather করা হয়েছে। সরাসরি টানা কপি ধাপটিকে পুরোপুরি বাদ দিয়েছে এবং parallel worker-রা নতুন সার্ভারের core পুরোপুরি কাজে লাগিয়েছে। মাইগ্রেশন সময়ের মধ্যেই ভালোভাবে শেষ হয়েছে, আর যেহেতু Data Pump তার log-এ object সংখ্যা যাচাই করেছে, তাই সবকিছু পৌঁছেছে তার একটি স্পষ্ট রেকর্ড আমাদের হাতে ছিল। এই ধরনের logical সরানো RMAN backup ও recovery-এর উপর গড়া একটি physical কৌশলের পরিপূরক।

সাধারণ জিজ্ঞাসা (FAQ)

Data Pump আর পুরনো exp/imp-এর মধ্যে পার্থক্য কী?

Data Pump (expdp/impdp) সার্ভারে ডেটাবেজের ভেতরেই চলে এবং অনেক বেশি দ্রুত, parallel-সক্ষম ও restartable। পুরনো exp/imp ক্লায়েন্টে চলত এবং নেটওয়ার্কের উপর দিয়ে row স্ট্রিম করত। এদের dump file ফরম্যাট পরস্পর সঙ্গতিপূর্ণ নয় - আপনি impdp দিয়ে পুরনো exp dump import করতে পারবেন না, উল্টোটাও নয়।

আমার export কেন ORA-39002 দিয়ে ব্যর্থ হয়?

ORA-39002 একটি সাধারণ মোড়ক মাত্র; আসল কারণ থাকে এর নিচের লাইনে। সবচেয়ে সাধারণ কারণ হলো directory object না থাকা অথবা operating-system ফোল্ডারটি Oracle সফটওয়্যার owner-এর দ্বারা লেখার যোগ্য না হওয়া। প্রথমে DIRECTORY object, READ/WRITE grant এবং ফোল্ডার পারমিশন পরীক্ষা করুন।

একটি schema-কে ভিন্ন schema নামে কীভাবে import করব?

impdp কমান্ডে REMAP_SCHEMA=source:target ব্যবহার করুন। যেমন remap_schema=hr:hr_test দিলে HR অবজেক্টগুলো HR_TEST নামের schema-তে import হয়। storage layout ভিন্ন হলে এর সঙ্গে REMAP_TABLESPACE জুড়ে দিন - প্রোডাকশন থেকে টেস্ট এনভায়রনমেন্ট রিফ্রেশ করার এটাই আদর্শ উপায়।

dump file ছাড়াই দুটি ডেটাবেজের মধ্যে ডেটা সরাতে পারি কি?

হ্যাঁ। target-এ source-এর দিকে নির্দেশ করা একটি database link তৈরি করুন, তারপর সেই link-এ NETWORK_LINK সেট করে এবং কোনো dumpfile প্যারামিটার ছাড়াই impdp চালান। Data Pump link-এর মধ্য দিয়ে সরাসরি ডেটা টেনে আনে, যা নতুন হার্ডওয়্যারে মাইগ্রেশনের জন্য আদর্শ এবং এমনকি ভিন্ন Oracle ভার্সনের মধ্যেও ডেটা সরাতে পারে।

বড় একটি Data Pump export কীভাবে দ্রুত চালাব?

সবচেয়ে বড় লিভার হলো PARALLEL-কে প্রায় CPU core-সংখ্যার সমান সেট করা, সঙ্গে একটি %U wildcard যাতে প্রতিটি worker নিজের dump file লেখে। compression=all যোগ করলে I/O কমে, আর statistics বাদ দিয়ে import-এর পর আবার gather করা প্রায়ই dump-এ বহন করার চেয়ে দ্রুত।