ORDS Connection Pool ব্যর্থতা: রিস্টার্টের পর APEX কেন ভাঙে (এবং reboot-নিরাপদ সমাধান)

রিস্টার্ট বা আপগ্রেডের ঠিক পরে APEX বা ORDS ব্যর্থ হলে সমস্যা প্রায় কখনও ডেটাবেজে থাকে না। সাধারণত ORDS হয় নিজের configuration folder খুঁজে পায় না, নয়তো কোনো ORDS connection pool-এর সংরক্ষিত পাসওয়ার্ড আর ডেটাবেজের সঙ্গে মেলে না। এই দুটি জিনিস এই ক্রমে দেখুন, বেশিরভাগ আউটেজ কয়েক মিনিটে শেষ হবে।

মে ২০২৬-এ একটি ফার্মাসিউটিক্যাল কোম্পানির Oracle স্ট্যাকে প্রতিটি APEX লিংক 404 দিচ্ছিল: The request could not be mapped to any database। ডিস্কে আটটি pool ঠিকঠাক ছিল; Tomcat শুধু ORDS-কে বলেনি configuration কোথায় আছে।

১. ORDS connection pool কী?

ORDS connection pool হলো এক সেট ডেটাবেজ কানেকশন, যা Oracle REST Data Services একটি ডেটাবেজের জন্য খোলে ও বারবার ব্যবহার করে; এটি configuration directory-র databases/-এর নিচে একটি folder দিয়ে সংজ্ঞায়িত। প্রতিটি pool একটি runtime ইউজার (সাধারণত ORDS_PUBLIC_USER) হিসেবে লগইন করে, আর folder-এর নামই URL prefix হয়।

তাই sales নামের folder সার্ভ করে /ords/sales/..., আর সংরক্ষিত default folder ধরে সেই সব রিকোয়েস্ট যা অন্য কোনো pool দাবি করে না। পাসওয়ার্ড pool.xml-এ থাকে না, থাকে pool-এর auto-login wallet cwallet.sso-তে।

২. কোন error কোন স্তরের দিকে ইঙ্গিত করে?

24.2-এর আগের রিলিজে এগুলো সবই 503 হয়ে আসে, পার্থক্য দেখা যায় কেবল লগে। 571 আসলে listener সমস্যা; সেটি আমার listener ও TNS ট্রাবলশুটিং গাইডে আছে, আর APEX ইমপোর্টে 413 হলে দেখুন nginx-এর পিছনে 413 সমাধান।

৩. ORDS কীভাবে configuration folder খুঁজে পায়?

Standalone mode-এ (ords serve) উৎস তিনটি: --config অপশন, ORDS_CONFIG environment variable, আর দুটোর কোনোটি না থাকলে বর্তমান working directory। শেষটিই ফাঁদ, কারণ service manager কদাচিৎ সেই folder থেকে ORDS চালায় যেখানে আপনি টেস্ট করেছিলেন।

Tomcat বা WebLogic-এ --config নেই। Oracle-এর deployment গাইড বলে, লোকেশন দিতে হবে config.url system property দিয়ে, অথবা ords war কমান্ডে বানানো WAR দিয়ে।

# $CATALINA_BASE/bin/setenv.sh  (Tomcat চালানো OS ইউজারের মালিকানায়)
export CATALINA_OPTS="$CATALINA_OPTS -Dconfig.url=/etc/ords/config"

WebLogic-এ একই property JAVA_OPTIONS-এ যায়, reboot-নিরাপদ জায়গা setUserOverrides.sh বা সার্ভারের start arguments। Oracle-এর বর্তমান চেকলিস্ট Tomcat 9.0.x ও WebLogic 14.1.2 সমর্থন করে, Java 17 বা 21-এ।

৪. ফার্মাসিউটিক্যাল স্ট্যাকে কী ঘটেছিল?

স্ট্যাকটি সাধারণ: সামনে TLS-সহ Apache, Tomcat 9-এ ords.war, পিছনে একগুচ্ছ Oracle ডেটাবেজ। Configuration-এ ছিল একটি default pool আর গ্রুপের বিভিন্ন ডেটাবেজে ছড়ানো সাতটি নামধারী pool।

Tomcat-এর কমান্ড লাইনে -Dconfig.url ছিলই না, তাই ORDS কোনো pool ছাড়াই চালু হয়েছিল। setenv.sh-এর ওই এক লাইনে সাতটি pool সঙ্গে সঙ্গে ফিরে এল।

অষ্টম, default pool দিচ্ছিল ORA-01017: এক বছরের বেশি পুরনো wallet-এর পাসওয়ার্ড আর ডেটাবেজের সঙ্গে মিলছিল না। Pool-টি নতুন করে কনফিগার করায় নতুন wallet ও নতুন ORDS_PUBLIC_USER পাসওয়ার্ড হলো, ফলে একই ডেটাবেজের আরেকটি pool পুরনো পাসওয়ার্ড নিয়ে 574 দিতে শুরু করল।

# পাসওয়ার্ড prompt-এ দিন - কখনও command-line argument হিসেবে নয়
ords --config /etc/ords/config config --db-pool <pool> secret db.password

এরপর আটটিই সাড়া দিল। শিক্ষা: পাসওয়ার্ড pool-এর নয়, ডেটাবেজ ইউজারের; তাই বদলালে সেই ইউজারের প্রতিটি pool আপডেট করতে হয়। Product folder-এ ভিন্ন নামে রাখা তিনটি বাড়তি ords.war কপিও সরানো হয়েছিল, কারণ একটি WAR-ই সব pool সার্ভ করে।

৫. Upgrade বা reinstall-এর পর pool কেন ভাঙে?

• পাসওয়ার্ড বদলেছে। Reinstall বা reconfiguration ORDS_PUBLIC_USER-এর পাসওয়ার্ড বদলাতে পারে, অথচ একই ডেটাবেজের অন্য pool পুরনোটাই রাখে।
• APEX বসানো হয়েছে ORDS-এর পরে। Install গাইডে ডিফল্ট gateway mode disabled; সে ক্ষেত্রে Oracle বলে plsql.gateway.mode proxied করতে।
• Java বদলেছে। ORDS-এর লাগে Java 17 বা 21। ওই স্ট্যাকে sudo -u oracle JAVA_HOME মুছে দিচ্ছিল; sudo -i -u oracle দিয়ে সমাধান হয়।
• পাসওয়ার্ডের মেয়াদ শেষ। ইউজারের profile-এ PASSWORD_LIFE_TIME থাকলে pool এমন সময়সূচিতে ব্যর্থ হয় যা কেউ লিখে রাখেনি।

WebLogic-এ মনে রাখুন, ORDS নিজের configuration folder থেকে নিজের connection pool বানায়, তাই JDBC data source টিউন করলে কিছু বদলায় না। বিস্তারিত আমার WebLogic গাইডে।

৬. Pool-এর আকার কীভাবে ঠিক করবেন?

Oracle-এর configuration reference অনুযায়ী jdbc.MinLimit-এর ডিফল্ট 2, jdbc.MaxLimit 10, আর jdbc.InactivityTimeout 1800 সেকেন্ড। jdbc.InitialLimit 23.4 ও 24.4 গাইডে 10, কিন্তু 25.4 ও 26.3-এ 0, তাই কোনো ব্লগ থেকে সংখ্যা নকল করবেন না।

ব্যস্ততম ঘণ্টায় কয়েকবার v$session-এ ORDS_PUBLIC_USER, APEX_PUBLIC_USER ও APEX_REST_PUBLIC_USER-এর ACTIVE সেশন গুনুন, সর্বোচ্চ সংখ্যার সঙ্গে কিছু বাড়তি যোগ করে jdbc.MaxLimit ঠিক করুন। এরপর সেটিকে ওই ডেটাবেজের pool সংখ্যা ও ORDS instance সংখ্যা দিয়ে গুণ করে ডেটাবেজের processes ও sessions-এর সঙ্গে মিলিয়ে নিন।

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

1. চলমান ORDS-কে আসলে কী দেওয়া হয়েছে দেখুন, শুধু আপনার deployment যে উৎস পড়ে সেগুলো (অংশ ৩; কমান্ড তালিকার পরের বক্সে)। Standalone (ords serve): কমান্ড লাইনে --config, তারপর environment-এ ORDS_CONFIG, তারপর যে working directory থেকে চালু হয়েছে। Tomcat বা WebLogic (ords.war): JVM-এর কমান্ড লাইনে -Dconfig.url, অথবা ords war দিয়ে deployed WAR-এর ভেতরে বসানো config.url।
2. ডিস্কের pool তালিকা দেখুন: ls /etc/ords/config/databases/ (Windows-এ configuration folder-এ dir)।
3. প্রতিটি pool-এর সেটিং পড়ুন: ords --config /etc/ords/config config --db-pool <pool> list; Source কলামে db.password হওয়া উচিত Pool Wallet।
4. রিস্টার্টের আগে লগ পড়ুন: catalina.out বা WebLogic সার্ভার লগে pool-এর নাম ও ORA- কোড খুঁজুন।
5. শুধু ভাঙাটি নয়, প্রতিটি pool টেস্ট করুন, আর DBA_USERS-এ অ্যাকাউন্টের অবস্থা দেখুন।
6. পরিষ্কারভাবে রিস্টার্ট করুন: পুরনো প্রসেস বন্ধ ও পোর্ট খালি নিশ্চিত করে চালু করুন, তারপর সব আবার টেস্ট করুন।

ধাপ ১ বিস্তারিত, Linux-এ

এই কমান্ডগুলো /proc ও systemd ব্যবহার করে, তাই কেবল Linux-এ চলে। root বা ORDS চালানো ইউজার হিসেবে চালান, কারণ অন্য প্রসেসের environment বা working directory পড়ার আগে kernel অনুমতি যাচাই করে।

# কেবল Linux (systemd + /proc)। ১. চলমান ORDS JVM-এর PID
PID=$(systemctl show -p MainPID --value ords.service)   # অথবা আপনার Tomcat unit-এর নাম
pgrep -af 'org.apache.catalina.startup.Bootstrap|ords\.war|ords serve'   # unit নেই? প্রার্থী প্রসেসগুলো দেখুন

# ২. দুই deployment-এই: JVM যে কমান্ড লাইনে চালু হয়েছে
tr '\0' ' ' < /proc/$PID/cmdline; echo
#    standalone: --config খুঁজুন     Tomcat / WebLogic: -Dconfig.url= খুঁজুন

# ৩. কেবল standalone: ORDS_CONFIG, তারপর যে folder থেকে চালু হয়েছে
tr '\0' '\n' < /proc/$PID/environ | grep '^ORDS_CONFIG='
( cd /proc/$PID/cwd && pwd -P )

# ৪. কেবল Tomcat / WebLogic: `ords war` WAR-এর ভেতরে যে config.url বসিয়েছে
#    (যে WAR আসলে deploy করেছেন সেটি দিন)
unzip -p /path/to/tomcat/webapps/ords.war 'WEB-INF/*.xml' | grep -i -A2 'config.url'

Windows-এ /proc বা systemctl নেই। Oracle-এর deploying ও monitoring গাইডের jps -ml দিয়ে ORDS প্রসেস খুঁজুন, আর Tomcat service বা WebLogic সার্ভার যে Java options নিয়ে চালু হয়েছে তা দেখুন (অংশ ৩)।

"configuration নেই" বলবেন কেবল তখন, যখন আপনার deployment-এর পড়া প্রতিটি উৎস খালি, অথবা এমন folder দেখায় যার databases/-এ কোনো pool নেই। ব্যবহারকারী তখন যা দেখেন: ওই স্ট্যাকে প্রতিটি /ords/ URL 404 দিত, The request could not be mapped to any database।

ওই স্ট্যাকে সুস্থ নামধারী pool 302 দিত। কিন্তু /ords/default/ সুস্থ অবস্থাতেও 404 দিত, তাই default pool টেস্ট করুন একটি আসল অ্যাপ্লিকেশন URL দিয়ে।

৮. সমাধানটি reboot-এ টেকসই করবেন কীভাবে?

শেলে টাইপ করা export লগআউটেই হারায়। লোকেশনটি রাখুন সেই ফাইলে যা service পড়ে: Tomcat-এ setenv.sh, WebLogic-এ setUserOverrides.sh, standalone-এ systemd-এর ExecStart বা ords.conf।

Container চালান মালিক OS ইউজার হিসেবে, root নয়। Configuration folder-এ সব pool-এর wallet থাকে, তাই অনুমতি সীমিত রাখুন এবং প্রতিটি পরিবর্তনের আগে তারিখসহ archive নিন।

শেষে ইচ্ছাকৃত reboot দিন। চালু হওয়া থেকে শেষ pool যাচাই পর্যন্ত কেউ বক্সে হাত না দিলে তবেই টেস্ট পাস; ওই স্ট্যাকে এই টেস্টই প্রমাণ করেছিল setenv.sh সমাধান স্থায়ী।

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

ORDS কেন বলে request could not be mapped to any database?

কারণ কোনো pool URL-টির সঙ্গে মেলেনি, আর রিস্টার্টের পর এর সাধারণ কারণ হলো ORDS একটিও pool লোড করেনি। Tomcat বা WebLogic-এ চলমান JVM-এ -Dconfig.url এবং deployed WAR-এ ords war-এর বসানো config.url আছে কি না দেখুন; standalone-এ দেখুন --config, ORDS_CONFIG এবং ORDS যে folder থেকে চালু হয়েছে।

ORDS configuration folder কোথায় খোঁজে?

Standalone ORDS ব্যবহার করে --config, ORDS_CONFIG, আর দুটোই না থাকলে বর্তমান working directory। Tomcat বা WebLogic-এ লোকেশন আসতে হবে config.url system property বা ords war-এ বানানো WAR থেকে।

ORDS error 574 মানে কী?

ORDS 24.2 থেকে 574 মানে ডেটাবেজ credential ত্রুটি, যেমন pool ইউজারের ভুল বা মেয়াদোত্তীর্ণ পাসওয়ার্ড। পাসওয়ার্ডটি pool-এর wallet-এ থাকে, তাই না মিললে ords config --db-pool <pool> secret db.password দিয়ে রিসেট করুন।

Pool না ভেঙে ORDS_PUBLIC_USER-এর পাসওয়ার্ড কীভাবে বদলাব?

আগে ওই ডেটাবেজে ORDS_PUBLIC_USER হিসেবে লগইন করা প্রতিটি pool-এর তালিকা করুন, কারণ সবাই একটিই পাসওয়ার্ড ভাগ করে। ডেটাবেজে বদলে প্রতিটি pool-এ secret db.password চালান, ORDS রিস্টার্ট দিন, তারপর প্রতিটি pool টেস্ট করুন।

jdbc.MaxLimit-এর ভালো মান কত?

সবার জন্য এক সংখ্যা নেই। ডিফল্ট 10, যা Oracle নিজেই কিছু প্রোডাকশনের জন্য কম বলে মনে করে; পিক সময়ে ACTIVE সেশন মেপে বাড়তি যোগ করুন এবং মোট সংখ্যা ডেটাবেজের সীমার মধ্যে আছে কি না দেখুন।

ORDS standalone mode কি প্রোডাকশনে সমর্থিত?

হ্যাঁ। Oracle-এর deployment গাইড বলে standalone mode প্রোডাকশনে সমর্থিত, যদিও Java EE অ্যাপ্লিকেশন সার্ভারের চেয়ে এর ম্যানেজমেন্ট সুবিধা কম; Oracle এটি HTTPS-এ চালানোর সুপারিশ করে।

Default pool ঠিক থাকলেও /ords/default/ কেন 404 দেয়?

default folder সংরক্ষিত সেই রিকোয়েস্টের জন্য যা অন্য কোনো pool দাবি করে না, তাই একে নাম ধরে ডাকার কথা নয়। এই লেখার স্ট্যাকে /ords/default/ 404 দিলেও ওই pool-এর আসল অ্যাপ্লিকেশন URL স্বাভাবিক কাজ করত।