एसक्यूएल सर्वर: रिकार्ड आकार बड़ा अपेक्षा से

Question

मेरे तालिका

| Column Name | Data Type | Size 
| Value  | real  | 4 
| LogId  | int  | 4 
| SigId  | smallint | 2 

एक प्राथमिक कुंजी कॉलम LogId, SigId के लिए निर्धारित है 3 कॉलम

के होते हैं।

सभी आकारों का योग 4+4+2=10 है, हालांकि sys.dm_db_index_physical_stats का उपयोग करते हुए मुझे लगता है कि बाइट्स में औसत (और न्यूनतम/अधिकतम) रिकॉर्ड आकार 25 है। क्या कोई समझा सकता है? क्या मैं सेब और संतरे की तुलना कर रहा हूं?

Answer 1

भौतिक रिकॉर्ड लंबाई में वास्तविक कॉलम मानों के लिए आवश्यक स्थान के अतिरिक्त पंक्ति ओवरहेड शामिल है। मेरी एसक्यूएल सर्वर उदाहरण पर, मैं 17 के एक औसत रिकॉर्ड लंबाई निम्न तालिका के साथ सूचना मिलती है:

CREATE TABLE dbo.Example1(
     Value real NOT NULL 
    , LogId int NOT NULL 
    , SigId smallint NOT NULL 
    , CONSTRAINT PK_Example1 PRIMARY KEY CLUSTERED(LogId, SigId) 
); 
GO 
INSERT INTO dbo.Example1 (Value, LogId, SigId) VALUES(1, 2, 3); 
GO 
SELECT avg_record_size_in_bytes 
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID(N'dbo.Example1'),1,0,'DETAILED') 
WHERE index_level = 0; 
GO 

17 बाइट रिकॉर्ड लंबाई sys.dm_db_index_physical_stats द्वारा रिपोर्ट डेटा के लिए 10 बाइट्स, रिकॉर्ड हेडर के लिए 4 बाइट भी शामिल है, स्तंभ गणना के लिए 2 बाइट, और पूर्ण बिटमैप के लिए 1 बाइट। रिकॉर्ड संरचना के विवरण के लिए Paul Randal's Anatomy of a record article देखें।

नीचे पहले क्लस्टर सूचकांक डेटा DBCC_PAGE का उपयोग कर के रूप में गैर-दस्तावेजी (उत्पादन में इसका इस्तेमाल नहीं करते हैं) sys.dm_db_database_page_allocations तालिका-मान समारोह द्वारा निर्धारित पेज डंप करने के लिए एक स्क्रिप्ट है:

DECLARE 
     @database_id int = DB_ID() 
    , @object_id int = OBJECT_ID(N'dbo.Example1') 
    , @allocated_page_file_id int 
    , @allocated_page_page_id int; 
--get first clustered index data page 
SELECT 
     @allocated_page_file_id = allocated_page_file_id 
    , @allocated_page_page_id = allocated_page_page_id 
FROM sys.dm_db_database_page_allocations(@database_id, @object_id, 1, 1, 'DETAILED') 
WHERE 
    page_type_desc = N'DATA_PAGE' 
    AND previous_page_page_id IS NULL --first page of clustered index; 
--dump record 
DBCC TRACEON(3604); 
DBCC PAGE(@database_id,@allocated_page_file_id,@allocated_page_page_id,1); 
DBCC TRACEOFF(3604); 
GO 

यहाँ से एक अंश है भौतिक रिकॉर्ड संरचना क्षेत्रों के साथ मेरी उदाहरण पर परिणाम बाहर बुलाया:

DATA: 


Slot 0, Offset 0x60, Length 17, DumpStyle BYTE 

Record Type = PRIMARY_RECORD  Record Attributes = NULL_BITMAP Record Size = 17 

Memory Dump @0x0000002262C7A060 

0000000000000000: 10000e00 02000000 03000000 803f0300 00  .............?... 
        |  |  | |  | |null bitmap (1 byte) 
        |  |  | |  |column count (2 bytes) 
        |  |  | |Value column data (4-byte real) 
        |  |  |SigId column data (2-byte smallint) 
        |  |LogId column data (4-byte int) 
        |Record header (2-byte record type and 2 byte offset to null bitmap) 

क्यों अपने वास्तविक रिकॉर्ड लंबाई 25 के बजाय 17 इस उदाहरण में है के रूप में, संभावित कारण के बाद तालिका था स्कीमा परिवर्तन किए गए है शुरुआत में रचना मार्टिन के रूप में एड ने अपनी टिप्पणी में सुझाव दिया। यदि डेटाबेस में एक पंक्ति-संस्करण अलगाव स्तर सक्षम है, तो पॉल के ब्लॉग पोस्ट में उल्लिखित अतिरिक्त ओवरहेड होगा लेकिन मुझे संदेह है कि यह कारण यहां है क्योंकि ओवरहेड 8 बाइट से अधिक होगा।