Oracle AWR ও ASH রিপোর্ট পড়া: Wait-Event ট্রাবলশুটিং

"ডেটাবেজ স্লো হয়ে গেছে।" প্রতিটি DBA এই কথা শোনেন, আর আতঙ্কে দেওয়া উত্তর — parameter পরিবর্তন শুরু করা — সাধারণত পরিস্থিতি আরও খারাপ করে। সুশৃঙ্খল উত্তর হলো ডেটাবেজকেই বলতে দেওয়া যে সে কীসের জন্য অপেক্ষা করছে। Oracle-এর AWR ও ASH রিপোর্ট ঠিক এই কাজটিই করে। ব্যাংকিং, ফার্মা ও ERP সিস্টেমে ১৮+ বছরের প্রোডাকশন ফায়ারফাইটিং শেষে আমি শিখেছি যে প্রায় প্রতিটি performance সমস্যা স্পষ্ট হয়ে ওঠে যখন আপনি এই রিপোর্টগুলো সঠিক ক্রমে পড়েন। এই হলো সেই ক্রম।

১. AWR বনাম ASH — সঠিক লেন্স বেছে নিন

• AWR দুটি snapshot-এর মধ্যেকার কার্যকলাপ সমষ্টিভুক্ত করে (সাধারণত প্রতি ঘণ্টায়)। "সিস্টেমটা আজ বিকেলে স্লো ছিল"-এর জন্য এটি ব্যবহার করুন — trend ও সামগ্রিক load।
• ASH প্রতিটি active session প্রতি সেকেন্ডে একবার sample করে। "দুপুর ২:১৪-তে ৯০ সেকেন্ডের জন্য জমে গিয়েছিল"-এর জন্য এটি ব্যবহার করুন — সংক্ষিপ্ত, তীক্ষ্ণ স্পাইক যা এক ঘণ্টার গড় মসৃণ করে মুছে ফেলবে।

মনে রাখার নিয়ম: ঘণ্টার জন্য AWR, মুহূর্তের জন্য ASH।

২. রিপোর্ট তৈরি করা

-- AWR (pick begin/end snapshot IDs when prompted)
@?/rdbms/admin/awrrpt.sql

-- ASH for a specific window
@?/rdbms/admin/ashrpt.sql

-- list recent snapshots
SELECT snap_id, begin_interval_time
FROM   dba_hist_snapshot
ORDER  BY snap_id DESC FETCH FIRST 12 ROWS ONLY;

AWR window সংকীর্ণ রাখুন — সমস্যাটি যে এক ঘণ্টায় ঘটেছে সেটি একটি ছয়-ঘণ্টার রিপোর্টের চেয়ে ভালো, যেখানে কষ্টটা গড়ে মুছে যায়।

৩. শুরু করুন শীর্ষ থেকে: DB Time ও Load Profile

প্রথমেই wait events-এ স্ক্রল করবেন না। header পড়ুন। DB Time হলো session-গুলো কাজ করা ও অপেক্ষা করায় ব্যয় করা মোট সময়। একে elapsed time-এর সাথে তুলনা করুন: ৬০ মিনিট elapsed অথচ ৬০০ মিনিট DB Time মানে ভারী concurrency।

Load Profile আপনাকে workload-এর আকৃতি জানায় — per second ও per transaction হিসেবে:

• DB Time / sec — গড় active session; "কতটা ব্যস্ত" জানার একক সেরা সংখ্যা।
• Logical ও physical reads — কাজটা memory-তে হচ্ছে নাকি disk-এ?
• Hard parses / sec — উচ্চ মান চিৎকার করে বলে "কোনো bind variable নেই"।
• Redo size, commits, rollbacks — write-এর তীব্রতা ও transaction-এর ধরন।

৪. মূল কেন্দ্র: Top Foreground Wait Events

এই সেকশন র‍্যাঙ্ক করে দেখায় DB Time আসলে কোথায় গেল। শীর্ষের দুই-তিনটি event-ই আপনার সমস্যা — তার নিচের সব কিছুই noise। এগুলো একটি বাক্যের মতো পড়ুন: "ডেটাবেজ তার বেশিরভাগ সময় ____-এর জন্য অপেক্ষায় কাটিয়েছে।" তারপর সেটি ঠিক করুন।

৫. যে Wait Events গুলো আপনি বাস্তবে দেখবেন

• db file sequential read — ডিস্ক থেকে single-block (index) read। উচ্চ = অনুপস্থিত/দুর্বল index, ছোট buffer cache, বা অত্যধিক block পড়া query থেকে physical I/O।
• db file scattered read — multi-block full-scan read। উচ্চ = full table scan যার হয়তো একটি index দরকার, অথবা ইচ্ছাকৃত বড় scan।
• log file sync — session-গুলো COMMIT-এর জন্য redo flush হওয়ার অপেক্ষায়। উচ্চ = অত্যধিক ঘন ঘন commit বা ধীর redo storage। commits/sec এবং log writer latency দেখুন।
• buffer busy waits — একই block-এর জন্য contention; প্রায়ই hot block বা অপর্যাপ্ত freelist/ASSM চাপ।
• library cache / cursor: pin S wait on X — parsing contention, সাধারণত bind variable-এর বদলে literal SQL।
• gc buffer busy / gc cr block busy (RAC) — cross-instance block contention। interconnect latency ও hot-block design পরীক্ষা করুন।
• enq: TX - row lock contention — application locking; একটি session একই row-এ অন্যদের block করছে।
• CPU time শীর্ষে — এটি আদৌ কোনো wait নয়; ডেটাবেজ গণনায় ব্যস্ত। যে SQL CPU পোড়াচ্ছে সেটি খুঁজুন।

৬. Wait থেকে SQL-এর দিকে অনুসরণ করুন

একটি wait event আপনাকে উপসর্গ বলে; SQL সেকশন অপরাধীর নাম বলে। SQL ordered by Elapsed Time এবং by Gets পড়ুন, সবচেয়ে খারাপ SQL_ID সংগ্রহ করুন, এবং এর plan বের করুন:

SELECT * FROM TABLE(
  DBMS_XPLAN.DISPLAY_AWR('&sql_id'));

-- or the live plan from cursor cache
SELECT * FROM TABLE(
  DBMS_XPLAN.DISPLAY_CURSOR('&sql_id', NULL, 'ALLSTATS LAST'));

এবার গল্পটা সম্পূর্ণ হয়: উচ্চ db file sequential read + একটি top SQL যা লক্ষ লক্ষ row-এর ওপর বিশাল INDEX RANGE SCAN করে TABLE ACCESS BY ROWID-এ যাচ্ছে = index বা query-টির কাজ প্রয়োজন।

৭. ক্ষণস্থায়ী স্পাইকের জন্য ASH

যখন জমে যাওয়াটা কয়েক সেকেন্ড স্থায়ী ছিল, তখন সেই window-এর জন্য সরাসরি ASH query করুন:

SELECT event, COUNT(*) AS samples
FROM   v$active_session_history
WHERE  sample_time BETWEEN TIMESTAMP '2026-06-12 14:13:00'
                       AND TIMESTAMP '2026-06-12 14:16:00'
GROUP  BY event
ORDER  BY samples DESC;

প্রতিটি sample ≈ একটি active session-এর এক সেকেন্ড, তাই count-গুলো প্রায় wait-এর সেকেন্ডের কাছাকাছি। আপনি প্রায়ই একটি blocking session বা একটি event দেখবেন যা স্পাইকটিতে প্রাধান্য বিস্তার করেছে, অথচ AWR সেটি সম্পূর্ণ গড় করে মুছে ফেলেছে।

৮. ADDM-কে দ্বিতীয় মতামত দিতে দিন

Oracle-এর Automatic Database Diagnostic Monitor AWR ডেটা পড়ে এবং সহজ ভাষায় findings লেখে — একটি কাজের sanity check, বিচারবুদ্ধির বিকল্প নয়:

@?/rdbms/admin/addmrpt.sql

ADDM findings-কে যাচাই করার সূত্র হিসেবে দেখুন, অন্ধভাবে মানার আদেশ হিসেবে নয়।

৯. একটি পুনরাবৃত্তিযোগ্য Troubleshooting Workflow

1. পরিসর নির্ধারণ করুন — সঠিক time window ও উপসর্গ। এক ঘণ্টাব্যাপী? AWR। কয়েক সেকেন্ড? ASH।
2. DB Time ও Load Profile পড়ুন — কতটা ব্যস্ত, memory-তে নাকি disk-এ, parsing কি কঠিন?
3. শীর্ষ ২–৩টি wait event পড়ুন — ডেটাবেজ কীসের জন্য অপেক্ষা করেছে তার নাম দিন।
4. wait → SQL মেলান — দায়ী statement খুঁজুন এবং এর plan পড়ুন।
5. একটি hypothesis গঠন করুন, একটি পরিবর্তন করুন — index, bind variable, commit frequency, memory।
6. পুনরায় পরিমাপ করুন — বিজয় ঘোষণার আগে নিশ্চিত করুন DB Time কমেছে।

১০. যে ভুলগুলো ঘণ্টার পর ঘণ্টা নষ্ট করে

• buffer cache hit ratio-র পেছনে ছোটা — প্রায় ১০০% ratio এমন একটি query আড়াল করতে পারে যা লক্ষ লক্ষ logical read করছে। ratio নয়, SQL টিউন করুন।
• অতিরিক্ত প্রশস্ত রিপোর্ট — একটি ৪-ঘণ্টার AWR ঘটনাটিকে গড় করে অদৃশ্য করে দেয়।
• একসাথে অনেক কিছু পরিবর্তন করা — আপনি কখনো জানবেন না কোনটি সাহায্য করল (বা ক্ষতি করল)।
• application উপেক্ষা করা — row-lock contention ও literal SQL হলো code-এর সমস্যা, parameter-এর নয়।
• baseline ছাড়া tuning — তুলনার জন্য একটি "ভালো দিনের" AWR রাখুন।

শেষ কথা

যে মুহূর্তে আপনি instrumentation-কে বিশ্বাস করেন, performance tuning অনুমানের খেলা হওয়া বন্ধ করে দেয়। AWR ও ASH উত্তর লুকায় না — যদি আপনি সেগুলো উপর থেকে নিচে পড়েন তাহলে তারা উত্তরটি আপনার হাতে তুলে দেয়: কতটা ব্যস্ত, কীসের জন্য অপেক্ষা, কোন SQL-এর কারণে। স্মৃতি থেকে parameter পরিবর্তনের তাড়না দমন করুন। পরিমাপ করুন, একটি hypothesis গঠন করুন, একটি জিনিস পরিবর্তন করুন, আবার পরিমাপ করুন। এই শৃঙ্খলাই একজন DBA যিনি একটি incident শান্ত করেন আর যিনি তা দীর্ঘায়িত করেন — এই দুইয়ের মধ্যে পুরো পার্থক্য।

যদি আপনার একটি বারবার হওয়া slowdown, মাস-শেষের স্পাইক, বা একটি AWR রিপোর্ট থাকে যেটিতে আরেক জোড়া চোখ চান, চলুন কথা বলি। আমি ব্যাংকিং, ফার্মা ও ERP সিস্টেমের জন্য production Oracle performance নির্ণয় ও টিউন করি এবং দ্রুত আসল bottleneck খুঁজে পেতে আপনাকে সাহায্য করতে পারি।

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