যেকোনো Oracle ত্রুটি নির্ণয়: একজন DBA-র নিয়মতান্ত্রিক পদ্ধতি

বেশিরভাগ Oracle ত্রুটি পদ্ধতিতে নয়, আতঙ্কে সমাধান করা হয়। স্ক্রিনে একটা লাল ORA- জ্বলে ওঠে, ম্যানেজার জিজ্ঞেস করেন "আর কতক্ষণ?", আর শুরু হয় আন্দাজ - কিছু একটা রিস্টার্ট করো, কিছু এডিট করো, ২০১১ সালের একটা ফোরাম ঘেঁটে ভিন্ন সমস্যার জন্য বানানো সমাধান পেস্ট করো। অথচ Oracle ত্রুটি দেখতে যতটা এলোমেলো, আসলে ততটা নয়। প্রতিটি ত্রুটি যে সাবসিস্টেম তাকে তুলেছে তার নাম বলে, একটি নির্দিষ্ট স্তরের দিকে আঙুল তোলে, আর ঠিকভাবে পড়লে - পরের কোথায় দেখতে হবে তা-ও বলে দেয়। এই গাইডটি সেই পুনরাবৃত্তিযোগ্য চার-ধাপের পদ্ধতি, যা দিয়ে আমি যেকোনো ORA-, PLS-, TNS- বা RMAN- ত্রুটিকে হুড়োহুড়ির বদলে শান্ত, দ্রুত সমাধানে বদলে ফেলি।

১. একটি Oracle ত্রুটি দেখতে যতটা, তার চেয়ে বেশি সাজানো

যেকোনো সমাধানের আগে গঠনটা বুঝুন। প্রতিটি Oracle ত্রুটি তিন অংশের:

ORA-00942: table or view does not exist
└┬─┘ └─┬─┘  └──────────────┬─────────────┘
 │     │                   └─ message: মানুষের-পাঠযোগ্য বিবরণ
 │     └─ number: ওই সাবসিস্টেমের নির্দিষ্ট ত্রুটি
 └─ prefix: কোন সাবসিস্টেম তুলেছে

উপসর্গ আপনার হাতে থাকা দ্রুততম সূত্র, অথচ বেশিরভাগ মানুষ এটি পেরিয়ে যায়:

• ORA- - মূল ডেটাবেজ, ক্লায়েন্ট বা সার্ভার দিক। সবচেয়ে বড় পরিবার।
• PLS- - PL/SQL কম্পাইলার। প্যাকেজ, প্রসিডিওর বা ট্রিগারে কম্পাইল-টাইম সমস্যা, রানটাইম ডেটা-সমস্যা নয়।
• TNS- - Oracle Net: নামকরণ, listener, নেটওয়ার্ক পথ। বিস্তারিত আমার listener ও TNS ট্রাবলশুটিং গাইডে।
• RMAN- - ব্যাকআপ ও রিকভারি ম্যানেজার।
• IMP- / EXP- / ORA-39xxx - Data Pump ও পুরোনো export/import টুল।

উপসর্গ আগে পড়লেই, কিছু স্পর্শ করার আগেই আপনি খোঁজার পরিসর অর্ধেক করে ফেলেছেন।

২. ধাপ এক: বার্তাটি আক্ষরিকভাবে পড়ুন

নির্ণয়ের সবচেয়ে সাধারণ ভুল হলো বার্তা উপর-উপর পড়া। Oracle-এর ত্রুটি-টেক্সট সাধারণত নির্ভুল, আর নির্দিষ্ট শব্দগুলো প্রচণ্ড গুরুত্বপূর্ণ।

ORA-00942: table or view does not exist মানে "ডেটাবেজ ভেঙে গেছে" নয়। মানে এই সেশন একটি নির্দিষ্ট অবজেক্ট দেখতে পাচ্ছে না - প্রায় সবসময় একটি অনুপস্থিত schema প্রিফিক্স, অনুপস্থিত grant, বা টাইপো। ORA-01555: snapshot too old এলোমেলো করাপশন নয়; এটি নির্দিষ্টভাবে বলছে যে read consistency-র জন্য দরকারি undo ওভাররাইট হয়ে গেছে (পুরো গল্প আমার ORA-01555 গাইডে)।

নিজেকে অভ্যস্ত করুন বার্তা থেকে বিশেষ্যগুলো বের করতে - অবজেক্ট নাম, constraint নাম, সংখ্যা, ফাইল। ওই বিশেষ্যগুলোই সূত্র। যে ত্রুটি constraint (HR.EMP_PK) নাম ধরে বলে, সে ঠিক কোন primary key লঙ্ঘন হয়েছে তা বলে দিয়েছে; আন্দাজ লাগে না।

৩. ধাপ দুই: স্তরটি চিহ্নিত করুন

উপসর্গ ও আক্ষরিক বার্তা হাতে নিয়ে ত্রুটিটিকে পাঁচটি স্তরের একটিতে রাখুন। এটি ঠিক করে দেয় পরের পাঁচ মিনিট কোথায় খরচ হবে:

1. ক্লায়েন্ট / নাম রিজলিউশন - অনুরোধ কোনো চালু ডেটাবেজেই পৌঁছায়নি (অনেক TNS- ত্রুটি, ORA-12154)।
2. নেটওয়ার্ক / listener - host-এ পৌঁছেছে কিন্তু চালু service-এ নয় (ORA-12541, ORA-12514)।
3. ইনস্ট্যান্স / সেশন - মেমরি, রিসোর্স বা সেশন অবস্থা (ORA-04031 shared pool, ORA-00018 max sessions)।
4. SQL / ডেটা - স্টেটমেন্ট বা ডেটাই সমস্যা (ORA-00942, ORA-00001, ORA-01722, ORA-00060 deadlock - দেখুন আমার locking ও deadlock গাইড)।
5. স্টোরেজ / OS - ডেটাবেজ অপারেটিং সিস্টেমে ঠেকেছে (ORA-01653 cannot extend, ORA-27037 file not found)।

স্তর-শৃঙ্খলাই ক্লাসিক অপচয় থামায় - ক্লায়েন্ট-সাইড নাম-রিজলিউশন ত্রুটির জন্য ডেটাবেজ রিস্টার্ট করা, বা আসলে যা runaway query ছিল তার জন্য মেমরি বাড়ানো।

৪. ধাপ তিন: পুরো ত্রুটি-স্ট্যাক নিন

ক্লায়েন্ট স্ক্রিন সাধারণত এক লাইন দেখায়। আসল নির্ণয়ে পুরো স্ট্যাক দরকার, আর Oracle প্রায় সবসময় যা দেখায় তার চেয়ে বেশি রেকর্ড করে। এক ব্যর্থতা আরেকটিকে ট্রিগার করায় ত্রুটি স্তূপ হয়, আর Oracle সবচেয়ে-সাম্প্রতিক-আগে তালিকা করে:

ORA-06512: at "HR.PROCESS_PAYROLL", line 142
ORA-06512: at line 1
ORA-00001: unique constraint (HR.PAY_RUN_PK) violated   ← মূল কারণ

উপরের ORA-06512 কেবল বলে PL/SQL কোথায় ফেটেছে; নিচের ORA-00001 বলে কেন। সবসময় নিচ পর্যন্ত পড়ুন। আর তুচ্ছ SQL ত্রুটির বাইরে যেকোনো কিছুর জন্য সত্যের উৎসে যান - alert log ও তার trace ফাইল:

-- ডায়াগনস্টিক লোকেশন খুঁজুন
SELECT name, value FROM v$diag_info;
-- alert log + trace ফাইল ADR home-এর নিচে ("Diag Trace")
-- গুরুতর ত্রুটি (ORA-00600/07445) alert log-এর পাশে পুরো trace ফাইল লেখে

alert log আপনাকে সময়, পুরো স্ট্যাক আর ত্রুটির চারপাশে আর কী ঘটেছে তা দেয় - যা ক্লায়েন্ট কখনও দেখায় না।

৫. ধাপ চার: পুনরুৎপাদন ও আলাদা করুন

কিছু বদলানোর আগে তিনটি প্রশ্নের উত্তর দিন: কে এটা পায় (এক ইউজার নাকি সবাই?), কখন (সবসময়, নাকি কেবল লোডের সময়?), আর সবচেয়ে ছোট কী এটা ট্রিগার করে। যে ত্রুটি কেবল এক ইউজার পায় তা grant বা ওই ইউজারের ডেটার দিকে ইঙ্গিত করে; যা সবাই পায় তা অবজেক্ট বা ইনস্ট্যান্সের দিকে।

পুরো অ্যাপ্লিকেশনের বদলে সর্বনিম্ন কেস দিয়ে পুনরুৎপাদন করুন - একটি SELECT, একটি সেশন। আলাদা করা অস্পষ্ট "ERP ত্রুটি ছুড়ছে"-কে "এই একটি query, এই এক ইউজার হিসেবে চালালে, ORA-00942 তোলে"-তে বদলে দেয় - যা আপনি সত্যিই সারাতে পারেন, আর প্রমাণও করতে পারেন যে সেরেছেন।

৬. দ্রুততম প্রথম পাঠ - তারপর যাচাই

এক থেকে চার ধাপ হলো শৃঙ্খলা। কিন্তু যখন আপনার কেবল একটি অচেনা ত্রুটি দ্রুত বুঝতে হবে - বিশেষত আপনার দৈনন্দিন সেটের বাইরের কোনোটি - তখন একটি ভালো ব্যাখ্যা ফোরাম-ঘাঁটাঘাঁটি বাঁচায়।

এজন্যই আমি একটি ফ্রি Oracle Error Explainer বানিয়েছি: যেকোনো ORA-/PLS-/TNS- ত্রুটি পেস্ট করুন, সেকেন্ডে সহজ ভাষায় পান এর মানে কী, সম্ভাব্য কারণ, আর কীভাবে সারাবেন। এর পেছনের AI আমি নিজে স্কোপ ও খরচ-সীমা দিয়ে তৈরি করেছি, আর প্রতিটি উত্তর সেই একই সতর্কবার্তা বহন করে যা আমি সামনাসামনি দিতাম।

কারণ নিয়মটা কখনও বদলায় না: একটি ব্যাখ্যা - টুল, ফোরাম বা সহকর্মীর কাছ থেকে - একটি দ্রুত প্রথম পাঠ, কাজ করার লাইসেন্স নয়। প্রোডাকশনে কোনো সমাধান চালানোর আগে Oracle-এর ডকুমেন্টেশনে যাচাই করুন এবং নন-প্রোডাকশন ডেটাবেজে টেস্ট করুন। উপরের পদ্ধতিই সেই দ্রুত পাঠকে একটি যাচাইকৃত, নিরাপদ পরিবর্তনে বদলে দেয়।

৭. যে ত্রুটিগুলো আপনি আসলেই দেখবেন

গুটিকয় ত্রুটিই বেশিরভাগ বাস্তব ঘটনার জন্য দায়ী। এগুলো ভালোভাবে জানা - আর প্রতিটির জন্য একটি গাইড থাকা - কাজের বড় অংশ:

খেয়াল করুন কতগুলো ডেটা বা SQL সমস্যা, ডেটাবেজ ত্রুটি নয়। বেশিরভাগ Oracle ত্রুটির পেছনে এটাই আশ্বস্ত করা সত্য: ডেটাবেজ সাধারণত ঠিকই আছে; স্টেটমেন্ট, grant বা ডেটাই মনোযোগ চায়।

৮. যখন ত্রুটি-বার্তা আপনাকে বিভ্রান্ত করে

মাঝেমধ্যে উপরের-লাইন ত্রুটি একটি উপসর্গ, রোগ নয়। জানার মতো কয়েকটি প্যাটার্ন:

• ক্যাসকেডিং ত্রুটি। প্রথম লাইন সাধারণ (ORA-06512 "at line N"); সত্যটা স্ট্যাকের নিচে। সবসময় নিচে স্ক্রল করুন।
• ORA-00600 (internal error) ও ORA-07445 (প্রসেস ক্র্যাশ)। এগুলো Oracle বাগ, SQL এডিট করে সারানোর জিনিস নয়। বর্গাকার বন্ধনীর প্রথম আর্গুমেন্ট ও trace ফাইলটি নিন, তারপর My Oracle Support-এ সেই সিগনেচার খুঁজুন - সাধারণত প্যাচসহ একটি পরিচিত বাগে মেলে। প্রোডাকশনে পরীক্ষা করবেন না।
• "সেরেছি কিন্তু ফিরে আসে।" ত্রুটি নির্দিষ্ট সময়ে ফিরলে বার্তাটি পর্যায়ক্রমিক কিছুর উপসর্গ - একটি job, batch load, stats gather - কারণ নয়। alert-log টাইমস্ট্যাম্প আপনার scheduler-এর সঙ্গে মেলান।

৯. নিজের ত্রুটি-রানবুক গড়ুন

সেরা DBA-রা তাঁরা নন যাঁরা প্রতিটি ত্রুটি মুখস্থ করেছেন - তাঁরা তাঁরাই যাঁরা শেষটা লিখে রেখেছেন। প্রতিটি বাস্তব ঘটনার পর চার লাইন লিখে রাখুন: সঠিক ত্রুটি, আসল মূল কারণ, যে সমাধান দিয়েছেন, আর কীভাবে নিশ্চিত করবেন এটা চলে গেছে। এক বছরে এটি আপনার দলের সবচেয়ে মূল্যবান নথি হয়ে ওঠে, কারণ বেশিরভাগ প্রোডাকশন ত্রুটি ফিরে আসে, আর দ্বিতীয়বার লাগবে দুই মিনিট, দুই ঘণ্টা নয়।

এটি একটি সঠিক ডেটাবেজ হেলথ চেকের পেছনের সেই একই মাপো-আগে শৃঙ্খলা: কাজের আগে প্রমাণ, আর পরে একটি লিখিত পথচিহ্ন।

১০. বাস্তব ঘটনা: যে ত্রুটিটাই আসল সমস্যা ছিল না

এক ক্লায়েন্ট মাস-শেষের রিপোর্টিংয়ের সময় ORA-01652 ("unable to extend temp segment") জানাল, আর ঘরের সবার ঝোঁক ছিল temp স্পেস বাড়ানো - বার্তাটা যেন তা-ই চাইছিল। পদ্ধতি ধরে হাঁটায় উত্তরটা বদলে গেল।

আক্ষরিকভাবে পড়া: temp ফুরিয়েছে। আলাদা করা: এটা কেবল একটি রিপোর্টে হচ্ছিল, একজন analyst চালাতেন, মাস-শেষে। পুরো স্ট্যাক ও SQL দেখাল একটিমাত্র query বিশাল sort করছে কারণ একটি সাম্প্রতিক পরিবর্তনের পর একটি join তার predicate হারিয়েছে - দুটি বড় টেবিল Cartesian-join করে ফলাফল temp-এ sort করার চেষ্টা করছিল।

Temp বাড়ালে ত্রুটিটা "সেরে" যেত আর এমন একটি query লুকিয়ে ফেলত যা শত কোটি অপ্রয়োজনীয় রো-তুলনা করছিল। আসল সমাধান ছিল একটি পুনরুদ্ধার করা join শর্ত। ক্লায়েন্ট যে শিক্ষাটা রাখল: ত্রুটি বলেছিল কোথায় ব্যথা, কী ভুল তা নয় - আর চার-ধাপের পদ্ধতিই সেই পার্থক্যটা বলে দেয়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

বিভিন্ন Oracle ত্রুটির উপসর্গগুলোর (prefix) মানে কী?

উপসর্গ কোন সাবসিস্টেম ত্রুটিটি তুলেছে তা বলে দেয়। ORA- হলো মূল ডেটাবেজ (সার্ভার বা ক্লায়েন্ট), PLS- হলো PL/SQL কম্পাইলার, TNS- হলো Oracle Net (নেটওয়ার্ক ও listener), RMAN- হলো ব্যাকআপ ও রিকভারি ম্যানেজার, আর IMP-/EXP-/ORA-39xxx সম্পর্কিত Data Pump-এর সঙ্গে। উপসর্গ পড়লেই বোঝা যায় কোন স্তরে খুঁজতে হবে।

একসঙ্গে কয়েকটি Oracle ত্রুটি স্তূপ হয়ে থাকলে মূল কারণ কীভাবে খুঁজব?

স্ট্যাকটি নিচ থেকে উপরে পড়ুন। Oracle সবচেয়ে সাম্প্রতিক (বাইরের) ত্রুটিটি আগে এবং আসল (মূল) ত্রুটিটি শেষে তালিকাভুক্ত করে। উপরের লাইন প্রায়ই সাধারণ - নিচের লাইনটিই সাধারণত আসল সমস্যা (নির্দিষ্ট অবজেক্ট, constraint বা OS ত্রুটি) নাম ধরে বলে দেয়।

ORA-00600 বা ORA-07445 ত্রুটি নিয়ে কী করব?

ORA-00600 (internal error) ও ORA-07445 (প্রসেস ক্র্যাশ) হাতে সারানোর জন্য নয়। বন্ধনীর প্রথম আর্গুমেন্ট ও alert log থেকে trace ফাইলটি সংগ্রহ করুন, তারপর My Oracle Support-এ সেই আর্গুমেন্ট সিগনেচার খুঁজুন - সাধারণত এটি প্যাচ বা ওয়ার্কঅ্যারাউন্ডসহ একটি পরিচিত বাগে মেলে। আন্দাজ করবেন না; এগুলো Oracle Support-এর জন্য, ট্রায়াল-অ্যান্ড-এরর নয়।

শুধু Google করে প্রথম যে সমাধান পাই সেটা চালিয়ে দেওয়া কি নিরাপদ?

না। ফোরামের উত্তর প্রায়ই ভিন্ন ভার্সন, ভিন্ন মূল কারণ বা প্রসঙ্গহীন, আর ভুল সমাধান প্রোডাকশনে চালালে অবস্থা খারাপ হতে পারে। দ্রুত ব্যাখ্যা ত্রুটিটি বুঝতে ব্যবহার করুন, তারপর সবসময় Oracle-এর ডকুমেন্টেশনে যাচাই করে নন-প্রোডাকশন ডেটাবেজে টেস্ট করে তবেই কাজ করুন।

স্ক্রিন ছাড়া Oracle ত্রুটি আর কোথায় রেকর্ড করে?

alert log হলো মূল রেকর্ড (V$DIAG_INFO ভিউ বা ADR home দিয়ে খুঁজুন), আর গুরুতর ত্রুটিগুলো তার পাশে একটি বিস্তারিত trace ফাইল লেখে। Listener সমস্যাগুলো আলাদাভাবে listener.log-এ লেখা হয়। এগুলো পড়লে পুরো ত্রুটি-স্ট্যাক ও সময় পাওয়া যায়, যা ক্লায়েন্ট স্ক্রিন প্রায়ই লুকিয়ে রাখে।