413 Request Entity Too Large: nginx-এর পিছনে আপনার Oracle APEX ইমপোর্ট কেন ব্যর্থ হয় (এবং সঠিক সমাধান)

APEX App Builder-এ Import চাপলেন, এক্সপোর্ট ফাইল বাছলেন - আর সাদা একটা পাতা এলো: 413 Request Entity Too Large, নিচে ছোট করে লেখা nginx/1.14.1। URL-এ APEX-এর নাম থাকে, তাই সবাই খোঁজা শুরু করে সেখানেই। জায়গাটা ভুল। 413 এসেছে আপনার reverse proxy থেকে, যেটি ORDS বা APEX একটি বাইটও দেখার আগেই আপলোডটি বাতিল করে দিয়েছে। এই লেখায় এক লাইনের সমাধান, ঠিক কোথায় বসাতে হবে, আর কাজ হয়েছে কি না তা আশা করার বদলে প্রমাণ করার উপায় আছে।

১. 413 Request Entity Too Large আসলে কী বোঝায়?

413 Request Entity Too Large একটি HTTP স্টেটাস কোড, যার মানে সার্ভার আপনার রিকোয়েস্ট প্রক্রিয়া করতে অস্বীকার করেছে কারণ বডিটি তার নির্ধারিত সর্বোচ্চ সীমা ছাড়িয়ে গেছে। সার্ভার পুরো আপলোডটি পড়েইনি। এটি ঘোষিত content length দেখেছে, বড় মনে করেছে, আর সঙ্গে সঙ্গে উত্তর দিয়ে দিয়েছে।

শেষ কথাটি দেখতে যত ছোট, গুরুত্বে তত বড় নয়। বাতিলটা ঘটে রিকোয়েস্ট পথের একদম সামনে, তাই আপনার APEX বা ORDS লগে কিছুই দেখা যায় না।

অর্থাৎ ত্রুটিটি বলছে না যে আপনার অ্যাপ্লিকেশন APEX-এর জন্য বড়। বলছে, মাঝপথের একজনের কাছে "বড়" শব্দের মাপ আপনার চেয়ে ছোট।

২. দোষ কেন nginx-এর, APEX বা ORDS-এর নয়

ত্রুটি পাতাটা আরেকবার দেখুন। নিচে nginx/1.14.1 লেখা সাদা পাতা nginx-এর নিজের বিল্ট-ইন আউটপুট, APEX-এর কোনো স্ক্রিন নয়।

APEX-এর ত্রুটি APEX-এর মতোই দেখায়: সাজানো পাতা, একটি এরর কোড, সাধারণত এমন বার্তা যা খুঁজে দেখা যায়। ORDS-এর ত্রুটি সাধারণত JSON বা Java stack trace। মাঝখানে বসা একটি হেডিং আর নিচে সার্ভারের ভার্সন - এটি proxy নিজেই উত্তর দেওয়ার স্বাক্ষর।

একটি সাধারণ APEX ডিপ্লয়মেন্টে যত স্তর থাকে, মানুষ একসঙ্গে তত মনে রাখে না:

1. ব্রাউজার আপনার এক্সপোর্ট ফাইলটি wwv_flow.accept-এ POST করে।
2. nginx সেটি ৮০ বা ৪৪৩ পোর্টে পায় এবং client_max_body_size-এর সঙ্গে সাইজ মেলায়।
3. ORDS - সাধারণত Tomcat-এর ভেতরে - proxy করা রিকোয়েস্ট পায়, আর তার নিজের বডি সীমা আছে।
4. ডেটাবেজ শেষে APEX ইঞ্জিনের মাধ্যমে ইমপোর্ট চালায়।

এই প্রতিটি স্তরই আপলোড বাতিল করতে পারে, আর প্রত্যেকে আলাদা ত্রুটি দিয়ে করে। কোন স্তর উত্তর দিয়েছে তা পড়তে শেখা ঘণ্টা বাঁচায় - ঠিক যেমন TNS ত্রুটিকে কানেকশনের শিকল হিসেবে পড়া listener সমস্যাকে পাঁচ-মিনিটের কাজে নামিয়ে আনে।

413 বলে দিচ্ছে এটি ছিল দ্বিতীয় স্তর। ওখান থেকেই শুরু করুন, আন্দাজ বন্ধ করুন।

৩. সমাধান: client_max_body_size-এর সঠিক জায়গা

একটি ডিরেক্টিভেই কাজ হয়। কোথায় বসাচ্ছেন সেটিই ঠিক করে দেয় এটি আসলে প্রযোজ্য হবে কি না।

সাধারণ Red Hat বা Oracle Linux ইনস্টলে ORDS proxy প্রায়ই nginx.conf-এ থাকেই না। সেটি থাকে নিজের আলাদা ফাইলে, একটি include দিয়ে টানা:

# /etc/nginx/conf.d/ords.conf - আসল vhost
server {
    listen 80 default_server;
    server_name _;
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

ওই server ব্লকের ভেতরেও ডিরেক্টিভটি দিতে পারতেন। তবে আরও ভালো জায়গা আছে।

বদলে /etc/nginx/nginx.conf-এর http ব্লকে বসান - তাহলে প্রতিটি virtual host এটি পাবে, পরে conf.d-তে যোগ হওয়া যেকোনো কিছুসহ:

http {
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # ORDS-এর মধ্য দিয়ে APEX ইমপোর্টের জন্য বাড়ানো
    client_max_body_size 500M;
    client_body_timeout  300s;
    proxy_read_timeout   300s;
    proxy_send_timeout   300s;

    include /etc/nginx/conf.d/*.conf;
}

চলমান সার্ভিসে হাত দেওয়ার আগে যাচাই করুন:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F)
nginx -t
systemctl reload nginx

nginx -t কখনও বাদ দেবেন না। একটি সেমিকোলন বাদ পড়লেই reload ব্যর্থ হবে, আর তখন ইমপোর্টের বদলে আপনি একটি মৃত ওয়েব স্তর নিয়ে বসে থাকবেন।

উত্তরাধিকার নিয়ে একটি সতর্কতা। সবচেয়ে নির্দিষ্ট ব্লকটি জেতে, তাই ORDS server ব্লকের ভেতরে বসে থাকা ছোট client_max_body_size চুপচাপ আপনার গ্লোবাল বড় মানটিকে বাতিল করে দেয়। খুঁজে দেখুন:

grep -rn "client_max_body_size" /etc/nginx/

৪. 500M কি সঠিক সংখ্যা?

সম্ভবত না - আর আমার সংখ্যা টুকে নেওয়ার বদলে দশ সেকেন্ড ভেবে নেওয়া ভালো।

সাধারণ একটি APEX অ্যাপ্লিকেশন এক্সপোর্ট কয়েক মেগাবাইটের। অনেক পেজ আর প্রচুর স্ট্যাটিক ফাইলসহ বড় অ্যাপ্লিকেশনও খুব কম সময়েই ৫০ MB পার করে।

তাই 500M উদার ফাঁকা জায়গা, বাধ্যবাধকতা নয়। বিনিময়ে যা সেট করবেন, একজন আক্রমণকারীও ততটাই আপনার দিকে POST করতে পারবে, আর প্রতিটি বড় রিকোয়েস্ট buffer করতে worker-এর মেমরি ও ডিস্ক খরচ হয়।

আমার পরামর্শ: ইন্টারনেটমুখী APEX ইনস্ট্যান্সে 100M রাখুন। খুব বড় মান রাখুন কেবল অভ্যন্তরীণ বিল্ড সার্ভারে, যেখানে পোর্টে কে পৌঁছাতে পারে তা আপনি নিয়ন্ত্রণ করেন।

৫. টাইমআউট কেন সাইজের মতোই গুরুত্বপূর্ণ

এই অংশটাই মানুষকে দ্বিতীয়বার ফোরামে ফেরায়, এই বিশ্বাস নিয়ে যে সমাধানটা কাজ করেনি।

আপনি client_max_body_size বাড়ালেন, 413 চলে গেল, আর ইমপোর্ট এখন নব্বই সেকেন্ড চলে 504 Gateway Timeout দিয়ে মরে গেল। ত্রুটি আলাদা, মূল কারণ একই: রিকোয়েস্টটি বড় এবং ধীর।

এটি নিয়ন্ত্রণ করে তিনটি ডিরেক্টিভ:

• client_body_timeout - ব্রাউজার থেকে আপলোড নেওয়ার সময় দুটি read-এর মাঝে nginx কতক্ষণ অপেক্ষা করবে।
• proxy_read_timeout - রিকোয়েস্ট ORDS-কে দেওয়ার পর উত্তরের জন্য nginx কতক্ষণ অপেক্ষা করবে।
• proxy_send_timeout - ORDS-এর কাছে রিকোয়েস্ট পাঠাতে nginx কতটা সময় দেবে।

APEX ইমপোর্ট দ্রুত ফাইল কপি নয়। ডেটাবেজ এক্সপোর্টটি পার্স করে পেজ, রিজিয়ন, আইটেম ও shared component বানায় - আর এই পুরো সময় HTTP কানেকশনটি খোলা থাকে।

ধীর অফিস আপলোডে ৫ Mbps লাইনে ৪০ MB এক্সপোর্ট পৌঁছাতেই এক মিনিটের বেশি লাগে। ৬০ সেকেন্ডের ডিফল্ট টাইমআউট সেটি মাঝপথে কেটে দেবে।

তিনটিকেই 300s করুন, সমস্যাটি আর কপাল-নির্ভর থাকবে না।

৬. Reload, restart নয় - আর যে ফাঁদে আমি পড়েছিলাম

systemctl reload nginx ব্যবহার করুন। Reload নতুন কনফিগ নিয়ে নতুন worker চালু করে আর পুরনোগুলোকে ধীরে অবসরে পাঠায়, তাই চলমান কানেকশন ছিঁড়ে যায় না।

restart পুরো সার্ভিসটাই নামিয়ে দেয়। শেয়ার্ড APEX ইনস্ট্যান্সে এর মানে প্রত্যেক ডেভেলপার এডিটের মাঝপথে সেশন হারায় - কোনো লাভ ছাড়াই।

এখন ফাঁদটা। reload সত্যিই হয়েছে কি না নিশ্চিত হতে আমি কনফিগ ফাইলের টাইমস্ট্যাম্প nginx master প্রসেসের স্টার্ট টাইমের সঙ্গে মিলিয়েছিলাম। Master চালু হয়েছিল দশ দিন আগে, তাই আমি সিদ্ধান্ত নিলাম নতুন কনফিগ লোড হয়নি।

সিদ্ধান্তটি ভুল ছিল। Reload একই master প্রসেস ও PID রাখে - কেবল worker বদলায়। Master-এর স্টার্ট টাইম বলে nginx শেষ কবে restart হয়েছে, reload নিয়ে সেটি কিছুই বলে না।

সঠিক পরীক্ষা কনফিগ ফাইলের সঙ্গে worker-এর স্টার্ট টাইম মেলায়:

# কনফিগ শেষ কবে লেখা হয়েছে?
stat -c %y /etc/nginx/nginx.conf

# বর্তমান worker-গুলো কখন চালু হয়েছে?
ps -eo pid,lstart,cmd | grep '[n]ginx: worker'

Worker কনফিগ ফাইলের চেয়ে নতুন হলে আপনার পরিবর্তন সক্রিয়। পুরনো হলে আপনি এডিট করেছেন কিন্তু reload দিতে ভুলে গেছেন।

আরও ভালো - এই ফরেনসিক বাদ দিয়ে সরাসরি আচরণটাই পরীক্ষা করুন।

৭. সীমা সত্যিই সক্রিয় কি না প্রমাণ করবেন কীভাবে

কনফিগ ফাইল ইচ্ছার কথা বলে। চলমান সার্ভার কী করে তা বলে একটি টেস্ট। এটি পনেরো সেকেন্ডের কাজ:

# ৫ MB ডামি পেলোড বানান
dd if=/dev/zero of=/tmp/blob.bin bs=1M count=5

# proxy-র মধ্য দিয়ে এমন পথে POST করুন যা নেই
curl -s -o /dev/null -w "%{http_code}\n" \
     -X POST --data-binary @/tmp/blob.bin \
     http://127.0.0.1/ords/__sizetest__

rm -f /tmp/blob.bin

ফলাফল এভাবে পড়ুন:

• 404 - সফল। nginx ৫ MB বডি নিয়েছে এবং ORDS-কে দিয়েছে, ORDS ঠিকভাবেই বলেছে এমন কোনো পথ নেই। ১ MB ডিফল্ট থাকলে এই রিকোয়েস্ট ORDS পর্যন্তই পৌঁছাত না।
• 413 - আপনার নতুন সীমা সক্রিয় নয়। হয় reload হয়নি, নয়তো আরও নির্দিষ্ট কোনো ব্লক এটিকে বাতিল করছে।

এই টেস্ট আমার পছন্দ কারণ এখানে "ভালো" উত্তরটাই একটি ত্রুটি। আপনি দেখছেন না পথটি কাজ করে কি না; দেখছেন কোন স্তর উত্তর দিল - আর ORDS থেকে আসা 404-ই প্রমাণ যে proxy বডিটি যেতে দিয়েছে।

__sizetest__-এর মতো ইচ্ছাকৃত নকল পথ ব্যবহার করুন, যাতে সত্যিকার APEX endpoint বা সেশন স্টেটে কখনও হাত না পড়ে।

আরও একটি সত্যের সূত্র জানার মতো। nginx যখন সত্যিই বডি বাতিল করে, তখন সে error log-এ নির্দিষ্ট একটি লাইন লেখে - সঙ্গে বাইট সংখ্যা:

grep 'too large body' /var/log/nginx/error.log | tail
grep -c ' 413 ' /var/log/nginx/access.log

এগুলো খালি আসছে অথচ ব্রাউজারে এখনও 413 দেখাচ্ছে? তাহলে রিকোয়েস্টটি সার্ভার পর্যন্ত পৌঁছায়ইনি - আপনি একটি ক্যাশ করা ত্রুটি পাতা দেখছেন। ব্যর্থ URL রিলোড করার বদলে হার্ড-রিফ্রেশ দিয়ে ইমপোর্ট আবার শুরু করুন।

৮. 413 গেছে, কিন্তু ইমপোর্ট এখনও ব্যর্থ

ভালো খবর, যদিও শুনতে তেমন লাগে না। আলাদা ত্রুটি মানে আপনি এক স্তর নিচে নেমেছেন।

ORDS সাধারণত Tomcat-এর ভেতরে চলে, আর রিকোয়েস্ট বডি নিয়ে Tomcat-এর নিজের মত আছে। দুটি connector অ্যাট্রিবিউট গুরুত্বপূর্ণ:

• maxPostSize - কন্টেইনার কত ফর্ম ডেটা পার্স করবে তার সীমা। বাড়ান, বা -1 দিয়ে সীমা তুলে দিন।
• maxSwallowSize - রিকোয়েস্ট বাতিল করার সিদ্ধান্ত নিলে Tomcat কতটা বডি পড়ে ফেলে দেবে তার সীমা। এটিই মানুষ ভুলে যায়।

দ্বিতীয়টি নিয়ে সতর্ক করা দরকার, কারণ এর লক্ষণ ভীষণ বিভ্রান্তিকর। maxSwallowSize ছাড়িয়ে গেলে Tomcat পরিষ্কার ত্রুটি পাতা না দিয়ে কানেকশন বন্ধ করে দেয়।

তখন ব্রাউজারে connection reset বা খালি রেসপন্স দেখায়, যা নেটওয়ার্ক সমস্যার মতো লাগে। ইঞ্জিনিয়াররা ফায়ারওয়াল আর ড্রপ হওয়া প্যাকেট খুঁজতে নামেন, অথচ উত্তরটা server.xml-এর একটি অ্যাট্রিবিউট।

ORDS standalone মোডে চালালে সমতুল্য রিকোয়েস্ট-সাইজ সীমা Tomcat-এর বদলে ORDS-এর standalone কনফিগারেশনে থাকে। নীতিটা একই: পথের প্রতিটি স্তরের ভোট আছে, আর সবচেয়ে ছোট সীমাটিই জেতে।

৯. বড় অ্যাপ্লিকেশনের ভালো পথ: HTTP পুরো এড়িয়ে যান

সত্যিই বড় অ্যাপ্লিকেশন ইমপোর্ট করছেন, বা একই ইমপোর্ট নানা এনভায়রনমেন্টে বারবার করবেন? তাহলে ওয়েব স্তরের সঙ্গে লড়াই থামান।

APEX এক্সপোর্ট একটি SQL স্ক্রিপ্ট। এটি সরাসরি ডেটাবেজ সার্ভারে চালানো যায়, যেখানে কোনো HTTP সীমা নেই:

-- এক্সপোর্ট ফাইল চালানোর আগে লক্ষ্য ঠিক করুন
BEGIN
  apex_application_install.set_workspace_id( 1234567890 );
  apex_application_install.generate_offset;
  apex_application_install.set_application_id( 500 );
  apex_application_install.set_application_alias( 'MYAPP_DEV' );
END;
/

@f500.sql

এক্সপোর্ট ফাইলটি আগে সার্ভারে কপি করে নিয়ে SQLcl বা SQL*Plus দিয়ে চালান।

এটি প্রায়ই সঠিক উত্তর হওয়ার তিনটি কারণ। কোনো proxy নেই, কন্টেইনার নেই, টিউন করার টাইমআউট নেই। এটি স্ক্রিপ্টযোগ্য, তাই dev থেকে test থেকে production-এ অ্যাপ্লিকেশন তোলা ম্যানুয়াল আপলোডের বদলে পুনরাবৃত্তিযোগ্য ধাপ হয়ে যায়।

আর এটি দীর্ঘ ডেটাবেজ অপারেশন থেকে ব্রাউজারকে সরিয়ে দেয় - যেখান থেকেই বেশিরভাগ রহস্যময় ব্যর্থতা আসে।

ছোট অ্যাপ্লিকেশন আর একবারের কাজে ব্রাউজার ইমপোর্ট সত্যিই সুবিধাজনক। কিন্তু যা দুবারের বেশি করবেন, তার জন্য SQL পথটি দ্রুত ও অনেক বেশি নির্ভরযোগ্য।

১০. এই কাজটি সাধারণত যে নিরাপত্তা সমস্যা বের করে আনে

413 সারাতে গিয়ে আপনি এমন একটি সার্ভারের কনফিগ খুলছেন, যা মালিকের ধারণার চেয়ে বেশি উন্মুক্ত থাকে। ভেতরে ঢুকেছেন যেহেতু, দুই মিনিট এখানে দিন।

খেয়াল করুন, ৩ নম্বর অংশের proxy 127.0.0.1:8080-এ ফরওয়ার্ড করছে। এটি সঠিক ও উদ্দেশ্যপূর্ণ: nginx সদর দরজা, আর ORDS-এ কেবল তার মধ্য দিয়েই পৌঁছানো উচিত।

এখন দেখুন ORDS আসলে কোথায় bind করা:

ss -lntp | grep -E ':8080|:1521'

127.0.0.1:8080-এর বদলে *:8080 বা 0.0.0.0:8080 দেখলে ORDS প্রতিটি ইন্টারফেসে শুনছে। তখন যে-ই হোস্টে পৌঁছাতে পারে, সে nginx পুরো এড়িয়ে যেতে পারে - সঙ্গে আপনি এইমাত্র যে সাইজ সীমা বসালেন, আর ওখানে রাখা অন্য সব সুরক্ষাও।

সবচেয়ে কঠিন চোখে দেখার লাইনটি অন্যটি। *:1521 মানে আপনার ডেটাবেজ listener যেকোনো জায়গা থেকে কানেকশন নিচ্ছে - আর পাবলিক IP-তে সেটি টিউনিংয়ের বিষয় নয়, গুরুতর উন্মুক্ততা।

একই সফরে চালানোর মতো আরও দুটি পরীক্ষা:

• হোস্ট ফায়ারওয়াল আদৌ চলছে? systemctl is-active firewalld। "inactive" মানে কিছুই ফিল্টার হচ্ছে না।
• APEX Builder কি সাদা HTTP-তে চলছে? তাহলে workspace ক্রেডেনশিয়াল ও সেশন কুকি পরিষ্কার টেক্সটে নেটওয়ার্ক পার হচ্ছে - আর Builder একটি পূর্ণ ডেভেলপমেন্ট কনসোল, রিড-অনলি অ্যাপ নয়।

এর কিছুই দুর্লভ নয়। এগুলোই আমি Oracle ডেটাবেজ নিরাপত্তা ও অবকাঠামো ডিজাইনে আলোচনা করি, আর সাধারণত দেখার প্রথম দশ মিনিটেই ধরা পড়ে - বিষয়টা ঠিক সেটাই।

অন্য কেউ দেখার আগে আপনার নিজের সিস্টেম ইন্টারনেটে কী দেখাচ্ছে জানতে চাইলে, ডিজিটাল এক্সপোজার অডিট ঠিক এই কাজেরই।

১১. পাঁচ মিনিটের চেকলিস্ট

1. ত্রুটি পাতার ফুটার পড়ুন। নিচে সার্ভারের ভার্সন মানে proxy উত্তর দিয়েছে, APEX নয়।
2. nginx.conf-এর ব্যাকআপ নিন, তারপর http ব্লকে client_max_body_size যোগ করুন।
3. client_body_timeout, proxy_read_timeout ও proxy_send_timeout 300s করুন।
4. আরও নির্দিষ্ট ব্লকে ছোট মান আছে কি না দেখতে grep -rn "client_max_body_size" /etc/nginx/ চালান।
5. nginx -t, তারপর systemctl reload nginx। কখনও restart নয়।
6. নকল পথে ৫ MB ডামি ফাইল POST করুন। 404 মানে সীমা সক্রিয়।
7. আবার চেষ্টার আগে ব্রাউজারে হার্ড-রিফ্রেশ দিন - বাসি 413 পাতা ক্যাশ হয়ে আপনার বিকেল নষ্ট করে।
8. নতুন ত্রুটি এলে এক স্তর নিচে নামুন - Tomcat-এর maxPostSize ও maxSwallowSize।
9. ওখানে থাকতেই দেখে নিন :8080 ও :1521 কোথায় bind করা।

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

Oracle APEX-এ 413 Request Entity Too Large মানে কী?

মানে APEX-এর সামনে বসা একটি ওয়েব সার্ভার আপনার আপলোডটি বাতিল করেছে, কারণ রিকোয়েস্ট বডি তার নির্ধারিত সর্বোচ্চ সীমা ছাড়িয়ে গেছে। APEX বা ORDS ফাইলটি দেখেইনি। nginx reverse proxy-তে ডিফল্ট সীমা মাত্র ১ MB, তাই বাস্তব যেকোনো অ্যাপ্লিকেশন এক্সপোর্টেই এটি ঘটে।

nginx-এ client_max_body_size কোথায় বসানো উচিত?

http ব্লকে বসান, যাতে প্রতিটি virtual host এটি পায় - conf.d-তে আলাদা ফাইলে ORDS proxy থাকলে এটিই সবচেয়ে নিরাপদ। server বা location ব্লকেও দেওয়া যায়। সবসময় সবচেয়ে নির্দিষ্ট ব্লকটি জেতে, তাই ORDS server ব্লকের ভেতরের ছোট মান গ্লোবাল বড় মানকে বাতিল করে দেবে।

client_max_body_size বদলানোর পর nginx restart করতে হবে?

না। প্রথমে nginx -t দিয়ে কনফিগ যাচাই করুন, তারপর systemctl reload nginx চালান। Reload কেবল worker প্রসেস বদলায়, চলমান কানেকশন ছাড়ে না - তাই চালু APEX ও ORDS সেশন টিকে থাকে। পূর্ণ restart অপ্রয়োজনীয় এবং ইউজারদের কাজ ভেঙে দেয়।

নতুন সীমা সত্যিই কাজ করছে কীভাবে প্রমাণ করব?

dd if=/dev/zero of=/tmp/blob.bin bs=1M count=5 দিয়ে একটি ডামি ফাইল বানান, তারপর curl দিয়ে proxy-র মধ্য দিয়ে এমন কোনো পথে POST করুন যা নেই। 404 এলে প্রমাণ হয় nginx ৫MB বডি গ্রহণ করেছে ও রিকোয়েস্ট এগিয়ে দিয়েছে। 413 এলে বোঝা যায় নতুন সীমা এখনও সক্রিয় নয়।

413 চলে গেছে কিন্তু APEX ইমপোর্ট এখনও ব্যর্থ হচ্ছে - এখন কী?

আপনি এক স্তর নিচে নেমেছেন, এটাই অগ্রগতি। এবার ORDS ও তার কন্টেইনার দেখুন: Tomcat-এ connector-এর maxPostSize ও maxSwallowSize দুটোই রিকোয়েস্ট বডি সীমিত করে, আর maxSwallowSize-ই সবচেয়ে বেশি ভুলে যাওয়া হয়। এটি পরিষ্কার ত্রুটি পাতার বদলে বিভ্রান্তিকর connection reset হিসেবে দেখা দেয়।

HTTP ছাড়াই বড় APEX অ্যাপ্লিকেশন ইমপোর্ট করা যায়?

হ্যাঁ, এবং খুব বড় অ্যাপ্লিকেশনের জন্য এটিই ভালো পথ। এক্সপোর্ট ফাইলটি ডেটাবেজ সার্ভারে কপি করে SQLcl বা SQL*Plus দিয়ে চালান, আগে APEX_APPLICATION_INSTALL প্যাকেজ দিয়ে লক্ষ্য workspace ও application ID ঠিক করে নিন। কোনো ওয়েব স্তর জড়িত নয়, তাই কোনো সাইজ সীমাও নেই এবং পুরো কাজটি স্ক্রিপ্টযোগ্য।