ओरेकल - क्यों चुनें * फू से; बहुत धीरे?

Question

मैं अपने वेब ऐप के साथ कुछ ओरेकल प्रदर्शन मुद्दों पर काम कर रहा हूं। एक बात मैंने देखा है कि ऐसा लगता है कि किसी भी तरह के परीक्षणों को खराब करना प्रतीत होता है कि बहुत से परिणाम लौटने वाले सरल प्रश्न अभी भी बहुत धीमे हैं। एक उदाहरण है:

select * from TPM_PROJECTWORKGROUPS; 

जब मैंने इसे चलाने के लिए, मैं:

5825 record(s) selected [Fetch MetaData: 0ms] [Fetch Data: 59s] 

[Executed: 9/22/2011 1:52:38 PM] [Execution: 203ms] 

यदि मैं यह सही ढंग से समझ, इसका मतलब है वास्तविक क्वेरी को चलाने के लिए 203ms लिया, लेकिन यह करने के लिए कि डेटा के लिए 59 सेकंड लगे ग्राहक को वापस लौटाया जाए, क्या इस मामले में "प्राप्त करें" का अर्थ है?

मुझे डेटाबेस मशीन से सीधे कनेक्ट करने और स्थानीय रूप से क्वेरी चलाने की सुविधा नहीं है, लेकिन क्या यह मानना ​​सुरक्षित है कि अपराधी वास्तविक नेटवर्क बैंडविड्थ है? यह समझ में आता है क्योंकि मैं सिएटल में हूं और सर्वर न्यूयॉर्क में है, लेकिन 5800 पंक्तियों के लिए अभी भी एक मिनट काफी धीमी गति से दिखता है।

क्या ए के लिए कोई त्वरित सलाह है) यह पुष्टि करना कि नेटवर्क बैंडविड्थ वास्तव में समस्या है और बी) किसी भी "गॉथचास" या चीजों को जांचने के लिए तारों पर डेटा को क्रमबद्ध करना क्यों धीमा है? धन्यवाद!

कुछ अपडेट टिप्पणी के आधार पर: से

COUNT का चयन करें (*) (* चुनें TPM_PROJECTWORKGROUPS से) टी;

परिणाम:

1 record(s) selected [Fetch MetaData: 0ms] [Fetch Data: 0ms] 

[Executed: 9/22/2011 2:16:08 PM] [Execution: 219ms] 

और अगर मैं केवल एक स्तंभ का चयन करके देखें:

चयन TPM_PROJECTWORKGROUPS से PROJECTID;

परिणाम:

5825 रिकॉर्ड (रों) चुना गया [लायें मेटाडाटा: 0ms] [डेटा लाएं: 1 मी 0]

[निष्पादित: 2011/09/22 02:17:20 PM] [निष्पादन: 203ms]

तालिका स्कीमा:

PROJECTID (संख्या) WORKGROUPID (संख्या)

Answer 1

डेटाबेस के साथ बातचीत करने के लिए आप किस एपीआई का उपयोग कर रहे हैं (एसक्यूएल * प्लस, जेडीबीसी, ओडीबीसी, आदि)? किसी भी एपीआई में कुछ फ़ंक्शन होगा जो निर्दिष्ट करता है कि एक नेटवर्क राउंड-ट्रिप में कितनी पंक्तियां (या कितना डेटा) लाने के लिए है। उदाहरण के लिए, एसक्यूएल * प्लस में, यह set arraysize N है। जेडीबीसी में, यह setFetchSize है। अन्य एपीआई में समान कार्य होंगे। यदि आप एक वैन पर हैं, तो आप आम तौर पर कम करना चाहते हैं कि प्रत्येक नेटवर्क राउंड ट्रिप के साथ प्राप्त पंक्तियों की संख्या में वृद्धि करके आपका आवेदन कितना चतुर है।

समान लाइनों के साथ, आपको शायद नेटवर्क पर कम डेटा ले जाने और सर्वर पर अधिक तर्क डालने से लाभ होगा। क्या आप वास्तव में उपयोगकर्ता को डेटा की 5800 पंक्तियों के साथ ग्रिड प्रदर्शित करते हैं? या आप उस डेटा को प्राप्त करते हैं और फिर एप्लिकेशन में कुछ प्रसंस्करण करते हैं (यानी डेटा ऑर्डर करें और पहली 100 पंक्तियां प्रदर्शित करें)? यदि आप डेटाबेस में उस प्रसंस्करण को धक्का दे सकते हैं और डेटाबेस पर प्रसारित होने वाले डेटा की मात्रा को कम कर सकते हैं, तो आप बहुत बेहतर हो जाएंगे।

ओरेकल में एसडीयू और टीडीयू के साथ-साथ SQL * नेट में कुछ अन्य नेटवर्किंग पैरामीटर को कॉन्फ़िगर करने के विकल्प हैं। मैं उन विकल्पों को देखना शुरू नहीं करूँगा, हालांकि, जब तक आप fetch आकार को अनुकूलित नहीं कर लेते हैं और सुनिश्चित करते हैं कि आप कम से कम डेटा को वापस खींच रहे हैं।

Answer 2

जैसा कि आप किसी वेब ऐप से निपट रहे हैं, कुछ वापस जल्दी प्राप्त करना महत्वपूर्ण है। FIRST_ROWS संकेत की जांच करें। यह आपकी स्थिति के लिए मूल्य का हो सकता है।

Answer 3

किसी तालिका से कुछ हजार पंक्तियों का चयन करना लगभग एक मिनट नहीं लेना चाहिए। मेरा अनुमान है कि आपके सिस्टम में कहीं और प्रदर्शन समस्या है। डीबी में अन्य गतिविधि हो सकती है, या सर्वर/नेटवर्क/स्टोरेज के साथ समस्याएं हो सकती हैं। क्या आपके डीबी में अन्य प्रश्नों के साथ प्रदर्शन समान रूप से धीमा है?

Answer 4

कृपया तालिका विखंडन की जांच करें। आम तौर पर टेबल फ्रैगमेंटियन अधिक I/O का कारण बनता है और क्वेरी धीमी हो जाती है। आप ऑरैकल सेगमेंट एडवाइजर का उपयोग करके इसे देख सकते हैं और इसे हल करने के लिए पहले ऑरैकल सिकंक टेबल कमांड का उपयोग करने के दो तरीके हैं: धीमा करना और टेबल लॉक करना, दूसरा ऑरैकल लेवल टेबल कमांड का उपयोग करके, यह बहुत तेज है अगर ऑरैक समानांतर विकल्प द्वारा उपयोग किया जाता है । चाल तालिका के बारे में एकमात्र बिंदु यह अप्रयुक्त सूचकांक होगा।