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

Oracle Multitenant আমরা কীভাবে ডেটাবেজ চালাই তা বদলে দিয়েছে। non-CDB আর্কিটেকচার desupported হওয়ায়, আজ আপনি যে database-ই তৈরি করেন তা একটি container database — আর CDB ও PDB পরিষ্কারভাবে অ্যাডমিনিস্টার করতে জানা আর ঐচ্ছিক নয়। DBA হিসেবে আমার ১৮+ বছরে ফার্মা, 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-এর মতো আচরণ করে।

প্রতিটি জুনিয়র DBA-কে আমি যে মানসিক মডেলটি দিই: CDB হলো একটি অ্যাপার্টমেন্ট ভবন, আর প্রতিটি PDB একটি অ্যাপার্টমেন্ট। ভবনের মালিকানায় থাকে ভিত্তি, বিদ্যুৎ সরবরাহ, পানির লাইন আর সিকিউরিটি ডেস্ক — সেটাই shared memory, background process, redo stream ও control file। প্রতিটি অ্যাপার্টমেন্টের আছে নিজের আসবাব, নিজের সদর দরজার চাবি আর নিজের বাসিন্দারা — আপনার schema, আপনার ডেটা, আপনার user।

উপমাটি তার মূল্য প্রমাণ করে কারণ এটি আচরণ অনুমান করে। ভাড়াটেরা প্রতিবেশীদের না জিজ্ঞেস করেই নিজের অ্যাপার্টমেন্ট সাজাতে পারে (প্রতি-PDB parameter, local user)। কেউ পাশের ফ্ল্যাটে ঢুকে পড়তে পারে না (PDB isolation)। আর যদি আপনি সরে যেতে চান, অ্যাপার্টমেন্টটি গুছিয়ে নিয়ে নতুন ভবনে চলে যান (unplug/plug)। এক সেট memory ও process এখন বহু database-কে সেবা দেয় — কম ওভারহেড, দ্রুততর provisioning এবং সহজতর patching (CDB একবার patch করুন, প্রতিটি PDB উপকৃত হয়)।

২. non-CDB কেন মৃত (এবং কেন আপনি অপেক্ষা করতে পারেন না)

non-CDB আর্কিটেকচার — যে ক্লাসিক standalone database-এ আমরা সবাই বড় হয়েছি — Oracle Database 21c থেকে desupported। এটি 12.1-এই deprecated হয়েছিল, আর 21c থেকে আপনি শারীরিকভাবেই একটি non-CDB তৈরি করতে পারবেন না। তাই 19c থেকে 23ai বা 26ai-তে প্রতিটি upgrade-এর মধ্যেই একটি PDB-তে রূপান্তর অন্তর্ভুক্ত। এর কোনো বিকল্প পথ নেই।

২০২৬ সালেও আমি এমন টিমের দেখা পাই যারা 11g ও 12c non-CDB চালাচ্ছে এবং "multitenant পরে দেখব" বলে পরিকল্পনা করছে। সেই "পরে" এসে গেছে। আপনি যে upgrade-ই পরিকল্পনা করুন না কেন — আর সেই পথ নিয়ে আমি লিখেছি আমার 19c থেকে 26ai আপগ্রেড গাইডে — গন্তব্য হলো একটি CDB-এর ভেতরের একটি PDB। সুখবর: রূপান্তরটি বহুল-পরীক্ষিত, টুলিং (AutoUpgrade) বেশিরভাগ কাজ করে দেয়, আর সেখানে পৌঁছানোর পর দৈনন্দিন অ্যাডমিনিস্ট্রেশন সত্যিই আরও সুন্দর।

৩. একটি 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 অপারেশন: Create, Open, Close

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 আপনার জন্য ফাইল বসিয়ে দেয়। একটি নতুন অ্যাপ্লিকেশন database provision করা এখন ত্রিশ-সেকেন্ডের কাজ, যে কারণে বছর কয়েক আগেই আমি নতুন CDB ছাড়া অন্য কিছুর জন্য পূর্ণ DBCA build স্ক্রিপ্ট করা বন্ধ করে দিয়েছি।

একটি database-এর যেমন state আছে, PDB-গুলোরও তেমনি open mode আছে, আর সেগুলো মুখস্থ জানা থাকলে ইনসিডেন্টের সময় আপনি বেঁচে যান:

-- normal read/write operation
ALTER PLUGGABLE DATABASE sales_pdb OPEN;

-- read-only (reporting, or as a clone source in older releases)
ALTER PLUGGABLE DATABASE sales_pdb OPEN READ ONLY;

-- restricted (maintenance — only RESTRICTED SESSION users get in)
ALTER PLUGGABLE DATABASE sales_pdb OPEN RESTRICTED;

-- close cleanly / immediately
ALTER PLUGGABLE DATABASE sales_pdb CLOSE;
ALTER PLUGGABLE DATABASE sales_pdb CLOSE IMMEDIATE;

INCLUDING DATAFILES বললে একটি drop করা PDB তার datafile-সহই চিরতরে চলে যায় — তাই, সব ধ্বংসাত্মক কাজের মতোই, PDB-এর নামটি দুবার টাইপ করুন এবং Enter চাপার আগে আরেকবার পড়ুন।

৬. 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-টি প্রায়-তাৎক্ষণিক ও স্পেস-সাশ্রয়ী হয় — ঘণ্টার বদলে সেকেন্ডে ডেভেলপারদের হাতে প্রোডাকশন ডেটার একটি পূর্ণ কপি তুলে দিতে পারেন।

বাস্তব প্রজেক্টে আমি যে ফিচারটি সবচেয়ে বেশি ব্যবহার করি তা হলো refreshable clone। এটি এমন একটি clone যা তার source-এর সঙ্গে যুক্ত থাকে এবং চাহিবামাত্র বা নির্দিষ্ট সূচিতে নতুন পরিবর্তন দিয়ে হালনাগাদ করা যায়। একটি ফার্মা ক্লায়েন্টের UAT পরিবেশের জন্য আমি এই প্যাটার্নটি চালাই:

-- one-time setup: refreshable clone from production over a DB link
CREATE PLUGGABLE DATABASE sales_uat FROM sales_pdb@prod_link
  REFRESH MODE MANUAL;

-- every Sunday night: close, pull the latest changes, reopen read-only
ALTER PLUGGABLE DATABASE sales_uat CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE sales_uat REFRESH;
ALTER PLUGGABLE DATABASE sales_uat OPEN READ ONLY;

-- or let Oracle refresh it automatically every 240 minutes
ALTER PLUGGABLE DATABASE sales_uat REFRESH MODE EVERY 240 MINUTES;

link-এর ওপর দিয়ে কেবল incremental পরিবর্তনগুলোই যায়, তাই একটি মাল্টি-টেরাবাইট PDB-এর সাপ্তাহিক refresh লাগে কয়েক মিনিট — আমাদের সবার মনে থাকা রাতভর Data Pump ম্যারাথন নয়। tester-দের যখন এতে লিখতে হয়, আপনি refresh link ভেঙে এটিকে read/write open করেন — এবং test cycle শেষে আবার তৈরি করে নেন। Multitenant-এর আগে UAT হালনাগাদ রাখা মানে ছিল প্রতি সপ্তাহান্তে একটি পূর্ণ RMAN duplicate। এখন তা একটি scheduler job-এ তিন লাইন।

৭. 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 অমিল কামড় বসানোর আগেই আপনাকে জানায়।

৮. Restart-এর পর আমার PDB কেন নিজে থেকে Open হলো না?

কারণ default-এ একটি CDB restart প্রতিটি PDB-কে MOUNTED অবস্থায় রেখে দেয়, OPEN নয়। Oracle কেবল সেই PDB-গুলোই পুনরায় open করে যাদের state আপনি স্পষ্টভাবে ALTER PLUGGABLE DATABASE ... SAVE STATE দিয়ে save করেছেন। saved state না থাকা মানে CDB চালু হয়, listener PDB-এর জন্য কিছুই রেজিস্টার করে না, আর প্রতিটি অ্যাপ্লিকেশন সংযোগ ORA-01109 বা একটি service error দিয়ে ব্যর্থ হয়।

ঠিক এই রাত ২টার ফোনকলটি আমি নিজে পেয়েছি: সার্ভার patch হয়েছে, CDB পরিচ্ছন্নভাবে restart হয়েছে, instance স্তরে মনিটরিং সবুজ — অথচ ERP বন্ধ, কারণ তার PDB চুপচাপ mounted হয়ে বসে ছিল। সমাধানে লাগে দশ সেকেন্ড; তৈরি করার সময়েই সেটা করতে মনে রাখাটাই হলো শৃঙ্খলা।

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

-- verify what Oracle will do at next restart
SELECT con_name, state FROM dba_pdb_saved_states;

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

প্রোডাকশনের জন্য আমার নিয়ম: যে change ticket ব্যবসার জন্য একটি নতুন PDB open করে, সেই একই ticket-এ SAVE STATE লাইনটি এবং প্রমাণ হিসেবে DBA_PDB_SAVED_STATES-এর ওপর কোয়েরিটি থাকতেই হবে। এটি আমাকে দ্বিতীয়বার কামড় বসাতে পারেনি।

৯. 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 অন্যগুলোকে অনাহারে রাখে — ঠিক সেই প্রতিবেশীর database-সংস্করণ যে রাত ৩টায় ওয়াশিং মেশিন চালায়। দুটি ব্যবস্থা ভবনটিকে সভ্য রাখে।

আমার অভিজ্ঞতায় সবচেয়ে সরল ও সবচেয়ে কার্যকর হলো প্রতি-PDB CPU_COUNT সীমা। 12.2 থেকে, একটি PDB-এর ভেতরে সেট করা CPU_COUNT নির্ধারণ করে সেই PDB-এর session-গুলো কতগুলো CPU ব্যবহার করতে পারবে:

ALTER SESSION SET CONTAINER = sales_pdb;
ALTER SYSTEM SET cpu_count = 4 SCOPE = BOTH;

-- check every PDB's cap from the root
SELECT con_id, name, value
FROM   v$system_parameter
WHERE  name = 'cpu_count';

আরও সূক্ষ্ম নিয়ন্ত্রণের জন্য, একটি CDB resource plan CPU বণ্টন করে share দিয়ে — আপেক্ষিক ওজন, ঠিক যেমন অ্যাপার্টমেন্ট মালিকরা ভবনের ভিন্ন ভিন্ন শতাংশের মালিক:

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(plan => 'cdb_prod_plan');
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan => 'cdb_prod_plan', pluggable_database => 'sales_pdb',
    shares => 3, utilization_limit => 70);
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan => 'cdb_prod_plan', pluggable_database => 'hr_pdb',
    shares => 1, utilization_limit => 30);
END;
/
ALTER SYSTEM SET resource_manager_plan = 'cdb_prod_plan';

• Shares — PDB-গুলোর মধ্যে আপেক্ষিক CPU weighting (ওপরের 3:1 মানে contention-এর সময় sales পায় HR-এর তিন গুণ CPU)।
• Utilization limit — প্রতি PDB-তে একটি hard CPU ceiling, মেশিন idle থাকলেও।
• Memory ও storage — প্রতি-PDB SGA_TARGET, PGA_AGGREGATE_LIMIT এবং MAX_PDB_STORAGE cap একটি tenant-কে পুরো ডিস্ক ভরে ফেলা থেকে আটকায়।

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

১১. Multitenant-এ Backup ও Recovery

RMAN পুরোপুরি container-aware। আপনি পুরো CDB backup করেন (যা root-সহ প্রতিটি PDB কভার করে), অথবা আলাদা PDB — এবং, রাত ২টায় যে অংশটি সবচেয়ে গুরুত্বপূর্ণ, container-এর অন্য প্রতিটি PDB ব্যবহারকারীদের সেবা দিতে থাকা অবস্থায় আপনি একটি একক PDB restore ও recover করতে পারেন:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;        -- whole CDB, my default

RMAN> BACKUP PLUGGABLE DATABASE sales_pdb;

-- disaster in ONE pdb: restore it alone, others stay open
RMAN> ALTER PLUGGABLE DATABASE sales_pdb CLOSE IMMEDIATE;
RMAN> RESTORE PLUGGABLE DATABASE sales_pdb;
RMAN> RECOVER PLUGGABLE DATABASE sales_pdb;
RMAN> ALTER PLUGGABLE DATABASE sales_pdb OPEN;

point-in-time recovery-ও PDB স্তরে কাজ করে (RECOVER PLUGGABLE DATABASE ... UNTIL TIME), পর্দার আড়ালে একটি auxiliary instance ব্যবহার করে। পূর্ণাঙ্গ RMAN শৃঙ্খলার জন্য — catalog, retention, restore drill — দেখুন আমার RMAN backup ও recovery গাইড; আর restore ছাড়াই logical ভুল ফিরিয়ে নিতে, Flashback-ও 19c থেকে প্রতি-PDB কাজ করে।

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

১২. non-CDB-গুলোকে একটি CDB-তে মাইগ্রেট করা

প্রতিটি legacy non-CDB-কে একদিন না একদিন এই যাত্রাটি করতেই হবে। পথগুলো এই — আমি যে ক্রমে সুপারিশ করি সেই ক্রমে:

1. AutoUpgrade সহ conversion (আমার default)। একটি টুল একটি অর্কেস্ট্রেটেড রানে non-CDB-কে upgrade করে এবং target CDB-এর একটি PDB-তে রূপান্তর করে — config file, java -jar autoupgrade.jar -mode deploy, শেষ। এটি plug-in, noncdb_to_pdb.sql এবং violation check-গুলো আপনার হয়ে সামলে দেয়।
2. PDB হিসেবে ম্যানুয়াল plug-in। manifest XML তৈরি করতে DBMS_PDB.DESCRIBE দিয়ে non-CDB-টি describe করুন, সেই manifest USING করে PDB তৈরি করুন, তারপর এর ভেতরে $ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql চালান। বেশি ধাপ, বেশি নিয়ন্ত্রণ — source ইতিমধ্যেই target version-এ থাকলে কাজে লাগে।
3. non-CDB-এর remote clone। 12.2 থেকে, CREATE PLUGGABLE DATABASE ... FROM noncdb@dblink একটি চালু non-CDB-কে database link-এর ওপর দিয়ে সরাসরি একটি CDB-তে টেনে আনে — source host-এ ন্যূনতম স্পর্শ।
4. একটি নতুন PDB-তে Data Pump। পুরনো নির্ভরযোগ্য পথ। বড় database-এর জন্য সবচেয়ে ধীর, কিন্তু এটি de-fragment-ও করে, মৃত ভার ঝেড়ে ফেলে, এবং যেকোনো version gap বা endianness পরিবর্তন জুড়ে কাজ করে।

যে পথই নিন, বিজয় ঘোষণার আগে PDB_PLUG_IN_VIOLATIONS যাচাই করুন এবং দুই পাশেই একটি পূর্ণ backup নিন। যে মাইগ্রেশন violation check বাদ দেয়, সেগুলোই এক সপ্তাহ পরে আপনাকে page করে।

১৩. নিরাপত্তা ও Isolation: Common User ও Lockdown Profile

Multitenant নিরাপত্তায় আত্মস্থ করার মতো একটি নতুন ধারণা আছে: common user ও local user-এর বিভাজন। একটি common user (নামের শুরুতে C##) root-এ তৈরি হয় এবং প্রতিটি PDB-তে বিদ্যমান থাকে — মাস্টার চাবিওয়ালা ভবনের সুপারিনটেনডেন্ট। একটি local user ঠিক একটি PDB-তে থাকে — এক অ্যাপার্টমেন্টের চাবিওয়ালা এক ভাড়াটে।

-- in CDB$ROOT: a common DBA account across all containers
CREATE USER c##dba_khan IDENTIFIED BY "..." CONTAINER = ALL;
GRANT DBA TO c##dba_khan CONTAINER = ALL;

-- in a PDB: a local application user
ALTER SESSION SET CONTAINER = sales_pdb;
CREATE USER sales_app IDENTIFIED BY "...";

common user একেবারে ন্যূনতম রাখুন — কেবল DBA ও মনিটরিং। অ্যাপ্লিকেশন অ্যাকাউন্ট সবসময় local। hosted বা multi-team CDB-এর জন্য lockdown profile আরও এগিয়ে যায়: এগুলো দিয়ে আপনি একটি PDB-এর ভেতরে নির্দিষ্ট feature, option ও ALTER SYSTEM clause নিষ্ক্রিয় করতে পারেন, যাতে একজন tenant admin instance-স্তরের সেটিং বদলাতে বা OS-এ পৌঁছাতে না পারে। প্রতি-PDB MAX_PDB_STORAGE ও resource plan-এর সঙ্গে মিলিয়ে, একটি সুপরিচালিত CDB এমন isolation দেয় যা সত্যি বলতে পুরনো "এক বড় database-এ প্রতি অ্যাপে এক schema" প্যাটার্নের চেয়ে শক্তিশালী — এই বিষয়টি আমি আরও বিস্তৃতভাবে কভার করেছি আমার database security hardening গাইডে।

১৪. Multitenant-এর খরচ কত? সৎ লাইসেন্সিং উত্তর

বেশিরভাগ মানুষ যা ভয় পান তার চেয়ে কম। Oracle 19c থেকে, আপনি Multitenant option লাইসেন্স না করেই প্রতি CDB-তে ৩টি পর্যন্ত user-created PDB চালাতে পারেন — Enterprise ও Standard Edition দুটোতেই। paid option কেবল তখনই প্রয়োজন যখন একটি একক CDB-তে চার বা তার বেশি user-created PDB থাকে।

বাস্তবে, এই ফ্রি ভাতাটি বাস্তব এস্টেটের বিশাল অংশ কভার করে: প্রোডাকশন, সঙ্গে একটি reporting কপি, সঙ্গে আরও একটি — সব এক container-এ। আরও দরকার? তিনটি করে PDB সহ একাধিক CDB চালাতে কিছুই আপনাকে আটকায় না। বেশিরভাগ মাঝারি আকারের consolidation আমি ঠিক এভাবেই ডিজাইন করি, আর চতুর্থ PDB-এর অভাব কেউ কখনও বোধ করেনি। প্রতিশ্রুতিবদ্ধ হওয়ার আগে Oracle Database Licensing Information গাইডে বর্তমান শর্তগুলো যাচাই করুন — কিন্তু একটি লাইসেন্সিং মিথ যেন আপনাকে ইতিমধ্যেই desupported একটি আর্কিটেকচারে আটকে না রাখে।

১৫. যুদ্ধের গল্প: নয়টি Legacy Database, এক CDB

আমার এক ম্যানুফ্যাকচারিং ক্লায়েন্ট বুড়িয়ে যাওয়া হার্ডওয়্যারে নয়টি আলাদা single-purpose database চালাত — ERP, HR, quality, একটি reporting কপি এবং পাঁচটি ছোট বিভাগীয় সিস্টেম। নয় সেট SGA, নয়টি backup job, নয়টি ত্রৈমাসিক patch window। সার্ভারগুলো end-of-life ছিল আর patching-এর জট একটি audit finding হয়ে উঠছিল।

আমরা দুটি নতুন সার্ভারে তিনটি CDB-তে consolidate করলাম — প্রতিটিতে তিনটি করে PDB, ইচ্ছাকৃতভাবে ফ্রি ভাতার ভেতরে থেকে। ভারী ERP পেল resource plan সহ নিজের CDB; ছোট সিস্টেমগুলো ভাগ করল আরেকটি। প্রতিটি legacy database সপ্তাহান্তে একটি করে remote clone বা AutoUpgrade-এ যাত্রা করল, প্রতিটি cutover-এর আগে PDB_PLUG_IN_VIOLATIONS যাচাই ও একটি fallback backup প্রস্তুত রেখে।

এক বছর পরের ফলাফল: patching নয়টি window থেকে তিনটিতে, RMAN job নয় থেকে তিনে, আর ERP-এর একটি নতুন test কপি provision করা দুই দিনের অনুরোধ থেকে দশ মিনিটের clone-এ নেমে এল। বারো মাসে একমাত্র ইনসিডেন্ট? একটি বিভাগীয় PDB যেটি plug-in-এর পরে কেউ SAVE STATE করেনি — ঠিক এই কারণেই সেই check এখন runbook-এ মোটা হরফে ছাপা।

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

• 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 — ডেভেলপারদের দ্রুত ও নিরাপদে সত্যিকারের ডেটা দিন।

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

CDB ও PDB-এর মধ্যে পার্থক্য কী?

একটি CDB (container database) হলো শীর্ষ-স্তরের Oracle instance: shared memory, background process, redo এবং Oracle-সরবরাহকৃত dictionary। একটি PDB (pluggable database) হলো schema ও ডেটার একটি স্বয়ংসম্পূর্ণ, বহনযোগ্য সেট যা সেই CDB-তে plug করা থাকে। অ্যাপ্লিকেশনের কাছে একটি PDB একটি সম্পূর্ণ স্বাধীন database-এর মতোই দেখায় ও আচরণ করে।

Multitenant-এর জন্য টাকা না দিয়ে আমি কয়টি PDB চালাতে পারি?

Oracle 19c থেকে, Multitenant option লাইসেন্স না করেই প্রতি CDB-তে ৩টি পর্যন্ত user-created PDB চালানো যায় — Enterprise ও Standard Edition দুটোতেই। একটি CDB-তে চতুর্থ user-created PDB থেকে তবেই paid option প্রয়োজন হয়। তিনটি করে PDB সহ একাধিক CDB চালানো একটি বৈধ ডিজাইন।

একই CDB-এর PDB-গুলোর কি ভিন্ন character set বা time zone থাকতে পারে?

ভিন্ন database time zone — হ্যাঁ, প্রতিটি PDB নিজেরটা সেট করতে পারে। character set বেশি সীমাবদ্ধ: CDB root AL32UTF8-এ থাকলে (প্রস্তাবিত ও default পছন্দ) ভিন্ন compatible character set-এর PDB plug করা যায়, তবে সর্বত্র AL32UTF8-কেই স্ট্যান্ডার্ড হিসেবে ধরা উচিত এবং যেকোনো ব্যতিক্রম সাবধানে test করা উচিত।

PDB-তে চলতে কি আমার অ্যাপ্লিকেশনের কোড বদলাতে হবে?

প্রায় কখনোই না। অ্যাপ্লিকেশন listener-এর মাধ্যমে PDB-এর service-এ ঠিক তেমনভাবেই সংযোগ দেয় যেমনটা একটি standalone database-এ দিত — একই driver, একই SQL, একই schema। যা বদলায় তা হলো connection descriptor (PDB-এর দিকে নির্দেশ করা একটি service name) এবং DBA-এর অ্যাডমিনিস্ট্রেশন অভ্যাস, অ্যাপ্লিকেশন কোড নয়।

CDB restart-এর পর PDB-গুলো কীভাবে স্বয়ংক্রিয়ভাবে open করাব?

PDB-টি open করুন, তারপর ALTER PLUGGABLE DATABASE pdb_name SAVE STATE চালান। Oracle open state রেকর্ড করে রাখে এবং প্রতিটি CDB startup-এ তা পুনরায় তৈরি করে। DBA_PDB_SAVED_STATES-এ একটি কোয়েরি দিয়ে যাচাই করুন। এটি ছাড়া restart-এর পর PDB-গুলো MOUNTED অবস্থায় ওঠে এবং অ্যাপ্লিকেশন সংযোগ দিতে পারে না।

অন্যগুলোকে প্রভাবিত না করে কি একটি PDB restore করা যায়?

হ্যাঁ। RMAN container-aware: RESTORE PLUGGABLE DATABASE ও RECOVER PLUGGABLE DATABASE একটি একক PDB-এর ওপর কাজ করে, আর CDB-এর বাকি অংশ open থেকে ব্যবহারকারীদের সেবা দিতে থাকে। point-in-time recovery-ও পৃথক PDB স্তরে সমর্থিত।

non-CDB আর্কিটেকচার কি সত্যিই শেষ?

হ্যাঁ। non-CDB 12.1-এ deprecated হয়েছিল এবং 21c থেকে desupported — আধুনিক রিলিজে আপনি একটি তৈরি করতেই পারবেন না। 19c-এর পরের যেকোনো upgrade আপনার database-কে একটি CDB-এর ভেতরের একটি PDB-তে নিয়ে যায়, তাই multitenant অ্যাডমিনিস্ট্রেশন এখন মূল DBA জ্ঞান, কোনো বিশেষায়িত দক্ষতা নয়।

শেষ কথা

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

যে DBA-রা Multitenant-এ উন্নতি করেন, তাঁরাই যাঁরা container সীমানাকে সম্মান করেন, শুরুতেই resource পরিকল্পনা করেন এবং সবসময় জানেন তাঁদের session কোন container-এ আছে। আপনি যদি এখনও সেই ভিত্তি গড়ছেন, শুরু করার জায়গা হলো আমার Oracle DBA ক্যারিয়ার ও ফান্ডামেন্টালস গাইড; container দক্ষতা তার ওপরই সুন্দরভাবে গড়ে ওঠে।

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

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