Início / dba / Perguntas / 12521
Accepted
Mitch Wheat
Asked: 2012-02-09 23:14:16 +0800 CST

Discrepância de tamanho da tabela do SQL Server

  • 772

Espero que isso tenha uma resposta simples e eu tenha perdido algo óbvio. Eu tenho uma tabela onde o número de linhas * o tamanho da linha é muito menor que o espaço de dados real usado pela tabela.

Se eu executar o relatório padrão "Disk Usage by Top Tables", os números que obtenho são:

# Records   Reserved (KB)      Data (KB)      Indexes (KB)      Unused (KB) 
33,245        32,962,192       31,070,264       144               1,891,784

o que (a menos que esteja faltando alguma coisa) implica que cada linha está ocupando pouco menos de 1 MB!

O esquema da tabela (que não desenvolvi) é:

CREATE TABLE [MySchema].[MyTable]
(
    [Code]     [varchar](4) NOT NULL,
    [SomeID]   [smallint] NOT NULL,
    [SomeID1]  [smallint] NOT NULL,
    [Updated]  [datetime] NOT NULL,
    [SomeId2]  [int] NULL,
    [SomeId3]  [int] NULL,
    [Somekey]  [real] NULL,
    [desc1]    [char](12) NULL,
    [colA]     [real] NULL,
    [someid4]  [char](20) NULL,
    [starttime] [real] NULL,
    [endtime]  [real] NULL,
    [duration] [real] NULL,
    [reason]   [real] NULL,
    [status]   [real] NULL,
    [category] [real] NULL,
    [comment]  [char](30) NULL,
    [ColB]     [real] NULL,
    [ColC]     [real] NULL
)

Não tem índices ou chaves.

Um pouco de pesquisa me levou à ideia de que talvez no passado a tabela tivesse colunas de comprimento variável que foram excluídas, então executei DBCC CLEANTABLE sem alterações.

SQL Server 2005 x64 Service Pack 3 (tanto quanto posso descobrir a partir da seguinte string de versão:

[Microsoft SQL Server 2005 - 9.00.4053.00 (X64) 26 de maio de 2009 14:13:01 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64 bits) no Windows NT 5.2 (Build 3790: Service Pack 2)]

Atualização : Tenho quase certeza de que isso se deve a um HEAP patologicamente fragmentado. Reconstruí aplicando um índice clusterizado (um índice é necessário, de acordo com relatórios de índice ausentes) e a discrepância de tamanho desapareceu.

sql-server sql-server-2005

2 respostas

  1. Best Answer

    Quando você exclui de heaps, o espaço alocado não pode ser desalocado, a menos que você use um bloqueio de tabela. Consulte "Excluindo linhas de uma pilha" de DELETE no MSDN

    Este é um problema separado da fragmentação (o que acontece, é claro)

    Apenas no caso, você tentou isso para atualizar as informações de uso?

    EXEC sp_spaceused 'MySchema.MyTable', 'true'

    Sem índices ou chaves, você não pode desfragmentá-lo normalmente.
    Você pode adicionar/soltar um índice clusterizado ou fazer algo assim

    SELECT * INTO [MySchema].[MyTableNew] 
FROM [MySchema].[MyTable]
-- ORDER BY something

-- if you like
EXEC sp_spaceused 'MySchema.MyTableNew', 'true'

DROP TABLE [MySchema].[MyTable];

EXEC sp_rename 'MySchema.MyTableNew', 'MyTable';

    oops: acabei de ver as atualizações, minha Internet foi quebrada e desligada...

    • 6

  2. Eu uso este script:

    CREATE TABLE #Temp
 (  [Table_Name] varchar(50),
    Row_Count int,
    Table_Size varchar(50),
    Data_Space_Used varchar(50),
    Index_Space_Used varchar(50),
    Unused_Space varchar(50) )
INSERT INTO #temp exec sp_msforeachtable 'sp_spaceused "?"'

SELECT Table_Name AS [Table], Row_Count AS [Row Count],
        dbo.strip_kb(Table_Size) / 1024 AS [Table size],
        dbo.strip_kb(Data_Space_Used) / 1024 AS [Data Space],
        dbo.strip_kb(Index_Space_Used) / 1024 AS [Index Space],
        dbo.strip_kb(Unused_Space) / 1024 AS [Unused Space],
        CASE Row_Count WHEN 0 THEN 0 ELSE dbo.strip_kb(Data_Space_Used) * 1024 / Row_Count END AS [Avg Row Size]
    FROM #temp order by Row_Count DESC

DROP TABLE #temp

    Ele fornece o tamanho médio da linha por tabela, bem como os dados que você mostrou acima, mas tendo a confiar um pouco mais em sua saída do que nos relatórios integrados :)

    • 2

relate perguntas