अपने अनुभव में, ओरेकल डेटाबेस आंकड़े कितनी बार चलाना चाहिए? डेवलपर्स की हमारी टीम ने हाल ही में पाया है कि आंकड़े हमारे उत्पादन बॉक्स को 2 1/2 महीने में नहीं चलाए गए थे। यह मेरे लिए एक लंबे समय की तरह लगता है, लेकिन मैं एक डीबीए नहीं हूँ।ओरेकल डेटाबेस आंकड़े कितनी बार चलाना चाहिए?
मेरे आखिरी काम पर हमने सप्ताह में एक बार आंकड़े चलाए। अगर मुझे सही याद है, तो हमने उन्हें गुरुवार की रात को निर्धारित किया था, और शुक्रवार को डीबीए अप्रत्याशित किसी भी चीज़ के लिए सबसे लंबे समय तक चलने वाले प्रश्नों की निगरानी करने के लिए बहुत सावधान थे। (शुक्रवार को चुना गया था क्योंकि यह अक्सर कोड रिलीज के बाद होता था, और काफी कम यातायात दिन होता था।) जब उन्हें एक बुरी सवाल दिखाई देती थी तो उन्हें एक बेहतर क्वेरी प्लान मिलेगा और उसे बचाया जाएगा ताकि यह अप्रत्याशित रूप से फिर से नहीं बदले । (ओरेकल के पास आपके लिए यह स्वचालित रूप से करने के लिए टूल हैं, आप इसे अनुकूलित करने के लिए क्वेरी बताते हैं और यह करता है।)
कई संगठन अप्रत्याशित रूप से खराब क्वेरी योजनाओं के डर से आंकड़े चलाने से बचते हैं। लेकिन इसका आमतौर पर मतलब है कि उनकी क्वेरी योजना समय के साथ बदतर और बदतर हो जाती है।और जब वे रन आंकड़े करते हैं तो उन्हें कई समस्याएं आती हैं। परिणामस्वरूप उन मुद्दों को ठीक करने के लिए परिणामस्वरूप आंकड़े चलने वाले आंकड़ों के खतरों के बारे में अपने डर की पुष्टि करते हैं। लेकिन अगर वे नियमित रूप से आंकड़े चलाते हैं, तो मॉनीटरिंग टूल्स का इस्तेमाल किया जाता है, और जब वे आएंगे तो निश्चित समस्याएं होती हैं, तो उनके पास कम सिरदर्द होता है, और वे उन्हें एक साथ सामना नहीं करेंगे।
जब भी डेटा "महत्वपूर्ण" बदलता है।
यदि कोई तालिका 1 पंक्ति से 200 पंक्तियों तक जाती है, तो यह एक महत्वपूर्ण परिवर्तन है। जब एक टेबल 100,000 पंक्तियों से 150,000 पंक्तियों तक जाती है, तो यह बहुत महत्वपूर्ण परिवर्तन नहीं होता है। जब एक तालिका 1000 पंक्तियों से होती है तो कॉलम एक्स में लगभग अद्वितीय मानों के साथ सामान्य रूप से पूछे जाने वाले कॉलम एक्स से 1000 पंक्तियों में समान मानों के साथ, यह एक महत्वपूर्ण परिवर्तन है।
आइटम की गणना और सापेक्ष आवृत्तियों के बारे में सांख्यिकी स्टोर जानकारी - चीजें जो इसे "अनुमान लगाएगी" कि कितनी पंक्तियां किसी दिए गए मानदंड से मेल खाती हैं। जब यह गलत लगता है, तो अनुकूलक बहुत उप-शीर्ष क्वेरी योजना चुन सकता है।
क्या ओरेकल संस्करण आप उपयोग कर रहे हैं? ओरेकल 10 यह पेज जो दर्शाता है की जाँच करें:
http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm
इसे कहते हैं:
दृष्टिकोण की सिफारिश की सभा आंकड़ों के ओरेकल स्वचालित रूप से आंकड़े एकत्र करता है अनुमति है। ओरेकल स्वचालित रूप से सभी डेटाबेस ऑब्जेक्ट्स पर आंकड़े एकत्र करता है और नियमित रूप से निर्धारित रखरखाव नौकरी में उन आंकड़ों को बनाए रखता है।
जब मैं एक बड़ी बहु उपयोगकर्ता योजना प्रणाली ओरेकल द्वारा समर्थित प्रबंध किया गया था, हमारे डीबीए एक साप्ताहिक काम है कि आंकड़े इकट्ठा किया था। साथ ही, जब हमने एक महत्वपूर्ण परिवर्तन किया जो आंकड़ों से प्रभावित हो सकता है या प्रभावित हो सकता है, तो हम काम को पकड़ने के लिए नौकरी को चक्र से बाहर करने के लिए मजबूर करेंगे।
जोखिम को संतुलित करना सुनिश्चित करें कि नए आंकड़े इस जोखिम के खिलाफ पूछताछ योजनाओं में अवांछित परिवर्तन करते हैं कि स्टेल आंकड़े खुद को क्वेरी योजनाओं को बदलने का कारण बन सकते हैं।
कल्पना कीजिए कि आपके पास एक तालिका ISSUE और कॉलम CREATE_DATE के साथ एक बग डेटाबेस है जहां कॉलम में मान एक-दूसरे से कम या कम हो जाते हैं। अब, मान लीजिए कि इस कॉलम पर एक हिस्टोग्राम है जो ओरेकल को बताता है कि इस कॉलम के मान 1 जनवरी, 2008 और 17 सितंबर, 2008 के बीच समान रूप से वितरित किए जाते हैं। इससे ऑप्टिमाइज़र के लिए संभवतः पंक्तियों की संख्या का आकलन करना संभव हो जाता है अगर आप पिछले हफ्ते बनाए गए सभी मुद्दों की तलाश में थे तो वापस लौटाएं (यानी 7 सितंबर - 13)। यदि आवेदन का उपयोग जारी है और आंकड़े कभी अपडेट नहीं होते हैं, हालांकि, यह हिस्टोग्राम कम और कम सटीक होगा। इसलिए ऑप्टिमाइज़र समय के साथ कम और कम सटीक होने के लिए "पिछले हफ्ते बनाए गए मुद्दों" के लिए पूछताछ की अपेक्षा करेगा और अंततः ओरेकल को क्वेरी योजना को नकारात्मक रूप से बदलने का कारण बन सकता है।
डेटा वेयरहाउस-प्रकार प्रणाली के मामले में आप कोई आंकड़े एकत्र करने पर विचार नहीं कर सकते हैं, और गतिशील नमूनाकरण पर निर्भर कर सकते हैं (ऑप्टिमाइज़र_डैनेमिक_समैलिंग को स्तर 2 या ऊपर तक सेट करना)।
ऑरैकल के 10 जी और उच्चतर संस्करण के साथ, "अच्छा" निष्पादन योजना निर्णय लेने के लिए अनुकूलक द्वारा टेबल और इंडेक्स पर अद्यतित आंकड़ों की आवश्यकता होती है। आप कितनी बार आंकड़े एकत्र करते हैं वह एक मुश्किल कॉल है। यह आपके आवेदन, स्कीमा, डेटा दर और व्यापार अभ्यास पर निर्भर करता है। कुछ तृतीय पक्ष ऐप्स जो ओरेकल के पुराने संस्करण के साथ पिछड़े संगत होने के लिए लिखे गए हैं, नए अनुकूलक के साथ अच्छा प्रदर्शन नहीं करते हैं। उन अनुप्रयोगों की आवश्यकता होती है कि तालिकाओं में कोई आंकड़े न हों ताकि डीबी बेस निष्पादन योजना पर वापस आ जाए। लेकिन औसत ऑरैकल पर सिफारिश की जाती है कि आंकड़े स्टेल आंकड़ों के साथ टेबल पर एकत्र किए जाएंगे। आप मॉनिटर होने के लिए टेबल सेट कर सकते हैं और अपने राज्य की जांच कर सकते हैं और उन्हें स्टेल करते समय विश्लेषण कर सकते हैं। अक्सर यह पर्याप्त है, कभी-कभी यह नहीं होता है। यह वास्तव में आपके डेटाबेस पर निर्भर करता है। मेरे डेटाबेस के लिए हमारे पास OLTP टेबल का एक सेट है जिसे प्रदर्शन को बनाए रखने के लिए रात के आंकड़े संग्रह की आवश्यकता होती है। अन्य टेबल सप्ताह में एक बार विश्लेषण कर रहे हैं। हमारे बड़े dw डेटाबेस पर, हम आवश्यकतानुसार विश्लेषण करते हैं क्योंकि समग्र डीबी लोड और प्रदर्शन को प्रभावित किए बिना नियमित विश्लेषण के लिए टेबल बहुत बड़े होते हैं। तो सही जवाब यह है कि यह एप्लिकेशन, डेटा परिवर्तन और व्यावसायिक आवश्यकताओं पर निर्भर करता है।
के बाद से Oracle 11g आँकड़े डिफ़ॉल्ट रूप से स्वचालित रूप से इकट्ठे हुए हैं।
दो समयबद्धक खिड़कियों Oracle डाटाबेस की स्थापना पर पूर्वनिर्धारित रहे हैं:
जब आँकड़े अंतिम बार इकट्ठे हुए थे?
SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.
स्वचालित आंकड़े एकत्रित करने की स्थिति?
SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';
विंडोज समूह?
SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;
विंडो अनुसूची?
SELECT window_name, start_time, duration FROM dba_autotask_schedule;
मैन्युअल इस स्कीमा में डाटाबेस सांख्यिकी इकट्ठा:
EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.
मैन्युअल सभी स्कीमा में डाटाबेस सांख्यिकी इकट्ठा!
-- Probably need to CONNECT/AS SYSDBA
EXEC dbms_stats.gather_database_stats;
आम तौर पर यह इस तरह के एक थोक डालने या बड़ा डेटा परिवर्तन डेटाबेस पर बार-बार हो के रूप में जब तक आप उस के लिए एक मजबूत औचित्य है, आंकड़े पूरे डेटाबेस पर तो अक्सर इकट्ठा करने के लिए अनुशंसित नहीं है। इस आवृत्ति में डेटाबेस पर एकत्रित आंकड़े मई में निष्पादन योजना को एक नई खराब निष्पादन योजनाओं में बदल सकते हैं, इस बात से आपको नई खराब योजनाओं से प्रभावित हर प्रश्न को ट्यून करने की कोशिश करने में अधिक समय लग सकता है, यही कारण है कि आपको इसका प्रभाव परीक्षण करना चाहिए एक परीक्षण डेटाबेस पर नए आंकड़े इकट्ठा करना, या यदि आपके पास समय या उस व्यक्ति की शक्ति नहीं है, तो कम से कम आपको नए आंकड़ों को इकट्ठा करने से पहले मूल सांख्यिकी को बैकबैक करके रखना चाहिए, इसलिए यदि आप इकट्ठा होते हैं एक नए आंकड़े और फिर प्रश्नों की अपेक्षा के अनुसार प्रदर्शन नहीं किया गया था, आप आसानी से मूल आंकड़े वापस बहाल कर सकते हैं।
एक बहुत उपयोगी स्क्रिप्ट आपको मूल आंकड़ों का बैकअप लेने और नए लोगों को इकट्ठा करने में मदद कर सकती है और आपको एसक्यूएल कमांड प्रदान कर सकती है जिसका उपयोग आप मूल आंकड़ों को वापस बहाल करने के लिए कर सकते हैं यदि नए आंकड़े इकट्ठा करने के बाद चीज की अपेक्षा नहीं की जाती है। आप इस लिंक में स्क्रिप्ट पा सकते हैं: http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html