Работаю в УПП.

Размер БД увеличился за три часа в два раза (регламентные задания в это время не выполнялись никакие).
Средствами SQL не сжимается.

Прогнала все виды тестирования – бесполезно.

Отчего это могло произойти? И что можно предпринять для уменьшения размера?

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

тебе место жалко?

(2) конечно жалко - 140 гигов

Размер БД увеличился - mdf или ldf?

с 200 мегабайт до 400?
Может просто конфу с поддержки сняли

загрузили файлы в базу

хорошо написанный запрос кончает место на диске минут за 5 выполнения ...
пациент еще жив ?

(4) mdf

(5) на поддержке с возможностью корректировки

Reports - Standard reports - disk usage by top tables

Было бы неплохо озвучить версию SQL - MS SQL 2008, -2014, -express и PostgreSQL - это всё тоже "SQL", но земля и небо

(7) причем тут место на диске, если вопрос о размере SQL-базы?

(6) кстати да, а какая конфа - не ДО?

а прирост места как указан в настройках базы?

(12) УПП, в самом начале написано.

Бэкап есть? Развернуть во временную базу и сравнить таблички

(11)
MS SQL 2008 R2

(13)
Прирост  по 4 Гб

(6) не загружали - хранилище пустое

8.1, 8.2, 8.3?

(19)
8.3.6.2041

(14) да, что то пропустил )

ТС - вот это (1) пробовали?

или в 1С - ПолучитьСтруктуруХраненияБазыДанных()

пока разговор ниочем...

(0) есть обработка которая показывает размеры таблиц в 1С.
ее надо запустить на копии и сравнить с рабочей

(1, 10, 21, 22)
Выросли регистры
РегистрНакопления.Остатки
1. ЗаданияНаВыпуск
2. ЗаданияНаТехОперации
3. ЗаказыНаПроизводство
4. МатериалыВПроизводстве
5. НезавершенноеПроизводство
6. НезавершенноеПроизводствоБухгалтерскийУчет
7. ПотребностиЗаказовНаПроизводство
8. РазмещениеЗаказовПокупателей

Накануне (перед тем, как выросла БД) запускала регламентное задание "Пересчет итогов". Из-за этого могла вырасти? Или совпадение?

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

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

(23) а конфу не меняли?
конкретно в эти РН не добавляли измерения/ресурсы?

(23) Проверяй даты документов на аномальные значения. Типа 1260 или 3050 год.

(23) Выбрать минимальный и максимальный период из данных регистров.

(23) После пересчета итогов неплохо бы сделать реиндексацию...

(0) что было и что стало после. Размер mdf.

(0) Возможно произошло приращение БД. Можно посмотреть с помощью менеджмент студии, какое приращение установлено у БД. Если установлен фиксированный размер, то просто могло так совпасть, что произошло приращение равное размеру БД, если установлено в процентах, то значение 100% это как раз получится удвоение размера (например было 100 стало 200).

(30)
Было 78 гигов

Стало 143 гига

(32) надо проверить конкретно какое приращение стоит у файлов. и еще убедится что вырос именно мдф , а не лог файл

(32) Это он, пересчет. Написать запрос по датам остатков. Выполнить в копии и основной. Думать.

наше УПП так быстро само не росло.

Что-то типа:
ВЫБРАТЬ Количество(*) ИЗ РегистрНакопления.<Имя регистра>.Остатки(&Период)
Параметр &Период менять с интервалом в месяц.

(0) Модель восстановления какая? Для сжатия средствами SQL должна быть простая

Кладры какие обновили?

(37) Не обязательно. Фулл тоже жамкается.

+38 Хотя на столько врят ли

(39) после бэкапа.

(38)

вообще не обновляли.

У нас в УПП только производство

сделать шринк средствами скуля не предлагать????

как я себе представляю сабж:
1. 1с открывает транзакцию
2. скуль начинает добавлять файл под все данные которые записывает 1с, а по сколько с регистрами 1с работает через удаление+запись, то туда попадают даже не измененные а просто перезаписанные данные
3. 1с пересчитывает итоги (итоги занимают примерно 20...30% от базы)
4. скуль формирует новые индексы (это еще 20%)
5. 1с фиксит транзакцию
6. скуль фиксит транзакцию, при этом размер файла не уменьшается а блоки которые были перезаписаны помечаются как свободные.

так, что шринк вам в руки :)

(43)
это ничего не даст, т.к. при следующей подобной ситуации размер базы вернется в прежнее состояние.

(0)
сравните количество записей в таблицах бд и её бэкапа.

бд в 2 раза может вырасти при реструктуризации.

(44) следующая подобная ситуация будет через полгода, а делать бекапы нужно каждый день, а бекапить 70 или 140 разница есть...

и потом у автора вопрос был ПОЧЕМУ и КАК ВЕРНУТЬ, а не "как жить в будущем" :)

в любом случае есть только 2 варианта сабжа
1. в базу напихали кучу новых данных
2. это пустые блоки после огромной транзакции

по сколько автор сам написал, что делали полный пересчет итогов, я сильно склоняюсь ко второму