यहां कुछ सामान्य Oracle प्रतीक्षा कार्यक्रम दिए गए हैं जिन्हें सभी को जानना चाहिए।
ईवेंट की प्रतीक्षा करें
आप क्वेरी का पालन करके पता लगा सकते हैं कि कौन सा ईवेंट सत्र इसकी प्रतीक्षा कर रहा है
select event from V$session_wait where sid=&1
मैं कुछ सामान्य Oracle प्रतीक्षा घटनाओं को समझाने की कोशिश कर रहा हूं, इसके कारण और समाधान हैं
एनक्यू
प्रक्रिया ऑरैकल एनक्यू पर प्रतीक्षा कर रही है (एक लॉक जिसे आप वी $ लॉक में देख सकते हैं)। यह आमतौर पर तब होता है जब एक उपयोगकर्ता किसी तालिका में एक पंक्ति को अद्यतन करने का प्रयास कर रहा होता है जिसे वर्तमान में किसी अन्य उपयोगकर्ता द्वारा अद्यतन किया जा रहा है। निम्नलिखित क्वेरी का उपयोग करके अवरोधकों का पता लगाया जा सकता है
select * from dba_waiters
लाइब्रेरी कैश पिन
प्रक्रिया परीक्षा के लिए लाइब्रेरी कैश में किसी ऑब्जेक्ट को मेमोरी में पिन करना चाहती है, यह सुनिश्चित करते हुए कि कोई अन्य प्रक्रिया उसी समय ऑब्जेक्ट को अपडेट नहीं कर सकती है। ऐसा तब होता है जब आप किसी PL/SQL ऑब्जेक्ट या व्यू को कंपाइल या पार्स कर रहे होते हैं। इस प्रतीक्षा घटना से बचने के लिए पीएल/एसक्यूएल ऑब्जेक्ट या ऑरेकल व्यू को उच्च उपयोग समय पर संकलित करने से बचें
लाइब्रेरी कैश लोड लॉक
प्रक्रिया किसी वस्तु या वस्तु के टुकड़े को लाइब्रेरी कैश में लोड करने के अवसर की प्रतीक्षा कर रही है। (एक समय में केवल एक प्रक्रिया किसी वस्तु या वस्तु के टुकड़े को लोड कर सकती है।)
कुंडी मुक्त
प्रक्रिया किसी अन्य प्रक्रिया द्वारा आयोजित कुंडी की प्रतीक्षा कर रही है। (यह प्रतीक्षा घटना उन प्रक्रियाओं पर लागू नहीं होती है जो कुंडी की प्रतीक्षा करते समय कताई कर रही हैं; जब कोई प्रक्रिया कताई कर रही है, तो यह प्रतीक्षा नहीं कर रही है।)। कुंडी हल्के क्रमांकन उपकरण हैं जिनका उपयोग साझा डेटा संरचनाओं, वस्तुओं के लिए बहु-उपयोगकर्ता पहुंच को समन्वयित करने के लिए किया जाता है, और फ़ाइलें.
कुंडी बहुत कम समय के लिए बनाए रखने के लिए डिज़ाइन किए गए ताले हैं, उदाहरण के लिए, इन-मेमोरी डेटा संरचना को संशोधित करने में लगने वाला समय। उनका उपयोग कुछ मेमोरी संरचनाओं की सुरक्षा के लिए किया जाता है, जैसे डेटाबेस ब्लॉक बफर कैश या साझा पूल में लाइब्रेरी कैश।
Oracle कुंडी आमतौर पर आंतरिक रूप से 'प्रतीक्षा करने के लिए तैयार' मोड में अनुरोध किया जाता है। इसका मतलब यह है कि यदि कुंडी उपलब्ध नहीं है, तो अनुरोध करने वाला सत्र थोड़े समय के लिए सो जाएगा और बाद में ऑपरेशन का पुन:प्रयास करेगा। अन्य कुंडी को 'तत्काल' मोड में अनुरोध किया जा सकता है, जो कि अवधारणा के समान है अद्यतन के लिए कोई प्रतीक्षा नहीं, जिसका अर्थ है कि प्रक्रिया कुछ और करेगी, जैसे कि समकक्ष भाई कुंडी को पकड़ने का प्रयास करें जो मुफ़्त हो सकता है, बैठने के बजाय और इस कुंडी के उपलब्ध होने की प्रतीक्षा करें। चूंकि कई अनुरोध एक ही समय में एक कुंडी की प्रतीक्षा कर रहे होंगे, आप कुछ प्रक्रियाओं को दूसरों की तुलना में अधिक समय तक प्रतीक्षा करते हुए देख सकते हैं।
ड्रॉ के भाग्य के आधार पर, यदि आप करेंगे, तो कुंडी को बेतरतीब ढंग से असाइन किया गया है। जो भी सत्र जारी होने के ठीक बाद कुंडी की मांग करेगा वह मिल जाएगा। लैच वेटर्स की कोई लाइन नहीं है बस वेटर्स की भीड़ लगातार पुनः प्रयास कर रही है।
बफर व्यस्त इंतजार
प्रक्रिया ऐसे डेटा ब्लॉक तक पहुंचना चाहती है जो वर्तमान में मेमोरी में नहीं है, लेकिन एक अन्य प्रक्रिया ने ब्लॉक को मेमोरी में पढ़ने के लिए I/O अनुरोध पहले ही जारी कर दिया है। (प्रक्रिया ब्लॉक को स्मृति में लाने के लिए दूसरी प्रक्रिया की प्रतीक्षा कर रही है।) दृश्य V$BH
डीबी फ़ाइल बिखरी हुई पढ़ी गई
प्रक्रिया ने डेटा फ़ाइल से बफर कैश में सन्निहित ब्लॉकों की एक श्रृंखला को पढ़ने के लिए I/O अनुरोध जारी किया है, और ऑपरेशन के पूरा होने की प्रतीक्षा कर रहा है। यह आमतौर पर पूर्ण तालिका स्कैन या पूर्ण अनुक्रमणिका स्कैन के दौरान होता है।
हमें जांचना चाहिए कि क्या क्वेरी पूर्ण तालिका स्कैन का उपयोग करके होनी चाहिए। सुनिश्चित करें कि Oracle अनुकूलक आँकड़े अद्यतित हैं। देखे गए ब्लॉकों की संख्या कम करने के लिए पार्टिशन प्रूनिंग का उपयोग करें
यदि कोई क्वेरी जो कुछ समय से ठीक चल रही है, तो अचानक डीबी फ़ाइल बिखरी हुई रीड इवेंट पर बहुत समय लगता है और कोई कोड परिवर्तन नहीं हुआ है, तो आप यह देखने के लिए जांचना चाहेंगे कि एक या अधिक इंडेक्स गिराए गए हैं या नहीं अनुपयोगी हो जाते हैं।
db फ़ाइल अनुक्रमिक पठन
प्रक्रिया ने डेटा फ़ाइल से एक ब्लॉक को बफर कैश में पढ़ने के लिए I/O अनुरोध जारी किया है, और ऑपरेशन पूरा होने की प्रतीक्षा कर रहा है। यह आमतौर पर इंडेक्स लुकअप के दौरान होता है या ROWID द्वारा ऑरैकल टेबल से फ़ेच किया जाता है जब आवश्यक डेटा ब्लॉक पहले से ही मेमोरी में नहीं होता है। इस प्रतीक्षा घटना के भ्रमित करने वाले नाम से भ्रमित न हों!
हमें जाँच करनी चाहिए कि क्या सही अनुक्रमणिका का उपयोग किया जा रहा है। गलत अनुक्रमणिका क्वेरी को खराब प्रदर्शन कर सकती है। सुनिश्चित करें कि अनुकूलक आँकड़े अद्यतित हैं।
डीबी फ़ाइल समानांतर पढ़ें
प्रक्रिया ने डेटा फ़ाइलों से मेमोरी में ब्लॉक पढ़ने के लिए समानांतर में कई I/O अनुरोध जारी किए हैं, और सभी अनुरोधों के पूरा होने की प्रतीक्षा कर रहे हैं। प्रलेखन कहता है कि यह प्रतीक्षा घटना केवल पुनर्प्राप्ति के दौरान होती है, लेकिन वास्तव में यह नियमित गतिविधि के दौरान भी होती है जब एक प्रक्रिया कई एकल ब्लॉक I/O अनुरोधों को एक साथ बैचती है और उन्हें समानांतर में जारी करती है। (नाम के बावजूद, आप समानांतर क्वेरी या समानांतर डीएमएल के दौरान इस प्रतीक्षा घटना को नहीं देखेंगे। उन मामलों में उनके नाम में पीएक्स के साथ प्रतीक्षा घटनाएं होती हैं।)
db फ़ाइल समानांतर लिखें
प्रक्रिया, आम तौर पर DBWR, ने बफर कैश से डिस्क पर गंदे ब्लॉक लिखने के लिए समानांतर में कई I/O अनुरोध जारी किए हैं, और सभी अनुरोधों के पूरा होने की प्रतीक्षा कर रहे हैं।
डायरेक्ट पाथ रीड, डायरेक्ट पाथ राइट
प्रक्रिया ने एसिंक्रोनस I/O अनुरोध जारी किए हैं जो बफर कैश को बायपास करते हैं, और उनके पूरा होने की प्रतीक्षा कर रहे हैं। इन प्रतीक्षा घटनाओं में आमतौर पर सॉर्ट सेगमेंट शामिल होते हैं।
फ़ंक्शन के साथ SQL कथन जिन्हें सॉर्ट करने की आवश्यकता होती है, जैसे ORDER BY, GROUP BY, UNION, DISTINCT, और ROLLUP, जब इनपुट आकार PGA में कार्य-क्षेत्र से बड़ा होता है, तो अस्थायी टेबलस्पेस पर सॉर्ट रन लिखें
सुनिश्चित करें कि ऑप्टिमाइज़र आंकड़े डेटा तक हैं और क्वेरी सही ड्राइविंग टेबल का उपयोग कर रही है। यह देखने के लिए जांचें कि पूरी तरह से सॉर्ट करने से बचने के लिए ORDER BY क्लॉज से मेल खाने के लिए कंपोजिट इंडेक्स के कॉलम को फिर से व्यवस्थित किया जा सकता है या नहीं।
सुनिश्चित करें कि उपयुक्त मान PGA_AGGREGATE_TARGET सेट है। यदि संभव हो तो UNION के बजाय UNION ALL का उपयोग करें।
साझा पूल कुंडी
साझा पूल कुंडी का उपयोग साझा पूल में स्मृति आवंटित और मुक्त करते समय महत्वपूर्ण संचालन की सुरक्षा के लिए किया जाता है। साझा पूल और लाइब्रेरी कैश लैच के लिए विवाद मुख्य रूप से तीव्र हार्ड पार्सिंग के कारण हैं। एक हार्ड पार्स नए कर्सर और कर्सर पर लागू होता है जो पुराने हो चुके हैं और उन्हें फिर से निष्पादित किया जाना चाहिए
एक नए SQL कथन को पार्स करने की लागत CPU आवश्यकताओं और लाइब्रेरी कैश और साझा पूल की संख्या दोनों के मामले में महंगी है। कुंडी को अधिग्रहित और जारी करने की आवश्यकता हो सकती है।
साझा पूल कुंडी से बचने के लिए शाब्दिक SQL को हटाना भी उपयोगी है
फ़ाइल अनुक्रमिक पठन को नियंत्रित करें
प्रक्रिया नियंत्रण फ़ाइल से ब्लॉकों के पढ़ने की प्रतीक्षा कर रही है। ऐसा आम तौर पर होता है
- कंट्रोलफाइल्स का बैकअप बनाना
- कंट्रोलफाइल से जानकारी (उदाहरणों के बीच) साझा करना
- कंट्रोलफाइल्स से अन्य ब्लॉक पढ़ना
- हेडर ब्लॉक पढ़ना
यदि यह प्रमुख प्रतीक्षा घटना है, तो इसका मतलब है कि नियंत्रण फ़ाइल स्थान को तेज़ डिस्क स्थान में बदलने की आवश्यकता है
नियंत्रण फ़ाइल समानांतर लेखन
प्रक्रिया ने सभी नियंत्रण फ़ाइलों को ब्लॉक लिखने के लिए समानांतर में कई I/O अनुरोध जारी किए हैं, और सभी लेखन के पूरा होने की प्रतीक्षा कर रहे हैं।
लॉग बफर स्पेस
प्रक्रिया लॉग बफर में स्थान उपलब्ध होने की प्रतीक्षा कर रही है (अंतरिक्ष केवल तभी उपलब्ध होता है जब LGWR ने लॉग बफर की वर्तमान सामग्री को डिस्क पर लिखा हो।) यह आमतौर पर तब होता है जब एप्लिकेशन LGWR की तुलना में तेजी से फिर से उत्पन्न करते हैं। डिस्क पर।
यह तब भी हो सकता है, यदि डिस्क पर I/O जहां फिर से लॉग स्थित हैं, धीमा है
डेटाबेस में कोई लॉग बफर स्पेस नहीं होना चाहिए। लॉग बफर को छोटा बनाने पर विचार करें या लॉग फ़ाइलों को तेज डिस्क जैसे धारीदार डिस्क पर ले जाने पर विचार करें।
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
pct_buff_alloc_retries शून्य या 0.01 से कम (<1%) होनी चाहिए। यदि यह अधिक है तो लॉग बफर को बड़ा बनाने पर विचार करें। यदि यह अधिक है तो लॉग फ़ाइलों को स्ट्राइप्ड डिस्क जैसे तेज़ डिस्क पर ले जाने पर विचार करें।
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
लॉग फ़ाइल अनुक्रमिक पठन
प्रक्रिया ब्लॉक को ऑनलाइन रीडो लॉग इन मेमोरी से पढ़े जाने की प्रतीक्षा कर रही है। यह मुख्य रूप से स्टार्टअप पर होता है और जब ARCH प्रक्रिया संग्रह ऑनलाइन फिर से लॉग भरता है।
लॉग फ़ाइल समानांतर लिखें
प्रक्रिया एक समूह में सभी ऑनलाइन रीडो लॉग सदस्यों को ब्लॉक लिखे जाने की प्रतीक्षा कर रही है। LGWR आमतौर पर इस प्रतीक्षा घटना को देखने की एकमात्र प्रक्रिया है। यह तब तक प्रतीक्षा करेगा जब तक कि सभी सदस्यों को सभी ब्लॉक नहीं लिख दिए जाते।
लॉग फ़ाइल समन्वयन
यह प्रक्रिया LGWR के डिस्क पर लॉग बफर को फ्लश करने के समाप्त होने की प्रतीक्षा कर रही है। यह तब होता है जब कोई उपयोगकर्ता लेनदेन करता है। (एक लेन-देन को तब तक प्रतिबद्ध नहीं माना जाता है जब तक कि लेन-देन को पुनर्प्राप्त करने के लिए सभी रीडो को सफलतापूर्वक डिस्क पर नहीं लिखा जाता है।)
एक धीमी LGWR प्रक्रिया लॉग फ़ाइल सिंक वेट पेश कर सकती है जो उपयोगकर्ता को कमिट या रोलबैक के दौरान प्रतीक्षा समय का अनुभव कराती है। लॉग फ़ाइल समानांतर लेखन और लॉग फ़ाइल सिंक प्रतीक्षा ईवेंट परस्पर संबंधित हैं और उन्हें एक साथ निपटाया जाना चाहिए।
हमें उच्च प्रदर्शन डिस्क (सॉलिड स्टेट डिस्क) को फिर से लॉग आवंटित करने का प्रयास करना चाहिए। साथ ही हमें अनुप्रयोगों में कमिट को कम करके LGWR पर लोड को कम करने का प्रयास करना चाहिए।
मैनुअल हॉट-बैकअप पीस भी बहुत सारे रीडो सामान उत्पन्न करके सिस्टम में तनाव पैदा कर सकता है, इसलिए पीक समय के दौरान इससे बचें
कभी-कभी LGWR CPU संसाधन के लिए भूखा रहता है। यदि सर्वर बहुत व्यस्त है, तो LGWR CPU के लिए भी भूखा रह सकता है। इससे LGWR की ओर से धीमी प्रतिक्रिया मिलेगी, जिससे 'लॉग फ़ाइल सिंक' प्रतीक्षा बढ़ जाएगी। आखिरकार, इन सिस्टम कॉलों और I/O कॉलों को CPU का उपयोग करना चाहिए। इस मामले में, 'लॉग फ़ाइल सिंक' एक द्वितीयक लक्षण है और उच्च CPU उपयोग के मूल कारण को हल करने से 'लॉग फ़ाइल सिंक' प्रतीक्षा कम हो जाएगी।
स्मृति भुखमरी के मुद्दों के कारण, LGWR को भी पृष्ठांकित किया जा सकता है। इससे LGWR की ओर से भी धीमी प्रतिक्रिया मिल सकती है।
सेगमेंट एक्सटेंशन पूर्ववत करें
सत्र पूर्ववत खंड के विस्तारित या सिकुड़ने की प्रतीक्षा कर रहा है।
पूरी प्रतीक्षा लिखें
सत्र अनुरोधित बफर को डिस्क पर लिखे जाने की प्रतीक्षा कर रहा है; बफ़र लिखते समय उपयोग नहीं किया जा सकता है।
कुंडी:कैश बफर चेन
कैश बफर चेन लैच का उपयोग बफर कैश में बफर सूची की सुरक्षा के लिए किया जाता है। इन कुंडी का उपयोग बफर कैश से बफर को खोजने, जोड़ने या हटाने के लिए किया जाता है।
बफर कैश में ब्लॉक लिंक्ड सूचियों (कैश बफर चेन) पर रखे जाते हैं जो हैश टेबल से लटकते हैं। हैश चेन जिस पर एक ब्लॉक रखा गया है वह ब्लॉक के डीबीए और क्लास पर आधारित है। प्रत्येक हैश चेन एक सिंगल चाइल्ड लैच द्वारा सुरक्षित है। प्रक्रियाओं को एक बफर के लिए हैश श्रृंखला को स्कैन करने की अनुमति देने के लिए प्रासंगिक कुंडी प्राप्त करने की आवश्यकता होती है ताकि लिंक की गई सूची उनके नीचे न बदले।
इस कुंडी पर विवाद का आमतौर पर मतलब है कि एक ब्लॉक है जो बहुत विवाद में है (हॉट ब्लॉक के रूप में जाना जाता है)।
अत्यधिक एक्सेस की गई बफर श्रृंखला की पहचान करने के लिए, और इसलिए ब्लॉक के लिए दावेदार, V$LATCH_CHILDREN दृश्य का उपयोग करके कैश बफ़र्स चेन लैच के लिए लैच आँकड़े देखें। यदि कोई विशिष्ट कैश बफ़र्स चेन चाइल्ड लैच है जिसमें अन्य चाइल्ड लैच की तुलना में कई अधिक GETS, MISSES, और SLEEPS हैं, तो यह चाइल्ड लैच के लिए दावेदार है।
इस लैच में एक मेमोरी एड्रेस होता है, जिसे ADDR कॉलम द्वारा पहचाना जाता है।
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
इस लैच द्वारा सुरक्षित ब्लॉकों की पहचान करने के लिए V$BH व्यू के साथ जुड़े ADDR कॉलम में मान का उपयोग करें। उदाहरण के लिए, एक अत्यधिक प्रतिस्पर्धी कुंडी का पता (V$LATCH_CHILDREN.ADDR) दिया गया है, यह फ़ाइल और ब्लॉक नंबरों पर प्रश्नचिह्न लगाता है:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH बफर के लिए एक स्पर्श गणना है। X$BH.TCH के लिए एक उच्च मान एक हॉट ब्लॉक को इंगित करता है।
प्रत्येक कुंडी द्वारा कई ब्लॉकों की रक्षा की जाती है। इनमें से एक बफ़र संभवतः हॉट ब्लॉक होगा। उच्च TCH मान वाला कोई भी ब्लॉक एक संभावित हॉट ब्लॉक है। इस क्वेरी को कई बार निष्पादित करें, और उस ब्लॉक की पहचान करें जो आउटपुट में लगातार दिखाई देता है।
हॉट ब्लॉक की पहचान करने के बाद, खंड की पहचान करने के लिए फ़ाइल नंबर और ब्लॉक नंबर का उपयोग करके DBA_EXTENTS को क्वेरी करें।
प्रतीक्षा घटना पर महत्वपूर्ण जानकारी
v$session_wait दृश्य प्रतीक्षा ईवेंट के बारे में जानकारी प्रदर्शित करता है जिसके लिए सक्रिय सत्र वर्तमान में प्रतीक्षा कर रहे हैं। इस दृश्य का विवरण निम्नलिखित है, और इसमें कुछ बहुत ही उपयोगी स्तंभ हैं, विशेष रूप से P1 और P2 प्रतीक्षा घटनाओं से संबंधित वस्तुओं के संदर्भ।
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
v$session_wait का उपयोग करके, उस पैरामीटर के लिए संबंधित वर्णनात्मक टेक्स्ट कॉलम का उपयोग करके प्रत्येक प्रतीक्षा ईवेंट पैरामीटर की व्याख्या करना आसान है। इसके अलावा, प्रतीक्षा वर्ग के कॉलम जोड़े गए ताकि विभिन्न प्रतीक्षा घटनाओं को प्रसंस्करण के संबंधित क्षेत्रों जैसे नेटवर्क, एप्लिकेशन, निष्क्रिय, समवर्ती, आदि में समूहीकृत किया जा सके।
इन कॉलम को 10g से v$session तालिका में भी जोड़ा गया था। . तो आप सभी विवरण खोजने के लिए बस v$session का उपयोग कर सकते हैं
प्रत्येक प्रतीक्षा ईवेंट में अन्य पैरामीटर होते हैं जो ईवेंट के बारे में अतिरिक्त जानकारी प्रदान करते हैं।
प्रतीक्षा ईवेंट और उसके पैरामीटर के बारे में जानकारी कैसे प्राप्त करें
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
मान लें कि उदाहरण के लिए हमने लिया
event_name इनपुट मान:db फ़ाइल बिखरी हुई पढ़ी गई
3 का मूल मान:WHERE NAME ='&event_name A'
नया मान 3:जहां NAME ='db फ़ाइल बिखरी हुई पढ़ी गई'
नाम P1 P2 P3
db फ़ाइल बिखरी हुई पठन फ़ाइल # ब्लॉक # ब्लॉक
फ़ाइल #:डेटा फ़ाइल संख्या
ब्लॉक #:प्रारंभिक ब्लॉक संख्या
ब्लॉक:डेटा ब्लॉक की संख्या पढ़ने के लिए
अब देखते हैं कि उपरोक्त जानकारी हमें विभिन्न चीजों को कैप्चर करने में कैसे मदद कर सकती है
मान लीजिए एक विशेष सत्र बफर व्यस्त प्रतीक्षा घटना की प्रतीक्षा करता है, इस प्रतीक्षा घटना के कारण डेटाबेस ऑब्जेक्ट आसानी से निर्धारित किया जा सकता है:
select username, event, p1, p2 from v$session_wait where sid = 4563;
SID 4563 के साथ किसी विशेष सत्र के लिए इस क्वेरी का आउटपुट इस तरह दिख सकता है:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
कॉलम P1 और P2 DBA को फ़ाइल और ब्लॉक नंबर निर्धारित करने की अनुमति देते हैं जो इस प्रतीक्षा घटना का कारण बने। नीचे दी गई क्वेरी उस ऑब्जेक्ट नाम को पुनः प्राप्त करती है जो डेटा ब्लॉक 155 का मालिक है, ऊपर P2 का मान:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
किसी भी ट्यूनिंग प्रोजेक्ट में Oracle डेटाबेस प्रतीक्षा ईवेंट का विश्लेषण और सुधार करने की क्षमता महत्वपूर्ण है। डेटाबेस में अधिकांश गतिविधि में डेटा पढ़ना शामिल है, इसलिए इस प्रकार की ट्यूनिंग का प्रदर्शन पर बहुत बड़ा, सकारात्मक प्रभाव हो सकता है।
नोट:प्रतीक्षा विश्लेषण करते समय, यह याद रखना महत्वपूर्ण है कि सभी Oracle डेटाबेस प्रतीक्षा घटनाओं का अनुभव करते हैं, और प्रतीक्षा की उपस्थिति हमेशा एक समस्या का संकेत नहीं देती है। वास्तव में, सभी सुव्यवस्थित डेटाबेस में कुछ अड़चनें होती हैं।
हम सत्र की प्रतीक्षा घटना को भी ट्रेस करने के लिए 10046 ईवेंट का उपयोग कर सकते हैं
यह भी पढ़ता है
Oracle के दस्तावेज़
v$active_session_history
Oracle में योजना की व्याख्या करें
