Несоответствие размера таблицы SQL Server

Надо надеяться, это имеет простой ответ, и я пропустил что-то очевидное. У меня есть таблица, где количество строк * размер строки намного меньше затем фактическое пространство данных, используемое таблицей.

Если я выполняю стандартный отчет "Использование диска Главными столами", числа, которые я получаю:

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

который (если я не пропускаю что-то) подразумевает, что каждая строка поднимает чуть менее чем 1 МБ!

Схема таблицы (который я не разработал):

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
)

Это не имеет никаких индексов или ключей.

Немного исследования приводит меня к идее, что, возможно, в прошлом таблица имела столбцы переменной длины, которые были удалены, таким образом, я выполнил DBCC CLEANTABLE без изменения.

2005 SQL Server x64 Пакет обновления 3 (насколько я могу работать из следующей строки версии:

[Microsoft SQL Server 2005 - 9.00.4053.00 (X64) 26 мая 2009 14:13:01 Copyright (c) 1988-2005 Microsoft Corporation, Enterprise Edition (64-разрядный) на Windows NT 5.2 (создают 3790: пакет обновления 2)]

Обновление: я абсолютно уверен, что это происходит из-за патологически фрагментированной "КУЧИ".... Я восстановил путем применения кластерного индекса (индекс требуется, согласно недостающим индексным отчетам), и несоответствие размера пошло.

6
09.02.2012, 11:10
2 ответа

Когда Вы удаляете из "кучи", выделенное место не может быть освобождено, если Вы не используете блокировку таблицы. См., что "Строки удаления от "кучи"" от УДАЛЯЮТ на MSDN

Это - отдельная проблема к фрагментации (который происходит, конечно),

На всякий случай Вы попробовали это для обновления информации об использовании?

EXEC sp_spaceused 'MySchema.MyTable', 'true'

Без индексов или ключей, Вы не можете обычно дефрагментировать его.
Можно добавить/отбросить кластерный индекс или сделать что-то вроде этого

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';

ой: просто замеченные обновления, мой Интернет был поврежден на и прочь...

6
22.02.2020, 22:34
  • 1
    был самым близким ответом на то, что я закончил выполнение (я на самом деле создал кластерный индекс: не было никакой причины, почему эта таблица была "кучей", и недостающий индекс был необходим в поиске диапазона), –  Mitch Wheat 12.02.2012, 05:11

Я использую этот сценарий:

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

Это дает Вам средний размер строки на таблицу, а также данные, которые Вы показали выше, но я склонен доверять его выводу немного больше, чем встроенные отчеты :)

2
22.02.2020, 22:34
  • 1
    Спасибо, но я уже знал размеры... Встроенные отчеты кажутся довольно хорошими. Я был бы удивлен, не использовали ли они что-то подобное... –  Mitch Wheat 09.02.2012, 11:12

Теги

Похожие вопросы