Oracle 19c Data Guard: সম্পূর্ণ ডিজাস্টার রিকভারি গাইড

২০২৩ সালে আমার এক ফার্মা ক্লায়েন্টের প্রাইমারি ডেটা সেন্টার ভয়াবহ বন্যায় ডুবে গেলে পুরো ব্যবসা অনলাইনেই টিকে ছিল — কারণ দুর্যোগ আঘাত হানার তিন বছর আগে থেকেই Data Guard নীরবে তার কাজ করে যাচ্ছিল। Oracle Data Guard-ই ব্যবসার ধারাবাহিকতা আর ব্যবসার ধস — এই দুইয়ের মধ্যে পার্থক্য গড়ে দেয়। এই গাইডে বাস্তব ডিজাস্টার রিকভারির জন্য Oracle 19c Data Guard আর্কিটেক্ট, ডিপ্লয় ও পরিচালনা করতে যা যা দরকার, সবই ভাগ করে নেব।

১. Oracle Data Guard কী?

Oracle Data Guard হলো Oracle Database Enterprise Edition-এর একটি ফিচার, যা এক বা একাধিক standby ডেটাবেজ-কে প্রাইমারি ডেটাবেজের ট্রানজ্যাকশনালি-কনসিস্টেন্ট কপি হিসেবে বজায় রাখে। প্রাইমারি থেকে নেটওয়ার্কের মাধ্যমে redo ডেটা পাঠিয়ে standby-কে অবিরত হালনাগাদ করা হয়। প্রাইমারি বিকল হলে standby সক্রিয় হয়ে যায় — ফলে ডেটা হারানো ও ডাউনটাইম কমে আসে।

মূল ধারণাটি: RAC রক্ষা করে node ফেইলিওর থেকে। Data Guard রক্ষা করে সাইট/ডেটা-সেন্টার ফেইলিওর থেকে।

২. কেন Data Guard আপনার একেবারেই দরকার

• ডিজাস্টার রিকভারি: ডেটা সেন্টারের আগুন, বন্যা, র‌্যানসমওয়্যার, আঞ্চলিক আউটেজ থেকে টিকে থাকা
• ডেটা সুরক্ষা: এমন লজিক্যাল করাপশন থেকে পুনরুদ্ধার যা ব্যাকআপ কেবল ঢেকে রাখত
• হাই অ্যাভেইলেবিলিটি: এক মিনিটেরও কম সময়ে failover ক্ষমতা
• রিপোর্টিং অফলোড: Active Data Guard standby-তে read-only কোয়েরি চালাতে দেয় — primary-র ওপর চাপ কমায়
• মাইগ্রেশন: সামান্য ডাউনটাইমে প্ল্যাটফর্ম/ডেটা সেন্টার জুড়ে ডেটাবেজ স্থানান্তর
• রোলিং আপগ্রেড: transient logical standby প্রায়-শূন্য-ডাউনটাইমে ভার্সন আপগ্রেড সম্ভব করে

৩. Standby ডেটাবেজের ধরন

৩.১ Physical Standby

প্রাইমারির হুবহু ব্লক-বাই-ব্লক কপি। redo ডেটা প্রয়োগ করতে Redo Apply (Managed Recovery Process - MRP) ব্যবহার করে। সবচেয়ে প্রচলিত ধরন। একই schema, একই ডেটা, failover-এর জন্য প্রস্তুত।

৩.২ Logical Standby

redo-কে SQL স্টেটমেন্টে রূপান্তর করে তা চালাতে SQL Apply (LogMiner-ভিত্তিক) ব্যবহার করে। অতিরিক্ত index, materialized view, এমনকি কিছু schema পরিবর্তনও অনুমোদন করে। Data Guard যে অবজেক্টগুলো রক্ষণাবেক্ষণ করে না, সেগুলোর জন্য read/write-এ খোলা থাকে। রিপোর্টিং + নির্বাচিত রেপ্লিকেশনে ব্যবহৃত।

৩.৩ Snapshot Standby

টেস্টিংয়ের জন্য সাময়িকভাবে read/write-এ রূপান্তরিত একটি physical standby। redo গ্রহণ করে কিন্তু প্রয়োগ করে না। যেকোনো সময় আবার physical standby-তে ফিরিয়ে নেওয়া যায় — সব টেস্ট পরিবর্তন বাতিল হয়ে যায়। প্রোডাকশন-টাটকা ডেটার বিপরীতে QA/UAT-এর জন্য চমৎকার।

৩.৪ Active Data Guard (পেইড অপশন)

একটি physical standby যা redo গ্রহণ ও প্রয়োগ চালিয়ে যাওয়ার পাশাপাশি read-only মোডে খোলা থাকে। রিপোর্টিং ওয়ার্কলোড অফলোড করার জন্য গেম-চেঞ্জার। আরও সম্ভব করে: standby block change tracking, real-time query, automatic block repair, Far Sync ইনস্ট্যান্স।

৪. Data Guard Protection Mode

ডেটা হারানো বনাম পারফরম্যান্সে আপনার সহনশীলতা অনুযায়ী বেছে নিন:

৪.১ Maximum Performance (ডিফল্ট)

• redo asynchronously পাঠানো হয় (ASYNC)
• standby-র স্বীকৃতি আসার আগেই primary commit করে
• দুর্যোগে সামান্য ডেটা হারানোর সম্ভাবনা (কয়েক সেকেন্ড)
• primary-র পারফরম্যান্সে কোনো প্রভাব নেই
• যার জন্য সেরা: অধিকাংশ প্রোডাকশন ওয়ার্কলোড

৪.২ Maximum Availability

• redo synchronously পাঠানো হয় (SYNC)
• commit-এর আগে primary standby-র স্বীকৃতির জন্য অপেক্ষা করে
• standby sync-এ থাকলে শূন্য ডেটা লস
• standby অনুপলব্ধ হলে primary চলতে থাকে (সাময়িকভাবে MAX PERFORMANCE-এ নেমে আসে)
• যার জন্য সেরা: শূন্য ডেটা লস প্রয়োজন এমন ফিনান্সিয়াল/নিয়ন্ত্রিত ওয়ার্কলোড

৪.৩ Maximum Protection

• Synchronous + কঠোর
• standby অনুপলব্ধ হলে কোনো ডেটা হারানো ঠেকাতে primary বন্ধ হয়ে যায়
• খুব কমই ব্যবহৃত — অপারেশনাল ঝুঁকি অতিরিক্ত বেশি
• যার জন্য সেরা: ডিফেন্স/নিয়ন্ত্রিত পরিবেশ যেখানে যেকোনো মূল্যে ডেটা হারানো অগ্রহণযোগ্য

৫. Data Guard আর্কিটেকচার

মূল প্রসেসগুলো:

• LGWR (Primary): লোকাল redo log-এ redo লেখে
• LNS (Network Server): standby-তে redo পাঠায় (SYNC বা ASYNC)
• RFS (Remote File Server): standby-তে redo গ্রহণ করে
• Standby Redo Logs (SRL): RFS যেখানে আগত redo লেখে
• MRP (Managed Recovery Process): physical standby-তে redo প্রয়োগ করে
• FSFO Observer: স্বয়ংক্রিয় failover-এর জন্য বাহ্যিক মনিটর

৬. Data Guard সেটআপ — ধাপে ধাপে

একটি physical standby যোগ করার উচ্চ-পর্যায়ের পদ্ধতি:

৬.১ প্রস্তুতি

1. primary-তে archivelog mode চালু করুন: ALTER DATABASE ARCHIVELOG;
2. forced logging চালু করুন: ALTER DATABASE FORCE LOGGING;
3. standby redo log তৈরি করুন (online redo log গ্রুপের চেয়ে একটি বেশি)
4. primary প্যারামিটার সেট করুন: DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, LOG_ARCHIVE_DEST_2, FAL_SERVER, STANDBY_FILE_MANAGEMENT
5. উভয় সার্ভারে TNS এন্ট্রি কনফিগার করুন
6. password file standby-তে কপি করুন

৬.২ Physical Standby তৈরি করুন (RMAN Duplicate)

rman target sys/password@PRIMARY auxiliary sys/password@STANDBY

DUPLICATE TARGET DATABASE FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER
  SPFILE
  NOFILENAMECHECK;

৬.৩ Managed Recovery শুরু করুন

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  USING CURRENT LOGFILE DISCONNECT FROM SESSION;

৬.৪ Sync যাচাই করুন

-- On primary
SELECT thread#, max(sequence#) FROM v$archived_log GROUP BY thread#;

-- On standby
SELECT thread#, max(sequence#) FROM v$archived_log
WHERE applied='YES' GROUP BY thread#;

-- Apply lag (Active DG)
SELECT name, value, time_computed FROM v$dataguard_stats;

৭. Data Guard Broker — এটি ব্যবহার করুন!

Data Guard Broker (DGMGRL) হলো ম্যানেজমেন্ট ফ্রেমওয়ার্ক। সবসময় এটি কনফিগার করুন। এটি switchover সহজ করে, স্বাস্থ্য মনিটর করে, protection mode ব্যবস্থাপনা করে এবং fast-start failover সম্ভব করে। প্রাথমিক সেটআপের পর:

dgmgrl sys/password
DGMGRL> CREATE CONFIGURATION 'DG_CONFIG'
        AS PRIMARY DATABASE IS 'PROD'
        CONNECT IDENTIFIER IS 'PROD';
DGMGRL> ADD DATABASE 'PROD_DR' AS
        CONNECT IDENTIFIER IS 'PROD_DR' MAINTAINED AS PHYSICAL;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> SHOW CONFIGURATION;

৮. Switchover বনাম Failover — পার্থক্যটা জানুন

Switchover (পরিকল্পিত)

• সুশৃঙ্খল role reversal: primary হয়ে যায় standby, standby হয়ে যায় primary
• শূন্য ডেটা লস
• পরিকল্পিত রক্ষণাবেক্ষণ, DR টেস্টিং, ডেটা সেন্টার স্থানান্তরে ব্যবহৃত
• কমান্ড: DGMGRL> SWITCHOVER TO 'PROD_DR';

Failover (অপরিকল্পিত)

• primary হারিয়ে গেছে — standby-কে primary-তে উন্নীত করুন
• protection mode অনুযায়ী ডেটা হারানোর সম্ভাবনা
• পুরনো primary-কে নতুন standby হিসেবে পুনঃস্থাপন করতে হবে (flashback database সাহায্য করে)
• কমান্ড: DGMGRL> FAILOVER TO 'PROD_DR';

Fast-Start Failover (FSFO)

বাহ্যিক Observer প্রসেস দ্বারা ট্রিগার হওয়া স্বয়ংক্রিয় failover। সমন্বয়যোগ্য থ্রেশহোল্ড (ডিফল্ট ৩০ সেকেন্ড)। সেরা চর্চা: Observer-কে primary বা standby-তে নয়, একটি তৃতীয় সাইটে চালান।

৯. Active Data Guard-এর ব্যবহার

• রিপোর্টিং অফলোড: standby-তে অ্যানালিটিক্স চালান, primary-কে OLTP-র জন্য মুক্ত রাখুন
• Real-time query: ETL/ড্যাশবোর্ড standby থেকে টাটকা ডেটা পড়ে
• Automatic block repair: primary-র করাপ্ট ব্লক standby থেকে স্বয়ংক্রিয়ভাবে আনা হয়
• standby থেকে RMAN ব্যাকআপ: primary-র ওপর I/O লোড কমায়
• DML redirection (19c+): standby-তে সীমিত DML স্বয়ংক্রিয়ভাবে primary-তে ফরোয়ার্ড হয়

১০. Data Guard স্বাস্থ্য মনিটরিং

প্রতিদিন চালানোর মতো গুরুত্বপূর্ণ কোয়েরি:

-- Transport lag
SELECT name, value FROM v$dataguard_stats
WHERE name IN ('transport lag', 'apply lag', 'apply finish time');

-- MRP status
SELECT process, status, sequence# FROM v$managed_standby
WHERE process='MRP0';

-- Gap check
SELECT * FROM v$archive_gap;

-- Broker status
DGMGRL> SHOW CONFIGURATION VERBOSE;
DGMGRL> SHOW DATABASE 'PROD_DR' STATUSREPORT;

১১. বাস্তব প্রোডাকশন থেকে Data Guard সেরা চর্চা

• Data Guard Broker ব্যবহার করুন। ম্যানুয়ালি প্যারামিটার ব্যবস্থাপনা ভুলপ্রবণ।
• Standby Redo Logs (SRL) কনফিগার করুন — primary-র চেয়ে একটি বেশি গ্রুপ, একই আকার।
• DB_UNIQUE_NAME আলাদা রাখুন প্রতিটি সদস্যে (যেমন PROD, PROD_DR)।
• SCAN/Service কানেকশন ব্যবহার করুন TNS এন্ট্রিতে নির্দিষ্ট IP নয়।
• Flashback Database চালু করুন — failover-এর পর পুনঃস্থাপনের জন্য অপরিহার্য।
• প্রতি ত্রৈমাসিকে DR ড্রিল পরীক্ষা করুন। কখনও অনুশীলন না করা failover মানে এমন failover যা কাজ করে না।
• lag অবিরত মনিটর করুন — apply lag ৫ মিনিটের বেশি হলে অ্যালার্ট দিন।
• WAN-এর ওপর redo-তে compression ব্যবহার করুন: LOG_ARCHIVE_DEST_2-এ compression=enable।
• রিকভারি পদ্ধতি নথিবদ্ধ করুন — failover/switchover-এর হুবহু কমান্ডসহ রানবুক।
• Far Sync ইনস্ট্যান্স দীর্ঘ দূরত্ব জুড়ে শূন্য-ডেটা-লসের জন্য (হালকা redo রিসিভার)।

১২. সাধারণ সমস্যা ও সমাধান

• Apply lag বাড়ছে: standby I/O, MRP প্রসেস, নেটওয়ার্ক ব্যান্ডউইথ পরীক্ষা করুন। parallel apply slave বাড়ান।
• Archive gap: FAL_SERVER কনফিগার করা আছে কিনা যাচাই করুন। ম্যানুয়াল রিকভারিতে ALTER DATABASE REGISTER LOGFILE ব্যবহার করুন।
• ORA-16957 (apply lag exceeded): নেটওয়ার্ক বা standby পারফরম্যান্স সমস্যা।
• primary রিস্টার্টের পর standby out of sync: incremental backup-from-SCN বা full duplicate দিয়ে পুনরায় sync করুন।
• FSFO ট্রিগার হচ্ছে না: Observer চলছে কিনা, থ্রেশহোল্ড কনফিগার করা আছে কিনা, FastStartFailoverThreshold সঠিকভাবে সেট আছে কিনা পরীক্ষা করুন।

১৩. Data Guard + RAC = Maximum Availability Architecture

মিশন-ক্রিটিক্যাল সিস্টেমের জন্য RAC + Data Guard একসাথে ডিপ্লয় করুন। প্রাইমারি সাইট: HA-র জন্য ২-node RAC। DR সাইট: ২-node RAC standby (বা single instance)। Oracle এটিকেই বলে MAA — Maximum Availability Architecture। এটি node ফেইলিওর, সাইট ফেইলিওর, এমনকি একযোগে ঘটা ফেইলিওর থেকেও টিকে থাকে।

শেষ কথা

Data Guard কোনো ঐচ্ছিক অবকাঠামো নয় — এটি বেঁচে থাকার অবকাঠামো। Data Guard ডিপ্লয় করার সঠিক সময় হলো প্রয়োজন পড়ার আগেই। যেসব প্রতিষ্ঠানের সাথে আমি কাজ করেছি, দুর্যোগ আঘাত হানার সময় যাদের Data Guard বসানো ছিল, তারা সবাই একে তাদের করা সেরা প্রযুক্তি বিনিয়োগ হিসেবে দেখে। আর যাদের ছিল না... তাদের গল্প আমি আর নতুন করে বলব না।

আপনার যদি একটি Oracle 19c Data Guard কনফিগারেশন ডিজাইন, ডিপ্লয় বা পরীক্ষা করতে সাহায্য দরকার হয় — single-instance, RAC, কিংবা পূর্ণ MAA টপোলজি যাই হোক — আমি সাহায্য করতে প্রস্তুত। আমি ব্যাংক, ফার্মা, সফটওয়্যার ফার্ম ও ট্রেডিং হাউসের জন্য Data Guard আর্কিটেক্ট করেছি, এবং ক্লায়েন্টদের পরিকল্পিত switchover ও বাস্তব ফেইলিওর — উভয়ের মধ্য দিয়েই পথ দেখিয়েছি। Data Guard-কে গুরুত্ব দিতে কোনো দুর্যোগের জন্য অপেক্ষা করবেন না।

সম্পর্কিত লেখা