База каждый месяц в среднем вырастает на 1 Гб.
Но за последний месяц база выросла на 13 Гб.
Как отследить за счет чего такой рост?

1С УТ 10.3 клиент-сервер на MS SQL

Посмотреть размеры табличек в текущей базе и в бэкапе

есть обработки которые показывают размер базы в целом  и конкретно по объектно.
+13 г это что выросло? mdf или log ?

Типовое обновление делали?

(0) Чего опасаешься?

(2) 13 Гб - mdf
(3) да, как раз в прошлом месяце обновил
(4) того, что она будет продолжать так расти. место быстро закончится

(5) т.е. mdf вырос на 13 Гб. Была была 34 Гб, стала 47

(6) она у тебя реально может быть и 25 Г и все 15.
скул так просто место не отдает .

(5) 1 гб в месяц - 12 гб в год. Копейки!

(8) 12 Гб в год - да.
Но 13 Гб за месяц - это много

(9)А что ты такого делал перед тем что оно так скакануло по объему?

(10) я кроме как накатил пару обновлений - ничего

полный пересчет итогов нужен

понимаю, что 47 Гб, это не реальный размер базы. На самом деле она весит примерно 25-27 Гб.
как мне ее сжать хотя бы до 35?

потом в sql посмотри доступное свободное место

(13) регистры надо закрыть, пересчитать итоги. мусор удалить. в скл сделать шринк

(15) шринк SQL мало убирает

(16) это последний этап.. ты не делаешь до этого ничего , поэтому он ничего и не убирает

(17) понял. достаточно только Пересчета итогов или Реструктуризацию таблиц тоже надо сделать?

(18) если в регистре накопления один только приход и нет расхода то нет смысла пересчитывать чтото..

(19) в каком регистре? по большинству регистров накопления есть обороты и прихода и расхода

(20) ну это уже ты смотри сам.

(18) И сжатие и переиндексация тоже
Потом - шринк, обновление статистики на sql

>> как мне ее сжать хотя бы до 35?

Зачем?

>> На самом деле она весит примерно 25-27 Гб.

Как определил?

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

>> достаточно только Пересчета итогов или Реструктуризацию таблиц тоже надо сделать?

Я бы сделал полное тестирования и исправления. Естественно на копии.
Только это будет иметь смысл в том случае, если рост действительно аномальный и ничем не обоснованный. А это определить можно только сравнив размеры таблиц, которые были до экстремального роста с теми, какие есть сейчас.

(0)
Сначала вот
http://catalog.mista.ru/public/280215/
тебе в помощь
или что-то подобное

(24)+1 в первую очередь

(0) Включить сжатие таблиц в скуле, и твоя база похудеет раз в 5-6, как минимум.

(26) включал и проделывал, не похудела ни на килограмм

(27) Ты хотя бы определился какие таблицы растут быстрее других?

(28) да, сейчас буду проверять

Результат: https://cdn1.savepice.ru/uploads/2017/9/11/a29a2c26ecc5e106f05d27686ab5de41-full.png

(30) см (19)

итоги по партиям  во много раз больше основной таблицы.

(32) т.е. итоги надо пересчитывать, правильно?

(32) +1
очевидно что регистр не закрывается

(33) пересчет итогов у тебя был при обновлении, так что толку от еще одного никакого не будет

так что мне делать?

(36) закрывать регистры

(33)документы--дополнительно--проведение по партиям. покажи эту картинку

(38) https://cdn1.savepice.ru/uploads/2017/9/11/ffcc208bf6a06b73b815649788e30642-full.png

(39) ну прям удовлетворил по полной ))

7 лет. это срок

(41) то есть мне теперь надо за 7 лет восстановить партионный учет?

начать с этого

(43) по годам, думаю, можно делать? сначала 2011, потом 2012 и т.д.
А то боюсь 7 лет надолго повиснет

(44) блин.. ты вообще не чуешь ничего..

(45) а что ему слышать, если он не понимает что нужно делать )))

(46) да. до меня только дошло.. все, умываю руки

(0) Может файлы хранят в 1с?

(48) ага, в регистрах партий

(45), (46) в смысле? не извините
да, я не очень понимаю, что нужно делать. закрыть регистры нужно. Проведение по партиям не выполнялось 7 лет.
Как я могу закрыть регистры? Запустить обработку - Проведение по партиям?

(50)+ т.е. ну извините*

(50) вряд ли поможет, но не без этого

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

а сдвинуть последовательность можно и насильно

(52) так а что может помочь? или ничего?
можно что-то сделать?
как тогда закрыть регистры?

(55) как все запущенно

(55) когда будешь закрывать, столкнешься с проблемой, что нет товара на складе. Тогда, что будешь делать ?

ну смотри сам, к примеру у тебя пришла 1 шт какого-то товара и была потом продана в течении месяца

в итоге у тебя должно быть в основной таблице 2 записи, а в итогах 0

начни с анализа ведомости по партиям и смотри какие партии у тебя висят с каких дат и почему так

пересчет итогов на некорректных данных не даст ничего - нужно править сами данные

(60) понял. в таком случае я знаю что и почему не закрывается. дело в том, что у нас весь партионный учет через одно место и я базу застал уже в таком плачевном состоянии
в таком случае мне сейчас надо формировать ведомости в разрезе всех аналитик, смотреть где что не закрыто и править все это дело?

(61) именно, иначе база будет расти в прогрессии

таблицы итогов будут переноситься из месяца в месяц и накапливаться

Можно просто обрезать и выровнять итоги.

(64) в смысле обрезать базу?

(65) да, сделать свертку и начать вести в новой базе правильно.

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

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

(61) Осталось непонятным, почему база сильно выросла только сейчас, хотя партии не закрываются уже 7 лет.

Может, итоги были не рассчитаны?

И еще. Если учет по партиям особо не нужен (7 лет никто не чесался), то зачем его восстанавливать? Проще отключить совсем и итоги удалить. И база сожмется.

(70) +100500

(69) база выросла скорее всего после типового обновления конфигурации

(70) учет по партиям нужен, но он кривой

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

наверное регистры не закрываются или может быть появились в регистрах измерения с типом "строка бесконечной длины"

в любом случае надо посмотреть на размеры таблиц, провести пересчет итогов, рееиндексацию, шринк
потом снова посмотреть на размер таблиц и БД
с жирными таблицами - разбираться и решать

(76) понял. попробую

(30) А есть какой-нибудь бэкап месячной давности чтобы сравнить размеры таблиц? Что именно за месяц выросло?

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

ахренеть 7 лет править  учет по партиям, я тут в прошлой работе 6 месц правил, чуть с ума не сошел.

(16) Хорошо, напиши команду Шринк, которую ты использовал.

Следующее: делал ли ты ТИИ, есть ли базе таблицы с суффиксом NG?

Коллеги, при свертке базы частично проблему можно избежать - скажем свернуть итоги до 01/01/2018

(83)+1. вот кстати рабочая идея. что бы не возится с 7 годами.
база сожмется, хватит еще лет 5. а потом , гляди и что лучше найдется

(84) что лучше в смысле?

Для начала, (26).

а с регистром, минут за 5 смотрится, по какому измерению не "закрывается"

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

(88) нет, своего в данном случае ничего не добавляли

(86) хорошо. обычное типовое задание сжатие таблиц мне ничем не помогает

USE [bptest]
GO
DBCC SHRINKDATABASE(N'bptest', 50, TRUNCATEONLY)

(90) понятно, значит не делал.
читай
http://catalog.mista.ru/public/114634/

(91) это тоже по-боку, ибо без бекапа, шринк ничего не сделает

(92)
Да там не в сжатии дело а в том что регистры не закрываются. Надо решать ЭТУ коренную проблему, а не гасить симптомы.

(94) он никогда не решит эту проблему.
Иначе, темы бы не было.

(95) Окей
(87) разве всего 5 минут?

(96) даже быстрее