मुझे "डेटाबेस के लिए लॉग फ़ाइल" tempdb 'पूर्ण क्यों है "

Question

हमारे पास प्राथमिक कुंजी (ऑटोइनक बिगिंट) के साथ 35 कॉलम और 3 गैर-क्लस्टर, गैर-अद्वितीय इंडेक्स (प्रत्येक पर एक int कॉलम)।

1. PAYMENT_DATEdatetime NOT NULL

2. EDIT_DATEdatetime NULL

तालिका के बारे में 1 200 000 पंक्तियां हैं:

तालिका के स्तंभों के अलावा हम दो datetime क्षेत्रों की है। केवल ~ 1000 पंक्तियों में edit_date कॉलम = शून्य है। पंक्तियों की 9000 EDIT_DATE नहीं बातिल और नहीं दूसरों PAYMENT_DATE के बराबर होता है EDIT_DATE = PAYMENT_DATE

हम निम्नलिखित क्वेरी 1 चलाते हैं:

select top 1 * 
from payments 
where edit_date is not null and (payment_date=edit_date or payment_date<>edit_date) 
order by payment_date desc 

सर्वर की एक जोड़ी की जरूरत है इसे करने के लिए सेकंड। लेकिन अगर हम क्वेरी 2 चलाएँ:

select top 1 * 
from payments 
where edit_date is not null 
order by payment_date desc 

निष्पादन डेटाबेस 'tempdb' के लिए लॉग फ़ाइल साथ समाप्त होता है भरा हुआ है। कुछ लॉग स्पेस को खाली करने के लिए डेटाबेस के लिए लेनदेन लॉग का बैकअप लें।

हम कुछ निश्चित स्तंभ के साथ बदलते हैं *, क्वेरी 3

select top 1 payment_date 
from payments 
where edit_date is not null 
order by payment_date desc 

यह भी सेकंड के एक जोड़े में खत्म देखते हैं।

जादू कहां है?

संपादित करें मैंने क्वेरी 1 बदल दिया है ताकि यह दूसरी क्वेरी के समान पंक्तियों पर समान रूप से संचालित हो। और फिर भी यह एक सेकंड में लौटता है, जबकि क्वेरी 2 tempdb भरता है।

उत्तर मैं एक सूचकांक से जोड़ने के लिए सलाह का पालन, दोनों तिथि खाने के लिए ऐसा किया - सब कुछ, जल्दी काम करना शुरू किया अपेक्षा के अनुरूप। हालांकि, सवाल यह था - क्यों इस सटीक स्थिति में SQL सर्वर समान प्रश्नों पर अलग-अलग व्यवहार करता है (क्वेरी 1 बनाम क्वेरी 2); मैं सर्वर अनुकूलन के तर्क को समझना चाहता था। मैं सहमत हूं कि दोनों प्रश्नों ने समान रूप से tempdb का उपयोग किया था, लेकिन उन्होंने नहीं किया ....

अंत में मैं पहले जवाब के रूप में चिह्नित हूं, जहां मैंने अपनी समस्या के लक्षणों को देखा और पहला , साथ ही, इस से बचने के विचारों पर विचार (यानीindeces)

Answer 1

ऐसा इसलिए हो रहा है क्योंकि एक निष्पादन योजना में कुछ कदम tempdb को विशेष रूप से sorts और joins में बहुत सारे डेटा शामिल कर सकते हैं।

चूंकि आप कॉलम के नाव लोड के साथ एक टेबल को सॉर्ट कर रहे हैं, एसक्यूएल निर्णय लेता है कि संबंधित डेटा के बिना temp डीबी में अकेले सॉर्ट करने के लिए पागल हो जाएगा। अगर ऐसा होता है तो इसे अंतर्निहित तालिका पर एक गैज़िलियन अक्षम बुकमार्क लुकअप करने की आवश्यकता होगी।

इन नियमों का पालन: केवल वांछित डेटा

आकार tempdb उचित रूप से की जरूरत है, अगर आप पागल क्वेरी का gazzilion पंक्तियां क्रमित करने की जरूरत का चयन करने के

1. प्रयास करें, तो आप बेहतर एक उचित रूप से tempdb आकार है

Answer 2

आमतौर पर, जब आप डिस्क स्थान पर कम होते हैं, या जब आपने डेटाबेस वृद्धि के लिए अनुचित रूप से कम अधिकतम आकार सेट किया है तो tempdb भर जाता है। कई लोग सोचते हैं कि tempdb केवल #temp टेबल के लिए उपयोग किया जाता है। वास्तव में, जब आप कभी भी एक अस्थायी तालिका बनाये बिना tempdb भर सकते हैं। कुछ अन्य परिस्थितियों में आपको tempdb पैदा कर सकता है को भरने के लिए:

• किसी भी छंटाई कि अधिक स्मृति सर्वर tempdb में अपने काम करने के लिए मजबूर किया जाएगा की तुलना में एसक्यूएल के लिए आवंटित किया गया है की आवश्यकता है;
• यदि सॉर्टिंग को tempdb, पर आवंटित किए गए स्थान की तुलना में अधिक स्थान की आवश्यकता है, तो उपर्युक्त त्रुटियों में से एक होगा;
• डीबीसीसी चेकडीबी ('कोई डेटाबेस') tempdb में अपना काम करेगा - बड़े डेटाबेस पर, यह काफी जगह का उपभोग कर सकता है;
• डीबीसीसी डीबीआरआईएनएक्सएक्स या इसी तरह के डीबीसीसी कमांड 'सॉर्ट इन टेम्पपड' विकल्प सेट के साथ संभावित रूप से tempdb भर जाएगा;
• यूनियनों को शामिल करने वाले बड़े परिणाम, कार्टेसियन में शामिल होते हैं, बाहरी जुड़ते हैं, कर्सर, अस्थायी तालिकाओं, तालिका चर, और हैशिंग को अक्सर tempdb से सहायता की आवश्यकता होती है;
• किसी भी लेनदेन को छोड़ दिया गया है और वापस लुढ़का नहीं वस्तुओं को tempdb में अनाथ हो सकता है;

• विकल्प के साथ एक ओडीबीसी डीएसएन का उपयोग 'अस्थायी संग्रहीत प्रक्रियाओं' सेट के साथ कनेक्शन के जीवन के लिए वस्तुओं को छोड़ सकता है।

  उपयोग tempdb GO

  SELECT name 
       FROM tempdb..sysobjects 
  
      SELECT OBJECT_NAME(id), rowcnt 
       FROM tempdb..sysindexes 
       WHERE OBJECT_NAME(id) LIKE '#%' 
       ORDER BY rowcnt DESC 
  

उच्च rowcount, मूल्यों की संभावना सबसे बड़ी अस्थायी तालिकाओं कि अंतरिक्ष उपभोग कर रहे हैं इंगित करेगा।

अल्पकालिक ठीक

DBCC OPENTRAN -- or DBCC OPENTRAN('tempdb') 
DBCC INPUTBUFFER(<number>) 
KILL <number> 

लंबे समय तक रोकथाम

-- SQL Server 7.0, should show 'trunc. log on chkpt.' 
-- or 'recovery=SIMPLE' as part of status column: 

EXEC sp_helpdb 'tempdb' 

-- SQL Server 2000, should yield 'SIMPLE': 

SELECT DATABASEPROPERTYEX('tempdb', 'recovery') 
ALTER DATABASE tempdb SET RECOVERY SIMPLE 

संदर्भ: http://sqlserver2000.databases.aspfaq.com/why-is-tempdb-full-and-how-can-i-prevent-this-from-happening.html
अन्य संदर्भ: http://social.msdn.microsoft.com/Forums/is/transactsql/thread/af493428-2062-4445-88e4-07ac65fedb76