2015 में वापस, मैंने अपने Oracle 11.2.0.4 डेटाबेस को 12.1.0.2 में अपग्रेड किया और GTT के हमारे उपयोग से संबंधित कुछ प्रदर्शन समस्याओं का अनुभव किया। मैंने यहां उन मुद्दों के बारे में ब्लॉग किया है।
जिस मुद्दे को मैं हल करने की कोशिश कर रहा था, वह यह था कि 12c में एक व्यवहार परिवर्तन Oracle बचत आँकड़े की ओर ले जाता है कि GTT में शून्य पंक्तियाँ होती हैं जब ऐसा नहीं होता है। जीटीटी से जुड़े प्रश्नों पर पंक्तियों की संख्या दिखाने वाले आंकड़े पूर्ण तालिका स्कैन और कार्टेशियन उत्पादों के लिए शून्य लीड के बराबर होते हैं। जैसा कि मैंने उस ब्लॉग पोस्ट में कहा था, हमने तालिका को डेटा से भरने के बाद DBMS_STATS.SET_TABLE_STATS का उपयोग किया ताकि प्रत्येक सत्र में बेहतर निष्पादन योजना पर पहुंचने के लिए उचित आँकड़े हों।
Oracle 19c में अपग्रेड करने के बाद, हमें GTT से संबंधित अन्य प्रदर्शन समस्याएं दिखाई देने लगीं। जीटीटी का उपयोग करने वाली क्वेरी "कर्सर पिन:एस वेट ऑन एक्स" प्रतीक्षा ईवेंट पर प्रतीक्षा करने लगीं। यह नए Oracle संस्करण के साथ एक व्यवहार परिवर्तन हो सकता था, लेकिन यह हमारे डेवलपर्स भी हो सकते थे जो हमारे कोड में GTT का अधिक बार उपयोग कर रहे थे और नए संस्करण से इसका कोई लेना-देना नहीं था।
कर्सर पिन प्रतीक्षा घटना में शामिल प्रश्नों के लिए, मैंने साझा पूल में SQL कथन के संस्करणों की एक बड़ी संख्या देखी। जब मैंने V$SQL_SHARED_CURSOR से पूछताछ की, तो मैंने पाया कि इन SQL कथनों के लिए PURGED_CURSOR='Y'। कर्सर अमान्य हो रहा है।
इस मुद्दे पर शोध करते समय, मैंने पाया कि क्या होता है कि हर बार जब हम GTT पर सत्र-आधारित आँकड़े प्राप्त करने के लिए DBMS_STATS.SET_TABLE_STATS को कॉल करते हैं, तो यह उस GTT का उपयोग करने वाले सभी SQL कथनों को अमान्य कर देता है। इसलिए प्रतीक्षा। इंतजार लंबा नहीं था इसलिए कई अंतिम उपयोगकर्ताओं ने इस मुद्दे पर ध्यान भी नहीं दिया।
लेकिन फिर हमें एक नई समस्या हुई। जब आप SET_TABLE_STATS पर कॉल करते हैं, तो Oracle SYS.WRI$_OPTSTAT_TAB_HISTORY में एक प्रविष्टि लिखता है और आप तालिका के आँकड़ों के लिए सत्र द्वारा निर्धारित मान देख सकते हैं। डिफ़ॉल्ट रूप से, यह तालिका 30 दिनों के इतिहास को संग्रहीत करती है। तालिका बहुत बड़े पैमाने पर बढ़ रही थी और अधिकांश SYSAUX का उपभोग कर रही थी। हर बार (प्रति घंटा?) Oracle 30 दिन से अधिक पुरानी प्रविष्टियों को हटा देगा। इस तालिका की नियमित छंटाई अब अंतिम उपयोगकर्ता प्रदर्शन को नकारात्मक रूप से प्रभावित कर रही थी। इस तालिका की छंटाई के प्रभाव को दर्शाने वाला लाइटी का प्रदर्शन ग्राफ निम्नलिखित है:
वह सब डरावना लाल रंग तब होता है जब SYS.WRI$_OPTSTAT_TAB_HISTORY से पुरानी पंक्तियों को हटाया जा रहा था।
तो पांच साल पहले मेरे प्रदर्शन "फिक्स" ने एक और प्रदर्शन मुद्दा पेश किया। प्रदर्शन में सुधार करने के लिए, मैंने GTT पर साझा आँकड़े बनाने और सत्र के आँकड़ों का उपयोग बंद करने का काम किया। ये चरण हैं:
--set prefs to SHARED globally
exec DBMS_STATS.set_global_prefs ( pname => 'GLOBAL_TEMP_TABLE_STATS', pvalue => 'SHARED');
--set the table and index stats
exec dbms_stats.set_table_stats(ownname=>'MY_SCHEMA',tabname=>'MY_GTT_TABLE',numrows=>1000,numblks=>2,avgrlen=>15);
exec dbms_stats.set_index_stats(ownname=>'MY_SCHEMA',indname=>'GTT_INDEX',indlevel=>1,numlblks=>2,numdist=>15,clstfct=>28,numrows=>1000);
-- set prefs back to SESSION
exec DBMS_STATS.set_global_prefs ( pname => 'GLOBAL_TEMP_TABLE_STATS', pvalue => 'SESSION');
-- verify stats set
select num_rows,blocks,last_analyzed,scope
from dba_tab_statistics
where table_name ='MY_GTT_TABLE';
select blevel,leaf_blocks,distinct_keys,num_rows,clustering_factor,last_analyzed,scope
from dba_ind_statistics
where index_name='GTT_INDEX' and owner='MY_SCHEMA';
एक बार साझा किए गए आँकड़े होने के बाद, हम अपने कोड से DBMS_SET_TABLE_STATS पर कॉल हटा देते हैं।
