सभी चीजों के साथ, यह निर्भर करता है।
यदि आप OCI का उपयोग कर रहे हैं, तो मुझे लगता है कि आप एक क्लाइंट / सर्वर एप्लिकेशन विकसित कर रहे हैं। मैं आम तौर पर साझा सर्वर कनेक्शन का समर्थन करने के लिए उस स्थिति में डेटाबेस चाहता हूं और जब डेटाबेस डेटाबेस से जुड़ा होता है तो मैं साझा सर्वर कनेक्शन का अनुरोध करना चाहता हूं। नए सत्र को बनाने के लिए डेटाबेस को जितना काम करना है, उतने सीमित करके एप्लिकेशन के प्रदर्शन में सुधार होता है। यह सर्वर पर दूसरों के लिए उपलब्ध अधिक संसाधनों को छोड़ने का दुष्प्रभाव है। साझा सर्वर कनेक्शन का उपयोग करने पर एक लंबा कोड पथ शामिल होता है जब क्वेरी के बाद के डेटाबेस को निष्पादित करने के बाद क्वेरी को एक साझा सर्वर प्रक्रिया में भेजा जाना होता है, लेकिन आम तौर पर साझा सर्वर प्रक्रियाओं की संख्या उचित होने पर यह कोई बड़ी बात नहीं है।
यदि DBA स्वचालित PGA प्रबंधन का उपयोग नहीं कर रहा है, तो कई सत्र खोलना भी एक समस्या हो सकती है। यदि आप मैन्युअल पीजीए प्रबंधन का उपयोग कर रहे हैं, तो पीजीए को प्रति सत्र के आधार पर कॉन्फ़िगर किया गया है, ताकि प्रत्येक सत्र SORT_AREA_SIZEअन्य वीजीए घटकों के बीच के प्रकार के लिए एक अलग आवंटित कर सके । यदि आपने मैन्युअल PGA प्रबंधन का उपयोग करके डेटाबेस में बड़ी संख्या में सत्र बनाए हैं और प्रत्येक सत्र ने अपने PGA उपयोग को अधिकतम करने का प्रयास किया है, तो आप आसानी से RAM के सर्वर को भूखा रख सकते हैं और सभी के लिए प्रदर्शन समस्याओं का कारण बन सकते हैं। मान लें कि आप Oracle 10.1 या बाद का उपयोग कर रहे हैं, हालाँकि, स्वचालित PGA प्रबंधन उपलब्ध है। उस स्थिति में, डीबीए PGA_AGGREGATE_TARGET(या MEMORY_TARGET11 पी में पीजीए को शामिल करता है ) को कॉन्फ़िगर करता है और डेटाबेस यह सुनिश्चित करने का ख्याल रखता है कि सभी सत्रों में समग्र पीजीए सीमित है ताकि डेटाबेस संसाधनों से बाहर चला जाए।
यदि डेटाबेस साझा सर्वर कनेक्शन का समर्थन करता है, तो आपके एप्लिकेशन को साझा सर्वर कनेक्शन मिलता है, और डेटाबेस स्वचालित पीजीए प्रबंधन का उपयोग करता है, अधिकांश डीबीए आपके द्वारा बनाए गए सत्रों की परवाह नहीं करेगा।
अब, यदि आप कई सत्र बना रहे हैं ताकि आप समानांतर में अधिक काम कर सकें, तो सत्रों की संख्या के ऊपर और ऊपर प्रदर्शन की समस्याएं पैदा होंगी। डेटाबेस को 1000 सत्रों का समर्थन करने के लिए कॉन्फ़िगर करना काफी आसान है, उदाहरण के लिए, डेटाबेस को ढेर में न मरने के लिए कॉन्फ़िगर करना बहुत कठिन है यदि सभी 1000 सत्र एक साथ एक डेटा वेयरहाउस के खिलाफ एक भावपूर्ण क्वेरी जारी करते हैं। यदि आपका एप्लिकेशन डेटाबेस के लिए आपके प्रश्नों के लिए उपलब्ध सभी संसाधनों का उपयोग कर रहा है, तो DBA शायद Oracle संसाधन प्रबंधक का उपयोग करने पर विचार करना चाहेगाविभिन्न अनुप्रयोगों और / या विभिन्न उपयोगकर्ताओं को प्राथमिकता देना। उदाहरण के लिए, डीबीए रिसोर्स मैनेजर को कॉन्फ़िगर कर सकता है ताकि यदि सीपीयू का उपयोग 100% हो जाए, तो कुल में आपके एप्लिकेशन को 50% सीपीयू मिलता है, एग्रीगेट में किसी अन्य एप्लिकेशन को 25% मिलता है, और अन्य सभी को शेष 25% मिलता है। । यदि कोई अन्य अनुरोध लंबित नहीं था, तो आपका एप्लिकेशन सभी 100% CPU का उपयोग करने के लिए स्वतंत्र होगा।
यदि आप समानांतर में चीजें चला रहे हैं, तो यह ओरेकल के समानांतर में बयानों को चलाने की क्षमता की जांच करने के लिए भी उपयोगी हो सकता है क्योंकि इसमें आपके स्वयं के समानांतर कोड लिखने की तुलना में कम ओवरहेड शामिल हो सकता है। मैं उदाहरण के लिए, उम्मीद करता हूं कि यह एक क्लाइंट एप्लिकेशन लिखने के लिए बहुत आसान और संभवतया तेजी से होगा जो क्रमिक रूप से प्रस्तुत किए गए कथन हैं जो कई सत्रों को खोलने के बजाय ओरेकल समानांतर क्वेरी का उपयोग करते थे और आपके आवेदन के एक अलग थ्रेड से प्रत्येक स्टेटमेंट को निष्पादित करते समय। ओरेकल किसी भी कथन को निष्पादित करने के लिए समानांतर क्वेरी का उपयोग नहीं कर रहा था। यदि आप समानांतर क्वेरी का उपयोग करते हैं, तो डेटाबेस समानांतर स्लेव्स की संख्या को समायोजित कर सकता है, जो कि स्पैन किए जाते हैं ताकि जब डेटाबेस विशेष रूप से व्यस्त हो तो कम समानांतर स्लेव्स शुरू हो जाते हैं और जब डेटाबेस अपेक्षाकृत निष्क्रिय होता है तो अधिक समानांतर स्लेव्स शुरू हो जाते हैं।