जब भी हम किसी डेटाबेस ऑब्जेक्ट में कोई परिवर्तन परिनियोजित करते हैं तो उस पर निर्भर कोई भी कोड अमान्य हो जाता है। यह ट्रिगर्स, विचारों और संग्रहीत प्रक्रियाओं को प्रभावित करता है। हालांकि, अगली बार जब कुछ उस कोड को कॉल करता है तो डेटाबेस स्वचालित रूप से इसे पुन:संकलित कर देगा।
तो हमें इस बारे में चिंता करने की ज़रूरत नहीं है, है ना? खैर, हाँ, एक बिंदु तक। बात यह है कि, ट्रिगर्स (या जो भी) का अमान्य होना हमारे लिए एक झंडा है कि एक बदलाव किया गया है जो उस ट्रिगर के संचालन को प्रभावित कर सकता है, जिसके दुष्प्रभाव हो सकते हैं। सबसे स्पष्ट दुष्प्रभाव यह है कि ट्रिगर संकलित नहीं होगा। अधिक सूक्ष्मता से, ट्रिगर संकलित करता है लेकिन संचालन के दौरान विफल रहता है।
इसलिए, यह सुनिश्चित करने के लिए कि हमारे परिवर्तन ने मौलिक रूप से कुछ भी तोड़ा नहीं है, विकास के माहौल में ट्रिगर्स के पुनर्संकलन को बाध्य करना एक अच्छा विचार है। लेकिन हम उस कदम को छोड़ सकते हैं जब हम उत्पादन में अपने बदलाव को लागू करते हैं, क्योंकि हमें इतना विश्वास है कि मांग पर सब कुछ फिर से संकलित हो जाएगा। हमारे तंत्रिका पर निर्भर करता है :)
Oracle स्कीमा में सभी अमान्य वस्तुओं को स्वचालित रूप से पुन:संकलित करने के लिए तंत्र प्रदान करता है।
-
DBMS_UTILITY.COMPILE_SCHEMA(). का उपयोग करना सबसे आसान है . लेकिन यह 8i के बाद से नीरस रहा है (क्योंकि जावा संग्रहीत प्रक्रियाओं के लिए समर्थन ने परिपत्र निर्भरता की संभावना को पेश किया) और अब सभी वस्तुओं को सफलतापूर्वक पहली बार संकलित करने की गारंटी नहीं है। -
9i में Oracle ने हमें एक स्क्रिप्ट दी
$ORACLE_HOME/rdbms/admin/utlrp.sqlजो चीजों को पुन:संकलित करता है। दुर्भाग्य से इसे SYSDBA एक्सेस की आवश्यकता है। -
10g में उन्होंने UTL_RECOMP पैकेज जोड़ा, जो मूल रूप से वह सब कुछ करता है जो वह स्क्रिप्ट करता है। बड़ी संख्या में वस्तुओं को पुन:संकलित करने के लिए यह अनुशंसित दृष्टिकोण है। दुर्भाग्य से इसे SYSDBA एक्सेस की भी आवश्यकता है। और जानें ।
11g में Oracle ने बढ़िया निर्भरता प्रबंधन की शुरुआत की। इसका मतलब यह है कि तालिकाओं में परिवर्तन का मूल्यांकन एक बेहतर ग्रैन्युलैरिटी (मूल रूप से तालिका स्तर के बजाय स्तंभ स्तर) पर किया जाता है, और केवल वे वस्तुएं जो परिवर्तनों से सीधे प्रभावित होती हैं, प्रभावित होती हैं। अधिक जानें .
