आपके प्रश्न वास्तव में पूर्ण नहीं हो रहे हैं। हालाँकि आपकी क्वेरी केवल पहली 1000 पंक्तियों को प्राप्त करती है, SQL डेवलपर केवल उन 1000 पंक्तियों की पहली 50 पंक्तियों को प्राप्त कर रहा है। जब तक आप अंतिम पंक्ति तक स्क्रॉल नहीं करते, तब तक IDE कर्सर को बंद नहीं करेगा। एक बार जब आप सभी डेटा को पुनः प्राप्त कर लेते हैं, तो वे समानांतर प्रक्रियाएं गायब हो जाती हैं। सुनिश्चित करें कि आप ""Y सेकंड में 50 पंक्तियाँ प्राप्त की गई" के बजाय "सभी पंक्तियाँ प्राप्त:1000 में X सेकंड" देखते हैं। (काश SQL डेवलपर इसे और अधिक स्पष्ट रूप से स्पष्ट करता कि अतिरिक्त पंक्तियाँ प्रतीक्षा कर रही हैं।) इस समस्या को SQL*Plus में देखें क्योंकि SQL*Plus हमेशा सभी पंक्तियों को पकड़ लेता है।
जब केवल पहली एन पंक्तियां प्राप्त की जाती हैं, तो समानांतर प्रक्रियाएं "सक्रिय" होती हैं लेकिन कुछ भी नहीं कर रही हैं। आपको चाहिए उन सत्रों को अनदेखा करने में सक्षम हो क्योंकि वे किसी महत्वपूर्ण संसाधन का उपयोग नहीं कर रहे हैं।
यदि आप केवल समानांतर सत्रों की संख्या के बारे में चिंतित हैं, तो हो सकता है कि आप अपनी अपेक्षाओं को समायोजित करना चाहें। मैं आपके जैसी ही स्थिति में हुआ करता था - लगातार उपयोगकर्ताओं को बता रहा था कि उनके (अपूर्ण) प्रश्न सभी समानांतर सत्रों को बाधित कर रहे थे। आखिरकार, मुझे पता चला कि यह केवल एक समस्या थी क्योंकि मैंने कृत्रिम रूप से दुर्लभ संसाधन बनाया था। Oracle समानांतर प्रक्रियाएं आमतौर पर हल्की होती हैं, और डेटाबेस अधिकांश लोगों के विचार से अधिक समानांतर प्रक्रियाओं का समर्थन कर सकते हैं।
PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU, और CPU_COUNT के लिए आपके पैरामीटर मान क्या हैं? PARALLEL_MAX_SERVERS
. मैनुअल के अनुसार, डिफ़ॉल्ट संख्या है:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 ।
अधिकांश डीबीए सैकड़ों, घबराहट में समानांतर धागे की अधिकतम संख्या देखते हैं, और फिर उस संख्या को कम कर देते हैं। और फिर हम डेवलपर्स पर एक महत्वहीन संसाधन का उपयोग करने के लिए चिल्लाना शुरू करते हैं जो कृत्रिम रूप से सीमित था। इसके बजाय, हमें संख्या को डिफ़ॉल्ट रूप से वापस क्रैंक करना चाहिए, और केवल यादृच्छिक समानांतर सत्रों को अनदेखा करना चाहिए। यदि कोई उपयोगकर्ता IO या CPU सीमा से अधिक नहीं है, तो इससे कोई फ़र्क नहीं पड़ता कि वे कितने समानांतर थ्रेड का उपयोग करते हैं।
(बड़े पैमाने पर . को रोकने के संभावित अपवाद के साथ समानांतर क्वेरी सत्र उपयोग। अपने उपयोगकर्ताओं को एक अलग प्रोफ़ाइल में रखें, और उनके SESSIONS_PER_USER को कुछ दर्जन पर सेट करें। इसे केवल 1 या 2 तक सीमित न करें। आईडीई को एकाधिक टैब के लिए अतिरिक्त सत्रों की आवश्यकता होती है, पृष्ठभूमि प्रक्रियाएं जो मेटाडेटा को पकड़ती हैं, और डीबग सत्र। यदि आप सीमा 2 पर सेट करते हैं, तो आपके डेवलपर किसी IDE का ठीक से उपयोग नहीं कर पाएंगे।)
संपादित करें (टिप्पणियों की प्रतिक्रिया)
मुझे नहीं पता कि आप क्वेरी समन्वयक . क्यूसी कई चीजें करता है, लेकिन आदर्श रूप से यह ज्यादातर समय निष्क्रिय रहेगा जबकि समानांतर सत्र ज्यादातर काम संभालते हैं।
निर्माता/उपभोक्ता मॉडल के साथ, समांतर सत्रों में से आधे डेटा प्राप्त कर रहे हैं लेकिन वास्तव में कुछ भी नहीं कर रहे हैं - जैसे वे कुछ परिचालनों में केवल स्मृति संरचनाएं हैं। समानांतर सत्र सक्रिय और निष्क्रिय के बीच स्विच कर सकते हैं, क्योंकि सभी चरणों के लिए उतने सत्रों की आवश्यकता नहीं होगी। लेकिन हम नहीं चाहेंगे कि Oracle बीच में सत्र बंद करे, क्योंकि बाद में उनकी आवश्यकता हो सकती है और हम सत्र खोलने और बंद करने में समय बर्बाद नहीं करना चाहेंगे।
ऐसे दर्जनों कारक हैं जो समांतरता की डिग्री को प्रभावित करते हैं, लेकिन जहां तक मुझे पता है कि PARALLEL_MAX_SERVERS बढ़ने से एकल कथन के लिए अनुरोधित समानांतर सर्वरों की संख्या प्रभावित नहीं होगी। (लेकिन अगर स्टेटमेंट पहले से ही अधिकतम से अधिक सर्वर मांग रहा था, तो पैरामीटर बढ़ाने से आवंटित सत्रों की संख्या प्रभावित हो सकती है)।
ऐसा लग सकता है कि SQL स्टेटमेंट सभी समानांतर सत्रों को बेतरतीब ढंग से पकड़ रहे हैं, लेकिन अंततः DOP गणना लगभग हमेशा नियतात्मक नियमों का पालन करती है। यह सिर्फ इतना है कि नियम इतने जटिल हैं, यह बताना मुश्किल है कि यह कैसे काम करता है। उदाहरण के लिए, भ्रम का एक सामान्य बिंदु यह है कि जब भी कोई क्वेरी सॉर्टिंग या ग्रुपिंग जोड़ती है, तो समानांतर सत्रों की संख्या दोगुनी हो जाती है।
