SPARSE को जोड़ने से तालिका बहुत बड़ी हो गई

Question

मेरे पास एक सामान्य लॉग टेबल है, लगभग 5 मीटर पंक्तियाँ।
एक "दृढ़ता से टाइप किया हुआ" फ़ील्ड है जो ईवेंट प्रकार को संग्रहीत करता है, और "लॉस टाइप किए गए" कॉलम का एक गुच्छा जिसमें डेटा प्रासंगिक होता है। यही है, उन "हारे हुए टाइप" कॉलम का अर्थ घटना के प्रकार पर निर्भर करता है।

इन स्तंभों को इस प्रकार परिभाषित किया गया है:

USER_CHAR1 nvarchar(150) null,
USER_CHAR2 nvarchar(150) null,
USER_CHAR3 nvarchar(150) null,
USER_CHAR4 nvarchar(150) null,
USER_CHAR5 nvarchar(150) null,

USER_INTEGER1 int null,
USER_INTEGER2 int null,
USER_INTEGER3 int null,
USER_INTEGER4 int null,
USER_INTEGER5 int null,

USER_FLAG1 bit null,
USER_FLAG2 bit null,
USER_FLAG3 bit null,
USER_FLAG4 bit null,
USER_FLAG5 bit null,

USER_FLOAT1 float null,
USER_FLOAT2 float null,
USER_FLOAT3 float null,
USER_FLOAT4 float null,
USER_FLOAT5 float null

प्रत्येक प्रकार के कॉलम 1 और 2 का भारी उपयोग किया जाता है, लेकिन संख्या 3 से शुरू होकर, बहुत कम घटना प्रकार इस जानकारी को प्रदान करते हैं। इसलिए मैं प्रत्येक प्रकार के कॉलम 3-5 को चिह्नित करना चाहता था SPARSE।

मैंने पहले कुछ विश्लेषण किया, और देखा कि, वास्तव में, प्रत्येक कॉलम में कम से कम 80% डेटा है null, और लगभग 100% डेटा है null। के अनुसार 40% बचत सीमा मेज , SPARSEउन पर एक बड़ी जीत होगी।

इसलिए मैं गया और SPARSEप्रत्येक समूह में कॉलम 3-5 पर लागू हुआ । अब मेरी तालिका डेटा स्पेस में लगभग sp_spaceused1.8Gb लेती है , जैसा कि रिपोर्ट किया गया है , जबकि स्पर्स करने से पहले यह 1Gb था।

मैंने कोशिश की dbcc cleantable, लेकिन इसका कोई असर नहीं हुआ।
फिर dbcc shrinkdatabase, कोई प्रभाव भी नहीं।

हैरान, मैंने हटा दिया SPARSEऔर दोहराया dbcc। तालिका का आकार 1.8Gb पर रहा।

क्या देता है?

Comments

कोशिश करेंगे और पुन: पेश करेंगे। बस यह किसी भी फर्क पड़ता है कि मेज एक ढेर है या यह एक संकुल सूचकांक है?

— मार्टिन स्मिथ

@MartinSmith एक क्लस्टर इंडेक्स है rowid int not null identity(1,1) primary key clustered।

— जीएसर्ज

Answer 1

कॉलम विरल बनाने के बाद आपको क्लस्टर किए गए अनुक्रमणिका को फिर से बनाने की आवश्यकता है। डेटा कॉलम पेज में तब तक मौजूद रहता है जब तक आप ऐसा नहीं करते हैं, जैसा कि किसी क्वेरी के साथ sys.system_internals_partition_columnsया उपयोग करके देखा जा सकता हैDBCC PAGE

SET NOCOUNT ON;
CREATE TABLE Thing 
(
ThingId int IDENTITY CONSTRAINT PK PRIMARY KEY,
USER_CHAR1 nvarchar(150) null,
USER_CHAR2 nvarchar(150) null,
USER_CHAR3 nvarchar(150) null,
USER_CHAR4 nvarchar(150) null,
USER_CHAR5 nvarchar(150) null
)
INSERT INTO Thing
SELECT REPLICATE('A',150),
       CASE WHEN number % 5 = 1 THEN REPLICATE('A',150) END,
       CASE WHEN number % 5 = 2 THEN REPLICATE('A',150) END,
       CASE WHEN number % 5 = 3 THEN REPLICATE('A',150) END,              
       CASE WHEN number % 5 = 4 THEN REPLICATE('A',150) END
FROM master..spt_values   

EXEC sp_spaceused 'Thing'

ALTER TABLE dbo.Thing ALTER COLUMN USER_CHAR2 ADD SPARSE
ALTER TABLE dbo.Thing ALTER COLUMN USER_CHAR3 ADD SPARSE
ALTER TABLE dbo.Thing ALTER COLUMN USER_CHAR4 ADD SPARSE
ALTER TABLE dbo.Thing ALTER COLUMN USER_CHAR5 ADD SPARSE

DECLARE @DynSQL NVARCHAR(MAX);

SELECT @DynSQL =  'DBCC TRACEON (3604);
                   DBCC PAGE(0, ' + LEFT(file_id,10) + ', ' + LEFT(page_id,10) + ', 3); 
                   DBCC TRACEOFF(3604); ' 
FROM Thing
CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%)
WHERE ThingId=76

EXEC(@DynSQL)    

SELECT pc.*
FROM sys.system_internals_partition_columns pc
JOIN sys.partitions p on p.partition_id=pc.partition_id
WHERE p.object_id = object_id('Thing')
AND pc.is_dropped=1

 EXEC sp_spaceused 'Thing'

ALTER INDEX PK ON Thing REBUILD;    

SELECT @DynSQL =  'DBCC TRACEON (3604);
                   DBCC PAGE(0, ' + LEFT(file_id,10) + ', ' + LEFT(page_id,10) + ', 3); 
                   DBCC TRACEOFF(3604); ' 
FROM Thing
CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%)
WHERE ThingId=76

EXEC(@DynSQL)    

SELECT pc.*
FROM sys.system_internals_partition_columns pc
JOIN sys.partitions p on p.partition_id=pc.partition_id
WHERE p.object_id = object_id('Thing')
AND pc.is_dropped=1

EXEC sp_spaceused 'Thing'

DROP TABLE Thing 

Comments

बहुत बढ़िया। क्या हमें इसे दस्तावेज़ में बग के रूप में लेना चाहिए ? "SQL सर्वर डेटाबेस इंजन इस परिवर्तन को पूरा करने के लिए निम्न प्रक्रिया का उपयोग करता है: 1) नए कॉलम को नए आकार और प्रारूप में तालिका में जोड़ता है। 2) तालिका में प्रत्येक पंक्ति के लिए, पुराने में संग्रहीत मान को अपडेट और कॉपी करता है। नए कॉलम में कॉलम। 3) पुराने कॉलम को टेबल स्कीमा से हटा देता है। 4) पुराने कॉलम द्वारा इस्तेमाल किए गए स्पेस को

— दोबारा

@ सर्ग - आह ठीक है। सहमत लगता है कि बिंदु 4 तब सही नहीं है। यह देखते हुए कि आप 12 स्तंभों के लिए ऐसा कर रहे हैं, तो आप चाहते हैं कि पुनर्निर्माण प्रत्येक स्तंभ के लिए अंतर्निहित न हो, हालांकि ऐसा लगता है कि व्यवहार सही है लेकिन दस्तावेज नहीं है।

— मार्टिन स्मिथ

@ SQLKiwi - धन्यवाद। संपन्न

— मार्टिन स्मिथ