दुर्भाग्य से वर्तमान में फाइलस्ट्रीम डेटा के कचरा संग्रहण (जीसी) को बाध्य करने का कोई तरीका नहीं है। यह एक एसिंक्रोनस पृष्ठभूमि कार्य द्वारा नियंत्रित किया जाता है जिसे केवल हर बार बुलाया जाता है और एक ही आमंत्रण में संसाधित होने वाली फ़ाइलों की संख्या में एक सीमा होती है। अन्य लोगों ने इसके बारे में पहले ही शिकायत कर दी है और Microsoft ने भविष्य के रिलीज़ में इस समस्या का समाधान करने का वादा किया है।
कहा जा रहा है, कुछ चीजें हैं जो आप यह सुनिश्चित करने के लिए कर सकते हैं कि सभी हटाई गई फ़ाइलें कचरा संग्रहण के लिए योग्य हैं। डेटाबेस से हटाए जाने के बाद फ़ाइल स्वचालित रूप से कचरा संग्रहण के लिए योग्य नहीं हो जाती - कुछ अतिरिक्त शर्तों को पूरा करना पड़ता है।
शर्तें डेटाबेस के पुनर्प्राप्ति मॉडल पर निर्भर करती हैं, इसलिए यह महत्वपूर्ण है कि आप जानते हैं कि आपका डेटाबेस किस पुनर्प्राप्ति मॉडल में है। ध्यान दें कि भले ही पुनर्प्राप्ति मॉडल (sys.databases द्वारा निर्दिष्ट) भरा हुआ हो, लेकिन आपने एक नहीं लिया है डीबी/लॉग बैकअप पूर्ण पुनर्प्राप्ति मॉडल को सक्षम करने के बाद से (या डीबी बनाने के बाद से), डेटाबेस कई पहलुओं में व्यवहार करेगा जैसे कि यह अभी भी साधारण पुनर्प्राप्ति मॉडल में था।
साधारण पुनर्प्राप्ति मॉडल के तहत किसी फ़ाइल को हटाने के योग्य होने के लिए केवल यह आवश्यक है कि वर्तमान चेकपॉइंट LSN (अंतिम चेकपॉइंट का LSN) फ़ाइल को हटाने वाले डिलीट ऑपरेशन के LSN से अधिक हो। इसलिए 40,000 पंक्तियों को हटाने के बाद आप केवल एक CHECKPOINT स्टेटमेंट जारी करके प्रतीक्षा कर सकते हैं।
जब डेटाबेस "वास्तव में पूर्ण" पुनर्प्राप्ति मॉडल में होता है तो चीजें अधिक जटिल हो जाती हैं। यदि ऐसा है, तो चेकपॉइंट एलएसएन के अतिरिक्त, बैकअप एलएसएन (अंतिम लॉग बैकअप का एलएसएन) हटाए गए एलएसएन से पहले होना चाहिए। इसके अलावा, जीसी 2 चरणों में काम करता है:पहले पास पर यह केवल हटाने के लिए एक फ़ाइल को चिह्नित करता है लेकिन इसे भौतिक रूप से हटा नहीं देता है। केवल जब GC दूसरी बार फ़ाइल को संसाधित करता है तो वह फ़ाइल डिस्क से भौतिक रूप से हटा दी जाएगी। चीजों को और भी दिलचस्प बनाने के लिए, जीसी का पहला पास डिलीट एलएसएन को "रीसेट" करता है, इसलिए दूसरा पास केवल तभी फाइल को प्रोसेस कर सकता है जब चेकपॉइंट एलएसएन और बैकअप एलएसएन पहले जीसी पास के एलएसएन से बड़ा हो।
यदि आप वास्तव में जानना चाहते हैं कि सिस्टम में क्या चल रहा है, तो आप एक विशेष आंतरिक "टॉम्बस्टोन" तालिका को देखकर वर्तमान जीसी प्रगति का ट्रैक रख सकते हैं। हर बार डेटाबेस से एक फ़ाइलस्ट्रीम मान हटा दिया जाता है, इस तालिका में एक समाधि का पत्थर डाला जाता है। डिस्क से फ़ाइल हटाए जाने के बाद ही समाधि का पत्थर हटाया जाता है। समाधि का पत्थर तालिका का नाम है sys.filestream_tombstone_ जहां कुछ संख्या है। आप निम्न क्वेरी का उपयोग करके सटीक नाम प्राप्त कर सकते हैं:
select name from sys.internal_tables where name like '%tombstone%'
चूंकि यह एक आंतरिक तालिका है, इसलिए इसे पूछने के लिए आपको DAC (समर्पित व्यवस्थापक कनेक्शन) का उपयोग करके लॉग ऑन करना होगा।
उदाहरण के लिए, मान लें कि मैंने एक फ़ाइलस्ट्रीम मान वाली एक पंक्ति को हटा दिया है। अब मैं निम्नलिखित प्रश्न (डीएसी से) जारी करके समाधि की स्थिति देख सकता हूं:
select * from sys.filestream_tombstone_2073058421
पहले 3 फ़ील्ड डिलीट ऑपरेशन के एलएसएन को दर्शाते हैं, लेकिन सबसे महत्वपूर्ण स्थिति स्थिति है। लॉग बैकअप + चेकपॉइंट जारी करने और इसे कुछ सेकंड के लिए चलने देने के बाद, मैं टॉम्बस्टोन टेबल को फिर से क्वेरी करता हूं और मुझे मिलता है:
ध्यान दें कि स्थिति बदल गई है (अंतिम 2 बिट 1 से 2 में बदल जाते हैं), यह दर्शाता है कि फ़ाइल को पहले GC पास द्वारा संसाधित किया गया है। इसके अतिरिक्त, एलएसएन को पहले जीसी पास के एलएसएन के साथ अपडेट किया गया है, इसलिए दूसरे जीसी पास के लिए अंततः फाइल को हटाने में सक्षम होने के लिए, हमें नए एलएसएन के ऊपर चेकपॉइंट एलएसएन और बैकअप एलएसएन लाने की जरूरत है। मैं एक और चेकपॉइंट + लॉग बैकअप जारी करता हूं, कुछ सेकंड प्रतीक्षा करें और टॉम्बस्टोन तालिका को फिर से पूछें। यह अब खाली है और फ़ाइल डिस्क से गायब हो गई है।
ध्यान रखें कि अन्य चीजें हैं (उदाहरण के लिए प्रतिकृति, संस्करण सक्षम होने पर अन्य लेनदेन) जो विशेष फ़ाइलों को कचरा एकत्र होने से रोक सकती हैं, लेकिन ज्यादातर मामलों में चेकपॉइंट और लॉग बैकअप 2 प्रमुख हैं।
ओह, मुझे लगता है कि मैं विवरण में बहुत गहराई तक जा सकता हूं, लेकिन शायद यह जीसी व्यवहार को समझने में किसी तरह से मदद करेगा।
