Oracle Pending Statistics: Publish করার আগে যাচাই

এটি সংক্ষিপ্ত বাংলা সহায়ক সংস্করণ। পূর্ণ English গাইড ও primary references পড়ুন।

Oracle pending statistics ব্যবহার করলে নতুন optimizer statistics সংগ্রহ করেই সবার জন্য প্রকাশ করতে হয় না। আগে নির্দিষ্ট test session-এ ফল যাচাই করে তারপর publish বা reject করার সিদ্ধান্ত নেওয়া যায়।

আমি কাজটিকে তিন ভাগে দেখি: candidate তৈরি, উপযুক্ত workload দিয়ে পরীক্ষা এবং সিদ্ধান্তের পরে আগের configuration ফিরিয়ে দেওয়া। এটি Oracle 19c-এর জন্য একটি সংক্ষিপ্ত কাজের নকশা; কোনো গ্রাহকের বাস্তব incident বা আপনার database-এ চালানো পরীক্ষার ফল নয়।

Pending statistics আসলে কী?

এটি নতুন statistics-এর একটি candidate set, যা সাধারণ published statistics থেকে আলাদা করে রাখা হয়। নির্বাচিত session সেটি ব্যবহার করে statement compile করতে পারে; অন্য session সাধারণত আগের published statistics ব্যবহার করে।

Statistics optimizer-কে row count ও distribution সম্পর্কে ধারণা দেয়। কিন্তু test চলার সময় application নতুন row যোগ করলে underlying data বদলাতে পারে, তাই candidate একই থাকলেই পরীক্ষার সব পরিস্থিতি একই থাকে না।

বিস্তৃত ধারণার জন্য Oracle optimizer statistics-এর মূল আলোচনা দেখুন। এখানে মূল লক্ষ্য হলো candidate গ্রহণ বা বাদ দেওয়ার নিয়ন্ত্রিত ধাপ।

শুরুর আগে কী লিখে রাখবেন?

Database ও PDB, owner, table, সংশ্লিষ্ট SQL এবং সিদ্ধান্তের দায়িত্বে থাকা ব্যক্তিকে শনাক্ত করুন। কোন application আচরণ ভালো থাকতে হবে এবং কোন অবস্থায় পরীক্ষা থামাবেন, সেটিও আগে ঠিক করুন।

উদাহরণে APP.ORDERS ব্যবহার করা হয়েছে। এটি illustrative নাম; নিজের অনুমোদিত target, সঠিক container এবং প্রয়োজনীয় privilege যাচাই ছাড়া modifying procedure চালাবেন না।

-- বর্তমান effective preference দেখার SQL
SELECT DBMS_STATS.GET_PREFS('PUBLISH', 'APP', 'ORDERS')
       AS publish_preference
FROM dual;

শুধু মান নয়, explicit table override আগে ছিল কি না সেটিও লিখুন। Inherited setting এবং table override এখন একই মান দেখালেও আগের configuration ফিরিয়ে দেওয়ার পদ্ধতি এক নয়।

আগে থেকে pending candidate, statistics lock বা অন্য কারও experiment আছে কি না দেখুন। Gather ব্যর্থ হলেই lock খুলে দেওয়া বা অন্য পরীক্ষার candidate সরিয়ে দেওয়া এই runbook-এর অংশ নয়।

Candidate কীভাবে তৈরি করবেন?

অনুমোদিত scope যদি একটি table হয়, পরিবর্তনটিও সেই table-এ সীমিত রাখুন। Gather কাজটি CPU ও I/O ব্যবহার করে, তাই এটিকে বিনা খরচের read-only পরীক্ষা ভাববেন না।

BEGIN
  DBMS_STATS.SET_TABLE_PREFS(
    ownname => 'APP', tabname => 'ORDERS',
    pname => 'PUBLISH', pvalue => 'FALSE');
  DBMS_STATS.GATHER_TABLE_STATS(
    ownname => 'APP', tabname => 'ORDERS');
END;
/

এখানে নতুন sampling percentage বা parallel degree বানিয়ে দেওয়া হয়নি। আপনার প্রযোজ্য gathering preferences বুঝে চালান এবং নির্দিষ্ট object-এর pending candidate তৈরি হয়েছে কি না যাচাই করুন।

আলাদা test session কেন দরকার?

Oracle-এর parameterটি statement compile হওয়ার সময় pending statistics ব্যবহার করবে কি না ঠিক করে। System scope-এ বদলালে পরীক্ষার পরিধি বড় হয়ে যায়, তাই এই workflow-তে dedicated session ব্যবহার করুন।

ALTER SESSION SET optimizer_use_pending_statistics = TRUE;
-- অনুমোদিত representative workload পরীক্ষা করুন।
ALTER SESSION SET optimizer_use_pending_statistics = FALSE;

Opt-in থাকা connection application pool-এ ফেরত দেবেন না। আগে থেকে cached cursor থাকলে compilation context যাচাই করুন; পরীক্ষা সহজ করার জন্য production shared pool flush করার মতো বড় পরিবর্তন করবেন না।

কীভাবে fair comparison করবেন?

প্রতিটি test-এর SQL, bind value, statistics mode, compilation context ও measurement window লিখুন। শুধু elapsed time নয়, actual plan, row estimate, observed rows এবং resource ব্যবহার মিলিয়ে দেখুন।

একই query-এর সাধারণ ও কম ব্যবহৃত input প্রয়োজনমতো পরীক্ষা করুন। একটি input-এর উন্নতির বিনিময়ে আরেকটির regression হচ্ছে কি না বোঝা দরকার।

Application build, system load ও session setting বদলে গেলে ফলের কারণ আলাদা করা কঠিন হয়। নিজের পরিবেশে যে observability অনুমোদিত ও পাওয়া যায় সেটি ব্যবহার করুন; এই পরীক্ষার জন্য নতুন licensed feature চালু করা বাধ্যতামূলক নয়।

Join-এর একটি table-এ pending statistics থাকলেও অন্যটিতে published statistics ব্যবহার হতে পারে। তাই কোন object থেকে কোন set এসেছে সেটি record-এ পরিষ্কার রাখুন।

Publish বা reject কীভাবে করবেন?

Acceptance criteria পূরণ হলে এবং পরিবর্তনের সিদ্ধান্ত হলে কেবল named table-এর candidate publish করুন। Table name null রেখে scope বড় করবেন না।

BEGIN
  DBMS_STATS.PUBLISH_PENDING_STATS(
    ownname => 'APP', tabname => 'ORDERS');
END;
/

ফল খারাপ বা অনিশ্চিত হলে publish না করে নির্ধারিত সিদ্ধান্ত অনুযায়ী pending candidate বাদ দিন। DBMS_STATS.DELETE_PENDING_STATS pending set মুছে দেয়; এটি ইতিমধ্যে published statistics ফিরিয়ে দেওয়ার পদ্ধতি নয়।

প্রকাশিত set-এর recovery আলাদা করে পরিকল্পনা করুন এবং প্রয়োজনীয় history বা export আছে কি না আগে যাচাই করুন। সাধারণ SQL ROLLBACK দিয়ে সব statistics-management কাজ উল্টে যাবে ধরে নেবেন না।

আগে override না থাকলে cleanup কেমন হবে?

শুরুর record-এ APP.ORDERS-এর জন্য explicit PUBLISH override না থাকলে temporary override সরিয়ে inheritance ফেরান। নিচের Oracle 19c PL/SQL শুধু সেই অবস্থার উদাহরণ; আগে override থাকলে SET_TABLE_PREFS দিয়ে তার সংরক্ষিত মান ফিরিয়ে দিন।

-- আগের record-এ override না থাকার প্রমাণ থাকলেই চালান।
BEGIN
  DBMS_STATS.DELETE_TABLE_PREFS(
    ownname => 'APP', tabname => 'ORDERS',
    pname   => 'PUBLISH');
END;
/

দুই branch একসঙ্গে চালাবেন না। DELETE_TABLE_PREFS preference সরায়; DELETE_TABLE_STATS statistics মুছে দেয়—নাম কাছাকাছি হলেও কাজ আলাদা।

পরে GET_PREFS দিয়ে effective মান দেখুন এবং cleanup operation সংরক্ষণ করুন। একই effective মান দেখালেই inheritance ফিরে এসেছে প্রমাণ হয় না।

শেষে কোন কাজগুলো বাকি থাকে?

আগের table preference ফিরিয়ে দিন অথবা আপনার নতুন override সরিয়ে আগের inheritance ফিরিয়ে দিন। Original value true ছিল ধরে নেবেন না; শুরুর record দেখেই ঠিক করুন।

1. Candidate publish, reject বা retained—কোন সিদ্ধান্ত হলো লিখুন।
2. Test session reset বা disconnect নিশ্চিত করুন।
3. Preference ফিরিয়ে effective setting যাচাই করুন।
4. Comparison ও regression-এর evidence সংযুক্ত করুন।
5. পরের application window কে দেখবেন ঠিক করুন।

Plan stability সম্পর্কে SQL Plan Management-এর বাংলা গাইড এবং সমস্যার কারণ খোঁজার জন্য Oracle performance troubleshooting পড়তে পারেন।

পরের কাজ হিসেবে gather call-এর আগে comparison ও cleanup sheet লিখুন। Oracle pending statistics-এর মূল্য শুধু candidate তৈরি নয়, সেই candidate সম্পর্কে স্পষ্ট ও প্রমাণভিত্তিক সিদ্ধান্ত নেওয়া।

Frequently Asked Questions

সব session কি pending statistics ব্যবহার করে?

Default অবস্থায় করে না। নির্বাচিত session-এ parameter চালু করতে হয়; system scope-এর পরিবর্তন এই সীমিত পরীক্ষার চেয়ে বড় প্রভাব তৈরি করে।

PUBLISH=FALSE কি gather বন্ধ করে?

না। এটি নতুন statistics-এর publication behaviour বদলায়; gather নিজে resources ব্যবহার করেই চলে।

Candidate publish হলেই preference আগের মতো হয়?

দুটি কাজ আলাদা করে দেখুন। আগের preference configuration স্পষ্টভাবে ফিরিয়ে দিয়ে যাচাই করুন।

একটি দ্রুত execution কি যথেষ্ট?

এটি কেবল ওই execution-এর evidence। সিদ্ধান্তের আগে representative statement, input ও resource readings মিলিয়ে দেখুন।

এই বাংলা পাতা কি সম্পূর্ণ English runbook-এর বিকল্প?

এটি সংক্ষিপ্ত সহায়ক সংস্করণ। Parameter, procedure, scope ও recovery-এর বিস্তারিত পরীক্ষা এবং primary references-এর জন্য পূর্ণ English গাইডও পড়ুন।