2010-08-16 3 views
5

По какой-то причине мой файл MDF - 154gigs, однако я загрузил только 7 гигабайт данных из плоских файлов. Почему файл MDF намного больше, чем фактические исходные данные?Размер файла MDF намного больше фактических данных

Подробнее:

только несколько столов с ~ 25 миллионов строк. Нет больших полей varchar (самые большие - 300, большинство из них меньше, чем varchar (50). Не очень широкие таблицы < 20 столбцов. Кроме того, ни одна из больших таблиц еще не указана. Таблицы с индексами имеют менее 1 миллиона строк. т использование голец, только VARCHAR для строк. Datatype не проблема.

Оказалось, это был файл журнала, а не файл мдф. файл MDF фактически 24gigs, который кажется более разумным, однако до сих пор большое ИМХО.

UPDATE:

Я исправил проблему с файлом LDF (журнал) путем изменения модели восстановления от полного до простого Это нормально, потому что этот сервер используется только для внутреннего развития и обработки ETL в.. Кроме того, перед тем, как перейти на SIMPLE, мне пришлось сжать файл LOG. В большинстве случаев сокращение не рекомендуется, но это был один из тех случаев, когда файл журнала никогда не становился таким большим и быстрым. Для дальнейшего ознакомления см. this

ответ

3

Может быть много причин, возможно, вы используете char (5000) вместо varchar (5000), возможно, вы используете bigints вместо int, nvarchar, когда все, что вам нужно, это varchar и т. Д. И т. Д. Возможно, вы используете много индексов для каждой таблицы, все это будет складываться. Возможно, ваши настройки автозагрузки ошибочны. Вы уверены, что это MDF, а не файл LDF?

+0

Также обратите внимание на изворотливый коэффициент заполнения по индексам. Я встречал индексы не один раз с коэффициентом заполнения 10%, а не с предполагаемыми 90%. :) –

+0

Кроме того, фрагментация индекса может быть фактором. http://www.sqlmag.com/article/tsql3/automatic-reindexing.aspx – David

+1

Я чувствую себя глупо. Это файл журнала. –

4

Поскольку MDF был выделен 154Gb или вырос до 154Gb через различные операции. Файл базы данных имеет не менее размер данных в нем, но он может быть больше, чем использованная сумма на любую сумму.

Очевидным вопросом будет как вы измеряете объем данных в базе данных? Вы использовали sp_spaceused? Вы проверили sys.allocation_units? Вы догадались?

Если использованный размер действительно 7Gb из 154Gb, тогда вы должны оставить его как есть. База данных была оценена кем-то такого размера или выросла, и, скорее всего, она будет расти. Если вы считаете, что рост или предварительная калибровка были случайными, то предыдущий пункт по-прежнему применяется, и вы должны оставить его как есть.

Если вы абсолютно уверены, что общая навигация является ошибкой, вы можете сжать базу данных со всеми negative consequences of shrinking.

+0

Хорошая информация. Я не администратор БД, но я кое-что прочитаю. Благодарю. –

0

Либо AUTO SHRINK не включен, либо начальный размер был установлен на большее значение.