ऐसा हो सकता है कि एसक्यूएल सर्वर में एक अन्य योजना या ऐसा कुछ करने के लिए डेटा की थोड़ी सी मात्रा एक निश्चित सीमा तक पहुंचती है। यह संभावना नहीं है। लेकिन यह तथ्य कि आपका डिस्क ड्यूटी के तहत भारी लगता है, मुझे दूसरे निष्कर्ष पर ले जाता है।
आपके धीमा होने के 2 संभावित आधार कारण हैं।
- आपने अपने सिस्टम को अपग्रेड किया और इसे रिबूट किया
- आप इसमें डेटा का एक गुच्छा लोड करते हैं
आइए एक नजर डालते हैं भाग संख्या 1 पर
यह हो सकता है कि आपका SQL सर्वर कॉन्फ़िगरेशन टूट जाए। यह आपके सर्वर की गति और डिस्क उपयोग के बारे में गंभीर समस्याएं पैदा कर सकता है।
कृपया पहले उदाहरण में अपनी मूल सर्वर सेटिंग्स की जाँच करें। उन मूलभूत सेटिंग कर रहे हैं max server memory, affinity I/O mask, affinity maskऔर max degree of parallelism। आपको उन्नत विकल्पों का उपयोग करके सक्षम करने की आवश्यकता हो सकती है show advanced options।
यहाँ एक पूरी स्क्रिप्ट है:
-- enable advanced options
EXEC sp_configure 'show advanced options',1
-- apply configuration
RECONFIGURE
-- how much memory can the sql server allocate?
EXEC sp_configure 'max server memory'
-- which cpu is used to run I/O operations
EXEC sp_configure 'affinity I/O mask'
-- which cpus can run processes?
EXEC sp_configure 'affinity mask'
-- how many threads can work on one query part?
EXEC sp_configure 'max degree of parallelism'
अपने संस्थापन चरणों में अपने प्रलेखित मूल्यों के साथ परिणाम की तुलना करें। क्या वे अब भी वही हैं?
इसके कई कारण हो सकते हैं कि आपका सर्वर इतना अजीब व्यवहार क्यों करता है। मैं आम तौर पर शर्त लगाऊंगा, कि तुम्हारा max server memoryगलत है। यह आपके SQL सर्वर को स्थायी रूप से डेटा पृष्ठों को स्वैप करने का कारण होगा। वह अपनी स्मृति में सब कुछ नहीं पकड़ सकता। इसका मतलब है कि उसे डिस्क से पृष्ठों को पढ़ना होगा, इसे अपडेट करना होगा, इसे तुरंत वापस लिखना होगा। यदि कोई अन्य अपडेट साथ आता है और अपडेट के लिए उसी पृष्ठ का उपयोग करता है, तो इसे मेमोरी से नहीं पढ़ा जा सकता है। इसके बजाय सर्वर को डिस्क से इसे फिर से पढ़ने की जरूरत है। बस अदला-बदली ...
एक अन्य समस्या डिस्क या प्रक्रियाओं पर एक उच्च संबंध के लिए हो सकती है। यदि आपने SQL सर्वर के लिए एक समर्पित डिस्क के साथ एक साझा सर्वर (SQL Server + अन्य सेवाएँ) का उपयोग किया है (जो एक दुर्लभ मामला हो सकता है, लेकिन यह हो सकता है), तो यह आपकी समस्या हो सकती है। आपका सर्वर आमतौर पर प्रक्रियाओं के लिए 3 cpus और I / O के लिए उदाहरण के लिए उपयोग करता है। अन्य 12 cpus अन्य सेवाओं के लिए उपयोग किया जाता है। इस मामले में आपका आत्मीयता का मुखौटा गलत है और उदाहरण के लिए एक स्वचालित कॉन्फ़िगरेशन का उपयोग करता है। इसका अर्थ है कि आपका सर्वर सभी 16 कोर का उपयोग प्रक्रियाओं के लिए करता है और I / O गतिशील रूप से करता है। यदि आपके पास बहुत बड़ी प्रक्रियाएं चल रही हैं, तो वे डिस्क पर एक बड़ा भार डाल सकते हैं, जिसे वह संभाल नहीं सकता है। लेकिन वास्तव में, मुझे विश्वास नहीं है कि यह आपका मामला है। यह तेज़ होगा (भले ही बस थोड़ा सा) अगर यह लागू होगा, लेकिन आपका मामला धीमा है।
एक और समस्या समानता का एक उच्च स्तर हो सकता है। जिसका अर्थ है कि आपके पास क्वेरी के एक भाग पर बहुत सारे थ्रेड्स इडलिंग हैं। यह भी एक बड़ी धीमी गति का कारण बन सकता है अगर समानता अपेक्षा के अनुरूप काम न करे। लेकिन यह आपके कुल I / O का वर्णन नहीं करेगा।
अब चलो भाग संख्या 2 पर भी एक नजर डालते हैं
आप अपने सिस्टम में पंक्तियों का एक गुच्छा लोड करते हैं। यहां तक कि अगर यह एक नियमित काम है, तो यह एक सीमा बढ़ा सकता है जिसमें आपकी क्वेरी योजना आगे बढ़ती है। यह भी मामला हो सकता है कि SQL सर्वर के साथ संयोजन में आपका सम्मिलित यह व्यवहार उत्पन्न करता है।
आपने उल्लेख किया है कि आपने पहले ही अपने सूचकांकों को किसी अन्य डिस्क पर स्थानांतरित करने का प्रयास किया है, जो मदद करने के लिए लगता है। यह सिर्फ इस तथ्य से हो सकता है कि आप दो अलग-अलग डिस्क पर लोड को विभाजित करते हैं।
यह हो सकता है कि आपके सूचक खंडित किए गए थे, कि आपकी योजनाएं खंडित थीं या आपके आंकड़े केवल पुराने हैं।
1.
आपको पिछले अपडेट के आंकड़ों की जांच करने देता है। आप प्रत्येक एकल आंकड़े के लिए इंटरफ़ेस पर मैन्युअल रूप से ऐसा कर सकते हैं। जो एक पीड़ा होगी। या आप इस कोड को आज़मा सकते हैं:
SELECT name AS indexname,
STATS_DATE(OBJECT_ID, index_id) AS StatsUpdated
FROM sys.indexes
यह आपको प्रत्येक सूचकांक (और ढेर) और उनके पीछे के आंकड़ों की पूरी जानकारी देगा। यहां तक कि अगर आप sp_updatestatsइसे चलाते हैं तो इसका मतलब यह नहीं है कि आँकड़े अपडेट किए गए थे। जब कोई अपडेट काफी मुश्किल होता है, तब भी जब आप चलाते हैं sp_updatestatsया auto update statisticsसक्षम होते हैं, तो भी आँकड़े समय पर अपडेट नहीं होंगे। जब अद्यतन की आवश्यकता / उत्पन्न होती है, तो यहां कुछ किनारे बिंदु हैं:
- एक खाली तालिका में एक या अधिक पंक्तियाँ मिलती हैं
- 500 से अधिक पंक्तियों वाली तालिका 20% + 500 अतिरिक्त पंक्तियों को अपडेट करती है और बाद में एक प्रविष्टि होती है
- जब 500 पंक्तियों को 500 से कम पंक्तियों वाली तालिका में बदला गया
इसका मतलब है, यदि आप अपडेट चलाते हैं तो भी आपके आँकड़े पुराने हो सकते हैं।
आप उपरोक्त क्वेरी पर एक नज़र डाल सकते हैं। यदि आपको कुछ तालिकाओं में बहुत पुराने आँकड़े मिलते हैं, तो आप इस तालिका के लिए एक मैनुअल स्टेटिस्टिक अपडेट चलाना चाहते हैं:
UPDATE STATISTICS dbo.YourBadTable WITH FULLSCAN
उसके बाद, आप अपने सर्वर को सभी पुरानी योजनाओं को फेंकने के लिए गधे में एक किक दे सकते हैं।
DBCC FREEPROCCACHE
यदि आप सभी कैश साफ़ करना चाहते हैं, तो आप इसके बजाय इसे चलाना चाहते हैं:
DBCC FREESYSTEMCACHE ('ALL')
यह सभी कैश को साफ करेगा, न कि केवल योजना कैश को। मैं सामान्य तौर पर चेतावनी दूंगा कि इसे प्रोडक्शन सर्वर के प्रोडक्शन फेज में इस्तेमाल करें। लेकिन जैसा कि आपका सर्वर वर्तमान में काम नहीं करता है, आप उन्हें बहुत अधिक नुकसान नहीं पहुंचा सकते। यह शायद 1-2 मिनट के लिए कुछ सेकंड के लिए धीमा हो सकता है क्योंकि उसे सभी कैश को फिर से बनाने की आवश्यकता है, लेकिन उसके बाद उसे सही योजनाओं के साथ चलना चाहिए।
एक और कारण पूरी तरह से खंडित सूचकांक हो सकता है। इस कथन का उपयोग करके इसे पूरे सर्वर पर देखा जा सकता है:
SELECT *
FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL, NULL, NULL)
यदि विखंडन बहुत अधिक है, तो आपको पुनर्गठन (विखंडन <20%) या पूरी तरह से पुनर्निर्माण (> 20%) की आवश्यकता हो सकती है। इससे आपकी डिस्क पर अधिक दबाव पड़ सकता है और परेशानी हो सकती है। दूसरी ओर, यदि सूचकांक खराब हैं, तो संभवत: यह नुकसान पहुंचाने से अधिक अंत में मदद करेगा।
उन दो कारणों के अलावा, अभी भी एक तीसरी समस्या हो सकती है
हो सकता है कि आपका सर्वर शायद कॉन्फ़िगर किया गया हो, आपने इस समय कोई कोड नहीं बदला है, बस कुछ पंक्तियों को जोड़ा है। सभी आंकड़े अपडेट किए जाते हैं और सभी कैश का पुनर्निर्माण किया जाता है। आपके सभी सूचकांकों को उस तरीके से पुनर्गठित किया जाता है, जिसकी आपको आवश्यकता है, लेकिन फिर भी - कुछ भी काम नहीं करता है। यह सिर्फ यह हो सकता है कि आप अपनी प्रक्रियाओं में उपलब्ध स्मृति की सीमा तक पहुंच गए। शायद आपको और चाहिए। आप बस जांच कर सकते हैं कि क्या कोई प्रक्रिया है जो आपके पास अधिक मेमोरी प्राप्त करने की कोशिश करती है।
आप इस आदेश का उपयोग करके इसे देख सकते हैं:
SELECT * FROM sys.dm_exec_query_memory_grants
यह आपको सभी सत्रों की एक सूची प्रदान करेगा जो मेमोरी का उपभोग करते हैं। कुछ क्वेरी हो सकती है जो अभी भी मेमोरी पाने के लिए इंतजार कर रही है। उन प्रश्नों को आसानी से फ़िल्टर किया जा सकता है। सभी सत्र जहां granted_memory_kb IS NULL। ये ऐसे सत्र हैं जो मेमोरी का अनुरोध करते हैं लेकिन यह नहीं मिलता है। एक और चीज एक दी गई स्मृति हो सकती है जो कम हो सकती है। आप स्तंभ की तुलना कर सकते requested_memory_kbके साथ granted_memory_kb। अनुरोधित दिखाता है कि स्मृति को प्रक्रिया को चलाने के लिए कितनी मेमोरी की आवश्यकता होती है जबकि प्रक्रिया के लिए सक्षम होने वाली मेमोरी को दिखाता है। यदि किसी प्रक्रिया को चलाने के लिए 2GB की आवश्यकता है, लेकिन केवल 2MB मिलती है ... तो आप इसे स्वयं प्राप्त कर सकते हैं। ;-)
एक और तरीका है RESSOURCE_SEMAPHORE:
SELECT * FROM sys.dm_exec_query_resource_semaphore
आप waiter_countऔर पर एक नज़र डाल सकते हैं grantee_count। यदि वेटर 0 से ऊपर है, तो आपके पास आपकी मेमोरी पर दबाव पड़ता है, जिससे स्वैपिंग हो सकती है और आपके द्वारा परफ्यूम में देखे गए दबाव का कारण हो सकता है।