जैसे-जैसे 2014 की हवा चल रही है, मैं इस साल की शुरुआत में वापस लिखे गए एक के आधार पर सक्रिय SQL सर्वर स्वास्थ्य जांच पर पोस्ट की एक श्रृंखला को बंद कर रहा हूं - प्रदर्शन मुद्दे:पहला मुठभेड़। उस पोस्ट में, मैंने चर्चा की थी कि किसी अपरिचित वातावरण में प्रदर्शन समस्या का निवारण करते समय मैं सबसे पहले क्या देखता हूं। पोस्ट की इस श्रृंखला में, मैं इस बारे में बात करना चाहता हूं कि जब मैं अपने दीर्घकालिक ग्राहकों के साथ चेक-इन करता हूं तो मैं क्या देखता हूं। हम एक दूरस्थ डीबीए सेवा प्रदान करते हैं, और हमारे नियमित कार्यों में से एक उनके पर्यावरण का मासिक "मिनी" स्वास्थ्य लेखा परीक्षा है। हमारे पास निगरानी है और, आमतौर पर, मैं परियोजनाओं पर काम कर रहा हूं, इसलिए मैं नियमित रूप से पर्यावरण में हूं। लेकिन यह सुनिश्चित करने के लिए एक अतिरिक्त कदम के रूप में कि हम कुछ भी नहीं खो रहे हैं, महीने में एक बार हम उसी डेटा से गुजरते हैं जो हम अपने मानक स्वास्थ्य लेखा परीक्षा में एकत्र करते हैं और कुछ भी सामान्य से बाहर की तलाश करते हैं। यह बहुत सी बातें हो सकती हैं, है ना? हां! तो, चलिए स्पेस से शुरू करते हैं।
वाह, अंतरिक्ष? हाँ, अंतरिक्ष। चिंता न करें, मैं अन्य विषयों पर पहुंचूंगा।
क्या जांचना है
मैं अंतरिक्ष से क्यों शुरू करूंगा? क्योंकि यह कुछ ऐसा है जिसे मैं अक्सर उपेक्षित देखता हूं, और यदि आप अपनी डेटाबेस फ़ाइलों के लिए डिस्क स्थान से बाहर हो जाते हैं, तो आप अपने डेटाबेस में जो कर सकते हैं उसमें आप बेहद सीमित हो जाते हैं। डेटा जोड़ने की आवश्यकता है लेकिन डिस्क भर जाने के कारण फ़ाइल नहीं बढ़ा सकते हैं? क्षमा करें, अब उपयोगकर्ता डेटा नहीं जोड़ सकते। किसी कारण से लॉग बैकअप नहीं लेना, तो लेन-देन लॉग ड्राइव को भर देता है? क्षमा करें, अब आप किसी भी डेटा को संशोधित नहीं कर सकते। अंतरिक्ष महत्वपूर्ण है। हमारे पास ऐसे कार्य हैं जो डिस्क और फाइलों में खाली स्थान की निगरानी करते हैं, लेकिन मैं अभी भी प्रत्येक ऑडिट के लिए निम्नलिखित को सत्यापित करता हूं, और पिछले महीने के मूल्यों की तुलना करता हूं:
- प्रत्येक लॉग फ़ाइल का आकार
- प्रत्येक डेटा फ़ाइल का आकार
- हर डेटा फ़ाइल में खाली जगह
- डेटाबेस फ़ाइलों के साथ प्रत्येक ड्राइव पर खाली स्थान
- बैकअप फ़ाइलों के साथ प्रत्येक ड्राइव पर खाली स्थान
लॉग फ़ाइल ग्रोथ
मुझे डिस्क स्थान से संबंधित अधिकांश समस्याएँ लॉग फ़ाइल वृद्धि के कारण दिखाई देती हैं। वृद्धि आमतौर पर दो कारणों में से एक के लिए होती है:
- डेटाबेस पूरी तरह से ठीक हो गया है और लेन-देन लॉग बैकअप किसी कारण से नहीं लिया जा रहा है
- कोई व्यक्ति एकल, बहुत बड़ा लेन-देन चलाता है जो सभी मौजूदा लॉग स्थान का उपभोग करता है, जिससे फ़ाइल बढ़ने के लिए बाध्य होती है
मैंने इंडेक्स रखरखाव के हिस्से के रूप में लॉग फ़ाइल को भी बढ़ते देखा है। पुनर्निर्माण के लिए, प्रत्येक आवंटन लॉग किया जाता है और बड़ी अनुक्रमणिका के लिए, जो महत्वपूर्ण मात्रा में लॉग उत्पन्न कर सकता है। यहां तक कि नियमित लेन-देन लॉग बैकअप के साथ, लॉग अभी भी बैकअप की तुलना में तेजी से बढ़ सकता है। लॉग को प्रबंधित करने के लिए आपको बैकअप आवृत्ति को समायोजित करने, या अपनी अनुक्रमणिका रखरखाव पद्धति को संशोधित करने की आवश्यकता है।
आपको यह निर्धारित करने की आवश्यकता है कि लॉग फ़ाइल क्यों बढ़ी, जो तब तक मुश्किल हो सकती है जब तक कि आप इसे ट्रैक नहीं कर रहे हों। मेरे पास एक काम है जो हर घंटे स्नैपशॉट लॉग फ़ाइल आकार और उपयोग के लिए चलता है:
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; मैं इस जानकारी का उपयोग यह निर्धारित करने के लिए करता हूं कि लॉग फ़ाइल कब बढ़ने लगी, और मैं यह देखने के लिए लॉग और नौकरी के इतिहास को देखना शुरू कर देता हूं कि मुझे कौन सी अतिरिक्त जानकारी मिल सकती है। लॉग का विकास स्थिर होना चाहिए - लॉग को उचित आकार और बैकअप के माध्यम से प्रबंधित किया जाना चाहिए (यदि पूर्ण पुनर्प्राप्ति में चल रहा है), और यदि फ़ाइल को बड़ा करने की आवश्यकता है, तो मुझे यह समझने की आवश्यकता है कि क्यों, और तदनुसार इसे फिर से आकार दें।
यदि आप इस समस्या से निपट रहे हैं, और आप पहले से ही फ़ाइल वृद्धि की घटनाओं को लगातार ट्रैक नहीं कर रहे हैं, तो आप अभी भी यह पता लगाने में सक्षम हो सकते हैं कि क्या हुआ। ऑटो-ग्रोथ इवेंट्स को SQL सर्वर द्वारा कैप्चर किया जाता है; SQL संतरी के आरोन बर्ट्रेंड ने 2007 में इस बारे में ब्लॉग किया था, जहाँ वह दिखाता है कि कैसे पता लगाया जाए कि ये घटनाएँ कब हुईं (जब तक कि वे अभी भी डिफ़ॉल्ट ट्रेस में मौजूद होने के लिए पर्याप्त थीं)।
डेटा फ़ाइलों में आकार और खाली जगह
आपने शायद पहले ही सुना होगा कि आपकी डेटा फाइलें पूर्व-आकार की होनी चाहिए ताकि उन्हें अपने आप बढ़ने की जरूरत न पड़े। यदि आप इस मार्गदर्शन का पालन करते हैं, तो संभवतः आपने उस घटना का अनुभव नहीं किया है जहां डेटा फ़ाइल अप्रत्याशित रूप से बढ़ती है। लेकिन अगर आप अपनी डेटा फ़ाइलों का प्रबंधन नहीं कर रहे हैं, तो संभवतः आपके पास नियमित रूप से विकास हो रहा है - चाहे आप इसे महसूस करें या नहीं (विशेषकर 10% और 1 एमबी की डिफ़ॉल्ट वृद्धि सेटिंग्स के साथ)।
डेटा फ़ाइलों को पूर्व-आकार देने के लिए एक तरकीब है - आप किसी डेटाबेस को बहुत बड़ा आकार नहीं देना चाहते हैं, क्योंकि याद रखें, यदि आप किसी देव या क्यूए वातावरण को पुनर्स्थापित करना चाहते हैं, तो फ़ाइलें समान आकार की होती हैं, भले ही वे ' डेटा से भरा नहीं है। लेकिन आप अभी भी विकास को मैन्युअल रूप से प्रबंधित करना चाहते हैं। मुझे लगता है कि डीबीए के पास नए डेटाबेस के साथ सबसे कठिन समय है। व्यापार उपयोगकर्ताओं को विकास दर के बारे में कोई जानकारी नहीं है और कितना डेटा जोड़ा जा रहा है, और वह डेटाबेस आपके वातावरण में एक ढीली तोप है। आपको इन फ़ाइलों पर तब तक ध्यान देने की ज़रूरत है जब तक कि आपके पास आकार और अपेक्षित वृद्धि पर नियंत्रण न हो। मैं एक क्वेरी का उपयोग करता हूं जो आकार और खाली स्थान के बारे में जानकारी देता है:
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; हर महीने, मैं डेटा फ़ाइलों के आकार और उपयोग की गई जगह की जांच करता हूं, फिर तय करता हूं कि आकार को बढ़ाने की जरूरत है या नहीं। मैं विकास की घटनाओं के लिए डिफ़ॉल्ट ट्रेस की भी निगरानी करता हूं, क्योंकि यह मुझे बताता है कि विकास कब होता है। नए डेटाबेस के अपवाद के साथ, मैं हमेशा स्वचालित फ़ाइल वृद्धि से आगे रह सकता हूं और इसे मैन्युअल रूप से संभाल सकता हूं। ठीक है, लगभग हमेशा। पिछले साल छुट्टियों से ठीक पहले, मुझे एक ग्राहक के आईटी विभाग द्वारा ड्राइव पर कम खाली स्थान के बारे में सूचित किया गया था (अगले भाग के लिए उस विचार को पकड़ें)। अब, अधिसूचना 20% से कम मुफ्त की सीमा पर आधारित है। यह ड्राइव 1TB से अधिक की थी, इसलिए जब मैंने ड्राइव की जाँच की तो लगभग 150GB मुफ़्त था। यह कोई आपात स्थिति नहीं थी, फिर भी, मुझे यह समझने की ज़रूरत थी कि स्थान कहाँ गया था।
एक डेटाबेस के लिए डेटाबेस फ़ाइलों की जाँच में, मैं देख सकता था कि वे भरे हुए थे - और पिछले महीने प्रत्येक फ़ाइल में 50GB से अधिक मुफ़्त थी। मैंने तब टेबल के आकार में खोदा, और पाया कि एक टेबल में, पिछले 16 दिनों में 270 मिलियन से अधिक पंक्तियों को जोड़ा गया था - कुल 100GB से अधिक डेटा। पता चला कि एक कोड संशोधन किया गया था और नया कोड अपेक्षा से अधिक जानकारी लॉग कर रहा था। हम पंक्तियों को शुद्ध करने और फ़ाइलों में खाली स्थान को पुनर्प्राप्त करने के लिए जल्दी से एक नौकरी स्थापित करते हैं (और उन्होंने कोड तय किया)। हालाँकि, मैं डिस्क स्थान को पुनर्प्राप्त नहीं कर सका - मुझे फ़ाइलों को सिकोड़ना होगा, और यह एक विकल्प नहीं था। फिर मुझे यह निर्धारित करना था कि डिस्क पर कितनी जगह बची है और यह तय करना है कि यह एक ऐसी राशि है जिसके साथ मैं सहज था या नहीं। मेरा आराम स्तर यह जानने पर निर्भर है कि प्रति माह कितना डेटा जोड़ा जा रहा है - सामान्य विकास दर। और मैं केवल इतना जानता हूं कि कितना डेटा जोड़ा जा रहा है क्योंकि मैं फ़ाइल उपयोग की निगरानी करता हूं और अनुमान लगा सकता हूं कि इस महीने, इस वर्ष और अगले दो वर्षों के लिए कितनी जगह की आवश्यकता होगी।
डिस्क स्पेस
मैंने पहले उल्लेख किया था कि हमारे पास डिस्क पर खाली स्थान की निगरानी करने के लिए कार्य हैं। यह प्रतिशत पर आधारित है, निश्चित राशि पर नहीं। मेरे अंगूठे का सामान्य नियम 10% से कम डिस्क के खाली होने पर सूचनाएं भेजने का रहा है, लेकिन कुछ ड्राइव के लिए, आपको इसे उच्चतर सेट करने की आवश्यकता हो सकती है। उदाहरण के लिए, 1 टीबी ड्राइव के साथ, मुझे सूचित किया जाता है जब 100GB से कम मुफ्त होता है। 100GB ड्राइव के साथ, 10GB से कम मुफ्त होने पर मुझे सूचित किया जाता है। 20GB ड्राइव के साथ ... ठीक है, आप देखते हैं कि मैं इसके साथ कहाँ जा रहा हूँ। समस्या होने से पहले उस सीमा को आपको सचेत करने की आवश्यकता है। यदि मेरे पास लॉग फ़ाइल को होस्ट करने वाली ड्राइव पर केवल 10GB मुफ़्त है, तो मेरे पास प्रतिक्रिया करने के लिए पर्याप्त समय नहीं हो सकता है, इससे पहले कि यह उपयोगकर्ताओं के लिए एक समस्या के रूप में दिखाई दे - इस पर निर्भर करता है कि मैं कितनी बार खाली आकार की जगह की जाँच कर रहा हूँ और क्या समस्या है है।
मुक्त स्थान की जांच के लिए xp_fixeddrives का उपयोग करना बहुत आसान है, लेकिन मैं इसकी अनुशंसा नहीं करूंगा क्योंकि यह अनिर्दिष्ट है और सामान्य रूप से विस्तारित संग्रहीत प्रक्रियाओं का उपयोग बहिष्कृत कर दिया गया है। यह प्रत्येक ड्राइव के कुल आकार की रिपोर्ट भी नहीं करता है, और आपके डेटाबेस द्वारा उपयोग किए जा रहे सभी ड्राइव प्रकारों पर रिपोर्ट नहीं कर सकता है। जब तक आप SQL Server 2008R2 SP1 या उच्चतर चला रहे हैं, तब तक आप अधिक सुविधाजनक sys.dm_os_volume_stats का उपयोग अपनी आवश्यक जानकारी प्राप्त करने के लिए कर सकते हैं, कम से कम उन ड्राइव के बारे में जहां डेटाबेस फ़ाइलें मौजूद हैं:
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
मैं अक्सर tempdb को होस्ट करने वाले वॉल्यूम पर ड्राइव स्पेस के साथ एक समस्या देखता हूं। मैंने उस समय की गिनती खो दी है जब मेरे पास अस्पष्टीकृत tempdb वृद्धि वाले ग्राहक थे। कभी-कभी यह केवल कुछ जीबी होता है; हाल ही में यह 200GB था। Tempdb एक मुश्किल जानवर है - इसे आकार देते समय पालन करने के लिए कोई सूत्र नहीं है, और अक्सर इसे थोड़ी खाली जगह वाली ड्राइव पर रखा जाता है जो धोखेबाज़ डेवलपर या डीबीए के कारण होने वाली पागल घटना को संभाल नहीं सकता है। Tempdb डेटा फ़ाइलों को आकार देने के लिए आपको एक "सामान्य" व्यवसाय चक्र के लिए अपना कार्यभार चलाने की आवश्यकता होती है ताकि यह निर्धारित किया जा सके कि यह tempdb का कितना उपयोग करता है, और फिर उसके अनुसार इसे आकार दें।
मैंने हाल ही में एक ड्राइव पर जगह से बाहर निकलने से बचने के तरीके के लिए एक सुझाव सुना है:बिना डेटा वाला डेटाबेस बनाएं, और फाइलों को आकार दें ताकि वे कितनी भी जगह का उपभोग करें जिसे आप "अलग रखना" चाहते हैं। फिर, यदि आप किसी समस्या में भाग लेते हैं, तो बस डेटाबेस और वायोला छोड़ दें, आपके पास फिर से खाली स्थान है। व्यक्तिगत रूप से, मुझे लगता है कि यह सभी प्रकार के अन्य मुद्दों को पैदा करता है और इसकी अनुशंसा नहीं करेगा। लेकिन अगर आपके पास स्टोरेज एडमिनिस्ट्रेटर हैं जो ड्राइव पर सैकड़ों अप्रयुक्त जीबी देखना पसंद नहीं करते हैं, तो यह ड्राइव को "लुक" पूर्ण बनाने का एक तरीका होगा। यह मुझे कुछ याद दिलाता है कि मैंने अपने एक अच्छे दोस्त को यह कहते सुना है:"अगर मैं तुम्हारे साथ काम नहीं कर सकता, तो मैं तुम्हारे आसपास काम करूंगा।"
बैकअप
DBA के प्राथमिक कार्यों में से एक डेटा की सुरक्षा करना है। बैकअप इसकी सुरक्षा के लिए उपयोग की जाने वाली एक विधि है, और जैसे, उन बैकअप को रखने वाली ड्राइव DBA के जीवन का एक अभिन्न अंग हैं। यदि आवश्यक हो तो तुरंत पुनर्स्थापित करने के लिए, संभवतः आप एक या अधिक बैकअप ऑनलाइन रख रहे हैं। आपकी SLA और DR रन बुक यह निर्धारित करने में मदद करती है कि आप कितने बैकअप ऑनलाइन रखते हैं, और आपको यह सुनिश्चित करना चाहिए कि आपके पास वह स्थान उपलब्ध है। मैं वकालत करता हूं कि आप पुराने बैकअप को तब तक न हटाएं जब तक कि वर्तमान बैकअप सफलतापूर्वक पूरा न हो जाए। पुराने बैकअप को हटाने, फिर वर्तमान बैकअप को चलाने के जाल में पड़ना बहुत आसान है। लेकिन अगर वर्तमान बैकअप विफल हो जाए तो क्या होगा? और, यदि आप संपीड़न का उपयोग कर रहे हैं तो क्या होगा? एक सेकंड रुकिए... कंप्रेस्ड बैकअप छोटे हैं, है ना? वे छोटे हैं, अंत में। लेकिन क्या आप जानते हैं कि .bak फ़ाइल का आकार आमतौर पर अंतिम आकार से बड़ा होता है? आप इस व्यवहार को बदलने के लिए ट्रेस फ्लैग 3042 का उपयोग कर सकते हैं, लेकिन आपको यह सोचना चाहिए कि बैकअप के साथ, आपको काफी जगह चाहिए। यदि आपका बैकअप 100GB है, और आप 3 दिनों का मूल्य ऑनलाइन रख रहे हैं, तो आपको 3 दिनों के बैकअप के लिए 300GB की आवश्यकता है, और फिर संभवत:अगले बैकअप के लिए एक स्वस्थ राशि (2X वर्तमान डेटाबेस आकार) निःशुल्क है। हां, इसका मतलब है कि किसी भी समय आपके पास इस ड्राइव पर 100GB से अधिक मुफ्त होगा। ठीक है। डिलीट जॉब के सफल होने और बैकअप जॉब के विफल होने से बेहतर है, और पता करें कि तीन दिन बाद आपके पास कोई बैकअप नहीं है (मेरे पिछले जॉब में ग्राहक के साथ ऐसा हुआ था)।
अधिकांश डेटाबेस समय के साथ बड़े होते जाते हैं, जिसका अर्थ है कि बैकअप भी बड़े होते जाते हैं। बैकअप फ़ाइलों के आकार की नियमित रूप से जाँच करना और आवश्यकतानुसार अतिरिक्त स्थान आवंटित करना न भूलें - एक डेटाबेस के लिए "200GB मुफ़्त" नीति जो कि 350GB तक बढ़ गई है, बहुत मददगार नहीं होगी। यदि स्थान की आवश्यकताएं बदलती हैं, तो किसी भी संबद्ध अलर्ट को भी बदलना सुनिश्चित करें।
प्रदर्शन सलाहकार का उपयोग करना
इस पोस्ट में कई प्रश्न शामिल हैं जिनका उपयोग आप अंतरिक्ष की निगरानी के लिए कर सकते हैं, यदि आपको अपनी प्रक्रिया को रोल करने की आवश्यकता है। लेकिन अगर आपके वातावरण में SQL संतरी प्रदर्शन सलाहकार है, तो कस्टम शर्तों के साथ यह बहुत आसान हो जाता है। डिफ़ॉल्ट रूप से कई स्टॉक शर्तें शामिल हैं, लेकिन आप अपनी खुद की भी बना सकते हैं।
SQL संतरी क्लाइंट के भीतर, नेविगेटर खोलें, साझा समूह (वैश्विक) पर राइट-क्लिक करें, और कस्टम स्थिति जोड़ें → SQL संतरी चुनें। शर्त के लिए एक नाम और विवरण प्रदान करें, फिर एक संख्यात्मक तुलना जोड़ें, और प्रकार को रिपोजिटरी क्वेरी में बदलें। क्वेरी दर्ज करें:
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
इसके बराबर बदलें इससे कम है, और 10 का स्पष्ट मान सेट करें। अंत में, डिफ़ॉल्ट मूल्यांकन आवृत्ति को हर 10 सेकंड से कम बार-बार बदलें। दिन में एक बार या हर 12 घंटे में एक बार शायद एक अच्छा मूल्य है - आपको दिन में एक से अधिक बार खाली स्थान की जांच करने की आवश्यकता नहीं है, लेकिन आप इसे जितनी बार चाहें जांच सकते हैं। नीचे दिया गया स्क्रीन शॉट अंतिम कॉन्फ़िगरेशन दिखाता है:
एक बार जब आप शर्त के लिए सहेजें पर क्लिक करते हैं, तो आपसे पूछा जाएगा कि क्या आप कस्टम स्थिति के लिए कार्रवाई असाइन करना चाहते हैं। अलर्टिंग चैनलों को भेजने का विकल्प डिफ़ॉल्ट रूप से चुना जाता है, लेकिन आप अन्य कार्य करना चाह सकते हैं, जैसे कि एक कार्य निष्पादित करें - पुराने बैकअप को किसी अन्य स्थान पर कॉपी करने के लिए (यदि वह कम स्थान वाला ड्राइव है)।
जैसा कि मैंने पहले उल्लेख किया है, सभी ड्राइव के लिए 10% खाली स्थान का डिफ़ॉल्ट शायद आपके वातावरण में प्रत्येक ड्राइव के लिए उपयुक्त नहीं है। आप विभिन्न उदाहरणों और ड्राइव के लिए क्वेरी को कस्टमाइज़ कर सकते हैं, उदाहरण के लिए:
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
आप अपने परिवेश के लिए आवश्यकतानुसार इस क्वेरी को बदल सकते हैं और विस्तारित कर सकते हैं, और फिर उसके अनुसार स्थिति में तुलना को बदल सकते हैं (मूल रूप से सही होने पर मूल्यांकन करना यदि परिणाम 1 है):
यदि आप प्रदर्शन सलाहकार को कार्य करते हुए देखना चाहते हैं, तो बेझिझक एक परीक्षण डाउनलोड करें।
ध्यान दें कि इन दोनों स्थितियों के लिए, आपको केवल एक बार अलर्ट किया जाएगा, भले ही कई ड्राइव आपकी सीमा से नीचे हों। जटिल वातावरण में आप कम "कैच-ऑल" स्थितियों के बजाय अधिक लचीली और अनुकूलित अलर्ट प्रदान करने के लिए अधिक विशिष्ट स्थितियों की ओर झुकना चाह सकते हैं।
सारांश
SQL सर्वर वातावरण में कई महत्वपूर्ण घटक होते हैं, और डिस्क स्थान वह है जिसे लगातार निगरानी और रखरखाव की आवश्यकता होती है। बस थोड़ी सी योजना के साथ, यह करना आसान है, और यह कई अज्ञात और प्रतिक्रियाशील समस्या समाधान को कम करता है। चाहे आप अपनी स्वयं की स्क्रिप्ट या किसी तृतीय-पक्ष टूल का उपयोग करें, यह सुनिश्चित करते हुए कि डेटाबेस फ़ाइलों के लिए पर्याप्त खाली स्थान है और बैकअप एक ऐसी समस्या है जिसे आसानी से हल किया जा सकता है, और प्रयास के लायक है।
