Oracle के दस्तावेज़ के अनुसार ,
PL/SQL प्रोग्रामिंग भाषा पर आधारित है। .DIANA आंतरिक रूप से कंपाइलर और अन्य टूल द्वारा उपयोग किया जाता है।
संकलन समय पर, पीएल/एसक्यूएल स्रोत कोड को मशीन-पठनीय एम-कोड में अनुवादित किया जाता है। प्रक्रिया या पैकेज के लिए डायना और एम-कोड दोनों डेटाबेस में संग्रहीत होते हैं। रन टाइम पर, उन्हें साझा मेमोरी पूल में लोड किया जाता है। डायना का उपयोग निर्भर प्रक्रियाओं को संकलित करने के लिए किया जाता है; एम-कोड बस निष्पादित किया जाता है।
दुर्भाग्य से, आप पार्स किए गए आकार से DIANA नोड्स की संख्या का अनुमान नहीं लगा सकते हैं। समान पार्स किए गए आकार वाली दो प्रोग्राम इकाइयों को क्रमशः 1500 और 2000 DIANA नोड्स की आवश्यकता हो सकती है, उदाहरण के लिए, दूसरी इकाई में अधिक जटिल SQL कथन होते हैं।
डायना नोड कैलकुलेशन पर अधिक, इस पुस्तक को पढ़ें "एडा-यूरोप '93:12वां एडा-यूरोप अंतर्राष्ट्रीय सम्मेलन, "एडा सैन्स फ्रंटियर्स", पेरिस, फ्रांस, 14-18 जून, 1993। कार्यवाही"
निम्नलिखित समर्थन नोट में इस विषय को अच्छी तरह शामिल किया गया है...
Article-ID: <Note:62603.1>
Folder: PLSQL
Topic: General Information Articles
Title: 'PLS-123 Program too Large' - Size Limitations on PLSQL
Packages
Document-Type: BULLETIN
Impact: MEDIUM
Skill-Level: NOVICE
Server-Version: 07 to 08
Updated-Date: 13-JUN-2000 17:41:01
References:
अवलोकन
इस आलेख में PL/SQL पैकेज आकार सीमाओं के बारे में जानकारी है। जब सीमाएँ पार हो जाती हैं, तो आपको निम्न त्रुटि प्राप्त होती है:
PLS-123 Program too large
पीएल/एसक्यूएल पैकेज पर आकार सीमाएं
8.1.3 से पहले के रिलीज में, बड़े कार्यक्रमों के परिणामस्वरूप PLS-123 त्रुटि हुई। यह संकलक में वास्तविक सीमाओं के कारण हुआ; बग के परिणामस्वरूप नहीं।
पीएल/एसक्यूएल इकाई संकलित करते समय, संकलक एक पार्स पेड़ बनाता है। एपीएल/एसक्यूएल इकाई का अधिकतम आकार पार्स ट्री के आकार से निर्धारित होता है। इस पेड़ में अधिकतम संख्या में डायना नोड मौजूद हैं।
7.3 तक, आपके पास 2 * * 14 (16K) डायना नोड्स हो सकते हैं, और 8.0 से 8.1.3 तक, 2 * * 15 (32K) डायना नोड्स की अनुमति है। 8.1.3 के साथ, इस सीमा में ढील दी गई है ताकि अब आपके पास पैकेज और टाइप बॉडी के लिए इस ट्री में 2 * * 26 (यानी, 64M) डायना नोड हो सकते हैं।
स्रोत कोड सीमाएं
हालांकि स्रोत कोड की पंक्तियों के संदर्भ में सीमाओं का अनुवाद करने का कोई आसान तरीका नहीं है, यह हमारा अवलोकन रहा है कि स्रोत कोड की प्रति पंक्ति लगभग 5 से 10 नोड हैं। 8.1.3 से पहले, कंपाइलर कोड की लगभग 3,000 पंक्तियों को स्पष्ट रूप से संकलित कर सकता था।
8.1.3 से शुरू होकर, पैकेज बॉडी और टाइप बॉडीज के लिए सीमा में ढील दी गई थी, जिसमें अब लगभग 6,000,000 लाइन कोड हो सकते हैं।
नोट:यह नई सीमा केवल पैकेज निकायों और प्रकार निकायों पर लागू होती है। साथ ही, अब आप इस विशेष कंपाइलर सीमा तक पहुंचने से पहले कुछ अन्य कंपाइलर सीमाओं को मारना शुरू कर सकते हैं।
स्रोत कोड आकार के संदर्भ में, मान लें कि टोकन (पहचानकर्ता, ऑपरेटर, फ़ंक्शन, आदि), औसतन चार वर्ण लंबे होते हैं। तब, अधिकतम होगा:
Up to 7.3: 4 * (2 * * 14)=64K
From 8.0 to 8.1.3: 4 * (2 * * 15)=128K
With 8.1.3: 4 * (2 * * 25)=256M
यह एक मोटा अनुमान है। यदि आपके कोड में कई रिक्त स्थान, लंबे पहचानकर्ता आदि हैं, तो आप इससे बड़ा स्रोत कोड प्राप्त कर सकते हैं। यदि आपके स्रोत बहुत कम पहचानकर्ताओं आदि का उपयोग करते हैं, तो आपको इससे छोटा स्रोत कोड भी मिल सकता है।
ध्यान दें कि यह प्रति कार्यक्रम इकाई है, इसलिए पैकेज निकायों को इस सीमा का सामना करने की सबसे अधिक संभावना है।
पैकेज के वर्तमान आकार की जांच कैसे करें
पैकेज के आकार की जांच करने के लिए, डेटा डिक्शनरी व्यू USER_OBJECT_SIZE में आप जिस निकटतम संबंधित नंबर का उपयोग कर सकते हैं वह PARSED_SIZE है। यह मान SYS.IDL_xxx$ तालिकाओं में संग्रहीत डायना इनबाइट्स का आकार प्रदान करता है और साझा पूल में आकार नहीं है।
पीएल/एसक्यूएल कोड (संकलन के दौरान प्रयुक्त) के डायना हिस्से का आकार सिस्टम टेबल की तुलना में साझा पूल में बहुत बड़ा है।
उदाहरण के लिए, जब USER_OBJECT_SIZE में PARSED_SIZE 50K से अधिक न हो, तो आपको 64K सीमा के साथ समस्याओं का सामना करना पड़ सकता है।
एक पैकेज के लिए, डायना का पार्स किया गया आकार या आकार केवल संपूर्ण वस्तु के लिए समझ में आता है, विनिर्देश और शरीर के लिए अलग से नहीं।
यदि आप किसी पैकेज के लिए parsed_size का चयन करते हैं, तो आपको विनिर्देश और बॉडी के लिए अलग स्रोत और कोड आकार प्राप्त होते हैं, लेकिन संपूर्ण ऑब्जेक्ट के लिए केवल एक अर्थपूर्ण पार्स आकार प्राप्त होता है जो पैकेज विनिर्देश के लिए लाइन पर आउटपुट होता है। एक 0 पैकेज बॉडी के लिए parsed_sizeon लाइन के लिए आउटपुट है।
निम्न उदाहरण इस व्यवहार को प्रदर्शित करता है:
CREATE OR REPLACE PACKAGE example AS
PROCEDURE dummy1;
END example;
/
CREATE OR REPLACE PACKAGE BODY example AS
PROCEDURE dummy1 IS
BEGIN
NULL;
END;
END;
/
SQL> start t1.sql;
Package created.
Package body created.
SQL> select parsed_size from user_object_size where name='EXAMPLE';
PARSED_SIZE
-----------
185
0
SQL> select * from user_object_size where name='EXAMPLE';
.....
Oracle डेटाबेस में DIANA और MCODE दोनों को स्टोर करता है। MCODE वास्तविक कोड है जो चलता है, जबकि एक विशेष पुस्तकालय इकाई X के लिए DIANA में ऐसी जानकारी होती है जो पुस्तकालय इकाई X का उपयोग करके प्रक्रियाओं को संकलित करने के लिए आवश्यक होती है।
निम्नलिखित कई नोट हैं:
ए) डायना को आईडीएल में दर्शाया गया है। IDL का रैखिक संस्करण डिस्क पर संग्रहीत होता है। वास्तविक पार्स ट्री को साझा पूल में बनाया और संग्रहीत किया जाता है। यही कारण है कि साझा पूल में डायना का आकार आमतौर पर डिस्क से बड़ा होता है।
b) साझा पूल में तथाकथित प्रक्रियाओं के लिए डायना की आवश्यकता तभी होती है जब आप प्रक्रियाएं बनाते हैं। उत्पादन प्रणालियों में, साझा पूल में डायना की कोई आवश्यकता नहीं है (लेकिन केवल MCODE के लिए)।
सी) रिलीज 7.2 से शुरू होकर, पैकेज निकायों के लिए डायना को फेंक दिया जाता है, उपयोग नहीं किया जाता है, और डेटाबेस में संग्रहीत नहीं किया जाता है। यही कारण है कि PACKAGE BODIES का PARSED_SIZE (अर्थात डायना का आकार) 0 है।
डेटाबेस में डायना में एक प्रक्रिया की तरह एक पैकेज संग्रहीत किया जाता है। हालांकि, एक पैकेज का उपयोग निर्भरता श्रृंखला को तोड़ने के लिए किया जा सकता है, शायद इसे दूर करने के लिए। यह मेरा विश्वास है कि सभी उत्पादन (वास्तविक) कोड एक पैकेज में होना चाहिए, कभी भी एक स्टैंडअलोन प्रक्रिया या कार्य में नहीं होना चाहिए।
