DBA के अनुरोध का कोई मतलब नहीं है।
डीबीए लगभग निश्चित रूप से सोच रहा है कि वह एसक्यूएल की संख्या को पीएल/एसक्यूएल इंजन संदर्भ बदलावों को कम करना चाहता है जो कर्सर से डेटा प्राप्त करते समय चलते हैं। लेकिन जिस समाधान का सुझाव दिया जा रहा है वह इस विशेष समस्या पर खराब लक्षित है और अधिकांश प्रणालियों में अन्य अधिक गंभीर प्रदर्शन समस्याओं का परिचय देता है।
Oracle में, SQL से PL/SQL संदर्भ बदलाव तब होता है जब PL/SQL VM SQL VM से अधिक डेटा के लिए पूछता है, SQL VM उस डेटा को प्राप्त करने के लिए कथन को आगे निष्पादित करके प्रतिक्रिया करता है जिसे वह तब पैकेज करता है और PL को वापस सौंपता है /एसक्यूएल वीएम। यदि पीएल/एसक्यूएल इंजन एक बार में पंक्तियों के लिए पूछ रहा है और आप बहुत सारी पंक्तियां ला रहे हैं, तो संभव है कि ये संदर्भ बदलाव आपके समग्र रनटाइम का एक महत्वपूर्ण अंश हो सकते हैं। उस समस्या से निपटने के लिए, Oracle ने कम से कम 8i दिनों में थोक संचालन की अवधारणा को वापस पेश किया। इसने PL/SQL VM को SQL VM से एक बार में कई पंक्तियों का अनुरोध करने की अनुमति दी। यदि PL/SQL VM एक बार में 100 पंक्तियों का अनुरोध करता है, तो आपने 99% संदर्भ परिवर्तन समाप्त कर दिए हैं और आपका कोड संभावित रूप से बहुत तेज़ी से चलता है।
एक बार बल्क ऑपरेशन शुरू किए जाने के बाद, बहुत सारे कोड थे जिन्हें स्पष्ट रूप से BULK COLLECT का उपयोग करके अधिक कुशल होने के लिए पुन:सक्रिय किया जा सकता था। पंक्ति-दर-पंक्ति लाने और फिर FORALL . का उपयोग करने के बजाय संचालन उन संग्रहों में डेटा को संसाधित करने के लिए लूप। हालांकि, 10.2 दिनों तक, Oracle ने थोक संचालन को अंतर्निहित FOR . में एकीकृत कर दिया था लूप्स तो एक निहित FOR लूप अब स्वचालित रूप से पंक्ति-दर-पंक्ति लाने के बजाय 100 के बैच में स्वचालित रूप से एकत्रित होता है।
हालांकि, आपके मामले में, चूंकि आप क्लाइंट एप्लिकेशन को डेटा वापस कर रहे हैं, बल्क ऑपरेशंस का उपयोग बहुत कम महत्वपूर्ण है। किसी भी सभ्य क्लाइंट-साइड एपीआई में कार्यक्षमता होने वाली है जो क्लाइंट को यह निर्दिष्ट करने देती है कि प्रत्येक नेटवर्क राउंड-ट्रिप में कर्सर से कितनी पंक्तियों को लाने की आवश्यकता है और उन लाने के अनुरोध सीधे एसक्यूएल वीएम पर जा रहे हैं, पीएल के माध्यम से नहीं /एसक्यूएल वीएम, इसलिए चिंता करने के लिए पीएल/एसक्यूएल संदर्भ बदलाव के लिए कोई एसक्यूएल नहीं है। आपके एप्लिकेशन को प्रत्येक राउंड-ट्रिप में उचित संख्या में पंक्तियों को लाने के बारे में चिंता करनी होगी-- पर्याप्त है कि एप्लिकेशन नेटवर्क पर बहुत अधिक बातूनी और अड़चन न बने, लेकिन इतने अधिक नहीं कि आपको परिणामों के लिए बहुत लंबा इंतजार करना पड़े। लौटाया या स्मृति में बहुत अधिक डेटा संग्रहीत करने के लिए।
क्लाइंट एप्लिकेशन के लिए आरईएफ कर्सर के बजाय पीएल/एसक्यूएल संग्रह लौटाने से होने वाले संदर्भ बदलावों की संख्या कम नहीं होगी। लेकिन इसमें अन्य डाउनसाइड्स का एक गुच्छा होने वाला है, जिनमें से कम से कम मेमोरी का उपयोग नहीं है। एक PL/SQL संग्रह को डेटाबेस सर्वर पर पूरी तरह से प्रोसेस ग्लोबल एरिया (PGA) (समर्पित सर्वर कनेक्शन मानते हुए) में संग्रहित किया जाना है। यह मेमोरी का एक हिस्सा है जिसे सर्वर की रैम से आवंटित किया जाना है। इसका मतलब है कि सर्वर को स्मृति आवंटित करनी होगी जिसमें प्रत्येक ग्राहक द्वारा अनुरोध की जाने वाली प्रत्येक अंतिम पंक्ति को लाने के लिए। बदले में, यह आपके एप्लिकेशन की मापनीयता को नाटकीय रूप से सीमित करने वाला है और, डेटाबेस कॉन्फ़िगरेशन के आधार पर, Oracle डेटाबेस के अन्य भागों से RAM को चुरा सकता है जो एप्लिकेशन प्रदर्शन को बेहतर बनाने में बहुत उपयोगी होगा। और यदि आप पीजीए स्थान से बाहर भागते हैं, तो आपके सत्रों में स्मृति संबंधी त्रुटियां होने लगेंगी। यहां तक कि पूरी तरह से पीएल/एसक्यूएल आधारित अनुप्रयोगों में भी, आप कभी भी सभी डेटा को संग्रह में नहीं लाना चाहेंगे, आप इसे हमेशा छोटे बैचों में लाना चाहेंगे, ताकि आपके द्वारा उपयोग किए जा रहे पीजीए की मात्रा को कम किया जा सके।
इसके अलावा, सभी डेटा को मेमोरी में लाने से एप्लिकेशन बहुत धीमा महसूस करने वाला है। लगभग कोई भी ढांचा आपको डेटा प्राप्त करने की अनुमति देता है, उदाहरण के लिए, यदि आपके पास एक रिपोर्ट है कि आप प्रत्येक 25 पंक्तियों के पृष्ठों में प्रदर्शित कर रहे हैं, तो आपके आवेदन को केवल पहली 25 पंक्तियों को चित्रित करने से पहले लाने की आवश्यकता होगी पहली स्क्रीन। और इसे अगली 25 पंक्तियों को तब तक नहीं लाना पड़ेगा जब तक कि उपयोगकर्ता परिणामों के अगले पृष्ठ का अनुरोध नहीं करता। यदि आप डेटा को सरणियों में ला रहे हैं जैसे कि आपका डीबीए प्रस्ताव करता है, हालांकि, आपको सभी पंक्तियों को लाना होगा इससे पहले कि आपका आवेदन पहली पंक्ति प्रदर्शित करना शुरू कर सके, भले ही उपयोगकर्ता पहले मुट्ठी भर से अधिक कभी नहीं देखना चाहता हो पंक्तियाँ। इसका मतलब है कि सभी पंक्तियों को लाने के लिए डेटाबेस सर्वर पर बहुत अधिक I/O, सर्वर पर अधिक पीजीए, परिणाम को बफर करने के लिए एप्लिकेशन सर्वर पर अधिक रैम, और नेटवर्क के लिए लंबे समय तक इंतजार करना होगा।
