Не учитывается размер базы данных

В настоящее время у меня есть база данных размером 20 ГБ. Я запустил несколько сценариев, которые показывают для каждого размера таблиц (и другую невероятно полезную информацию, такую ​​как индексные данные), и самая большая таблица - это 1,1 миллиона записей, которые занимают 150 МБ данных. У нас менее 50 таблиц, большинство из которых занимают менее 1 МБ данных.

Посмотрев на размер каждой таблицы, я не понимаю, почему база данных не должна иметь размер 1 ГБ после сжатия. Объем доступного свободного пространства, о котором сообщает SqlServer (2005), составляет 0%. Режим журнала установлен на простой. На данный момент моя главная проблема в том, что я чувствую, что у меня есть 19 ГБ неучтенного использованного пространства. Есть ли что-то еще, что я должен посмотреть?

Обычно мне было бы все равно, и я бы сделал это пассивным исследовательским проектом, за исключением той конкретной ситуации, которая требует от нас делать резервное копирование и восстановление на еженедельной основе, чтобы разместить копию на спутнике (у которого нет Интернета, поэтому это нужно делать вручную). ). Я бы предпочел копировать 1 ГБ (или даже если бы это было до 5 ГБ!), Чем 20 ГБ данных каждую неделю.

sp_spaceused сообщает следующее:

Navigator-Production    19184.56 MB 3.02 MB

И вторая часть этого:

19640872 KB 19512112 KB 108184 KB   20576 KB

хотя я нашел несколько других сценариев (например, один из двух вопросов о размере базы данных сервера здесь, они все сообщают одну и ту же информацию, найденную выше или ниже). Скрипт, который я использую, взят из SqlTeam. Вот информация заголовка:

*  BigTables.sql
*  Bill Graziano (SQLTeam.com)
*  graz@<email removed>
*  v1.11

Несколько верхних таблиц показывают это (таблица, строки, зарезервированное пространство, данные, индекс, неиспользованные и т. Д.):

Activity    1143639     131 MB  89 MB   41768 KB    1648 KB 46% 1%
EventAttendance 883261      90 MB   58 MB   32264 KB    328 KB  54% 0%
Person  113437      31 MB   15 MB   15752 KB    912 KB  103%    3%
HouseholdMember 113443      12 MB   6 MB    5224 KB 432 KB  82% 4%
PostalAddress   48870       8 MB    6 MB    2200 KB 280 KB  36% 3%

Остальные таблицы либо одинакового размера, либо меньше. Не более 50 таблиц.

Обновление 1: - Все таблицы используют уникальные идентификаторы. Обычно int увеличивается на 1 в строке.

  • Я также переиндексировал все.

  • Я выполнил команду dbcc shrink, а также обновил использование до и после. И снова и снова. Интересно, что я обнаружил, что, когда я перезапустил сервер и подтвердил, что никто не использовал его (и никакие служебные прокси не запущены, это очень новое приложение - до недели назад), и когда я пошел, чтобы запустить сжатие, каждый время от времени это говорит о том, что данные изменились. Поиск в Google дал слишком мало полезных ответов с очевидным неприменением (это было в 1:00, и я отключил всех, так что кажется невозможным, что это действительно так). Данные были перенесены с помощью кода C #, который в основном смотрел на другой сервер и переносил события. Количество удалений, на данный момент, вероятно, меньше 50 тыс. В строках. Даже если бы эти ряды были самыми большими, это было бы не более 100 м, я бы вообразил.

  • Когда я иду к сжатию через графический интерфейс, он сообщает, что 0% доступно для сжатия, указывая, что я уже получил его настолько маленьким, насколько он думает, что может пойти.

Обновление 2:

  • sp_spaceused 'Activity' дает это (что кажется правильным на деньги):

    Активность 1143639 134488 КБ 91072 КБ 41768 КБ 1648 КБ

  • Коэффициент заполнения был 90.

  • Все первичные ключи являются целочисленными.

  • Вот команда, которую я использовал для «updateusage»:

    DBCC UPDATEUSAGE (0);

Обновление 3:

  • По запросу Edosoft: Image 111975 2407773 19262184 Похоже, что таблица изображений считает, что это часть 19GB. Я не понимаю, что это значит, хотя. Это действительно 19 ГБ или это искажено?

Обновление 4:

  • Разговаривая с коллегой, я узнал, что это из-за страниц, так как кто-то здесь также указал потенциал для этого. Единственный индекс в таблице изображений - это кластерный ПК. Это то, что я могу исправить, или мне просто нужно с этим справиться? Обычный скрипт показывает размер таблицы изображений размером 6 МБ.

Обновление 5:

  • Я думаю, что мне просто придется иметь дело с этим после дальнейших исследований. Размеры изображений были изменены, чтобы быть примерно 2-5 КБ каждый и в обычной файловой системе не занимает много места, но в SqlServer, кажется, потребляет значительно больше. Реальным ответом, в конечном счете, будет разделение этой таблицы на другой раздел или что-то подобное.
11.12.2008 08:23:20
7 ОТВЕТОВ
РЕШЕНИЕ

Попробуйте этот запрос:

SELECT object_name(object_id)  AS name, rows,  total_pages, 
  total_pages * 8192 / 1024 as [Size(Kb)]
FROM sys.partitions p
INNER JOIN sys.allocation_units a
  ON p.partition_id = a.container_id
1
22.04.2010 13:40:53

Вы пробовали команду dbcc, чтобы уменьшить каталог? Если вы перенесете все данные в пустой каталог, это тоже 20 ГБ?

База данных использует файловую систему на основе страниц, так что вы можете столкнуться с большой слабостью (пустое пространство между страницами) из-за удаления тяжелых строк: если dbms ожидает, что строки будут вставлены в это место, лучше оставить пятна открыты. Используете ли вы PK на основе unique_identifier с кластерным индексом?

0
11.12.2008 08:33:50

Вы также можете обновить использование в systables перед запуском запроса, чтобы убедиться, что они точны.

DECLARE @DbName NVARCHAR(128)
SET @DbName = DB_NAME(DB_ID())
DBCC UPDATEUSAGE(@DbName)
1
11.12.2008 08:48:21

Вы можете попробовать создать вакуум в базе данных, что может привести к значительным улучшениям в пространстве, если вы никогда не делали этого раньше.

надеюсь это поможет.

0
11.12.2008 08:58:27
Как вы делаете вакуум базы данных?
Bernhard Hofmann 11.12.2008 12:01:13
это то же самое, что и сокращение, но это слово используется в других БД, как SQLLite & postgresql
Nick Kavadias 11.12.2008 14:10:08

Вы проверили статистику в диалоге «Сжатие базы данных»? В SQL Server Management Studio (2005/2008) щелкните правой кнопкой мыши базу данных, выберите Задачи -> Сжать -> База данных. Это покажет вам, сколько места выделено для БД, и сколько этого выделенного пространства в настоящее время не используется.

0
11.12.2008 09:03:02

какой коэффициент заполнения вы используете при переиндексации? это должно быть высоко. от 90-100% в зависимости от типа данных PK. если ваш коэффициент заполнения низкий, то у вас будет много полупустых страниц, которые нельзя сжать.

1
11.12.2008 14:05:31

Вы гарантировали, что пространство не используется вашим журналом транзакций? Если вы находитесь в режиме полного восстановления, t-log не будет сжиматься, пока вы не выполните резервное копирование журнала транзакций.

0
12.12.2008 00:33:35
Да. Он установлен в простой режим, и эти файлы журналов были сжаты до приемлемого уровня (1 МБ).
Kenny Mann 12.12.2008 13:06:50