SQL सर्वर सिस्टम डेटाबेस के बारे में मेरे पिछले लेख में, हमने प्रत्येक सिस्टम डेटाबेस के बारे में सीखा जो SQL सर्वर स्थापना के भाग के रूप में आता है। वर्तमान लेख tempdb डेटाबेस के आसपास अक्सर आने वाली समस्याओं और उन्हें सही तरीके से हल करने के तरीके पर ध्यान केंद्रित करेगा।
SQL सर्वर TempDB
जैसा कि इस सिस्टम डेटाबेस के नाम से संकेत मिलता है, tempdb अस्थायी वस्तुओं को धारण करता है SQL सर्वर द्वारा बनाया गया। वे कई कार्यों से संबंधित हैं और SQL सर्वर इंस्टेंस से कनेक्ट होने वाले सभी उपयोगकर्ताओं के लिए एक वैश्विक कार्य क्षेत्र के रूप में कार्य करते हैं।
जब उपयोगकर्ता अपना कार्य करते हैं तो Tempdb डेटाबेस नीचे दिए गए ऑब्जेक्ट प्रकारों को धारण करेगा:
- अस्थायी वस्तुएं स्पष्ट रूप से उपयोगकर्ताओं द्वारा बनाई जाती हैं। वे स्थानीय या वैश्विक अस्थायी टेबल और इंडेक्स, टेबल वेरिएबल, टेबल-वैल्यू फंक्शन में इस्तेमाल होने वाली टेबल और कर्सर हो सकते हैं।
- डेटाबेस इंजन द्वारा बनाई गई आंतरिक वस्तुएं जैसे
- स्पूल, कर्सर, सॉर्ट और अस्थायी बड़े ऑब्जेक्ट (LOB) के लिए मध्यवर्ती परिणाम संग्रहीत करने वाली कार्य तालिकाएँ।
- हैश जॉइन या हैश एग्रीगेट ऑपरेशंस करते समय काम की फाइलें।
- यदि SORT_IN_TEMPDB को ON पर सेट किया गया है, और अन्य ऑपरेशन जैसे GROUP BY, ORDER BY, या SQL UNION क्वेरीज़ को बनाने या फिर से बनाने के दौरान इंटरमीडिएट सॉर्ट परिणाम।
- संस्करण स्टोर जो पंक्ति संस्करण सुविधा का समर्थन करते हैं, या तो सामान्य संस्करण स्टोर या ऑनलाइन इंडेक्स बिल्ड संस्करण स्टोर tempdb डेटाबेस फ़ाइलों का उपयोग करता है।
Tempdb डेटाबेस हर बार SQL सर्वर सेवा शुरू होने पर बनाया जाता है। इसलिए, tempdb डेटाबेस निर्माण के समय को अनुमानित SQL सर्वर सेवा स्टार्टअप समय के रूप में माना जा सकता है। हम इसकी पहचान sys.databases DMV . से कर सकते हैं नीचे दिखाई गई क्वेरी का उपयोग करके:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
हालाँकि, SQL सर्वर सेवा के वास्तविक स्टार्टअप में सभी सिस्टम डेटाबेस को एक विशिष्ट क्रम में शुरू करना शामिल है। यह tempdb निर्माण समय से थोड़ा पहले हो सकता है। हम sys.databases DMV . का उपयोग करके मान प्राप्त कर सकते हैं sys.dm_os_sys_info DMV . पर निम्न क्वेरी निष्पादित करके ।
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks कॉलम कंप्यूटर या सर्वर के शुरू होने के बाद से मिलीसेकंड की संख्या निर्दिष्ट करता है। sqlserver_start_time_ms_ticks कॉलम ms_ticks . के बाद से मिलीसेकंड की संख्या निर्दिष्ट करता है नंबर जब SQL सर्वर सेवा शुरू हुई।
हम SQL सर्वर त्रुटि लॉग में SQL सर्वर सेवाओं को प्रारंभ करते समय प्रारंभ हुए डेटाबेस के क्रम के बारे में अधिक जानकारी प्राप्त कर सकते हैं।
SSMS में, प्रबंधन को विस्तृत करें > SQL सर्वर त्रुटि लॉग > वर्तमानखोलें त्रुटि लॉग। प्रारंभ . को लागू करें डेटाबेस ऊपर फ़िल्टर करें और तारीख पर क्लिक करें इसे आरोही क्रम में क्रमबद्ध करने के लिए:
हम देख सकते हैं कि SQL सर्वर सेवा शुरू करते समय सबसे पहले मास्टर डेटाबेस शुरू हो गया है। फिर सभी उपयोगकर्ता डेटाबेस और अन्य सभी सिस्टम डेटाबेस का अनुसरण किया। अंत में, tempdb शुरू हुआ। आप xp_readerrorlog . को क्रियान्वित करके इस जानकारी को प्रोग्रामेटिक रूप से भी प्राप्त कर सकते हैं सिस्टम प्रक्रिया:
नोट :उपरोक्त दोनों दृष्टिकोण आवश्यक जानकारी नहीं दिखा सकते हैं यदि SQL सर्वर सेवा को हाल ही में पुनरारंभ नहीं किया गया था, और SQL सर्वर त्रुटि लॉग को पुनर्नवीनीकरण किया गया था, जिसने पुराने त्रुटि लॉग को पुरानी फ़ाइलों में धकेल दिया हो सकता है। उस स्थिति में, हमें संग्रहीत SQL सर्वर त्रुटि लॉग फ़ाइलों में डेटा को स्कैन करने की आवश्यकता हो सकती है।
SQL TempDB डेटाबेस में अक्सर आने वाली समस्याएं
जैसा कि tempdb सभी उपयोगकर्ता सत्रों या गतिविधियों के लिए एक वैश्विक कार्य क्षेत्र प्रदान करता है, यह उपयोगकर्ता संचालन के लिए एक प्रदर्शन बाधा बन सकता है यदि सावधानीपूर्वक कॉन्फ़िगर नहीं किया गया हो। मेरे पिछले लेख में, हमने tempdb डेटाबेस में लागू करने के लिए अनुशंसित सर्वोत्तम प्रथाओं पर चर्चा की है। हालांकि, उन्हें लागू करने के बाद भी, हम अक्सर समस्याओं का सामना कर सकते हैं:
- tempdb डेटा फ़ाइलों में असमान फ़ाइल वृद्धि।
- Tempdb डेटा फ़ाइलें बहुत बड़ी मात्रा में बढ़ रही हैं और Tempdb को सिकोड़ने की आवश्यकता है।
TempDB डेटा फ़ाइलों में असमान फ़ाइल वृद्धि
SQL सर्वर 2000 से शुरू होकर, सर्वर में उपलब्ध लॉजिकल कोर की संख्या के आधार पर कई डेटा फ़ाइलों को रखने के लिए डिफ़ॉल्ट अनुशंसा है।
जब हमारे पास कई डेटा फ़ाइलें होती हैं, उदाहरण के लिए, नीचे दी गई छवि में 4 tempdb डेटा फ़ाइलें, tempdb डेटा फ़ाइलों का स्वत:विकास 64 एमबी तक राउंड-रॉबिन फैशन में होगा tempdev> temp2> temp3> temp4> tempdev से शुरू और इसी तरह।
यदि किसी फ़ाइल आकार में से किसी एक कारण से ऑटो-ग्रो नहीं हो सकता है, तो इसका परिणाम अन्य फ़ाइलों की तुलना में कुछ फ़ाइलों के विशाल आकार में होगा। यह बड़ी फ़ाइलों पर अतिरिक्त अधिभार डालता है और tempdb डेटाबेस पर नकारात्मक प्रदर्शन प्रभाव डालता है।
हमें मैन्युअल रूप से यह सुनिश्चित करने की आवश्यकता है कि SQL सर्वर 2014 तक विवाद या प्रदर्शन के मुद्दों से बचने के लिए सभी tempdb डेटा फ़ाइलों को मैन्युअल रूप से किसी भी समय समान रूप से आकार दिया गया है। Microsoft ने SQL सर्वर 2016 और बाद के संस्करणों से शुरू होने वाले इस व्यवहार को कुछ सुविधाओं को लागू करके बदल दिया है जो होगा इस लेख में बाद में चर्चा की गई।
उपरोक्त प्रदर्शन समस्याओं को दूर करने के लिए, SQL सर्वर ने 2 ट्रेस फ़्लैग्स पेश किया है नाम 1117 और 1118 tempdb के आसपास विवाद के मुद्दों से बचने के लिए।
- ट्रेस फ्लैग 1117 - एक ही फाइलग्रुप के भीतर सभी फाइलों के ऑटो-ग्रोथ को सक्षम करता है
- ट्रेस फ्लैग 1118 - tempdb के लिए यूनिफ़ॉर्म पूर्ण विस्तार सक्षम करता है
ट्रेस फ्लैग 1117
ट्रेस फ्लैग 1117 सक्षम किए बिना, जब भी tempdb कई डेटा फ़ाइलों के साथ कॉन्फ़िगर किया गया है जो समान रूप से आकार में हैं और डेटा फ़ाइलों को ऑटो-ग्रो करने की आवश्यकता है, डिफ़ॉल्ट रूप से SQL सर्वर फ़ाइल आकार को राउंड-रॉबिन फैशन में बढ़ाने की कोशिश करेगा यदि सभी फाइलें। यदि डेटा फ़ाइलें समान रूप से आकार में नहीं हैं, तो SQL सर्वर tempdb की सबसे बड़ी डेटा फ़ाइल के आकार को बढ़ाने का प्रयास करेगा और अधिकांश उपयोगकर्ता कार्यों के लिए इस बड़ी फ़ाइल का उपयोग करेगा जिसके परिणामस्वरूप tempdb विवाद की समस्याएँ होंगी..
इस समस्या को हल करने के लिए, SQL सर्वर ने ट्रेस फ्लैग 1117 की शुरुआत की। एक बार सक्षम होने पर, यदि फ़ाइल समूह के भीतर एक फ़ाइल को ऑटो-ग्रो करने की आवश्यकता होती है, तो यह उस फ़ाइलग्रुप के भीतर सभी फ़ाइलों को ऑटो-ग्रो करेगा। यह tempdb विवाद मुद्दों को हल करता है। हालांकि, पकड़ यह है कि एक बार ट्रेस फ्लैग 1117 सक्षम हो जाने के बाद, सभी उपयोगकर्ता डेटाबेस के लिए ऑटो-ग्रोथ को भी कॉन्फ़िगर किया जाता है।
ट्रेस फ्लैग 1118
ट्रेस फ्लैग 1118 का उपयोग यूनिफ़ॉर्म पूर्ण विस्तार को सक्षम करने के लिए किया जाता है। आइए यह समझने के लिए एक कदम पीछे हटें कि SQL सर्वर बुनियादी से डेटा कैसे संग्रहीत करता है।
पेज SQL सर्वर में 8 किलोबाइट्स (KB) के आकार के साथ स्टोरेज की मूलभूत इकाई है।
सीमा 64KB(8*8KB) के आकार के साथ 8 भौतिक रूप से सन्निहित पृष्ठों का एक समूह है। एक सीमा के भीतर कितने ऑब्जेक्ट या मालिक डेटा को स्टोर करते हैं, इसके आधार पर, Extent को इसमें वर्गीकृत किया जा सकता है:
- समान विस्तार 8 सन्निहित पृष्ठ हैं जिनका किसी एक वस्तु या स्वामी द्वारा उपयोग किया जाता है या उन तक पहुँचा जाता है;
- मिश्रित विस्तार - कम से कम 2 और अधिकतम 8 वस्तुओं या मालिकों द्वारा उपयोग या एक्सेस किए गए 8 सन्निहित पृष्ठ हैं
ट्रेस फ्लैग 1118 को सक्षम करने से tempdb को एक समान विस्तार करने की अनुमति मिलेगी जिसके परिणामस्वरूप बेहतर प्रदर्शन होगा।
ट्रेस फ़्लैग्स 1117 और 1118 कैसे सक्षम करें
ट्रेस फ्लैग को कई तरीकों से सक्षम किया जा सकता है। आप नीचे दिए गए विकल्पों में से उपयुक्त तरीके को परिभाषित कर सकते हैं:
SQL सर्वर सेवा स्टार्टअप पैरामीटर
SQL सेवा पुनरारंभ होने के बाद भी स्थायी रूप से उपलब्ध है। अनुशंसित तरीका SQL सर्वर सेवा स्टार्टअप पैरामीटर के माध्यम से ट्रेस फ्लैग 1117 और 1118 को सक्षम करना है ।
SQL सर्वर कॉन्फ़िगरेशन प्रबंधक खोलें और एसक्यूएल सर्वर सेवाएं पर क्लिक करें उस सर्वर में उपलब्ध सेवाओं को सूचीबद्ध करने के लिए:
- SQL सर्वर (MSSQLSERVER) पर राइट-क्लिक करें > गुण > स्टार्टअप पैरामीटर्स ।
- टाइप करें -T ट्रेस फ्लैग . को इंगित करने के लिए खाली फ़ील्ड में ।
- मान प्रदान करें 1117 और 1118 जैसा कि नीचे दिखाया गया है।
- क्लिक करें जोड़ें ट्रेस फ़्लैग्स को स्टार्टअप पैरामीटर के रूप में जोड़ने के लिए।
फिर ठीक . क्लिक करें SQL सर्वर की इस आवृत्ति के लिए स्थायी रूप से ट्रेस फ़्लैग जोड़ने के लिए। परिवर्तनों को प्रतिबिंबित करने के लिए SQL सर्वर सेवा को पुनरारंभ करें।
DBCC TRACEON (<ट्रेस फ्लैग नंबर>, -1)
वैश्विक स्तर पर ट्रेस ध्वज सक्षम करें। SQL सर्वर सेवा सेवा पुनरारंभ होने पर ट्रेस फ़्लैग खो देगी। वैश्विक स्तर पर ट्रेस फ़्लैग को सक्षम करने के लिए, नीचे दी गई स्क्रिप्ट को एक नई क्वेरी विंडो में निष्पादित करें:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON (<ट्रेस फ्लैग नंबर>)
सत्र-स्तर पर ट्रेस ध्वज सक्षम करें। यह केवल उपयोगकर्ता द्वारा बनाए गए वर्तमान सत्र पर लागू होता है। सत्र स्तर पर ट्रेस फ़्लैग को सक्षम करने के लिए, नीचे दी गई स्क्रिप्ट को एक नई क्वेरी विंडो में निष्पादित करें:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
SQL सर्वर की आवृत्ति में सक्षम ट्रेस फ़्लैग की सूची देखने के लिए, हम DBCC TRACESTATUS का उपयोग कर सकते हैं आदेश:
DBCC TRACESTATUS();
जैसा कि हम देख सकते हैं, ट्रेस फ़्लैग्स 1117 और 1118 मेरे उदाहरण में सत्र के साथ-साथ वैश्विक रूप से सक्षम हैं ।
ट्रेस फ्लैग को बंद करने के लिए, हम DBCC TRACEOFF कमांड का उपयोग कर सकते हैं जैसे:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
SQL सर्वर 2016 TempDB एन्हांसमेंट
SQL सर्वर संस्करणों में SQL Server 2000 से SQL Server 2014 तक, हमें tempdb विवाद मुद्दों से बचने के लिए tempdb की पूरी निगरानी के साथ ट्रेस फ़्लैग्स 1117 और 1118 को सक्षम करना होगा। SQL सर्वर 2016 और बाद के संस्करणों से शुरू होकर, ट्रेस फ़्लैग्स 1117 और 1118 डिफ़ॉल्ट रूप से कार्यान्वित किए जाते हैं।
हालांकि, मेरे व्यक्तिगत अनुभव के आधार पर यह बेहतर है कि tempdb को एक बड़े आकार में पूर्व-विकसित किया जाए ताकि कई बार ऑटोग्रोथ की आवश्यकता से बचा जा सके और असमान फ़ाइल आकार या SQL सर्वर द्वारा व्यापक रूप से उपयोग की जा रही एकल फ़ाइलों को समाप्त किया जा सके ।
हम सत्यापित कर सकते हैं कि SQL सर्वर 2016 में ट्रेस फ्लैग 1117 और 1118 कैसे कार्यान्वित किए जाते हैं:
ट्रेस फ्लैग 1117 जो एक फाइलग्रुप के भीतर सभी फाइलों के ऑटोग्रोथ को सेट करता है, अब फाइलग्रुप की एक संपत्ति है . हम एक नया फ़ाइल समूह बनाते समय या किसी मौजूदा फ़ाइल समूह को संशोधित करते समय इसे कॉन्फ़िगर कर सकते हैं।
फाइलग्रुप की ऑटो-ग्रो प्रॉपर्टी को सत्यापित करने के लिए , नीचे दी गई स्क्रिप्ट को sys.filegroups DMV . से निष्पादित करें :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
एडवेंचरवर्क्स डेटाबेस के प्राथमिक फाइलग्रुप की ऑटो-ग्रोथ प्रॉपर्टी को संशोधित करने के लिए , हम सभी फ़ाइलों को समान रूप से ऑटो-ग्रो करने के लिए AUTOGROW_ALL_FILES के साथ नीचे दी गई स्क्रिप्ट को निष्पादित करते हैं या केवल एक डेटा फ़ाइल के ऑटोग्रोथ की अनुमति देने के लिए AUTOGROW_SINGLE_FILE।
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
ट्रेस फ्लैग 1118 जो डेटा फ़ाइलों की समान सीमा संपत्ति सेट करता है डिफ़ॉल्ट रूप से tempdb और SQL सर्वर 2016 से शुरू होने वाले सभी उपयोगकर्ता डेटाबेस के लिए सक्षम है . हम tempdb के गुणों को नहीं बदल सकते, क्योंकि यह अब केवल यूनिफ़ॉर्म एक्स्टेंट विकल्प का समर्थन करता है।
उपयोगकर्ता डेटाबेस के लिए, हम इस पैरामीटर को संशोधित कर सकते हैं। सिस्टम डेटाबेस मास्टर, मॉडल और एमएसडीबी डिफ़ॉल्ट रूप से मिश्रित विस्तार का समर्थन करता है और इसे बदला भी नहीं जा सकता।
उपयोगकर्ता डेटाबेस के लिए मिश्रित पृष्ठ आवंटन संपत्ति मूल्यों को संशोधित करने के लिए, नीचे दी गई स्क्रिप्ट का उपयोग करें:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
मिश्रित पृष्ठ आवंटन गुण को सत्यापित करने के लिए, हम is_mixed_page_allocation_on को क्वेरी कर सकते हैं sys.databases DMV . से कॉलम 0 के रूप में मान के साथ, एक समान सीमा पृष्ठ आवंटन को दर्शाता है, और 1 मिश्रित सीमा पृष्ठ आवंटन को इंगित करने के लिए।
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
TempDB डेटा फ़ाइलें एक विशाल मूल्य तक बढ़ रही हैं जिसके लिए TempDB को सिकोड़ना आवश्यक है
SQL सर्वर 2014 या पुराने संस्करणों में, यदि ट्रेस फ़्लैग 1117 और 1118 को tempdb डेटाबेस के लिए बनाई गई एकाधिक डेटा फ़ाइलों के साथ ठीक से कॉन्फ़िगर नहीं किया गया है, तो उनमें से कुछ फ़ाइलें अनिवार्य रूप से बड़ी हो जाएंगी। यदि ऐसा होता है, तो DBA आमतौर पर tempdb डेटा फ़ाइलों को सिकोड़ने का प्रयास करता है। लेकिन यह एक अनुचित . है इस परिदृश्य को संभालने के लिए दृष्टिकोण।
Tempdb को सिकोड़ने के लिए अन्य विकल्प उपलब्ध हैं।
आइए श्रिंक टेम्पडब के लिए उपलब्ध डीबीसीसी कमांड और इन कार्यों को करने के प्रभावों पर विचार करें।
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE कंसोल कमांड डेटा\लॉग फाइल्स के अंत को सिकोड़कर काम करता है ।
डेटाबेस को सफलतापूर्वक सिकोड़ने के लिए, कमांड को फ़ाइल के अंत में खाली स्थान की आवश्यकता होती है। यदि फ़ाइल के अंत में कोई सक्रिय लेनदेन है, तो डेटाबेस फ़ाइलों को छोटा नहीं किया जा सकता है।
DBCC SHRINKDATABASE निष्पादित करने का प्रभाव यह है कि यह प्रत्येक डेटा फ़ाइल या लॉग फ़ाइल के अंत में उपलब्ध खाली स्थान को साफ़ करने का प्रयास करेगा जो तालिका डेटा के भविष्य के विकास के लिए आरक्षित हो सकता है। इसलिए, इस कमांड को चलाने से फ़ाइल का आकार असमान हो सकता है जिससे tempdb विवाद की समस्या हो सकती है।
उपयोगकर्ता डेटाबेस को सिकोड़ने के लिए सिंटेक्स उदाहरण के लिए एडवेंचरवर्क्स डेटाबेस होगा
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);
डीबीसीसी श्रिंकफाइल
DBCC SHRINKFILE कंसोल कमांड DBCC SHRINKDATABASE के समान काम करता है, लेकिन यह निर्दिष्ट डेटाबेस डेटा या लॉग फ़ाइलों को सिकोड़ता है ।
यदि आप पहचानते हैं कि एक विशेष tempdb डेटा फ़ाइल बहुत बड़ी है, तो हम नीचे दिखाए गए अनुसार DBCC SHRINKFILE का उपयोग करके उस विशेष आइटम को सिकोड़ने का प्रयास कर सकते हैं।
Tempdb पर इस कमांड का उपयोग करते समय सावधान रहें क्योंकि यदि कोई फ़ाइल अन्य डेटा फ़ाइलों की तुलना में कम या अधिक मान तक सिकुड़ जाती है, तो उस विशेष डेटा फ़ाइल का प्रभावी ढंग से उपयोग नहीं किया जाएगा। या, इसका अधिक बार उपयोग किया जाएगा जिससे tempdb विवाद की समस्या उत्पन्न हो सकती है।
एडवेंचरवर्क्स डेटा फ़ाइल पर 1GB (1024 एमबी) तक DBCC SHRINKFILE ऑपरेशन निष्पादित करने के लिए सिंटैक्स होगा:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
डीबीसीसी ड्रॉपक्लीनबफर
DBCC DROPCLEANBUFFERS कंसोल कमांड का उपयोग बफ़र पूल से सभी साफ़ बफ़र्स और कॉलमस्टोर ऑब्जेक्ट पूल से कॉलमस्टोर ऑब्जेक्ट को साफ़ करने के लिए किया जाता है ।
बस नीचे दिए गए आदेश को निष्पादित करें:
DBCC DROPCLEANBUFFERS
डीबीसीसी फ्रीप्रोकैच
DBCC FREEPROCCACHE आदेश सभी संग्रहीत कार्यविधि निष्पादन योजना कैश साफ़ करता है ।
प्रक्रिया निष्पादन योजना कैश का उपयोग SQL सर्वर द्वारा समान प्रक्रिया कॉल को तेज़ी से निष्पादित करने के लिए किया जाता है। DBCC FREEPROCCACHE को क्रियान्वित करने के बाद, प्लान कैश साफ़ हो जाता है। इस प्रकार, उदाहरण में संग्रहीत कार्यविधि निष्पादित होने पर SQL सर्वर को उस कैश को फिर से बनाना होगा। उत्पादन डीबी उदाहरणों में निष्पादित होने पर यह एक गंभीर नकारात्मक प्रभाव छोड़ता है।
उत्पादन डेटाबेस इंस्टेंस पर DBCC FREEPROCCACHE को निष्पादित करने की अनुशंसा नहीं की जाती है!
DBCC FREEPROCCACHE को निष्पादित करने का सिंटैक्स नीचे है:
DBCC FREEPROCCACHE
डीबीसीसी फ्रीसेशन कैशे
DBCC FREESESSIONCACHE कमांड SQL सर्वर इंस्टेंस से वितरण क्वेरी कनेक्शन कैश को साफ़ करता है . यह तब मददगार होगा जब किसी विशेष SQL सर्वर इंस्टेंस पर कई वितरित क्वेरी निष्पादित हो रही हों।
DBCC FREESESSIONCACHE को निष्पादित करने का सिंटैक्स होगा:
DBCC FREESESSIONCACHE
डीबीसीसी फ्री सिस्टम कैशे
DBCC FREESYSTEMCACHE आदेश सभी कैश से सभी अप्रयुक्त कैश प्रविष्टियों को साफ़ करता है . SQL सर्वर नए संचालन के लिए अधिक मेमोरी उपलब्ध कराने के लिए डिफ़ॉल्ट रूप से ऐसा करता है। हालाँकि, हम इसे नीचे दिए गए कमांड का उपयोग करके मैन्युअल रूप से निष्पादित कर सकते हैं:
DBCC FREESYSTEMCACHE
जैसा कि हम जानते हैं, tempdb निष्पादन योजना कैश, बफर पूल डेटा, सत्र कैश और सिस्टम कैश सहित सभी अस्थायी उपयोगकर्ता वस्तुओं या आंतरिक वस्तुओं को संग्रहीत करता है। इसलिए, उपरोक्त 6 DBCC कमांड को निष्पादित करने से सामान्य सिकुड़न प्रक्रिया को रोकने वाली tempdb डेटा फ़ाइलों को साफ़ करने में मदद मिलेगी।
भले ही हम विभिन्न तरीकों के माध्यम से tempdb को सिकोड़ने के चरणों के माध्यम से चले गए हैं, tempdb डेटाबेस से निपटने के लिए अनुशंसित सर्वोत्तम अभ्यास नीचे सूचीबद्ध हैं:
ए. यदि संभव हो तो tempdb डेटा फ़ाइलों को समान रूप से पुन:बनाने के लिए SQL सर्वर सेवाओं को पुनरारंभ करें। संभावित प्रभाव होगा, हम ऊपर चर्चा की गई सभी निष्पादन योजनाओं और अन्य कैश जानकारी को खो देंगे।
ख. tempdb डेटा फ़ाइलों को रखने वाली ड्राइव में उपलब्ध एक विशाल फ़ाइल आकार में tempdb डेटा फ़ाइलों को प्री-ग्रो करें। यह SQL सर्वर को SQL सर्वर संस्करण 2014 और उससे पहले के फ़ाइल आकार को असमान रूप से बढ़ाने से रोकेगा।
सी. यदि आरटीओ या आरपीओ के कारण SQL सर्वर सेवाओं को पुनरारंभ नहीं किया जा सकता है, तो प्रभावों को स्पष्ट रूप से समझने के बाद उपरोक्त डीबीसीसी कमांड का प्रयास करें।
डी. tempdb डेटाबेस या डेटा फ़ाइलों को सिकोड़ना एक अनुशंसित दृष्टिकोण नहीं है और इसलिए अपने उत्पादन वातावरण में ऐसा कभी न करें जब तक कि कोई अन्य विकल्प न हों।
निष्कर्ष
हमने आंतरिक के बारे में अधिक सीखा है कि tempdb कैसे काम करता है ताकि हम tempdb पर विवाद के मुद्दों से बचने के लिए बेहतर प्रदर्शन के लिए tempdb को कॉन्फ़िगर कर सकें। हम tempdb में अक्सर सामना की जाने वाली समस्याओं, विभिन्न संस्करणों में SQL सर्वर में उपलब्ध उपायों और इसे कुशलता से कैसे संभालें, से भी गुजरे हैं। इसके अलावा, हमने जांच की है कि tempdb डेटाबेस से निपटने के दौरान tempdb डेटाबेस या डेटा फ़ाइलों को सिकोड़ना अनुशंसित दृष्टिकोण क्यों नहीं है।