मेरे पास केवल 2GB शेष है, इसलिए मुझे इस इतिहास तालिका को निकालने की आवश्यकता है। यह तालिका अब खाली है लेकिन डेटाबेस डिस्क स्थान जारी नहीं किया गया है। और डेटाबेस फ़ाइल 320GB है।
जवाबों:
यदि आप वॉल्यूम पर वास्तविक डेटाबेस फ़ाइल की खपत को संदर्भित कर रहे हैं, तो SQL सर्वर स्वचालित रूप से संभाल नहीं करता है । सिर्फ इसलिए कि आपने डेटाबेस से डेटा हटा दिया है इसका मतलब यह नहीं है कि डेटाबेस फाइलें केवल मौजूदा डेटा को फिट करने के लिए सिकुड़ेंगी।
आप अगर तुम क्या, के लिए विचार करना होता है की मात्रा पर अंतरिक्ष को पुनः प्राप्त करने के साथ विशेष फ़ाइल सिकुड़ होगा DBCC SHRINKFILE। यह उस प्रलेखन के अनुसार कुछ सर्वोत्तम प्रथाओं पर ध्यान देने योग्य है:
सर्वोत्तम प्रथाएं
जब आप किसी फ़ाइल को सिकोड़ने की योजना बनाते हैं तो निम्न जानकारी पर विचार करें:
एक ऑपरेशन के बाद हटना ऑपरेशन सबसे प्रभावी होता है जो बहुत सारे अप्रयुक्त स्थान बनाता है, जैसे कि एक ट्रंकट टेबल या ड्रॉप टेबल ऑपरेशन।
अधिकांश डेटाबेस को नियमित रूप से दिन-प्रतिदिन के संचालन के लिए कुछ खाली स्थान की आवश्यकता होती है। यदि आप किसी डेटाबेस को बार-बार सिकोड़ते हैं और ध्यान देते हैं कि डेटाबेस का आकार फिर से बढ़ता है, तो यह इंगित करता है कि सिकुड़ा हुआ स्थान नियमित संचालन के लिए आवश्यक है। इन मामलों में, डेटाबेस को बार-बार सिकोड़ना एक व्यर्थ ऑपरेशन है।
एक सिकुड़ा हुआ ऑपरेशन डेटाबेस में अनुक्रमित के विखंडन की स्थिति को संरक्षित नहीं करता है, और आम तौर पर विखंडन को एक हद तक बढ़ाता है। डेटाबेस को बार-बार सिकोड़ने का यह एक और कारण है।
समवर्ती के बजाय क्रमिक रूप से एक ही डेटाबेस में कई फ़ाइलों को सिकोड़ें। ब्लॉक करने के कारण सिस्टम टेबल पर ध्यान देने में देरी हो सकती है।
नोट का भी:
DBCC SHRINKFILEप्रक्रिया में किसी भी बिंदु पर संचालन को रोका जा सकता है, और कोई भी पूरा काम बरकरार रखा जाता है।
ऐसा करने पर विचार करने के लिए कुछ चीजें निश्चित रूप से हैं, और मैं आपको सलाह देता हूं कि आप पॉल रैंडल के ब्लॉग पोस्ट पर एक नज़र डालें कि जब आप यह ऑपरेशन करते हैं तो क्या होता है।
पहला कदम निश्चित रूप से यह सत्यापित करने के लिए होगा कि आप वास्तव में कितनी जगह और मुक्त स्थान को बदलने में सक्षम हैं, साथ ही फ़ाइल (एस) पर प्रयुक्त स्थान:
use AdventureWorks2012;
go
;with db_file_cte as
(
select
name,
type_desc,
physical_name,
size_mb =
convert(decimal(11, 2), size * 8.0 / 1024),
space_used_mb =
convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
from sys.database_files
)
select
name,
type_desc,
physical_name,
size_mb,
space_used_mb,
space_used_percent =
case size_mb
when 0 then 0
else convert(decimal(5, 2), space_used_mb / size_mb * 100)
end
from db_file_cte;यह सामान्य व्यवहार है जब आप टेबल को काटते हैं और जिसमें प्रति पुस्तकें ऑनलाइन के अनुसार 128 से अधिक विस्तार को हटाना शामिल है
जब आप बड़ी अनुक्रमणिका को छोड़ते या पुन: निर्मित करते हैं, या बड़ी तालिकाओं को छोड़ते या काटते हैं, तो डेटाबेस इंजन वास्तविक पृष्ठ व्यवहार और उनके संबद्ध ताले को तब तक हटाता है, जब तक कि लेनदेन शुरू नहीं हो जाता। यह कार्यान्वयन एक बहुउपयोगी वातावरण में ऑटोकॉमिट और स्पष्ट लेनदेन दोनों का समर्थन करता है, और बड़े टेबल और इंडेक्स पर लागू होता है जो 128 से अधिक सेंट का उपयोग करते हैं।
डेटाबेस इंजन उस आवंटन ताले से बचता है जो दो अलग-अलग चरणों में प्रक्रिया को विभाजित करके बड़ी वस्तुओं को छोड़ने के लिए आवश्यक है: तार्किक और भौतिक।
तार्किक चरण में, तालिका या सूचकांक द्वारा उपयोग की जाने वाली मौजूदा आवंटन इकाइयां सौदे के लिए चिह्नित होती हैं और लेनदेन शुरू होने तक बंद रहती हैं। क्लस्टर किए गए अनुक्रमणिका को गिराए जाने के साथ, डेटा पंक्तियों को कॉपी किया जाता है और फिर स्टोर पर बनाई गई नई आवंटन इकाइयों में या तो एक पुनर्निर्मित क्लस्टर इंडेक्स, या एक ढेर में ले जाया जाता है। (एक सूचकांक के पुनर्निर्माण के मामले में, डेटा पंक्तियों को भी सॉर्ट किया जाता है।) जब कोई रोलबैक होता है, तो केवल इस तार्किक चरण को वापस रोल करने की आवश्यकता होती है।
लेन-देन के शुरू होने के बाद भौतिक चरण होता है। डीललोकेशन के लिए चिन्हित आवंटन इकाइयों को शारीरिक रूप से बैचों में गिरा दिया जाता है। इन बूंदों को पृष्ठभूमि में होने वाले छोटे लेनदेन के अंदर संभाला जाता है, और बहुत सारे ताले की आवश्यकता नहीं होती है।
क्योंकि लेन-देन के शुरू होने के बाद भौतिक चरण होता है, टेबल या इंडेक्स का संग्रहण स्थान अभी भी अनुपलब्ध दिखाई दे सकता है। यदि भौतिक चरण पूरा होने से पहले डेटाबेस के बढ़ने के लिए इस स्थान की आवश्यकता होती है, तो डेटाबेस इंजन डीलक्लोकेशन के लिए चिह्नित आवंटन इकाइयों से स्थान को पुनर्प्राप्त करने का प्रयास करता है। वर्तमान में इन आवंटन इकाइयों द्वारा उपयोग किए जाने वाले स्थान को खोजने के लिए, sys.allocation_units कैटलॉग दृश्य का उपयोग करें।
आस्थगित ड्रॉप संचालन आवंटित स्थान को तुरंत जारी नहीं करते हैं, और वे डेटाबेस इंजन में अतिरिक्त ओवरहेड लागत का परिचय देते हैं। इसलिए, 128 या उससे कम एक्सटेंशन्स का उपयोग करने वाले टेबल और इंडेक्स को SQL Server 2000 की तरह ही हटा दिया जाता है, काट दिया जाता है और फिर से बनाया जाता है। इसका मतलब यह है कि लेनदेन शुरू होने से पहले तार्किक और भौतिक दोनों चरण होते हैं।
आपको इंतजार करना होगा और निश्चित रूप से आपको फ़ाइल को मैन्युअल रूप से सिकोड़ना होगा ताकि स्पेस को पुनः प्राप्त किया जा सके, यह भी ध्यान देने योग्य है कि सिकुड़ने से तार्किक विखंडन होता है और तब तक बचा जाना चाहिए जब तक कि आपकी आवश्यकता गंभीर न हो। आपको कुछ सिकुड़ना और विखंडन के बीच संतुलन बनाना होगा। अपने आप से यह पूछना बेहतर होगा कि क्या वास्तव में सिकुड़न वास्तव में उस परिदृश्य को देखते हुए समस्या को हल करेगी जहां डेटा फिर से किसी भी तरह बढ़ेगा।
डेटाबेस में कितना खाली स्थान है यह जांचने के लिए नीचे क्वेरी का उपयोग करें
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;यदि आपके डेटाबेस में LOB / BLOB डेटा है तो टॉम और शैंकी के उत्तरों के अलावा, DBCC SHRINKFILE काम नहीं कर सकता है। यदि ऐसा है, तो आपके पास दो विकल्प हैं, इस पर निर्भर करता है कि आप डेटाबेस को ऑफ़लाइन ले सकते हैं या नहीं। यदि आप डेटाबेस को ऑफ़लाइन ले जा सकते हैं, तो आपको खाली जगह निकालने के लिए डेटा को कॉपी करके वापस कॉपी करना होगा। आप इसे निम्न में से एक द्वारा पूरा कर सकते हैं:
यदि आप डेटाबेस को ऑफ़लाइन नहीं ले जा सकते हैं, तो आप EMPTYFILE विकल्प के साथ DBCC SHRINKFILE कमांड का उपयोग कर सकते हैं ।
ऑफ़लाइन प्रति के लिए विवरण: http://support.microsoft.com/kb/324432/en-us
EMPTYFILE विकल्प के लिए वर्तमान जानकारी http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx