मैं हाल ही में MOSC फ़ोरम में एक प्रश्न पर एक व्यक्ति के साथ काम कर रहा था जहाँ उन्होंने V$SQL_SHARED_CURSOR व्यू के TOP_LEVEL_RPI_CURSOR कॉलम के बारे में पूछा। यह कॉलम डीबीए को क्या बताने की कोशिश कर रहा है, इस पर बहुत कम दस्तावेज हैं।
सभी Oracle दस्तावेज़ कहते हैं कि इस कॉलम में "(Y|N) शीर्ष स्तर का RPI कर्सर है"। तो इसका क्या मतलब है?
मुझे लगता है कि इस पोस्ट के पाठक बाल कर्सर से परिचित हैं। यह मुझे बड़ी मात्रा में प्रारंभिक जानकारी बचाएगा। V$SQL_SHARED_CURSOR दृश्य DBA को बताएगा कि साझा पूल में चाइल्ड कर्सर और उसके माता-पिता के अलग-अलग संस्करण क्यों हैं। यदि चाइल्ड कर्सर के OPTIMIZER_MISMATCH कॉलम में इस दृश्य में एक 'Y' है, तो कर्सर को निष्पादित करने वाले सत्र में पैरेंट कर्सर निष्पादन के लिए जिम्मेदार सत्र की तुलना में अलग ऑप्टिमाइज़र सेटिंग्स थीं।
तो इसका क्या अर्थ है जब किसी बच्चे के लिए TOP_LEVEL_RPI_CURSOR को Y पर सेट किया जाता है? दस्तावेज़ीकरण स्पष्ट नहीं है। MOS के पास इस विषय पर बहुत कम है। और मेरे सभी Google इस कॉलम पर हिट करते हैं, बस दस्तावेज़ीकरण को दोबारा शुरू करते हैं। यह जानने के लिए, यह जानने में मदद करता है कि RPI का अर्थ रिकर्सिव प्रोग्राम इंटरफ़ेस है। यह Oracle कर्नेल का हिस्सा है जो पुनरावर्ती SQL से संबंधित है। हमारे मामले में, यह इस तथ्य से संबंधित है कि SQL कथन एक अलग "गहराई" पर जारी किया गया था।
रिकर्सिव एसक्यूएल क्या है? यह SQL है जो आपकी ओर से जारी किया गया है, जिसका अर्थ है एक अलग गहराई पर जैसा कि मैं वर्णन करूंगा। सबसे पहले, Oracle हर समय पुनरावर्ती SQL का प्रदर्शन कर रहा है। एक बुनियादी स्तर पर, जब आप "टेबल_नाम से चुनें *" जारी करते हैं, तो ओरेकल डेटा डिक्शनरी से यह सुनिश्चित करने के लिए पूछताछ करता है कि ऑब्जेक्ट मौजूद है और आपके पास उस टेबल पर अनुमतियां हैं। ओरेकल यह कैसे करता है? यह अन्य SQL कथनों का उपयोग करता है। आपके द्वारा जारी किया गया विवरण स्तर 0, आधार स्तर पर है। जब Oracle यह जांचने के लिए SQL स्टेटमेंट जारी करता है कि क्या तालिका मौजूद है, जो अगले स्तर, स्तर 1 पर होगी। कभी-कभी, यह अन्य SQL कथनों को अगले स्तर, स्तर 2 पर जारी करने का कारण बनेगा।
SQL कथन की गहराई केवल आपकी ओर से पृष्ठभूमि में Oracle क्या कर रही है, तक सीमित नहीं है। विचार करें कि आप किसी संग्रहीत कार्यविधि को कब निष्पादित करते हैं। संग्रहीत कार्यविधि के लिए आपका कॉल गहराई 0 पर है। संग्रहीत कार्यविधि में कोई भी SQL कथन गहराई पर है। यदि वह संग्रहीत कार्यविधि किसी अन्य प्रक्रिया को कॉल करती है, तो दूसरी प्रक्रिया में SQL गहराई 2 पर होगी।
मैंने अपने Oracle 12.1.0.2 डेटाबेस में एक साधारण उदाहरण बनाने के लिए पुनरावर्ती SQL और SQL गहराई पर इस जानकारी का उपयोग किया। सबसे पहले, मैंने एक संग्रहित प्रक्रिया बनाई।
create or replace procedure my_sysdate as v_dt date; begin select sysdate into v_dt from dual; end; /
मैंने फिर एक एसक्यूएल * प्लस सत्र निकाल दिया और एक ट्रेस शुरू किया। मैंने वही SQL स्टेटमेंट जारी किया और फिर मैंने अपनी प्रक्रिया को कॉल किया।
SQL> alter session set sql_trace=true;
Session altered.
SQL> SELECT SYSDATE FROM DUAL 2 /
SYSDATE --------- 05-APR-16
SQL> exec my_sysdate;
PL/SQL procedure successfully completed.
SQL> exit
जब मैंने कच्ची ट्रेस फ़ाइल की जांच की, तो मुझे DUAL से SYSDATE को दो कॉल इस प्रकार मिलीं:
कर्सर में पार्सिंग #140670990815296 len=24 dep=0 uid=9449 oct=3 ढक्कन=9449 tim=24905125014484 hv=124468195 ad='81477be0′ sqlid='c749bc43qqfz3′ DUAL से SYSDATE चुनें
कर्सर में पार्सिंग #140670907623848 लेन=24 डीपी=1 यूआईडी=9449 अक्टूबर=3 ढक्कन=9449 टिम=24905129780963 एचवी=124468195 विज्ञापन='81477be0′ sqlid='c749bc43qqfz3′ DUAL से SYSDATE चुनें
यदि आप ट्रेस फ़ाइल को बारीकी से देखते हैं, तो आप देखेंगे कि गहराई =1 पर दूसरा संग्रहीत कार्यविधि का प्रत्यक्ष परिणाम था। ध्यान दें कि भले ही मेरी संग्रहीत कार्यविधि सभी निचले मामलों में परिभाषित की गई थी, लेकिन गहराई =1 पर जारी किया गया SQL सभी ऊपरी मामलों में था। परिणामस्वरूप, जब मैंने वही SQL कथन सीधे अपने SQL*Plus सत्र (गहराई =0) में जारी किया, तो मुझे उस कथन के समान अपर केस प्रपत्र का उपयोग करना पड़ा ताकि उसका SQL ID मान समान हो। पी>
ट्रेस फ़ाइल SQL ID भी दिखाती है। अब मैं उस SQL ID मान के लिए V$SQL_SHARED_CURSOR को क्वेरी कर सकता हूं और दिखा सकता हूं कि TOP_LEVEL_RPI_CURSOR बच्चे के लिए सेट है।
SQL> select sql_id,top_level_rpi_cursor from v$sql_shared_cursor where sql_id='c749bc43qqfz3';
SQL_ID T ------------- - c749bc43qqfz3 N c749bc43qqfz3 Y
तो वहां हमारे पास सबूत है। इन दो कर्सर के बीच एकमात्र अंतर यह है कि एक गहराई थी जिससे उन्हें निष्पादित किया गया था। मुझे यकीन नहीं है कि Oracle को साझा पूल में इस अंतर की आवश्यकता क्यों है। अगर किसी को पता है, तो मुझे एक लाइन छोड़ दो।
आम तौर पर, हम कुछ अतिरिक्त संस्करणों की परवाह नहीं करते हैं, किसी दिए गए SQL ID के लिए कुछ चाइल्ड कर्सर। यदि आपके SQL कथन में अधिक संख्या में संस्करण हैं, तो यह संभवतः विभिन्न गहराई स्तरों के कारण नहीं है। अन्य कारण अधिक प्रासंगिक होंगे कि SQL कथन में अधिक संख्या में चाइल्ड कर्सर क्यों होंगे, विभिन्न संस्करणों की एक उच्च संख्या। लेकिन यह इस सवाल का जवाब जरूर देता है कि वह कॉलम हमें क्या बता रहा है।
