यदि आप ऑटो क्लीनअप सेट करते हैं, तो समय-समय पर परिवर्तन ट्रैकिंग जानकारी को स्वयं से हटाकर हटाएं और फिर प्रत्येक तालिका के लिए परिवर्तन ट्रैकिंग को फिर से सक्षम कर दें। अन्यथा, हाँ, ट्रैकिंग डेटा बढ़ने और बढ़ने के लिए जारी रहेगा।
आप सीधे अंतर्निहित तालिकाओं से पूछ नहीं सकते हैं, लेकिन आप अपने मेटाडेटा पर पोक कर सकते हैं। निम्नलिखित क्वेरी सापेक्ष पंक्ति गणना दिखाती है:
select
s.name as schema_name
, t.name as table_name
, (select sum(rows) from sys.partitions x where o.parent_object_id = x.object_id) as rows_in_base_table
, o.name as tracking_table
, p.rows as rows_in_tracking_table
from sys.objects o
join sys.tables t on o.parent_object_id = t.object_id
join sys.schemas s on t.schema_id = s.schema_id
join sys.partitions p on o.object_id = p.object_id
where o.name like 'change[_]tracking%'
and o.schema_id = schema_id('sys')
order by schema_name, table_name
अपने डेटाबेस में चलाएं, और आपको वर्तमान ओवरहेड का मोटा होना चाहिए।
परिवर्तन ट्रैकिंग टेबल सभी मानक स्कीमा का पालन करते हैं। उदाहरण के लिए:
select
c.name, c.column_id
, type_name(user_type_id) as type_name
, c.max_length, c.precision, c.scale
, c.is_nullable, c.is_identity
from sys.columns c
where object_id = (
select top 1 object_id from sys.objects o
where o.name like 'change[_]tracking%'
and o.schema_id = schema_id('sys')
)
k_% कॉलम तालिका द्वारा भिन्न होते हैं और ट्रैक की गई तालिका की प्राथमिक कुंजी से मेल खाते हैं। आप प्रति पंक्ति 18 बाइट्स + (प्राथमिक कुंजी लंबाई) के आधार पर न्यूनतम ओवरहेड देख रहे हैं। वह जोड़ता है!
उदाहरण के लिए, मैं कुछ पतली बेस टेबलों को ट्रैक कर रहा हूं जो 7-बाइट समग्र कुंजी के साथ केवल 15 बाइट चौड़े हैं। इससे ट्रैकिंग टेबल 18 + 7 = 25 बाइट चौड़े होते हैं!
स्रोत
2010-09-29 05:00:47
प्रश्नों के लिए +1 ... मुझे कुछ काम बचाया। धन्यवाद – RThomas
यहां तक कि एक 100 बाइट पंक्ति आपको दस लाख पंक्तियों के बाद केवल 100 एमबी प्राप्त करेगी, इसलिए मुझे आपका उदाहरण _too_ महत्वपूर्ण नहीं दिख रहा है, हालांकि मुझे लगता है कि यह प्रति तालिका ट्रैक होने पर बहुत कुछ हो सकता है। कृपया मुझे सुधारें अगर मैं गलत हूं। –
@ सahuगिन: मेरे मामले में, तालिका के अधिकांश 10% मानते हुए दो दिन की खिड़की में अपडेट हो जाता है, मुझे परिवर्तन ट्रैकिंग के लिए 0.1 * (25/15) = 16.7% स्टोरेज ओवरहेड होता है। नहीं, यह भयानक नहीं है - तुलना करके, कोई भी सूचकांक कम से कम (7/15) = 46.7% होगा। अनिश्चितकालीन प्रतिधारण, हालांकि - इसका खर्च 166% होगा। इसके अलावा, अगर परिवर्तन तालिका डेटा संपीड़न का उपयोग करती है, तो मैं अपने सिर के शीर्ष से नहीं जानता, लेकिन यदि वे नहीं करते हैं, और यदि मेरी तालिका * संपीड़ित है, तो प्रतिशत बहुत अधिक हो जाते हैं। –