2013-02-06 12 views
5

Ho un database MS SQL Server 2008 su un hosting condiviso e ho bisogno di ridurre lo spazio di archiviazione utilizzato il più possibile. Il mio tavolo più grande ha la seguente definizione:Dimensioni file overhead

CREATE TABLE [stage](
    [station_id] [smallint] NOT NULL, 
    [time_utc] [smalldatetime] NOT NULL, 
    [stage_mm] [smallint] NOT NULL, 
CONSTRAINT [PK_stage] PRIMARY KEY CLUSTERED ([station_id] ASC,[time_utc] ASC) 

ho cercato di scoprire il numero medio di byte per record nella mia tavola. Secondo la teoria la dimensione dovrebbe essere: 4B (intestazione riga) + 2B (smallint) + 4B (smalldatetime) + 2B (smallint) che è 12 byte.

Tuttavia, quando ho eseguito il comando:

dbcc showcontig ('stage') with tableresults 

Essa mostra: MinimumRecordSize = 15, MaximumRecordSize = 15 Quindi, secondo SQL Server, i byte per record è 15 e non 12 il numero 15 byte per record sembra anche corretto quando guardo lo spazio totale su disco preso dalla tabella e lo divido per numero di righe.

Cosa sta occupando i 3 byte extra ???

risposta

5

Questi 3 extra provengono dalla bitmap NULL. According to Paul's post, è su ogni riga, salvo per quelli che sono tutti SPARSE tra le colonne (a partire da SQL Server 2008).

E in base a una riga in this BOL post, la bitmap NULL è = 2 + ((numero_columns_in_clustered_index + 7)/8). Nel tuo caso, 3.

+0

Grazie per la spiegazione. Sembra quindi che nel mio caso sia impossibile ridurre l'overhead di riga in SQL Server 2008 a meno di 7 byte. – jirikadlec2

1

Sono parzialmente d'accordo con @Matt, i 2 byte sono necessari per NULL bitmap che è corretto.

Tuttavia, l'ultimo byte viene consumato dal numero di colonne per bit. Significato, se ho 6 colonne nella mia tabella, allora avrò bisogno di 1 byte (6 bit), o Se avrò 12 colonne, allora avrò bisogno di 2 byte (12 bit).

Nel caso ci sono 3 colonne quindi ha preso solo 1 byte.