Oracle Listener ও TNS ট্রাবলশুটিং: ORA-12154, 12514 ও সঙ্গীদের নিয়মতান্ত্রিক সমাধান

Oracle-এর কোনো ত্রুটি-পরিবার সম্মিলিতভাবে TNS ত্রুটির চেয়ে বেশি ঘণ্টা নষ্ট করে না। সকাল ৯টায় ORA-12154, একশো ইউজার আটকে গেছে, আর সবাই আন্দাজে চালাচ্ছে - listener রিস্টার্ট করো, অ্যাপ সার্ভার রিবুট দাও, tnsnames এলোমেলোভাবে এডিট করো। সত্যটা হলো, Oracle কানেক্টিভিটি একটি ছোট, নির্দিষ্ট শিকল - আর প্রতিটি TNS ত্রুটি আপনাকে ঠিক বলে দেয় কোন কড়াটা ভেঙেছে। শিকলটা একবার শিখে নিন, এগুলো পাঁচ-মিনিটের সমাধান হয়ে যাবে। এই গাইড শিকল ধরে হাঁটে, বাস্তবে আপনার দেখা হবে এমন চারটি ত্রুটির মর্ম ভাঙে, আর অনুমান ছাড়াই প্রতিটি স্তর নির্ণয়ের কমান্ডগুলো দেয়।

১. কানেকশনের শিকল - চারটি কড়া, সবসময় একই

SQL*Plus থেকে বিশাল ERP পর্যন্ত প্রতিটি Oracle ক্লায়েন্ট কানেকশন একই চারটি ধাপ পার হয়:

1. নাম রিজলিউশন। ক্লায়েন্ট আপনার কানেক্ট স্ট্রিংকে (@PRODDB) একটি ঠিকানায় রূপান্তর করে: host, port, service name। সাধারণত tnsnames.ora-র মাধ্যমে, নয়তো EZConnect স্ট্রিং (host:port/service) বা LDAP দিয়ে।
2. নেটওয়ার্কে পৌঁছানো। ক্লায়েন্ট ওই host ও port-এ (ডিফল্ট 1521) একটি TCP কানেকশন খোলে।
3. Listener-এর মেলানো। সার্ভারের listener প্রসেস অনুরোধটি পায় এবং তার কাছে রেজিস্টার্ড service-গুলোর মধ্যে চাওয়া service name-টি খোঁজে।
4. হ্যান্ডঅফ। Listener ইনস্ট্যান্সের জন্য একটি সার্ভার প্রসেস তৈরি করে (বা রিডাইরেক্ট করে) এবং পথ থেকে সরে দাঁড়ায়। এরপর থেকে listener আর জড়িত নয় - এজন্যই listener মেরে ফেললেও বিদ্যমান সেশনগুলো কখনও ডিসকানেক্ট হয় না।

শিকলটা মুখস্থ করুন - প্রতিটি ত্রুটি একটি নির্দেশক হয়ে যাবে: 12154 ভাঙে ১ নম্বর কড়ায়, 12541 ও 12170 ভাঙে ২ নম্বরে, 12514 ভাঙে ৩ নম্বরে। নির্ণয় মানে কেবল ক্রম অনুযায়ী শিকল ধরে হাঁটা।

২. ORA-12154: "TNS: could not resolve the connect identifier"

ক্লায়েন্ট ঘর থেকেই বেরোয়নি। আপনার দেওয়া নামটিকে সে ঠিকানায় অনুবাদ করতে পারেনি - তাই এটি সবসময় ক্লায়েন্ট-সাইড সমস্যা, আর এর জন্য ডেটাবেজ সার্ভার রিস্টার্ট করা নিছক কুসংস্কার।

# 1. Which tnsnames.ora is the client actually reading?
#    Check TNS_ADMIN first - it overrides the default location
echo %TNS_ADMIN%           (Windows)    /  echo $TNS_ADMIN    (Linux)
# default: $ORACLE_HOME/network/admin/tnsnames.ora

# 2. Test resolution + reachability in one shot
tnsping PRODDB

যে ক্রমে আমি অপরাধীদের পাই: ক্লায়েন্ট যে tnsnames.ora পড়ছে সেখানে alias-টিই নেই (এক মেশিনে একাধিক Oracle home থাকা হলো ক্লাসিক ফাঁদ - প্রত্যেকটির নিজস্ব network/admin আছে); alias-এ টাইপো বা শেষে বাড়তি স্পেস; হাতের এডিটে ভাঙা বন্ধনী - একটি বন্ধনী মিস হলে তার নিচের প্রতিটি এন্ট্রি অচল; কিংবা এমন মেশিন যার TNS_ADMIN কোনো বাসি জায়গায় নির্দেশ করছে। সন্দেহ হলে EZConnect দিয়ে ফাইলটাই এড়িয়ে যান - sqlplus user@//dbhost:1521/PRODDB - তা কাজ করলে আপনার ফাইল বা ভ্যারিয়েবলই সমস্যা, নিশ্চিত।

৩. ORA-12541 ও ORA-12170: কারও নাগাল না পাওয়া

ORA-12541 "TNS: no listener" মানে নাম রিজলিউশন কাজ করেছে, প্যাকেট host ও port-এ পৌঁছেছে - কিন্তু সেখানে কিছুই শুনছিল না। হয় listener বন্ধ, নয়তো ক্লায়েন্ট যা ভাবছে তার চেয়ে ভিন্ন কোনো port-এ সে শুনছে।

# On the database server:
lsnrctl status                       # is it up? which ports?
ps -ef | grep tnslsnr                # is the process even alive?
lsnrctl start                        # if down

# From the client: is the port reachable at all?
ping dbhost
tnsping PRODDB

ORA-12170 "TNS: connect timeout" আরও সূক্ষ্ম: প্যাকেট বেরিয়ে যায় আর কিছুই কখনও উত্তর দেয় না। দশবারের নয়বার এটি একটি ফায়ারওয়াল - 1521-এর ট্রাফিক নিঃশব্দে ফেলে দিচ্ছে - লোকাল OS ফায়ারওয়াল (firewalld/Windows Firewall), সেগমেন্টের মাঝের নেটওয়ার্ক ফায়ারওয়াল, বা ক্লাউড security group। চেনার উপায়: ping কাজ করে (ICMP অনুমোদিত) কিন্তু port টেস্ট ব্যর্থ হয়। Oracle-কে দোষ দেওয়ার আগে শুধু host নয়, নির্দিষ্টভাবে port-টি টেস্ট করুন।

৪. ORA-12514: Listener আপনার Service-কে চেনে না

"TNS: listener does not currently know of service requested in connect descriptor" - আমার প্রিয় ত্রুটি, কারণ এটি এত নিখুঁত। শিকল listener পর্যন্ত পুরোটাই কাজ করেছে; শুধু listener-এর তালিকায় ওই নামের কোনো service নেই। সে ঠিক কী কী চেনে দেখে নিন:

lsnrctl services
# or the shorter view:
lsnrctl status
# look at the "Services Summary" - each service, each instance, its state

তিনটি ক্লাসিক কারণ। ডেটাবেজ বন্ধ (বা সবে চালু হচ্ছে) - ইনস্ট্যান্স নেই, registration-ও নেই, আর সমাধান হলো ডেটাবেজ চালু করা, listener নয়। ক্লায়েন্ট যা চাইছে service name তার থেকে ভিন্ন - ক্লায়েন্ট চাইছে PRODDB কিন্তু ডেটাবেজ রেজিস্টার করেছে PRODDB.WORLD বা কোনো কাস্টম service; SHOW PARAMETER service_names ও V$SERVICES-এর সঙ্গে মিলিয়ে দেখুন। Registration এখনও ঘটেনি - যা আমাদের নিয়ে যায় সেই মেকানিজমে, যার কথা বেশিরভাগ মানুষকে কখনও বলাই হয়নি।

৫. Dynamic বনাম Static Registration - অনুপস্থিত মানসিক মডেলটি

Dynamic registration: ইনস্ট্যান্সের LREG ব্যাকগ্রাউন্ড প্রসেস listener-এর সঙ্গে যোগাযোগ করে বলে "আমি ইনস্ট্যান্স PRODDB, এই service-গুলো দিচ্ছি।" সে এটি করে স্টার্টআপে এবং মোটামুটি প্রতি ৬০ সেকেন্ডে আবার চেষ্টা করে। এটিই দুটি নিত্যদিনের রহস্যের ব্যাখ্যা: কেন সদ্য চালু হওয়া ডেটাবেজ এক মিনিট পর্যন্ত 12514 দেয় (registration এখনও চলেনি - ALTER SYSTEM REGISTER; দিয়ে জোর করুন), আর কেন ডেটাবেজের পরে চালু হওয়া listener-ও এক মিনিট পরে নিজে নিজেই service-গুলো শিখে নেয়।

Static registration: আপনি service-টি listener.ora-তে হার্ড-কোড করেন:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = PRODDB)
      (ORACLE_HOME   = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME      = PRODDB)
    )
  )

Static এন্ট্রি lsnrctl-এ status UNKNOWN হিসেবে দেখায় (listener যাচাই না করেই সেগুলো ঘোষণা করে) - এটি স্বাভাবিক, ত্রুটি নয়। Static registration দরকার ঠিক সেই মুহূর্তগুলোর জন্য যখন dynamic কাজ করতে পারে না: DOWN বা কেবল MOUNTED অবস্থার ডেটাবেজে দূর থেকে কানেক্ট করা - RMAN ডুপ্লিকেশন, Data Guard বিল্ড, রিমোট startup। এজন্যই DUPLICATE রানবুকগুলো সবসময় auxiliary-র জন্য একটি static listener এন্ট্রি দিয়ে শুরু হয়, আর Data Guard সেটআপ দুই পাশেই static এন্ট্রি সংজ্ঞায়িত করে।

৬. পাঁচ-মিনিটের পদ্ধতি, ক্রম অনুযায়ী

যখন "অ্যাপ্লিকেশন কানেক্ট করতে পারছে না," কিছু রিস্টার্ট করার সব প্রবৃত্তি দমন করে শিকল ধরে হাঁটুন:

1. ব্যর্থ ক্লায়েন্ট থেকে tnsping ALIAS - ব্যর্থ? কড়া ১: tnsnames/TNS_ADMIN ঠিক করুন। (EZConnect টেস্ট দিয়ে নিশ্চিত হোন।)
2. host:1521-এ port টেস্ট - refused বা timeout? কড়া ২: listener বন্ধ নাকি ফায়ারওয়াল। সার্ভারে lsnrctl status-ই কোনটি তা ঠিক করে দেয়।
3. lsnrctl services - alias রিজলভ হয়, port উত্তর দেয়, তবু 12514? কড়া ৩: চাওয়া service-কে রেজিস্টার্ডগুলোর সঙ্গে মেলান; ডেটাবেজ OPEN কিনা দেখুন; সবে চালু হয়ে থাকলে ALTER SYSTEM REGISTER; দিন।
4. কানেক্ট হয় কিন্তু ধীরে, বা লগইন-ঝড়ে ঝুলে যায় - listener log-এ হার দেখুন, আর অ্যাপের connection pooling; listener log ($ORACLE_BASE/diag/tnslsnr/.../trace/listener.log) প্রতিটি অনুরোধের টাইমস্ট্যাম্প রাখে - এটিই সেই ফরেনসিক রেকর্ড, যার অস্তিত্বের কথাই বেশিরভাগ মানুষ ভুলে যায়।

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

৭. রেখে দেওয়ার মতো কিছু প্রোডাকশন নোট

• Listener-এর সঙ্গে বিদ্যমান সেশন কখনও মরে না। Listener কেবল নতুন কানেকশনের মধ্যস্থতাকারী। দুপুরেও রিস্টার্ট করতে পারেন লগইন-করা ইউজারদের না ছুঁয়ে - আর উল্টোদিকে, ইতিমধ্যে কানেক্টেড সেশনগুলোর জন্য রিস্টার্ট কিছুই ঠিক করে না।
• RAC-এ ক্লায়েন্টরা SCAN listener-দের সঙ্গে কথা বলে, যারা node listener-এ রিডাইরেক্ট করে - তাই "কোন listener?" প্রশ্নের তিনটি উত্তর আছে, আর lsnrctl status চালাতে হবে সঠিকটির বিরুদ্ধে (lsnrctl status LISTENER_SCAN1)। শিকল একই, শুধু একটি বাড়তি ধাপ - দেখুন RAC গাইড।
• Log রোটেশনের অভ্যাস গড়ুন। listener.log চিরকাল বাড়তেই থাকে, আর কয়েক-গিগাবাইটের log lsnrctl-কে মন্থর করে দেয়; নিয়মিত রোটেট করুন।
• নিরাপত্তা: listener একটি নেটওয়ার্ক-মুখী সার্ভিস - ত্রৈমাসিক RU দিয়ে প্যাচড রাখুন (দেখুন প্যাচিং গাইড) আর পুরনো ভার্সনে কখনও অথেনটিকেশন ছাড়া অ্যাডমিনযোগ্য অবস্থায় ফেলে রাখবেন না।

৮. একটি বাস্তব কেস: সোমবার সকালের লকআউট

এক ক্লায়েন্ট আতঙ্কে ফোন করলেন: সপ্তাহান্তের OS প্যাচের পর কোনো অ্যাপ্লিকেশন ইউজার কানেক্ট করতে পারছে না - সর্বত্র ORA-12170 timeout, আর টিম ইতিমধ্যে ডেটাবেজ দুবার রিস্টার্ট করে ফেলেছে (তাতে অবস্থা আরও খারাপ - যে সেশনগুলো ঠিক ছিল সেগুলোও মরে গেল)। শিকল ধরে হাঁটতে লাগল আট মিনিট: tnsping সঙ্গে সঙ্গে রিজলভ করল (কড়া ১ ঠিক আছে), কিন্তু 1521-এ port টেস্ট timeout হলো অথচ ping সফল - ফায়ারওয়ালের স্বাক্ষর। OS প্যাচটি ডিফল্ট রুলসেটসহ firewalld আবার চালু করে দিয়েছিল, যা নিঃশব্দে 1521 ফেলে দিচ্ছিল।

একটি firewall-cmd --permanent --add-port=1521/tcp আর একটি reload - সব কানেক্ট হয়ে গেল। ক্লায়েন্ট যে শিক্ষাটা মনে রেখেছিলেন তা ফায়ারওয়াল কমান্ড নয় - বরং এই যে ডেটাবেজের দুটি রিস্টার্ট ছিল শূন্য ডায়াগনস্টিক মূল্যের বিশুদ্ধ ক্ষতি। শিকলই বলে দেয় কোথায় দেখতে হবে; আগে সেখানেই দেখুন।

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

ORA-12154 আর ORA-12514-এর পার্থক্য কী?

ORA-12154 মানে ক্লায়েন্ট কানেক্ট নামটিকে একটি ঠিকানায় রূপান্তরই করতে পারেনি - এটি tnsnames.ora বা TNS_ADMIN-এর ক্লায়েন্ট-সাইড সমস্যা। ORA-12514 মানে ক্লায়েন্ট listener পর্যন্ত সফলভাবে পৌঁছেছে, কিন্তু অনুরোধ করা নামে listener-এর কাছে কোনো service রেজিস্টার্ড নেই - অর্থাৎ সমস্যাটা সার্ভার সাইডে, service registration বা বন্ধ হয়ে থাকা ডেটাবেজে।

ORA-12154 দ্রুত কীভাবে সারাব?

ক্লায়েন্ট আসলে কোন tnsnames.ora পড়ছে তা নিশ্চিত করুন (TNS_ADMIN দেখুন, আর মনে রাখুন প্রতিটি Oracle home-এর নিজস্ব ফাইল আছে), alias-টি সঠিক বন্ধনীসহ আছে কিনা যাচাই করুন, তারপর tnsping দিয়ে টেস্ট করুন। ক্রস-চেক হিসেবে user@//host:1521/service-এর মতো EZConnect স্ট্রিং চেষ্টা করুন - তা কানেক্ট হলে ফাইল বা ভ্যারিয়েবলটাই নিশ্চিতভাবে সমস্যা।

ডেটাবেজ চালু করার ঠিক পরেই ORA-12514 আসে কেন?

কারণ service registration গতিশীল: LREG প্রসেস স্টার্টআপে এবং মোটামুটি প্রতি ৬০ সেকেন্ডে ইনস্ট্যান্সের service-গুলো listener-এর কাছে রেজিস্টার করে। স্টার্টআপের পর এক মিনিট পর্যন্ত listener হয়তো service-টি এখনও চেনে না। ALTER SYSTEM REGISTER তাৎক্ষণিক registration বাধ্য করে।

listener.ora-তে static registration কখন দরকার?

যখনই এমন ডেটাবেজে দূর থেকে কানেক্ট করতে হবে যা OPEN নয় - NOMOUNT auxiliary-তে RMAN DUPLICATE, Data Guard বিল্ড, বা রিমোট startup/shutdown। Dynamic registration কেবল ইনস্ট্যান্স চলাকালেই কাজ করে, তাই ওই পরিস্থিতিগুলোতে service-টি listener.ora-তে হার্ড-কোড করতে হয়। Static এন্ট্রি lsnrctl-এ status UNKNOWN দেখানো স্বাভাবিক।

Listener রিস্টার্ট করলে কি ইউজাররা ডিসকানেক্ট হয়?

না। Listener কেবল নতুন কানেকশনের মধ্যস্থতা করে - সেশন একবার স্থাপিত হয়ে গেলে listener পথ থেকে পুরোপুরি সরে যায়। রিস্টার্ট ইতিমধ্যে-কানেক্টেড সেশনগুলোর কোনো উপকারও করে না, ক্ষতিও করে না; রিস্টার্ট চলাকালে কেবল নতুন কানেকশন তৈরির সক্ষমতাই প্রভাবিত হয়।