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 প্রায়-শূন্য-ডাউনটাইমে ভার্সন আপগ্রেড সম্ভব করে

প্রতিটি ক্লায়েন্টকে আমি একটি কথা বলি: Data Guard কখনও RMAN ব্যাকআপের বিকল্প নয়। কোনো ডেভেলপার ভুল টেবিল truncate করলে Data Guard সেই truncate কয়েক সেকেন্ডের মধ্যেই standby-তে পাঠিয়ে দেয় — ভুলটিকে বিশ্বস্তভাবে রেপ্লিকেট করে। ব্যাকআপ আপনাকে সময়ে পিছিয়ে যেতে দেয়; Data Guard আপনাকে একটি ভবন হারিয়েও টিকে থাকতে দেয়। দুটোই দরকার।

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

৩.১ Physical Standby

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

১৮+ বছরে আমার সব Data Guard কাজের সম্ভবত ৯০ শতাংশেই আমি physical standby ডিপ্লয় করেছি। এটিই দ্রুততম apply মেকানিজম, সব datatype সমর্থন করে, আর failover-এর মুহূর্তে ভাবার কিছুই থাকে না — standby-টিই তখন ব্লকে-ব্লকে হুবহু primary।

৩.২ Logical Standby

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

খোলাখুলি মতামত: logical standby আজকাল আমি খুব কমই সুপারিশ করি। SQL Apply-এর datatype-এর সীমাবদ্ধতা আছে, ভারী DML-এর নিচে পিছিয়ে পড়ে, আর একে বসে বসে দেখভাল করতে হয়। যেহেতু রিপোর্টিংয়ের প্রয়োজন Active Data Guard মেটায় আর নির্বাচিত রেপ্লিকেশন GoldenGate সামলায়, logical standby টিকে আছে মূলত রোলিং আপগ্রেডের বাহন হিসেবেই।

৩.৩ Snapshot Standby

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

এটি যতটা ব্যবহৃত হওয়া উচিত, তার চেয়ে কম হয়। একটিমাত্র কমান্ডে (dgmgrl-এ CONVERT DATABASE ... TO SNAPSHOT STANDBY) আপনার টেস্টাররা পেয়ে যায় পূর্ণ আকারের, প্রোডাকশন-টাটকা একটি ডেটাবেজ, আর আরেকটি কমান্ডে আপনার DR সুরক্ষা ফিরে আসে। একটাই সতর্কতা: snapshot standby থাকা অবস্থায় redo জমা হয় কিন্তু প্রয়োগ হয় না — টেস্টিংয়ের প্রতিটি ঘণ্টার সাথে ফিরে আসার পরের রিকভারি সময়ও বাড়তে থাকে।

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

একটি physical standby যা redo গ্রহণ ও প্রয়োগ চালিয়ে যাওয়ার পাশাপাশি read-only মোডে খোলা থাকে। দামি DR সার্ভারকে প্রতিদিন তার খরচ উসুল করানোর উপায় এটিই — রিপোর্টিং, ETL এক্সট্র্যাক্ট আর read-ভারী ড্যাশবোর্ড primary থেকে সরে আসে। আরও সম্ভব করে: 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 বন্ধ হয়ে যায়
• খুব কমই ব্যবহৃত — অপারেশনাল ঝুঁকি অতিরিক্ত বেশি
• যার জন্য সেরা: ডিফেন্স/নিয়ন্ত্রিত পরিবেশ যেখানে যেকোনো মূল্যে ডেটা হারানো অগ্রহণযোগ্য

৪.৪ আমি আসলে যেভাবে বেছে নিই

বছরের পর বছর এই আলোচনার পর আমার সহজ নিয়ম: প্রথমে ব্যবসাকে জিজ্ঞেস করুন, "কত সেকেন্ডের committed ট্রানজ্যাকশন হারানো আপনার সহ্য হবে?" সৎ উত্তর যদি হয় "কয়েক সেকেন্ড চলবে," তাহলে Maximum Performance নিন এবং commit latency-তে শূন্য প্রভাব উপভোগ করুন।

যেসব ব্যাংকের সাথে আমি কাজ করেছি, তাদের উত্তর শূন্য — নিয়ন্ত্রকরা তা-ই বলে। এর মানে SYNC transport-সহ Maximum Availability, আর এর মানে standby-কে এত কাছে থাকতে হবে যেন round-trip time commit latency নষ্ট না করে। আমার কাজের সীমা মোটামুটি ৫ ms RTT; এর বাইরে গেলে Far Sync দেখুন।

Maximum Protection আমি আমার ক্যারিয়ারে ঠিক একবারই কনফিগার করেছি, এবং ক্লায়েন্ট এক বছরের মধ্যে তা নামিয়ে এনেছিল। WAN লিংক একটু নড়ে উঠলেই যে primary নিজেই বন্ধ হয়ে যায়, তা সাধারণত কয়েক সেকেন্ডের সম্ভাব্য ডেটা লসের চেয়ে বড় ব্যবসায়িক ঝুঁকি। জেনে রাখুন এটি আছে; ব্যবহারের আগে খুব ভালো করে ভাবুন।

৪.৫ Redo Transport: বাস্তবে SYNC বনাম ASYNC

Protection mode আসলে transport mode-এর ওপর দাঁড়ানো একটি চুক্তি। ASYNC-এ LNS প্রসেস redo পড়ে ইউজারের commit আটকে না রেখেই পাঠিয়ে দেয়। SYNC-এ commit অপেক্ষা করে যতক্ষণ না standby-র RFS প্রসেস নিশ্চিত করে যে redo standby redo log-এ পৌঁছেছে — আপনি আক্ষরিক অর্থেই প্রতিটি commit-এ নেটওয়ার্ক latency-র দাম দিচ্ছেন।

destination-এ দুটি attribute আমি সবসময় স্পষ্ট করে সেট করি:

-- Primary: SYNC with a sane timeout, or ASYNC for Max Performance
ALTER SYSTEM SET log_archive_dest_2=
  'SERVICE=PROD_DR SYNC NET_TIMEOUT=15
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=PROD_DR' SCOPE=BOTH;

-- Confirm transport is healthy
SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id=2;

NET_TIMEOUT মানুষ যতটা ভাবে তার চেয়ে বেশি গুরুত্বপূর্ণ। ডিফল্ট ৩০ সেকেন্ড — অর্থাৎ SYNC mode-এ একটি মৃত standby, Oracle হাল ছাড়ার আগে, primary-র প্রতিটি commit ৩০ সেকেন্ড পর্যন্ত আটকে রাখতে পারে। অধিকাংশ সিস্টেমে আমি ১০–১৫ সেকেন্ড সেট করি। অন্যদিকে, WAN লিংকে redo compression চালু করুন; এটি আমার বেশ কয়েকজন ক্লায়েন্টকে ব্যান্ডউইথ আপগ্রেড থেকে বাঁচিয়েছে।

৫. 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-এর জন্য বাহ্যিক মনিটর

নতুনরা যে জিনিসটি মিস করে তা হলো standby redo log। এগুলো না থাকলে redo পৌঁছায় সম্পূর্ণ archive log হিসেবে — অর্থাৎ standby সবসময় অন্তত এক log switch পিছিয়ে, আর real-time apply অসম্ভব। SRL থাকলে RFS আগত redo আসামাত্র লিখে ফেলে এবং MRP সরাসরি SRL থেকে প্রয়োগ করে। সবসময় তৈরি করুন, সবসময় primary-র চেয়ে এক গ্রুপ বেশি, সবসময় একই আকারে।

৬. 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;

আমি সবসময় এমনটা ভাবতাম না। ক্যারিয়ারের শুরুতে আমি Data Guard হাতে-হাতে চালাতাম — primary-তে LOG_ARCHIVE_DEST_2, standby-তে FAL_SERVER, আর switchover-এর ধাপগুলোর একটি টেক্সট ফাইল। এতে কাজ চলে, আর এতে অভ্যন্তরীণ ব্যাপারগুলোও শেখা হয়। কিন্তু এভাবেই একদিন দেখা যায়, কারও এক মধ্যরাতের পরিবর্তনের পর standby-র প্যারামিটার নিঃশব্দে primary-র থেকে সরে গেছে।

Broker সেই যুগের অবসান ঘটায়। এটি দুই পক্ষের কনফিগারেশন সামঞ্জস্যপূর্ণ রাখে, পূর্বশর্ত পূরণ না হলে switchover প্রত্যাখ্যান করে, আর পনেরো ধাপের ম্যানুয়াল role change-কে বানিয়ে দেয় SWITCHOVER TO 'PROD_DR';। 19c থেকে VALIDATE DATABASE হলো পুরো প্রোডাক্টের সবচেয়ে দরকারি প্রি-ফ্লাইট চেক:

DGMGRL> VALIDATE DATABASE 'PROD_DR';
-- Checks: ready for switchover?, SRLs present, flashback on,
-- redo transport healthy, apply lag, temp files matching

এই কমান্ড দুটি ডেটাবেজেই "Ready for Switchover: Yes" দেখালে আপনার role change প্রায় নিশ্চিতভাবেই সফল হবে। এই লেখা থেকে একটিমাত্র অভ্যাস নিতে চাইলে, এটি প্রতি সপ্তাহে চালান।

৮. 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-তে নয়, একটি তৃতীয় সাইটে চালান।

দুটি অপারেশনেরই হুবহু কমান্ড সিকোয়েন্স — প্রতিটি ধাপে যাচাইয়ের কোয়েরিসহ — আমি আলাদা একটি লেখায় রেখেছি: Oracle Data Guard switchover ও failover: ধাপে ধাপে রানবুক। সেটিকে এই গাইডের সঙ্গী হিসেবে দেখুন।

একটি Switchover মহড়া যা তার দাম উসুল করেছিল

ঢাকার আমার এক ব্যাংকিং ক্লায়েন্ট দুই বছর ধরে Data Guard চালাচ্ছিল, একটিও role change ছাড়াই। কাগজে-কলমে: নিখুঁত DR। তাদের বার্ষিক অডিটের আগে আমি একটি মহড়ার জন্য জোর দিলাম — batch close-এর পর এক শুক্রবার রাতে সময় ধরা হলো।

প্রথম চেষ্টাটি দুই মিনিটের মধ্যেই ব্যর্থ হলো। VALIDATE DATABASE ধরিয়ে দিল যে মাসখানেক আগে primary RAC-এ যাওয়ার সময় যোগ হওয়া একটি redo thread-এর জন্য standby-তে standby redo log নেই — standby-তে কেউ হাতই দেয়নি। এরপর দেখা গেল অ্যাপ্লিকেশনের TNS এন্ট্রিগুলো role-based service নয়, primary-র ফিজিক্যাল hostname-এর দিকে তাক করা — অর্থাৎ switchover সফল হলেও প্রতিটি app সার্ভার এমন একটি ডেটাবেজে কানেক্ট করত, যা তখন standby।

শান্ত, পরিকল্পিত একটি উইন্ডোতে দুটি সমস্যাই এক ঘণ্টার কমে ঠিক হয়ে গেল। সত্যিকারের দুর্যোগে, রাত ৩টায়, ম্যানেজমেন্ট ফোনে — এই দুটি সমস্যাই আউটেজে ঘণ্টার পর ঘণ্টা যোগ করত। সেই রাতটিই ক্লায়েন্টকে "DR ড্রিল একটি আনুষ্ঠানিকতা" থেকে প্রতি ত্রৈমাসিকে ড্রিল চালানোয় নিয়ে এলো। আমরা যে মহড়ার চেকলিস্টে থিতু হয়েছিলাম, সেটি এই:

1. এক সপ্তাহ আগে: দুটি ডেটাবেজেই VALIDATE DATABASE চালান; শুধু error নয়, প্রতিটি warning ঠিক করুন।
2. lag প্রায় শূন্য নিশ্চিত করুন: v$dataguard_stats দেখুন — transport ও apply lag দুটোই সেকেন্ডের ঘরে।
3. অ্যাপ্লিকেশন কানেক্টিভিটি ডিজাইন যাচাই করুন: TNS/JDBC-কে অবশ্যই এমন role-based service ব্যবহার করতে হবে যা primary-কে অনুসরণ করে — কখনও নির্দিষ্ট host নয়।
4. "আগের" অবস্থার স্ন্যাপশট নিন: দুই পাশেই প্রতিটি thread-এর বর্তমান sequence নম্বর লিখে রাখুন।
5. Broker দিয়ে switchover চালান: SWITCHOVER TO 'PROD_DR'; — এবং স্টপওয়াচে সময় মাপুন।
6. বিজনেস স্মোক টেস্ট চালান: অ্যাপ্লিকেশন টিম লগইন করবে, সত্যিকারের একটি ট্রানজ্যাকশন পোস্ট করবে, একটি রিপোর্ট চালাবে — লিখিত সাইন-অফ।
7. উল্টানো ভূমিকায় নির্দিষ্ট সময় চালান (আস্থা বাড়ার পর আমরা পুরো এক কর্মদিবসে থিতু হয়েছিলাম), তারপর আবার ফিরে যান।
8. পোস্টমর্টেম লিখুন: প্রকৃত সময়, প্রতিটি চমক আর রানবুকের সংশোধন — স্মৃতি টাটকা থাকতে থাকতেই।

আমাদের প্রথম মহড়ায় ডাউনটাইম ছিল ৪০ মিনিট। তৃতীয়টিতে তা ৮ মিনিটের নিচে। ওই সংখ্যাটিই — আর্কিটেকচার ডায়াগ্রাম নয় — অডিটররা দেখতে চেয়েছিল।

৯. 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-তে ফরোয়ার্ড হয়

আমার এক ফার্মা ক্লায়েন্ট প্রতিটি রেগুলেটরি batch-release রিপোর্ট Active Data Guard standby-র বিপরীতে চালাত। রিপোর্টগুলো সরানোর সপ্তাহেই primary-র OLTP latency দৃশ্যমানভাবে ভালো হলো, আর — CFO-র যে অংশটি পছন্দ হয়েছিল — DR সার্ভারটি অ্যাসেট রেজিস্টারে "শুধু বসে থাকা" মেশিন হওয়া বন্ধ করল। standby হার্ডওয়্যারের খরচ যেহেতু এমনিতেই দিচ্ছেন, Active DG প্রায়ই Oracle স্ট্যাকের সবচেয়ে সহজ লাইসেন্স আলোচনাটি।

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

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

-- Transport lag and apply lag (run on standby)
SELECT name, value, time_computed, datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag', 'apply finish time');

-- MRP status
SELECT process, status, thread#, sequence# FROM v$managed_standby
WHERE  process LIKE 'MRP%';

-- Gap check (rows returned = you have a problem)
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;

-- Last received vs last applied, per thread (standby)
SELECT thread#,
       MAX(sequence#) KEEP (DENSE_RANK LAST ORDER BY sequence#) latest,
       MAX(CASE WHEN applied='YES' THEN sequence# END) applied
FROM   v$archived_log GROUP BY thread#;

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

অভিজ্ঞতা থেকে দুটি পড়ার টিপস। প্রথমত, v$dataguard_stats-এ datum_time দেখুন — এটি বাসি হলে lag-এর সংখ্যাগুলোও বাসি, এবং standby রিপোর্টের চেয়েও খারাপ অবস্থায় থাকতে পারে। দ্বিতীয়ত, "transport lag" আর "apply lag" আলাদাভাবে বিগড়ায়: transport lag বাড়া মানে নেটওয়ার্ক বা primary-পাশের সমস্যা (redo পৌঁছাচ্ছে না); transport lag স্থির রেখে apply lag বাড়া মানে standby নিজেই তাল রাখতে পারছে না — standby-র I/O আর recovery parallelism দেখুন।

আমার স্থায়ী অ্যালার্ট থ্রেশহোল্ড: যেকোনো lag ২ মিনিটে warning, ৫ মিনিটে page। আর একটি স্ক্রিপ্ট যা কেবল নিশ্চিত করে MRP বেঁচে আছে — নতুন ক্লায়েন্টদের কাছে আমি যে সমস্যাটি সবচেয়ে বেশি পাই তা lag নয়, বরং এমন একটি apply প্রসেস যা তিন সপ্তাহ আগে নিঃশব্দে মারা গেছে, অথচ সবাই ধরে নিয়েছে standby হালনাগাদ আছে।

১১. বাস্তব প্রোডাকশন থেকে 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 সঠিকভাবে সেট আছে কিনা পরীক্ষা করুন।

দ্রুততম পথে gap সমাধান: SCN থেকে Roll-Forward

ছোট gap সাধারণত নিজেই সেরে যায় — FAL হারানো sequence-গুলো স্বয়ংক্রিয়ভাবে এনে নেয়, না পারলে আপনি archive log কপি করে ম্যানুয়ালি register করেন। যন্ত্রণাদায়ক ঘটনাটি হলো বড় gap: standby দিনের পর দিন বন্ধ ছিল আর primary ততদিনে দরকারি archive log-গুলো মুছে ফেলেছে। মাল্টি-টেরাবাইট ডেটাবেজে WAN-এর ওপর পুরো standby আবার বানাতে পুরো একটি দিন লেগে যেতে পারে।

দ্রুত পথটি হলো standby-র বর্তমান SCN থেকে একটি RMAN incremental backup:

-- 1. On standby: find where it stopped
SELECT current_scn FROM v$database;

-- 2. On primary: incremental backup from that SCN
RMAN> BACKUP INCREMENTAL FROM SCN 123456789
      DATABASE FORMAT '/backup/dg_roll_%U' TAG 'ROLLFWD';

-- 3. Ship files, catalog on standby, then:
RMAN> RECOVER DATABASE NOREDO;

-- 4. Refresh standby controlfile from primary, restart MRP

DR সাইটে স্টোরেজ ফেইলিওরের পর নয় দিন পিছিয়ে থাকা এক standby-তে আমি এই roll-forward ব্যবহার করেছি; ৪ TB পুনঃস্থাপনের বদলে incremental-টি ছিল ৬০ GB। মনে রাখুন, 18c থেকে RECOVER STANDBY DATABASE FROM SERVICE এই ধাপগুলোর অধিকাংশই নেটওয়ার্কের ওপর এক কমান্ডে স্বয়ংক্রিয় করে দেয় — আপনার পরিবেশে পরীক্ষা করে দেখার মতো। এই কৌশলের পূর্ণ RMAN দিকটি আছে আমার RMAN ব্যাকআপ ও রিকভারি গাইডে।

১৩. ভিন্ন স্টোরেজ বা ভিন্ন OS-এ Standby?

সংক্ষিপ্ত উত্তর: ভিন্ন স্টোরেজ চলবে, ভিন্ন OS বেশিরভাগ ক্ষেত্রেই চলবে না। Data Guard পাঠায় redo, স্টোরেজ ব্লক নয় — তাই primary চলতে পারে ASM-এ আর standby ফাইলসিস্টেমে, ভিন্ন ডিস্ক ভেন্ডরে, এমনকি ভিন্ন ফাইল লেআউটেও — পাথের পার্থক্য সামলান DB_FILE_NAME_CONVERT ও LOG_FILE_NAME_CONVERT দিয়ে, আর STANDBY_FILE_MANAGEMENT=AUTO সেট করুন যেন নতুন datafile স্বয়ংক্রিয়ভাবে তৈরি হয়।

আমি Exadata-য় primary চালিয়েছি, আর standby ছিল লোকাল ডিস্কের সাধারণ কমোডিটি সার্ভারে। এতে কাজ চলে, তবে একটি সৎ সতর্কতাসহ: failover-এর পর সেই সাদামাটা standby-টিই প্রোডাকশন। DR মেশিনটিকে সেই ওয়ার্কলোডের জন্য সাইজ করুন যা নিয়ে আপনাকে টিকে থাকতে হবে — কেবল redo apply-কে খুশি রাখার ন্যূনতমটুকুর জন্য নয়।

অপারেটিং সিস্টেমের বেলায় নিয়ম কঠোরতর। Physical standby-তে একই platform family ও endianness লাগে — Linux x86-64 থেকে Linux x86-64 হলো স্বাভাবিক ক্ষেত্র, আর মিশ্র Windows/Linux কম্বিনেশন সীমাবদ্ধ Oracle-এর নথিভুক্ত নির্দিষ্ট জোড়াগুলোতে (My Oracle Support note 413484.1-ই কর্তৃপক্ষ)। ডেটাবেজ ভার্সনেও একই কথা: primary ও physical standby-কে একই release-এ চলতে হবে, এবং বাস্তবে rolling-upgrade উইন্ডোর বাইরে একই patch level-এ। Cross-endian স্থানান্তর (ধরুন AIX থেকে Linux) একটি মাইগ্রেশন প্রজেক্ট — Data Pump, transportable tablespace বা GoldenGate — কোনো Data Guard কনফিগারেশন নয়।

১৪. Data Guard + RAC = Maximum Availability Architecture

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

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

Data Guard আর ব্যাকআপের মধ্যে পার্থক্য কী?

ব্যাকআপ হলো নির্দিষ্ট একটি সময়ের কপি, যা restore করতে হয় — বড় ডেটাবেজের জন্য ঘণ্টার পর ঘণ্টার কাজ। Data Guard হলো একটি জীবন্ত, অবিরত সিঙ্ক্রোনাইজড দ্বিতীয় ডেটাবেজ, যা কয়েক মিনিটেই দায়িত্ব নিতে পারে। তবু RMAN ব্যাকআপ লাগবেই: খারাপ কোনো batch job বা ভুলবশত TRUNCATE হলে Data Guard তা বিশ্বস্তভাবে standby-তেও পৌঁছে দেয়, আর ব্যাকআপ আপনাকে সময়ে পিছিয়ে যেতে দেয়। দুটি ভিন্ন সমস্যার সমাধান — প্রোডাকশনে দুটোই দরকার।

প্রতিটি Data Guard protection mode-এ RPO ও RTO কেমন?

Maximum Performance (ASYNC): RPO কয়েক সেকেন্ড — যে redo পথে ছিল, ততটুকুই — আর broker থাকলে RTO এক থেকে পাঁচ মিনিট। Maximum Availability (SYNC): standby sync-এ থাকা অবস্থায় RPO শূন্য, RTO একই। Maximum Protection: নিশ্চিত শূন্য RPO, কিন্তু সিঙ্ক্রোনাইজড standby-তে পৌঁছাতে না পারলে primary বন্ধ হয়ে যায়। সব mode-এই RTO মূলত নির্ভর করে আপনি কতটা ভালো মহড়া দিয়েছেন তার ওপর, সফটওয়্যারের ওপর নয়।

Standby ডেটাবেজ কি read-only খোলা যায়?

হ্যাঁ। যেকোনো physical standby read-only খোলা যায়, কিন্তু সাধারণ Data Guard খোলা অবস্থায় redo প্রয়োগ বন্ধ রাখে, ফলে standby পিছিয়ে পড়ে। Active Data Guard (আলাদা লাইসেন্সের অপশন) ডেটাবেজ read-only খোলা থাকা অবস্থাতেও redo apply চালু রাখে — রিপোর্ট সাম্প্রতিক ডেটা পড়ে এবং DR সুরক্ষা কখনও থেমে থাকে না।

একটি standby ডেটাবেজ কতটা পিছিয়ে থাকতে পারে?

ASYNC mode-এ ভালো নেটওয়ার্ক লিংকে সুস্থ standby কয়েক সেকেন্ড পিছিয়ে চলে। কয়েক মিনিটের বেশি apply lag মানেই সমস্যা — নেটওয়ার্ক স্যাচুরেশন, standby-র ধীর I/O, কিংবা বন্ধ হয়ে যাওয়া MRP। আমি ৫ মিনিটে অ্যালার্ট দিই। রেপ্লিকেট হয়ে যাওয়া মানুষের ভুলের বীমা হিসেবে DelayMins property দিয়ে ইচ্ছাকৃতভাবে apply দেরিও করানো যায়, যদিও আজকাল flashback database-ই বেশি প্রচলিত সমাধান।

Oracle Data Guard-এ switchover ও failover-এর পার্থক্য কী?

Switchover হলো পরিকল্পিত role reversal — দুটি ডেটাবেজই সুস্থ, ভূমিকা সুশৃঙ্খলভাবে বদলায় এবং কোনো ডেটা হারায় না। Failover হলো জরুরি পথ: primary হারিয়ে গেছে, আপনি standby-কে উন্নীত করেন এবং আপনার protection mode যতটুকু অনুমোদন করে ততটুকু ডেটা হারানো মেনে নেন। Failover-এর পর পুরনো primary-কে পুনঃস্থাপন করতে হয়, যা flashback database অনেক সহজ করে দেয়।

কোন Data Guard protection mode আমার ব্যবহার করা উচিত?

অধিকাংশ প্রোডাকশন ওয়ার্কলোডের জন্য Maximum Performance (async) — পারফরম্যান্সে কোনো প্রভাব নেই, ডেটা হারানোর জানালা কয়েক সেকেন্ডের। যেখানে নিয়ন্ত্রক সংস্থা শূন্য ডেটা লস চায় এবং standby এত কাছে যে commit latency গ্রহণযোগ্য থাকে, সেখানে Maximum Availability (sync)। Maximum Protection কেবল তখনই, যখন যেকোনো মূল্যে ডেটা হারানো অগ্রহণযোগ্য এবং standby অনুপলব্ধ হলে primary নিজে বন্ধ হয়ে যাবে — এই ঝুঁকি আপনি মেনে নেন।

শেষ কথা

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

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

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