База SQL весит больше чем объем всех таблиц #531825

База весит 160Гб, а объем всех таблиц 37 Гб - вместе с индексами и с unused. Что в ней еще так много весит?

лог

86 год...

а где смотрели 160гб?

чем взвешивали ?

сделай full backup, а потом shrink и буде тебе щасте!

mdf файл - 118 Гб log файл - 45 Гб В свойствах размер базы 160 Гб

пустое пространство имеет место быть, сделай шринк

в дт-шник попробуй слить базу и восстанови из него

По поводу пустого пространства: 74 Гб по свойствам. Даже учитывая его все 160 - 74 = 86 - и то в 2 раза больше чем все таблицы

где смотрели "объем" всех таблиц?

dbcc updateusage sp_spaceused

Почитай что-нибуть толковое по-поводу устройства и особенностей работы баз MS SQL. Я, в своё время, кажись статью какую-то нарыл на sql.ru Много вопросов отпало. Кратко: ldf из расчетов отбрасываем сразу, это служебная хрень. mdf кроме данных всегда содержит пустое место. По многим причинам. 1) растет он всегда с запасом, чтобы минимизировать запросы к оси на доп-место (это одна из самых медленных операций) 2) фрагментируется 3) освободившееся пространство никогда добровольно оси не возвращается (по той же причине, что и п.1) К тому же, кроме исходных данных есть еще индексы, статистика и другая служебная информация, которая тоже место занимает.

Вообще, в утилите администрирования MS SQL давным давно (в 2000 точно уже было) можно посмотреть соотношение пустого места к полезному в ldf и mdf в удобном графическом виде.

а как можно узнать какой реквизит сколько занимает места? например у меня в документе 8 реквизитов. Могу я как-то в скуле посмотреть какая колонка в таблице сколько весит?

+ еще нужно учитывать, что SQL имеет страничную структуру хранения, и во первых всегда есть пустые страницы (после транзакции), во вторых что заполнение страниц не 100% всегда есть пустое место, в среднем это около 30%

2 всегда что ли 30%? и ни от чего не зависит?

филфактори на скульных таблицах. он равен 70% по умолчанию..

нет конечно, иногда больше иногда меньше, это зависит от данных... размер страницы условно фиксированый, например 512к (точный размер я не помню), если при транзакции записывается только 10к, то после фиксации или откате (пофигу), останется 1 страница, правда она будет исползована для следующей транзакции, но если делаешь БОЛЬШУЮ транзакцию, например на 1 гиг, то этот гиг резервируется а после транзакции забиватся данными будет медлено. Кроме того те-же строки неограниченой длины если они более 2к добавляют 1 страницу, тоесть если у тебя строка 2500 символов - то 2024 будет записано в основную таблицу а под 476 будет выделена отдельная страница (512к)

2 видимо не от данных, а от .

хотя сорри, да, от данных - в связи с БЛОБАМи - тоже...

- используется только как некая стратегия (ограничивающая нижний предел), фактическое выделение страниц зависит только от данных и транзакций

размер 1ой страницы 8кб. новые страницы заполняются под значение филфактори у таблицы, которое по умолчанию равно 70%. только unused это ловить должен сносно. строки неограниченной длины в страницах данных не хранятся вообще. там хранится только ссылка на место, где это значение хранится.

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

это че значит в базе 123 Гб пустого места?

раньше - с какого места? еще с 2000 скуля так было. и какой поиск по заголовку (что сие "заголовок" значит) вас интересует?

в целом - да, хотя я думаю что реально свободного места примерно 100 гиг...

2что тебя беспокоит?

в базе 118 - 37гб пустого места у sp_spaceused есть 2 таблицы на выход database_name                                                                                                                    database_size      unallocated space -------------------------------------------------------------------------------------------------------------------------------- ------------------ ------------------ td82                                                                                                                             9240.31 MB         3199.77 MB reserved           data               index_size         unused ------------------ ------------------ ------------------ ------------------ 4367792 KB         2462520 KB         1848064 KB         57208 KB

unused и unallocated - вообще разные вещи.

в том что в базе в 40 Гб 120 Гб свободного места - это и беспокоит. Если шринкану можно выйти в итоге на 40?

2 как видишь, уже указали причины которые могут объяснить это поведение. И уже понятно что где это все написано. Следующий шаг - это понимание того, что как с этим справляться - также описано там же.

результат sp_spaceused увидеть можно?

database_size = 162654.34 unallocated space = 72219.49

1986. Этим все сказано

ну вот видите. 72 + 37 = 110 + 45 ~ 160ГБ что вы и говорите. шринк базы и вперед и с песней.

Шринк не панацея. Если хитро фрагментировано - он только чуток срезать с конца сможет. А шринк с дефрагментацией - сильно накладная операция. Я бы вообще не парился, если данные к пустому месту в mdf 1:1 А ldf - отдельная песня

dbcc updateusage уже было сделано.. поэтому хитростей поубивилось..