जैसा कि प्रदर्शन से संबंधित सभी प्रश्नों का उत्तर है, "यह निर्भर करता है"। RLS नियंत्रित क्वेरी को एक बाहरी क्वेरी में लपेटकर काम करता है जो पॉलिसी फ़ंक्शन को WHERE क्लॉज के रूप में लागू करता है...
select /*+ rls query */ * from (
select /*+ your query */ ... from t23
where whatever = 42 )
where rls_policy.function_t23 = 'true'
तो प्रदर्शन प्रभाव पूरी तरह से समारोह में क्या होता है पर निर्भर करता है।
इन चीजों को करने का सामान्य तरीका संदर्भ नामस्थानों का उपयोग करना है। ये SYS_CONTEXT() फ़ंक्शन के माध्यम से एक्सेस की गई सत्र मेमोरी के पूर्वनिर्धारित क्षेत्र हैं। जैसे किसी संदर्भ से संग्रहीत मूल्य को पुनः प्राप्त करने की लागत नगण्य है। और जैसा कि हम आम तौर पर प्रति सत्र एक बार नामस्थानों को पॉप्युलेट करते हैं - एक लॉगऑन ट्रिगर या इसी तरह के कनेक्शन हुक द्वारा कहें - प्रति क्वेरी कुल लागत छोटी है। नेमस्पेस को रीफ्रेश करने के विभिन्न तरीके हैं जिनमें प्रदर्शन प्रभाव हो सकते हैं लेकिन फिर से ये चीजों की समग्र योजना में तुच्छ हैं (यह अन्य उत्तर देखें )।
तो प्रदर्शन प्रभाव इस बात पर निर्भर करता है कि आपका कार्य वास्तव में क्या करता है। जो हमें आपकी वास्तविक नीति के बारे में बताता है:
अच्छी खबर है निष्पादन इस तरह के एक समारोह के अपने आप में महंगा होने की संभावना नहीं है। बुरी खबर यह है कि प्रदर्शन अभी भी तह चूसना हो सकता है! वैसे भी, यदि जीवित अभिलेखों का ऐतिहासिक अभिलेखों से अनुपात प्रतिकूल है। आप शायद सभी रिकॉर्ड्स को पुनः प्राप्त कर लेंगे और फिर ऐतिहासिक लोगों को फ़िल्टर कर देंगे। ऑप्टिमाइज़र आरएलएस विधेय को मुख्य क्वेरी में धकेल सकता है, लेकिन मुझे लगता है कि आरएलएस के काम करने के तरीके के कारण इसकी संभावना नहीं है:यह नीति के मानदंडों को सामान्य रूप से प्रकट करने से बचता है (जो डिबगिंग आरएलएस संचालन को वास्तविक पीआईटीएन बनाता है)।
आपके उपयोगकर्ता आपके खराब डिज़ाइन निर्णय की कीमत चुकाएंगे। पुराने रिकॉर्ड को स्टोर करने और वास्तविक टेबल में केवल लाइव डेटा रखने के लिए जर्नलिंग या हिस्ट्री टेबल रखना बेहतर है। जीवित लोगों के साथ-साथ ऐतिहासिक रिकॉर्ड बनाए रखना शायद ही कोई समाधान होता है जो मापता है।
DBMS_RLS को एंटरप्राइज़ संस्करण लाइसेंस की आवश्यकता है।
