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

Question

В настоящее время у меня есть база данных размером 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:

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

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

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

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

• Я думаю, что мне просто придется иметь дело с этим после дальнейших исследований. Размеры изображений были изменены, чтобы быть примерно 2-5 КБ каждый и в обычной файловой системе не занимает много места, но в SqlServer, кажется, потребляет значительно больше. Реальным ответом, в конечном счете, будет разделение этой таблицы на другой раздел или что-то подобное.

Answer 1

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

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

Answer 2

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

Answer 3

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

DECLARE @DbName NVARCHAR(128)
SET @DbName = DB_NAME(DB_ID())
DBCC UPDATEUSAGE(@DbName)

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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