প্রোডাকশনে Oracle Parallel Execution: PX কখন সাহায্য করে, কখন RAC আটকে দেয়

Oracle parallel execution একটি বড় কোয়েরিকে অনেকগুলো সার্ভার প্রসেসে ভাগ করে দ্রুত শেষ করে - তবে কেবল তখনই, যখন মেশিনে বাড়তি CPU ও I/O থাকে আর অল্প কয়েকটি স্টেটমেন্ট ওই প্রসেসগুলোর জন্য প্রতিযোগিতা করে। সবকিছুর জন্য চালু করে দিলে parallel server-ই হয়ে ওঠে বক্সের সবচেয়ে দুর্লভ সম্পদ। একটি আর্থিক প্রতিষ্ঠানের প্রোডাকশন 19c RAC-এ আমি ঠিক এটাই পেয়েছিলাম: হোস্ট ৮৮.৬% অলস, অথচ গড়ে ১০৯টি সেশন parallel server-এর জন্য লাইনে দাঁড়িয়ে।

১. Oracle Parallel Execution কী?

Oracle parallel execution হলো একটি SQL স্টেটমেন্টকে কয়েকটি parallel execution (PX) server প্রসেসে ভাগ করে দেওয়ার ক্ষমতা, যাদের সমন্বয় করে স্টেটমেন্টটি চালানো সেশন নিজেই - যাতে বড় scan, join, sort বা load দ্রুত শেষ হয়। প্রতিটি ধাপে কতগুলো server কাজ করছে, সেটিই degree of parallelism বা DOP।

যে সেশন স্টেটমেন্ট চালায় সে হয় query coordinator (QC)। সে কাজ granule-এ ভাগ করে দেয়, ফলাফল জড়ো করে ক্লায়েন্টকে ফেরত দেয়।

কর্মীরা আসে প্রতিটি ইনস্ট্যান্সের PX server পুল থেকে, যার ছাদ PARALLEL_MAX_SERVERS। প্রতি coordinator-এ সর্বোচ্চ দুটি server set থাকে বলে বেশিরভাগ স্টেটমেন্ট DOP × ২ server নেয় - DOP 4-এর কোয়েরিতে আটটি।

২. Parallel Query কখন সাহায্য করে, কখন ক্ষতি করে?

Oracle VLDB and Partitioning Guide স্পষ্ট বলে: বড় ডেটা সেট, কম concurrency আর elapsed time জরুরি হলে parallel জেতে। ছোট ডেটা সেট, বেশি concurrency আর দক্ষতা জরুরি হলে জেতে serial।

তাই কোর ব্যাংকিং বা ERP ডেটাবেজে parallelism নির্দিষ্ট কাজের জন্য, সবকিছুর জন্য নয়। কোথায় এটি লাভ দেয়, তা আমার ব্যাংকিংয়ের জন্য Oracle ডেটাবেজ গাইডের end-of-day batch অংশে আছে।

৩. কোন প্যারামিটার ঠিক করে আপনি কতগুলো PX Server পাবেন?

• PARALLEL_MAX_SERVERS - প্রতি ইনস্ট্যান্সে PX server-এর কঠিন ছাদ। এই কেসে: 4।
• PARALLEL_SERVERS_TARGET - queuing শুরুর আগে কতগুলো server সক্রিয় থাকতে পারে, অর্থাৎ লাইনের দাগ। এই কেসে: 4।
• PARALLEL_DEGREE_POLICY - manual DOP, নাকি queuing-সহ automatic DOP। ডিফল্ট MANUAL; এই কেসে: AUTO।
• PARALLEL_FORCE_LOCAL - RAC-এ PX server-কে coordinator-এর নিজের নোডে আটকে রাখে। ডিফল্ট FALSE; এই কেসে: TRUE।

Non-CDB-তে ডিফল্ট target সর্বোচ্চের নিচে থাকে, যাতে ঢুকতে পারা প্রতিটি স্টেটমেন্ট চাওয়া সব server পায়। এখানে দুটোই ছিল 4, অর্থাৎ কোনো ফাঁকা জায়গাই ছিল না।

ডিফল্ট সূত্রটি (threads per CPU × CPU_COUNT × concurrent parallel users × ৫) নিজের নোডে বসিয়ে দেখুন। CPU_COUNT ৩২ হলে ফল দাঁড়ায় শতকের ঘরে, তাই 4 কোনো ডিফল্ট নয় - কেউ হাতে বসিয়েছে।

৪. DOP Downgrade আর Statement Queuing-এর পার্থক্য কী?

MANUAL বা LIMITED-এ স্টেটমেন্ট downgrade হয়। খালি server যতটা দেয় সেই DOP-তে চলে, পুল শেষ হলে serial-এ। PARALLEL_MIN_PERCENT সেট থাকলে আর সেই অংশ না মিললে ORA-12827 দিয়ে ব্যর্থ হয়।

AUTO বা ADAPTIVE-এ স্টেটমেন্ট লাইনে দাঁড়ায়। First in, first out ক্রমে অপেক্ষা করে, যতক্ষণ না optimizer-এর বেছে নেওয়া DOP-এর মতো server খালি হয়; অপেক্ষাটি দেখায় resmgr:pq queued হিসেবে।

Serial স্টেটমেন্ট কখনও লাইনে দাঁড়ায় না। RAC-এ parallel statement queuing সব ইনস্ট্যান্সের PARALLEL_SERVERS_TARGET-এর যোগফল ধরে চলে, কিন্তু PARALLEL_FORCE_LOCAL=TRUE থাকলে PX server কেবল coordinator-এর নোডেই চলতে পারে।

৫. প্রোডাকশন RAC-এ PX Starvation দেখতে কেমন ছিল?

সিস্টেমটি ছিল একটি আর্থিক প্রতিষ্ঠানের দুই-নোড Oracle 19c RAC - ব্যাংকিং ও ঋণের workload, পেছনে Data Guard standby। যে নোডটি দেখেছিলাম তাতে ১৬ কোরে ৩২টি CPU আর ২৫০ GB RAM।

এক বিকেলে দ্বিতীয় ইনস্ট্যান্সের এক ঘণ্টার AWR উইন্ডো যা দেখাল:

• শীর্ষ wait: resmgr:pq queued, DB time-এর ৫৫.৭%।
• লাইনে থাকা সেশন: গড়ে ১০৯টি active session parallel server-এর অপেক্ষায়।
• শীর্ষ তিনটি SQL: elapsed time-এর প্রায় ৯৯% PX queue-তে, CPU বা I/O-তে ০%।
• বাকি সব: buffer cache hit ১০০%, হোস্ট ৮৮.৬% অলস, redo, I/O ও interconnect স্বাভাবিক।

তৃতীয় লাইনটি আবার পড়ুন: ওই স্টেটমেন্টগুলো ধীর ছিল না, চলছিলই না। AWR পড়ার সাধারণ ক্রম আমার AWR ও ASH রিপোর্ট পড়ার গাইডে আছে।

৬. অলস ৩২-CPU নোডে ১০৯টি সেশন কেন অপেক্ষা করছিল?

# spfile-এ পাওয়া parallel সেটিং
parallel_degree_policy   = AUTO
parallel_max_servers     = 4
parallel_servers_target  = 4
parallel_force_local     = TRUE

AUTO পুরো workload-এ automatic DOP চালু করে দিয়েছিল। আনুমানিক serial সময় PARALLEL_MIN_TIME_THRESHOLD (ডিফল্ট ১০ সেকেন্ড) ছাড়ালেই স্টেটমেন্ট parallel-এর প্রার্থী।

চারটি server একটি parallel কোয়েরির চেয়েও কম। দুই server set-সহ DOP 2-এর একটি স্টেটমেন্টই চারটি নিয়ে নেয়, পরেরটি লাইনে যায়। FIFO লাইনে এভাবেই একটি SQL তার সময়ের ৯৯% কাটিয়ে দেয়।

প্রতিটি সেটিং আলাদাভাবে যুক্তিসংগত; একসঙ্গে তারা ৩২-CPU মেশিনের সামনে চার প্রসেস চওড়া একটি টার্নস্টাইল বানিয়েছিল। এই 19c ডেটাবেজে optimizer_features_enable='11.2.0.4'-ও দেখেছিলাম, তবে queue-এর কারণ নয় বলে পরের maintenance window-র জন্য চিহ্নিত রেখেছি।

৭. ধাপে ধাপে কীভাবে PX Starvation নির্ণয় করবেন?

এর কিছুই সিস্টেমে কিছু বদলায় না। লাইসেন্স: AWR ও ASH-এ Diagnostics Pack, V$SQL_MONITOR-এ Tuning Pack লাগে; V$PQ_SYSSTAT, V$PX_SESSION ও V$SYSSTAT কোনো pack-এর তালিকায় নেই।

1. AWR-এর শীর্ষ foreground event-এ resmgr:pq queued খুঁজুন।
2. ASH-এর queued sample SQL_ID ধরে গুছিয়ে দেখুন কোন SQL লাইনে।
3. GV$PQ_SYSSTAT-এ দেখুন Servers Busy সর্বোচ্চে, Servers Idle শূন্যে আর Queries Queued বাড়ছে কি না।
4. GV$PX_SESSION-এ DEGREE যদি REQ_DEGREE-এর চেয়ে কম হয়, স্টেটমেন্ট কাটা পড়েছে।
5. GV$SYSSTAT-এ "Parallel operations downgraded" কাউন্টার দেখুন।
6. প্রতিটি ইনস্ট্যান্সের parallel প্যারামিটার gv$parameter থেকে তুলুন।

-- কোন SQL PX queue-তে অপেক্ষা করছে? (ASH, গত এক ঘণ্টা)
SELECT sql_id, COUNT(*) AS samples
FROM   gv$active_session_history
WHERE  event = 'resmgr:pq queued'
AND    sample_time > SYSTIMESTAMP - INTERVAL '1' HOUR
GROUP  BY sql_id
ORDER  BY samples DESC
FETCH FIRST 10 ROWS ONLY;

-- প্রতিটি ইনস্ট্যান্সের PX পুল
SELECT inst_id, statistic, value
FROM   gv$pq_sysstat
WHERE  statistic IN ('Servers Busy', 'Servers Idle', 'Queries Queued')
ORDER  BY inst_id, statistic;

এই কাউন্টারগুলো ইনস্ট্যান্স চালুর পর থেকে জমা হয়, তাই এক ঘণ্টা ব্যবধানে দুটি রিডিং নিয়ে পার্থক্য দেখুন। আর PX Deq wait-এর বেশিরভাগই idle শ্রেণির - সেগুলো বলে parallel কাজ চলছে, ধীর কেন তা নয়।

PX server নোড পেরিয়ে ছড়ালে খরচটা যায় interconnect-এ - উল্টো সেই ব্যর্থতার গল্প আমার Oracle 19c RAC গাইডে আছে।

৮. PARALLEL Hint আর Table DEGREE ভুলবশত কীভাবে থেকে যায়?

সবচেয়ে চেনা উৎস maintenance window-তে চালানো ALTER INDEX ... REBUILD PARALLEL 8। Oracle-এর ALTER INDEX রেফারেন্স স্পষ্ট বলে, এই clause ইনডেক্সের নিজের degree-ও বদলে দেয়, আর পরের সব কাজ সেটিই ব্যবহার করে।

CREATE TABLE ... AS SELECT টেবিলের ক্ষেত্রে একই কাজ করে। আর statement-level /*+ PARALLEL */ hint, policy যা-ই হোক, automatic DOP চালু করে দেয়।

-- যেসব টেবিল ও ইনডেক্স parallel-এ চলতে চাইবে
SELECT 'TABLE' AS obj_type, owner, table_name AS name, TRIM(degree) AS degree
FROM   dba_tables
WHERE  TRIM(degree) NOT IN ('0', '1')
AND    owner NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y')
UNION ALL
SELECT 'INDEX', owner, index_name, TRIM(degree)
FROM   dba_indexes
WHERE  TRIM(degree) NOT IN ('0', '1')
AND    owner NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y')
ORDER  BY 1, 2, 3;

মোচড়টা এখানে: AUTO-তে টেবিল বা ইনডেক্সের degree কার্যকর হয় না, তাই এগুলো ঘুমিয়ে থাকে। MANUAL-এ গেলেই জেগে ওঠে - তাই এই কোয়েরি সমাধানের আগে চালান, পরে নয়।

৯. কোন সমাধান ঠিক: MANUAL, বড় সীমা, নাকি Resource Manager?

আমি MANUAL সুপারিশ করেছিলাম। ওই স্টেটমেন্টগুলোকে parallel বানিয়েছিল auto DOP, নকশা নয়; হোস্টের ৮৮.৬% CPU অব্যবহৃত ছিল; আর প্যারামিটারটি dynamic, ফেরানোও এক লাইনে:

ALTER SYSTEM SET parallel_degree_policy = 'MANUAL' SCOPE = BOTH SID = '*';
-- rollback
ALTER SYSTEM SET parallel_degree_policy = 'AUTO'   SCOPE = BOTH SID = '*';

প্রোডাকশন বলে পরিবর্তনটি change advisory board-এ গিয়েছিল। সীমা বাড়ানোর বিকল্প আমি বাতিল করেছি: তাতে লাইন ছোট হতো ঠিকই, কিন্তু আরও বেশি ট্রানজ্যাকশনাল কাজ parallel-এ চলত, আর ক্ষুধার্ত সিস্টেম হয়ে যেত ডুবন্ত সিস্টেম।

যেখানে batch ও OLTP সত্যিই একই ডেটাবেজে, সেখানে দীর্ঘমেয়াদি উত্তর Resource Manager। প্রতিটি consumer group-এর জন্য parallel_degree_limit_p1, parallel_server_limit ও parallel_queue_timeout দিয়ে DOP, পুলের ভাগ আর লাইনের সময় বেঁধে দিন।

১০. পরিবর্তনের আগে ও পরে কী যাচাই করবেন?

1. আগে: DEGREE কোয়েরি চালিয়ে অপ্রয়োজনীয় অবশিষ্টগুলো NOPARALLEL করুন, আর GV$PQ_SYSSTAT ও downgrade কাউন্টারের baseline রেখে দিন।
2. পরে: পরের তুলনীয় AWR উইন্ডোতে resmgr:pq queued থাকা চলবে না, কারণ MANUAL লাইন বানায় না।
3. পরে: CPU বাড়বে, আর সেটাই উদ্দেশ্য - অপেক্ষারত কাজ এখন চলছে।
4. পরে: "Parallel operations downgraded to serial" বাড়লে বুঝবেন decorated object বা hint চারটি server নিয়ে লড়ছে।

শেষ কথা: Oracle parallel execution বাড়তি হার্ডওয়্যারে বড় কাজের জন্য সচেতনভাবে ব্যবহারের টুল। সমস্যাটি ছিল প্রবেশাধিকারের, সক্ষমতার নয় - তাই হার্ডওয়্যার কেনার আগে queue মাপুন, আমার Oracle পারফরম্যান্স টিউনিং গাইডের top-down পদ্ধতিতে।

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

Oracle-এ resmgr:pq queued মানে কী?

একটি parallel স্টেটমেন্ট parallel statement queue-তে অপেক্ষা করছে, কারণ এটি শুরু হলে সক্রিয় PX server PARALLEL_SERVERS_TARGET ছাড়িয়ে যেত। এটি দেখা যায় PARALLEL_DEGREE_POLICY AUTO বা ADAPTIVE হলে, কিংবা কোনো hint বা Resource Manager directive queuing প্রয়োগ করলে। এটি DB time-এ গোনা হয়, তাই এর বড় অংশ মানে স্টেটমেন্ট শুরু হওয়ার অপেক্ষায় - ধীরে চলছে না।

PARALLEL_MAX_SERVERS আর PARALLEL_SERVERS_TARGET-এর পার্থক্য কী?

PARALLEL_MAX_SERVERS হলো প্রতি ইনস্ট্যান্সে PX server প্রসেসের কঠিন ছাদ। PARALLEL_SERVERS_TARGET বলে statement queuing শুরুর আগে কতগুলো সক্রিয় থাকতে পারে, আর এটি কাজে লাগে কেবল queuing চালু থাকলে। দুটো সমান হলে লাইনের দাগ আর ছাদের মাঝে কোনো জায়গা থাকে না।

চালু ডেটাবেজে PARALLEL_DEGREE_POLICY বদলানো কি নিরাপদ?

প্যারামিটারটি dynamic: ALTER SYSTEM ... SCOPE=BOTH SID='*' রিস্টার্ট ছাড়াই প্রতিটি ইনস্ট্যান্সে বদলায়, আর পুরনো মান দিলে ফিরে যায়। ঝুঁকি আচরণে, প্রাপ্যতায় নয় - MANUAL-এ রয়ে যাওয়া টেবিল ও ইনডেক্সের degree কার্যকর হয়, আর auto DOP-নির্ভর স্টেটমেন্ট serial-এ চলে। আগে DBA_TABLES ও DBA_INDEXES দেখুন এবং স্বাভাবিক change control মানুন।

কোন টেবিল ও ইনডেক্স parallel-এ সেট আছে, কীভাবে খুঁজব?

DBA_TABLES ও DBA_INDEXES-এ 1 বা 0 ছাড়া অন্য DEGREE খুঁজুন; কলামটি টেক্সট হিসেবে থাকে বলে TRIM করুন, আর DEFAULT-কেও parallel ধরুন। অবশিষ্টগুলো সাধারণত আসে parallel index rebuild বা CREATE TABLE AS SELECT থেকে। ALTER TABLE বা ALTER INDEX ... NOPARALLEL দিয়ে রিসেট করুন।

OLTP ডেটাবেজে কি আদৌ parallel query ব্যবহার করা উচিত?

কদাচিৎ, এবং কেবল সচেতনভাবে। Oracle-এর VLDB গাইড বলছে সাধারণ OLTP স্টেটমেন্ট এতে লাভ পায় না, কারণ ছোট কাজে সমন্বয়ের খরচ সাশ্রয়ের চেয়ে বেশি। Index build, data load আর end-of-day batch-এর মতো নির্দিষ্ট কাজে রাখুন, আর policy রাখুন MANUAL-এ।

RAC-এ PARALLEL_FORCE_LOCAL উপকার করে, নাকি ক্ষতি?

দুটোই। TRUE করলে PX server স্টেটমেন্ট শুরু হওয়া নোডেই থাকে, ফলে parallel ট্রাফিক interconnect-এ যায় না। দাম হলো, স্টেটমেন্ট কেবল নিজের নোডের পুল ব্যবহার করতে পারে - তাই সেখানে ছোট PARALLEL_MAX_SERVERS হয়ে যায় শক্ত দেয়াল, যেমনটা এই কেসে হয়েছিল।