RMAN DUPLICATE দিয়ে Oracle ডেটাবেজ ক্লোন করা: Active ও Backup-Based

প্রতিটি টিমেরই production-এর কপি দরকার হয়: প্রকৃত ডেটার সাথে মিল রাখা একটি test ডেটাবেজ, পরের রিলিজের জন্য একটি UAT environment, ব্যবসা রক্ষার জন্য একটি standby, migration-এর জন্য নতুন হার্ডওয়্যারে একটি clone। এটি হাতে হাতে করা - ফাইল restore করা, সব কিছু rename করা, control file সম্পাদনা করা - ধীর ও ভুলপ্রবণ। RMAN DUPLICATE পুরো কাজটিকে একটিমাত্র কমান্ডে স্বয়ংক্রিয় করে দেয়, যা একটি ডেটাবেজের সম্পূর্ণ কার্যক্ষম কপি তৈরি করে - হয় সরাসরি চলমান source থেকে, নয়তো বিদ্যমান backup থেকে। এই গাইডে আছে উভয় পদ্ধতি, প্রথমে যে auxiliary instance আপনি সেটআপ করেন, যে clause গুলো ফাইলকে সঠিক জায়গায় রাখে, এবং যে ভুলগুলো মানুষকে প্রথমবারেই আটকে দেয়।

১. কেন একটি ডেটাবেজ ক্লোন করবেন?

ক্লোনিং হলো বাস্তব জগতের সবচেয়ে সাধারণ DBA কাজগুলোর একটি, আর তা নানা রূপে হাজির হয়। আপনি একটি test বা UAT environment refresh করেন যাতে ডেভেলপাররা বাস্তবসম্মত ডেটার বিপরীতে কাজ করতে পারে। আপনি একটি reporting copy বানান যাতে ভারী query গুলো production-কে স্পর্শ না করে। আপনি Data Guard-এর জন্য একটি standby তৈরি করেন। migration ধাপ হিসেবে নতুন হার্ডওয়্যারে একটি কপি দাঁড় করান। প্রতিটি ক্ষেত্রেই আপনার দরকার একটি বিশ্বস্ত, কার্যক্ষম কপি - এবং তা চাই একটি পুরো সপ্তাহান্তের হাতে-করা restore কাজ ছাড়াই।

RMAN DUPLICATE ঠিক এ কারণেই আছে। এটি datafile গুলো restore বা কপি করে, একটি নতুন control file বানায়, ফাইলগুলোকে নতুন অবস্থানে rename করে, ডেটাবেজটিকে একটি নতুন পরিচয় দিয়ে open করে এবং আপনার হাতে একটি চলমান clone তুলে দেয় - সবটাই একটিমাত্র কমান্ড দিয়ে চালিত।

২. দুই পদ্ধতি: Active বনাম Backup-Based

duplicate করার দুটি উপায় আছে, আর সঠিকটি বেছে নেওয়া গুরুত্বপূর্ণ।

Active duplication চলমান source ডেটাবেজ থেকে network-এর মাধ্যমে সরাসরি clone-এ datafile গুলো কপি করে। আপনার কোনো বিদ্যমান backup লাগে না, যা সুবিধাজনক, তবে এটি source-এর ওপর read load ফেলে এবং কপির সময় network bandwidth ব্যবহার করে। যখন আপনার হাতে সাম্প্রতিক কোনো backup নেই বা সম্ভাব্য সবচেয়ে তাজা কপি চান, তখন এটি আদর্শ।

Backup-based duplication বিদ্যমান RMAN backup থেকে clone তৈরি করে, live source-কে মোটেও স্পর্শ না করেই। ব্যস্ত production সিস্টেমের জন্য এটিই সদয় পছন্দ, কারণ কপিতে source যুক্ত থাকে না - clone backup ফাইল পড়ে। এটি ভালো, অ্যাক্সেসযোগ্য backup থাকার ওপর নির্ভর করে, যা একটি মজবুত RMAN backup কৌশল-এর সুফল দেওয়ার আরেকটি কারণ।

৩. Auxiliary Instance প্রস্তুত করুন

যে ডেটাবেজটি clone হতে যাচ্ছে তাকে বলা হয় auxiliary instance। RMAN তাতে duplicate করার আগে আপনি এটিকে একটি খালি, start করার-উপযোগী খোল হিসেবে সেটআপ করেন।

-- 1. Create a minimal init file for the clone (auxiliary)
--    at minimum: db_name, memory, and file-location parameters
echo "db_name=TESTDB" > $ORACLE_HOME/dbs/initTESTDB.ora

-- 2. Create a password file (needed for the RMAN auxiliary connection)
orapwd file=$ORACLE_HOME/dbs/orapwTESTDB password=oracle

-- 3. Create the directories the clone's files will live in
mkdir -p /u01/app/oracle/oradata/TESTDB
mkdir -p /u01/app/oracle/fast_recovery_area/TESTDB

-- 4. Add a static listener entry / TNS alias for the auxiliary, then:
export ORACLE_SID=TESTDB
sqlplus / as sysdba
STARTUP NOMOUNT;   -- auxiliary must be in NOMOUNT for DUPLICATE

DUPLICATE চালানোর সময় auxiliary-কে অবশ্যই NOMOUNT অবস্থায় থাকতে হবে - RMAN সেখান থেকেই সব কিছু তৈরি করে। একটি static listener registration গুরুত্বপূর্ণ কারণ auxiliary যখন এখনও open হয়নি তখন RMAN listener-এর মাধ্যমেই তার সাথে connect করে।

৪. ধাপে ধাপে Active Duplication

auxiliary NOMOUNT-এ থাকা অবস্থায়, RMAN-কে source (target) এবং auxiliary উভয়ের সাথে connect করুন এবং duplicate চালান।

rman TARGET sys/password@PRODDB AUXILIARY sys/password@TESTDB

DUPLICATE TARGET DATABASE TO TESTDB
  FROM ACTIVE DATABASE
  DB_FILE_NAME_CONVERT '/oradata/PRODDB/','/u01/app/oracle/oradata/TESTDB/'
  LOG_FILE_NAME_CONVERT '/oradata/PRODDB/','/u01/app/oracle/oradata/TESTDB/'
  SPFILE
    SET DB_UNIQUE_NAME 'TESTDB'
    SET DB_CREATE_FILE_DEST '/u01/app/oracle/oradata/TESTDB';

DB_FILE_NAME_CONVERT ও LOG_FILE_NAME_CONVERT জোড়াগুলো source ফাইলের path গুলোকে clone-এর path-এ পুনর্লিখন করে। RMAN PRODDB থেকে সরাসরি লাইভ datafile কপি করে, একটি control file বানায় এবং TESTDB-কে একটি নতুন DBID দিয়ে open করে - ফলে এটি production থেকে সম্পূর্ণ স্বাধীন।

৫. ধাপে ধাপে Backup-Based Duplication

Backup-based duplication প্রায় অভিন্ন দেখায়, শুধু FROM ACTIVE DATABASE বাদে। RMAN-এর source-এর backup গুলোতে অ্যাক্সেস দরকার (একটি shared location বা একটি catalog)।

rman TARGET sys/password@PRODDB AUXILIARY sys/password@TESTDB
-- (or connect to the RMAN catalog instead of the target)

DUPLICATE TARGET DATABASE TO TESTDB
  DB_FILE_NAME_CONVERT '/oradata/PRODDB/','/u01/app/oracle/oradata/TESTDB/'
  LOG_FILE_NAME_CONVERT '/oradata/PRODDB/','/u01/app/oracle/oradata/TESTDB/'
  NOFILENAMECHECK;

যেহেতু এটি backup থেকে পড়ে, source ডেটাবেজ কপির দ্বারা অস্পর্শিত থাকে - এ কারণেই ব্যস্ত production সিস্টেমের জন্য এই পদ্ধতিটি পছন্দনীয়। আপনি UNTIL TIME দিয়ে অতীতের কোনো নির্দিষ্ট বিন্দুতেও duplicate করতে পারেন, যা তখন কাজে লাগে যখন clone-টিকে একটি নির্দিষ্ট মুহূর্তের ডেটা প্রতিফলিত করাতে চান।

৬. যে Clause গুলো আপনাকে বাঁচায়

• DB_FILE_NAME_CONVERT / LOG_FILE_NAME_CONVERT: source থেকে clone-এ ফাইল path গুলো একসাথে পুনর্লিখন করে। layout যখন একটি প্যাটার্নে মেলে তখন এটিই মূল কর্মী।
• SET NEWNAME: একটি নির্দিষ্ট ফাইলকে সুনির্দিষ্টভাবে রাখে, যখন কোনো একটি datafile-এর প্যাটার্নের চেয়ে ভিন্ন অবস্থান দরকার।
• NOFILENAMECHECK: RMAN-কে বলে যে clone-এর ফাইলের নাম source-এর সাথে মিলে গেলেও আপত্তি না করতে - একই path দিয়ে ভিন্ন সার্ভারে duplicate করার সময় এটি দরকার।
• SKIP TABLESPACE: clone-এ যে tablespace আপনার দরকার নেই (বড় history বা index tablespace) সেগুলো বাদ দেয়, clone-কে ছোট ও দ্রুত করে তোলে।
• SET UNTIL TIME: ডেটাবেজটি আগের কোনো সময়ে যেমন ছিল সেভাবে duplicate করে (backup-based)।

৭. Clone-এর পর - এটি ভুলবেন না

production-এর একটি তাজা clone-এ প্রকৃত production ডেটা থাকে। ডেভেলপার বা টেস্টাররা তা স্পর্শ করার আগে ডেটা প্রাইভেসিকে একটি বাধ্যতামূলক ধাপ হিসেবে ধরুন, পরে দেখা যাবে এমন কিছু নয়। ব্যক্তিগত ও আর্থিক ডেটা mask বা scramble করুন, outbound integration ও email বন্ধ করুন যাতে clone প্রকৃত গ্রাহকদের বার্তা পাঠাতে না পারে, এবং credential reset করুন। ফার্মা বা ব্যাংকিং clone-এর জন্য এটি একটি কমপ্লায়েন্স বাধ্যবাধকতা, ভদ্রতা নয়। আপনি যদি পুরো ডেটাবেজের বদলে শুধু নির্বাচিত schema clone করতে চান, তবে এখানেই Data Pump সাহায্য করতে পারে।

৮. সাধারণ ভুল এবং কীভাবে সেগুলো সামলাবেন

• Auxiliary connection ব্যর্থ হয়: password file নেই অথবা listener-এ auxiliary-র জন্য কোনো static entry নেই। auxiliary NOMOUNT-এ থাকা অবস্থায় RMAN listener-এর মাধ্যমে তার সাথে connect করে - দুটোই উপস্থিত থাকতে হবে।
• RMAN-05001 (file name source-এর সাথে conflict করে): আপনি একই path দিয়ে ভিন্ন সার্ভারে duplicate করছেন এবং NOFILENAMECHECK ভুলে গেছেন, নয়তো আপনার CONVERT প্যাটার্ন কোনো একটি ফাইল কভার করেনি।
• Auxiliary-তে জায়গা ফুরিয়ে যায়: clone-এর সব datafile-এর জন্য জায়গা দরকার; শুরুর আগে target file system গুলোর আকার ঠিক করে নিন।
• Active duplication-এর জন্য network খুব ধীর: একটি খুব বড় ডেটাবেজে সরু লিঙ্কের ওপর, backup-এর একটি local কপি থেকে backup-based duplication প্রায়ই দ্রুততর এবং production-এর প্রতি বেশি সদয়।

৯. শুধু একটি Pluggable Database ক্লোন করা

আপনি যদি multitenant চালান, প্রায়ই আপনার পুরো একটি ডেটাবেজ duplicate করার দরকারই হয় না - আপনি একটি একক pluggable database clone করতে পারেন, যা পূর্ণ DUPLICATE-এর চেয়ে নাটকীয়ভাবে দ্রুত ও সহজ। একটি অ্যাপ্লিকেশনের ডেটার test বা reporting কপি দাঁড় করানোর এটিই আধুনিক উপায়।

-- Clone a PDB within the same container (source PDB stays open in 19c - hot clone)
CREATE PLUGGABLE DATABASE test_pdb FROM prod_pdb;

-- Clone a PDB from a REMOTE database over a database link
CREATE PLUGGABLE DATABASE test_pdb FROM prod_pdb@src_link;

-- Then open it
ALTER PLUGGABLE DATABASE test_pdb OPEN;

Oracle 12.2 থেকে clone-এর সময় source PDB open থাকতে পারে (একটি hot clone), তাই source-এ কোনো outage হয় না। একটি একক-অ্যাপ্লিকেশন refresh-এর জন্য এটিই সাধারণত সঠিক টুল; পূর্ণ RMAN DUPLICATE রাখুন whole-database clone, migration এবং standby-এর জন্য। যেভাবেই হোক, আগের অংশের clone-পরবর্তী data-masking ধাপটি এখনও প্রযোজ্য।

১০. একটি বাস্তব Refresh: প্রতি Sprint-এ Production থেকে UAT

একটি ম্যানুফ্যাকচারিং ক্লায়েন্ট চেয়েছিল প্রতিটি রিলিজের আগে তাদের UAT ডেটাবেজ production থেকে refresh হোক, কিন্তু refresh একজন DBA-র পুরো দিন খেয়ে ফেলত এবং কখনও কখনও ভুল ফাইল স্পর্শ করত। আমরা এটিকে একটি পুনরাবৃত্তিযোগ্য RMAN DUPLICATE job-এ পরিণত করলাম: একটি স্থির init file ও listener entry সহ প্রস্তুত একটি auxiliary, একটি backup-based duplicate যাতে অফিস-সময়ে production কখনও load না হয়, path-এর পার্থক্য সামলাতে DB_FILE_NAME_CONVERT, এবং একটি clone-পরবর্তী স্ক্রিপ্ট যা গ্রাহকের ডেটা mask করে ও outbound email বন্ধ করে। যা ছিল একটি স্নায়ুক্ষয়ী, পুরো-দিনের হাতে-করা কাজ, তা হয়ে গেল একটি স্ক্রিপ্টেড, কয়েক-ঘণ্টার কাজ এবং একটি সঙ্গতিপূর্ণ ফলাফল - আর যেহেতু এটি backup থেকে পড়ত, production কখনও তা টের পেত না। এটি সেই একই RMAN ভিত্তির ওপর দাঁড়িয়ে যা ব্যবসাকে রক্ষা করে, এবং একটি ভালো recovery কৌশল-এর পরিপূরক।

১১. ছোট Host-এ Clone করা: Memory, SET NEWNAME এবং NOOPEN

আমাকে সবচেয়ে বেশি যে প্রশ্নটি করা হয় তা duplicate কীভাবে করব সেটি নয় - প্রশ্নটি হলো, 100 GB SGA-সহ 2 TB-র একটি production ডেটাবেজকে 32 GB RAM আর অর্ধেক ডিস্কওয়ালা একটি dev মেশিনে কীভাবে আঁটাব। উত্তর হলো, clone-এর production-এর parameter দরকার নেই, এবং DUPLICATE আপনাকে সেগুলো inline-এই override করতে দেয়।

DUPLICATE TARGET DATABASE TO TESTDB
  FROM ACTIVE DATABASE
  SPFILE
    SET sga_target '8G'
    SET pga_aggregate_target '2G'
    SET db_recovery_file_dest_size '50G'
  SKIP TABLESPACE hist2022, hist2023, audit_archive
  DB_FILE_NAME_CONVERT '/oradata/PRODDB/','/u01/oradata/TESTDB/';

SPFILE clause-এর নিচের প্রতিটি SET clone-এর spfile-এ production-এর মানটিকে override করে। আমি সবসময় memory target গুলো ছোট করি, recovery area-র সীমা বেঁধে দিই, এবং diagnostic ও audit destination গুলোকে এমন path-এ নির্দেশ করি যা ছোট host-টিতে সত্যিই বিদ্যমান।

SKIP TABLESPACE হলো ডিস্ক বাঁচানোর হাতিয়ার, তবে কিছু নিয়মসহ: আপনি SYSTEM, SYSAUX, undo, বা SYS-এর মালিকানাধীন segment ধারণকারী কোনো tablespace বাদ দিতে পারবেন না, এবং বাদ দেওয়া ডেটাকে reference করা কোড আপনি পরিষ্কার না করা পর্যন্ত error দেবে। সেখানে আসলে কী আছে তা আমি আগে দেখে নিই:

-- What am I really leaving behind if I skip these?
SELECT owner, segment_type, COUNT(*) segs,
       ROUND(SUM(bytes)/1024/1024/1024) gb
FROM dba_segments
WHERE tablespace_name IN ('HIST2022','HIST2023')
GROUP BY owner, segment_type;

যখন একটি বিশাল datafile-এর নিজস্ব mount point দরকার হয়, তখন SET NEWNAME ব্যতিক্রমটি সামলায় আর একটি database-স্তরের নিয়ম বাকি সব কিছু কভার করে - %b মূল ফাইলের নাম ধরে রাখে:

RUN {
  SET NEWNAME FOR DATABASE TO '/u01/oradata/TESTDB/%b';
  SET NEWNAME FOR DATAFILE 14 TO '/u03/big/TESTDB/sales_data01.dbf';
  DUPLICATE TARGET DATABASE TO TESTDB FROM ACTIVE DATABASE;
}

আর যে কৌশলটি খুব কম মানুষ ব্যবহার করে: NOOPEN যোগ করুন, তাহলে DUPLICATE শেষ হয় clone-কে mount করা কিন্তু open না-করা অবস্থায় রেখে। এতে প্রথম OPEN RESETLOGS-এর আগে আপনি parameter সমন্বয় করার, অতিরিক্ত বড় redo group ছোট করা বা বাদ দেওয়ার, কিংবা restricted session চালু করার একটি সুযোগ পান। clone-টিকে যখনই বধির ও নিঃশব্দ অবস্থায় উঠতে হবে তখনই আমি এটি ব্যবহার করি - যা আমাকে নিচের checklist-এ নিয়ে যায়।

১২. আমার Clone-পরবর্তী Hygiene Checklist

এটি আমি কঠিনভাবে শিখেছি। বছর কয়েক আগে সদ্য clone করা একটি test ডেটাবেজ জেগে উঠে দেখল তার scheduler job গুলো এখনও enabled, এবং আমাদের cleanup স্ক্রিপ্ট চলার আগেই প্রকৃত গ্রাহকদের কাছে এক দফা payment-reminder SMS পাঠিয়ে দিল। সেদিন থেকে job_queue_processes=0 সরাসরি auxiliary init file-এর মধ্যেই যায়, যাতে clone-টি scheduler বন্ধ অবস্থাতেই open হয়।

এটি open হওয়ার পর, প্রতিবার একই চারটি পদক্ষেপ, এই ক্রমে:

-- 1. Break production database links
SELECT db_link, host FROM dba_db_links;
DROP PUBLIC DATABASE LINK erp_prod_link;

-- 2. Review and disable jobs BEFORE re-enabling the scheduler
SELECT owner, job_name FROM dba_scheduler_jobs WHERE enabled='TRUE';
EXEC DBMS_SCHEDULER.DISABLE('APP.NIGHTLY_INVOICE_PUSH');

-- 3. Point outbound mail at a sinkhole, not the real relay
ALTER SYSTEM SET smtp_out_server='localhost:2500' SCOPE=BOTH;

-- 4. Reset application and personal passwords
ALTER USER app_admin IDENTIFIED BY "DevOnly#2026";

তারপর খোদ ডেটা: প্রথম টেস্টার login করার আগেই ব্যক্তিগত ও আর্থিক column গুলো mask করুন, এবং production বলে ভুল হতে পারে এমন সব কিছু rename করুন - global name, console banner, এমনকি SQL*Plus prompt-ও। আঠারো বছরে কেউ কখনও অভিযোগ করেনি যে একটি test ডেটাবেজকে বড্ড স্পষ্টভাবে test ডেটাবেজের মতো দেখাচ্ছে।

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

RMAN DUPLICATE কী করে?

RMAN DUPLICATE একটি মাত্র কমান্ড থেকে একটি ডেটাবেজের সম্পূর্ণ, কার্যক্ষম কপি তৈরি করে। এটি datafile গুলো restore বা কপি করে, একটি নতুন control file বানায়, ফাইলগুলোকে নতুন অবস্থানে rename করে এবং clone-টি একটি নতুন DBID দিয়ে open করে - হাতে হাতে ফাইল restore ও rename করার ধীর, ভুলপ্রবণ প্রক্রিয়া এড়িয়ে। test/UAT refresh, reporting copy, standby এবং migration-এর জন্য এটি ব্যবহৃত হয়।

active এবং backup-based duplication-এর মধ্যে পার্থক্য কী?

Active duplication চলমান source থেকে network-এর মাধ্যমে সরাসরি datafile কপি করে, কোনো বিদ্যমান backup লাগে না তবে source-এর ওপর load ফেলে। Backup-based duplication বিদ্যমান RMAN backup থেকে clone তৈরি করে, live source-কে স্পর্শ না করেই, যা ব্যস্ত production সিস্টেমের জন্য বেশি সদয়। backup না থাকলে সবচেয়ে তাজা কপির জন্য active বেছে নিন, আর production-এ load এড়াতে backup-based।

DUPLICATE চালানোর আগে আমাকে কী সেটআপ করতে হবে?

আপনি auxiliary instance প্রস্তুত করেন: একটি ন্যূনতম init parameter file, একটি password file, clone-এর datafile ও recovery area-র জন্য directory, এবং একটি static listener/TNS entry। auxiliary-কে NOMOUNT অবস্থায় start করতে হবে। এরপর RMAN source (target) এবং auxiliary উভয়ের সাথে connect করে এবং তাতে clone তৈরি করে।

clone করা ফাইলগুলো ভিন্ন directory-তে কীভাবে রাখব?

source path গুলোকে একসাথে clone-এর path-এ পুনর্লিখনের জন্য DB_FILE_NAME_CONVERT ও LOG_FILE_NAME_CONVERT ব্যবহার করুন, আর একটি নির্দিষ্ট ফাইলকে সুনির্দিষ্টভাবে রাখতে SET NEWNAME। যদি source-এর মতোই একই path ব্যবহার করে ভিন্ন সার্ভারে duplicate করেন, তবে NOFILENAMECHECK যোগ করুন যাতে মিলে যাওয়া নাম নিয়ে RMAN আপত্তি না করে।

production-কে test environment-এ clone করা কি নিরাপদ?

প্রযুক্তিগতভাবে হ্যাঁ, তবে clone-এ প্রকৃত production ডেটা থাকে, তাই ব্যবহারের আগে তা সুরক্ষিত করতে হবে। ব্যক্তিগত ও আর্থিক ডেটা mask বা scramble করুন, outbound integration ও email বন্ধ করুন যাতে clone প্রকৃত গ্রাহকের সাথে যোগাযোগ করতে না পারে, এবং credential reset করুন। ফার্মা বা ব্যাংকিংয়ের মতো নিয়ন্ত্রিত ডেটার ক্ষেত্রে এই ডেটা-প্রাইভেসি ধাপটি একটি কমপ্লায়েন্স বাধ্যবাধকতা।