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

Добавил в шапку булевый реквизит, полчаса сохраняло, на сто процентов был загружен диск и оперативная память.
по окончанию база из 9Гб, стала 16.
+5 гигов лога.

Нормальная ли это ситуация, или значит что какая-то проблема с настройкой сервера или sql?

(0) > Есть документ ... для обработки и хранения некоторой истории ... Нормальная ли это ситуация

С точки зрения SQL - нормальная. С точки зрения архитектуры системы - лютый бред.

(1) не бред. это документ с которым работают интерактивно, сохраняю предварительные результаты работы.

сохраняют

(0) шринк сделай, будет опять 9 или меньше

(4) только смысл? Гроус базы во время работы как бы ресурсов ест

(5) Свободное место на диске тоже вполне себе ресурс.

А в чем может быть причина такой реакции на добавление одного реквизита?

(7) В механике реструктуризации SQL базы в режиме по умолчанию.

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

И как там говорится... А, "стаж: 13 лет 3 месяца 16 дней"...

(0)

>> Добавил в шапку булевый реквизит, полчаса сохраняло, на сто процентов был загружен диск и оперативная память.
>> по окончанию база из 9Гб, стала 16.

HDD ?

Может быть это булевский реквизит можно заменить категорией ?

(0) Модель восстановления полная? Тогда при бэкапе должно место в журнале должно освободиться.