Oracle Multitenant: প্রোডাকশনে CDB ও PDB ব্যবস্থাপনা

Oracle Multitenant আমরা কীভাবে ডেটাবেজ চালাই তা বদলে দিয়েছে। non-CDB আর্কিটেকচার desupported হওয়ায়, আজ আপনি যে database-ই তৈরি করেন তা একটি container database — আর CDB ও PDB পরিষ্কারভাবে অ্যাডমিনিস্টার করতে জানা আর ঐচ্ছিক নয়। ফার্মা, ERP ও ব্যাংকিং workload-এর জন্য কয়েক ডজন single-purpose database multitenant container-এ একত্র করার পর, এই ফিল্ড গাইডটি আমি আমার নিজের টিমকে দিই: যে ধারণাগুলো গুরুত্বপূর্ণ, যে কমান্ড আপনি আসলেই টাইপ করবেন, এবং যে ভুলগুলো প্রোডাকশনে কামড় বসায়।

১. মূল ধারণা: এক Container, বহু Database

12c-এর আগে প্রতিটি Oracle database ছিল নিজস্ব dictionary, background process ও memory সহ একটি স্বতন্ত্র instance। দশটি অ্যাপ্লিকেশন একত্র করা মানে ছিল দশটি পূর্ণ database — দশ সেট ওভারহেড। Multitenant তা উল্টে দেয়:

• CDB (Container Database): শীর্ষ-স্তরের container। এটি shared redo, undo (shared mode-এ), background process এবং Oracle-সরবরাহকৃত data dictionary-র মালিক।
• PDB (Pluggable Database): একটি বহনযোগ্য, স্বয়ংসম্পূর্ণ database — আপনার schema, আপনার ডেটা, আপনার অ্যাপ্লিকেশন — যা একটি CDB-তে plug করে এবং অ্যাপের কাছে একটি স্বাধীন database-এর মতো আচরণ করে।

এক সেট memory ও process এখন বহু database-কে সেবা দেয়। এটাই consolidation-এর জয়: কম ওভারহেড, দ্রুততর provisioning এবং সহজতর patching (CDB একবার patch করুন, প্রতিটি PDB উপকৃত হয়)।

২. একটি CDB-এর গঠন

প্রতিটি CDB-এর ভেতরে কয়েকটি বিশেষ container থাকে:

• CDB$ROOT — container 1। Oracle metadata ও common user ধারণ করে। এখানে আপনি অ্যাপ্লিকেশন ডেটা রাখেন না।
• PDB$SEED — container 2। একটি read-only template যা Oracle দ্রুত নতুন PDB বানাতে ব্যবহার করে।
• আপনার PDB-গুলো — container 3, 4, 5… প্রতিটি একটি অ্যাপ্লিকেশন database।

আপনি কোথায় আছেন ও কী কী বিদ্যমান তা যাচাই করুন:

SHOW CON_NAME
SHOW CON_ID

SELECT con_id, name, open_mode FROM v$containers ORDER BY con_id;
SELECT pdb_id, pdb_name, status FROM cdb_pdbs ORDER BY pdb_id;

৩. Container-এর মধ্যে চলাচল

সবচেয়ে গুরুত্বপূর্ণ অভ্যাস: সবসময় জানুন আপনার session কোন container-এ আছে। switch করা তাৎক্ষণিক:

-- connect to the root
ALTER SESSION SET CONTAINER = CDB$ROOT;

-- switch into an application PDB
ALTER SESSION SET CONTAINER = SALES_PDB;

-- or connect directly via a service / TNS entry that points at the PDB
sqlplus app_user@SALES_PDB

প্রতিটি PDB listener-এ নিজের service রেজিস্টার করে, তাই অ্যাপ্লিকেশন কখনও root স্পর্শ না করেই সরাসরি তাদের PDB-তে সংযোগ দেয়।

৪. PDB তৈরি করা

দ্রুততম উপায় হলো seed থেকে:

CREATE PLUGGABLE DATABASE sales_pdb
  ADMIN USER pdbadmin IDENTIFIED BY "StrongPass#2026"
  FILE_NAME_CONVERT = ('/u02/oradata/CDB1/pdbseed/',
                       '/u02/oradata/CDB1/sales_pdb/');

ALTER PLUGGABLE DATABASE sales_pdb OPEN;

Oracle Managed Files (OMF)-এ আপনি FILE_NAME_CONVERT পুরোপুরি বাদ দিতে পারেন — Oracle আপনার জন্য ফাইল বসিয়ে দেয়।

৫. PDB Clone করা — DBA-এর মহাশক্তি

প্রোডাকশনের একটি test কপি দরকার? clone করুন। এখানেই Multitenant তার মূল্য প্রমাণ করে:

-- hot clone (source stays open) — great for refreshing test from prod
CREATE PLUGGABLE DATABASE sales_test FROM sales_pdb;

-- remote clone over a database link
CREATE PLUGGABLE DATABASE sales_test FROM sales_pdb@prod_link;

ALTER PLUGGABLE DATABASE sales_test OPEN;

যে স্টোরেজ snapshot/thin clone সমর্থন করে, সেখানে SNAPSHOT COPY যোগ করুন আর clone-টি প্রায়-তাৎক্ষণিক ও স্পেস-সাশ্রয়ী হয় — ঘণ্টার বদলে সেকেন্ডে ডেভেলপারদের হাতে প্রোডাকশন ডেটার একটি পূর্ণ কপি তুলে দিতে পারেন।

৬. Unplug ও Plug: সত্যিকারের বহনযোগ্যতা

একটি PDB এক CDB থেকে unplug করে অন্য একটিতে plug করা যায় — এমনকি একটি নতুন Oracle সংস্করণেও, যা এটিকে একটি পরিষ্কার আপগ্রেড ও মাইগ্রেশন টুল করে তোলে।

-- unplug to a manifest XML
ALTER PLUGGABLE DATABASE sales_pdb CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE sales_pdb UNPLUG INTO '/tmp/sales_pdb.xml';
DROP PLUGGABLE DATABASE sales_pdb KEEP DATAFILES;

-- plug into the target CDB
CREATE PLUGGABLE DATABASE sales_pdb USING '/tmp/sales_pdb.xml' NOCOPY;
ALTER PLUGGABLE DATABASE sales_pdb OPEN;

একটি নতুন CDB-তে open করার আগে সবসময় PDB_PLUG_IN_VIOLATIONS কোয়েরি করে compatibility check চালান — এটি version, option বা parameter অমিল কামড় বসানোর আগেই আপনাকে জানায়।

৭. Open, Close ও Save State

একটি ক্লাসিক নবীন-চমক: একটি CDB restart-এর পর PDB-গুলো MOUNTED অবস্থায় ওঠে, OPEN নয় — যদি না আপনি Oracle-কে মনে রাখতে বলেন।

ALTER PLUGGABLE DATABASE sales_pdb OPEN;
-- make it auto-open on every CDB startup
ALTER PLUGGABLE DATABASE sales_pdb SAVE STATE;

-- open / close all at once
ALTER PLUGGABLE DATABASE ALL OPEN;
ALTER PLUGGABLE DATABASE ALL EXCEPT sales_pdb CLOSE IMMEDIATE;

৮. RAC-এ Multitenant

একটি RAC পরিবেশে আপনি service-এর মাধ্যমে প্রতি instance-এ PDB-এর open state পরিচালনা করেন। PDB-এর সঙ্গে বাঁধা একটি service তৈরি করুন এবং Clusterware-কে ঠিক করতে দিন কোথায় তা চলবে:

srvctl add service -db CDB1 -service sales_oltp -pdb sales_pdb \
       -preferred CDB11 -available CDB12
srvctl start service -db CDB1 -service sales_oltp
srvctl status service -db CDB1

অ্যাপ্লিকেশন sales_oltp service-এ সংযোগ দেয়, কখনও সরাসরি কোনো instance-এ নয় — এটাই node জুড়ে transparent failover দেয়।

৯. PDB-গুলোর মধ্যে Resource Management

Consolidation মানে PDB-গুলো CPU ও I/O ভাগ করে। guardrail ছাড়া, একটি হইচই করা PDB অন্যগুলোকে অনাহারে রাখে। CDB Resource Manager-এর share ও limit ব্যবহার করুন:

• Shares — PDB-গুলোর মধ্যে আপেক্ষিক CPU weighting।
• Utilization limit — প্রতি PDB-তে একটি hard CPU সীমা।
• Memory ও session — প্রতি-PDB SGA_TARGET, PGA_AGGREGATE_LIMIT এবং MAX_PDB_STORAGE cap।

শুরুতেই একটি যুক্তিসঙ্গত CDB plan সেট করুন। একটি বেপরোয়া PDB ইতিমধ্যেই একটি ইনসিডেন্ট ঘটানোর পর resource limit বসানো অনেক কঠিন আলোচনা।

১০. Backup, Recovery ও Data Dictionary

RMAN পুরোপুরি container-aware। আপনি পুরো CDB বা আলাদা PDB backup করতে পারেন, এবং অন্যগুলো স্পর্শ না করেই একটি একক PDB recover করতে পারেন:

RMAN> BACKUP PLUGGABLE DATABASE sales_pdb;
RMAN> RESTORE PLUGGABLE DATABASE sales_pdb;
RMAN> RECOVER PLUGGABLE DATABASE sales_pdb;

dictionary বিভাজন মনে রাখুন: CDB_* view সব container জুড়ে অবজেক্ট দেখায় (একটি CON_ID কলাম সহ), আর DBA_* view কেবল বর্তমান container দেখায়। যখন একটি কোয়েরি "কিছুই ফেরত দেয় না", দশবারের নয়বারই আপনি কেবল ভুল container-এ আছেন।

১১. সাধারণ ফাঁদ

• SAVE STATE ভুলে যাওয়া — restart-এর পর PDB mounted থেকে যায় আর অ্যাপ সংযোগে ব্যর্থ হয়।
• CDB$ROOT-এ অবজেক্ট তৈরি করা — অ্যাপ্লিকেশন অবজেক্ট একটি PDB-তে থাকে, কখনও root-এ নয়।
• Local বনাম common user — common user (C## prefixed) সব PDB জুড়ে থাকে; local user একটি PDB-তে থাকে। এদের গুলিয়ে ফেললে privilege বিভ্রান্তি হয়।
• plug-in violation উপেক্ষা করা — একটি plug বা upgrade-এর পর সবসময় PDB_PLUG_IN_VIOLATIONS যাচাই করুন।
• কোনো resource plan না থাকা — একটি PDB CPU একচেটিয়া দখল করে আর পুরো container ভোগে।

১২. প্রোডাকশন সেরা চর্চা

• প্রতি PDB-তে একটি অ্যাপ্লিকেশন — পরিষ্কার isolation, সহজ clone/refresh, সরল chargeback।
• OMF ব্যবহার করুন — Oracle-কে ফাইল placement সামলাতে দিন; কম path ভুল।
• নামকরণ standardize করুন — একটি পরিষ্কার convention সহ PDB নাম, service ও TNS entry।
• একটি প্রোডাকশন PDB open করার পর সবসময় SAVE STATE।
• consolidate করার আগে একটি CDB resource plan সেট করুন, পরে নয়।
• CDB স্তরে patch করুন এবং এক পাসে সব PDB-তে SQL পরিবর্তন প্রয়োগ করতে datapatch ব্যবহার করুন।
• non-prod-এর জন্য hot-clone — ডেভেলপারদের দ্রুত ও নিরাপদে সত্যিকারের ডেটা দিন।

শেষ কথা

Multitenant "বাড়তি syntax সহ একই database" নয় — এটি একটি consolidation প্ল্যাটফর্ম। ভালোভাবে সামলালে এটি ওভারহেড কমায়, provisioning-কে এক-লাইনের কমান্ড বানায়, আর upgrade-কে একটি unplug-and-plug অনুশীলনে পরিণত করে। অসাবধানে সামলালে এটি বহু অ্যাপ্লিকেশনকে একটি shared engine-এ কেন্দ্রীভূত করে যেখানে একটি মাত্র misconfiguration সবাইকে প্রভাবিত করে। যে DBA-রা Multitenant-এ উন্নতি করেন, তাঁরাই যাঁরা container সীমানাকে সম্মান করেন, শুরুতেই resource পরিকল্পনা করেন এবং সবসময় জানেন তাঁদের session কোন container-এ আছে।

আপনার টিম যদি Multitenant-এ consolidate করছে, non-CDB মাইগ্রেট করছে, বা কয়েকটি workload-এর জন্য একটি CDB সাইজ করছে, চলুন কথা বলি। আমি ফার্মা, ERP ও ব্যাংকিং পরিবেশে multitenant consolidation আর্কিটেক্ট ও পরিচালনা করেছি এবং সাধারণ চমকগুলো ছাড়াই আপনাকে তা করতে সাহায্য করতে পারি।

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