Конфа УТАП 11.4.9.83, платформа 8.3.13.1690, база MS SQL.

Доброго времени!

Трое суток назад файл базы весил 68Гб, сегодня заметил, что размер файла вырос почти на 25Гб, с чем может быть связан такой резкий и большой рост объема базы?
На что обратить внимание? В журнале регистрации ничего сверхъестественного нет.

Конфа на поддержке?
Файлы хранятся в томах или в базе?
Слышал про базопузометр?

(1) Конфа на поддержке, файлы базы хранятся на ссд, про базопузометр не слышал.

(1) Не файлы базы, а присоединенные файлы, их можно хранить в базе или в томах на диске

(3) никаких файлов присоедененных нет в базе ни в каком виде. Картинки и прочее не прикрепляем.

Тогда базопузометр в руки

(5) угу, спасибо за совет.

(0) Версионирование включено, скорее всего

(0) режим архивации фулл иди симпл ?

Или кто то классификатор загрузил (адресный к примеру)

(9) классификатор на 25гб?)

(10) Ну вообще полный ФИАС почти 300ГБ, так что очень даже запросто, если кто-то без отбора втянул.

(11) понял. Тяжело представляется такое количество данных

(12) кладр в dbf тянут на 10 Гбайт =)

(12) https://fias.nalog.ru/Updates.aspx

БД ФИАС от 07.10.2019    
fias_delta_dbf.rar
(размер 11 173 377 байт)    
fias_delta_xml.rar
(размер 10 316 013 байт)    
fias_dbf.rar
(размер 7 274 692 621 байт)    
fias_xml.rar
(размер 6 360 085 518 байт)    
Base.arj
(размер 66 242 418 байт)    
Base.7z
(размер 36 710 326 байт)

(14) 150 метров вся рашка?

(7) версионирование отключено
(8) Режим архивации фулл.

(0) Индексирование полнотекстового поиска включил, наверное.

(15) вся "рашка" - то 7 ГБ в архиве rar. Распаковывается в 37 ГБ.

Пузометром уже прошёлся?

(0) Да какой-нибудь большой документ или регистр реструктуризировался.

(17) И что?... Индекс ППД хранится отдельно от базы. Его размер никак не влияет на размер базы.

Только пузомер покажет точно.

Возможные причины - рост таблиц итогов какого-нибудь регистра или сразу нескольких регистров.
Например, кто-нибудь опечатался, завёл и провёл документ сильно ранней датой или наоборот сильно далёкой. Например, 1019-м годом, 2119-м. Если итоги рассчитываются без ограничения периода, то регламент автоматического пересчета итогов (есть в типовых) рассчитал вам итоги на пару сотен лет вперёд или назад.

(22) +1
Тоже ставлю на итоги

(16) > Режим архивации фулл

может тогда план архивирования перестал работать?

(23) + 1
Итоги. Была аналогичная ситуация, бух внесла документ 0019 годом. Итоги пересчитывались сутки, пришлось прервать. Раскопки выявили много интересных документов, практически одногодков Христа.

(0) все версии возможны:
- итоги
- ldf
- классификатор

пока от ТС нет обратной связи гадать нечего

Прошелся пузомером, в чем выражется пузатость?

Это например самые толстые регистры накопления:

Себестоимость товаров (СебестоимостьТоваров)        3 582 157
Выручка и себестоимость продаж (ВыручкаИСебестоимостьПродаж)        2 857 790
Товары на складах (ТоварыНаСкладах)        1 854 639
Товары организаций (ТоварыОрганизаций)        1 853 929
Свободные остатки (СвободныеОстатки)        1 852 372
Алкогольные товары организаций (бухгалтерский учет) (алкТоварыОрганизацийБухгалтерскийУчет)        1 808 846

А это регистры сведений:

Замеры времени (ЗамерыВремени)        2 024 786
История адресных объектов (ИсторияАдресныхОбъектов)        1 701 121
Суммы документов в валюте регл. учета (СуммыДокументовВВалютеРегл)        1 610 653
Адресные объекты (АдресныеОбъекты)        1 356 417
Дома здания строения (ДомаЗданияСтроения)        1 260 154
Хранилище акцизных марок (КТ-2000) (алкХранилищеАкцизныхМарок)        953 385

"файл базы весил 68Гб, сегодня заметил, что размер файла вырос почти на 25Гб" // Покажи на картинке

А замеры времени разве не чистится периодически?

(0) включили версионирование? +)

Изменения в план обмена какие-нибудь.

(27) по этому перечню не видно на чем вырос размер.

А по чем смотришь? По размеру каталога, в котором размещается файл-СУБД базы? Или по самому файлу?

(28) Какую картинку показать? подключился к серверу, в проводнике посмотрел содержимое папки Data на SSD диске, где хранятся базы. Увидел размер файла базы 68Гб. Те же действия проделывал спустя 3 дня, посмотреть размеры лог файлов и обнаружил, что файл базы стал 92Гб.
(30) версионирование отключено
(31) изменений в план обмена не вносили

(32) ответил выше, по самому файлу .mdf

Попробовал пузомером сформировать отчет по "Таблицы БД" с расчетом объема таблиц, валится с ошибкой "Время ожидания запроса истекло"...

(34) Посмотри размеры таблиц на скуле. Потом найди синонимы этих таблиц (обработкой или кодом).

(29) развернул бэкап, который был до роста базы, запустил позомер, и там вообще нет замеров времени.

(33)>>>изменений в план обмена не вносили

Не в том смысле.
Может, завели новое рабочее место, создали Правило обмена без явных отборов, а УТАП с дуру записал изменения для этого узла. У меня таблица изменений только для регистра "Коды подключаемого оборудования" весит 14 Гб + индекс 14 Гб. Ломаю голову, как безболезненно сократить рост таких таблиц.

(37) нет, такого точно не было, т.к. эта база используется для оптового учета, синхронизация только с БП и то в одну сторону.

TableName               TotalRows        TotalSpaceKB   UsedSpaceKB     UnusedSpaceKB
_InfoRg19063    dbo    67966             63441720    63437976    3744

InfoRg19063 - это кто?

(39) Ну и что это за регистр сведений?

(41) вот как узнать что это за регистр?

(42) -> (35)

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

(44) сорри, но я не программист, и врядли в рабочей базе это можно провернуть )

РегистрСведений.ДвоичныеДанныеФайлов этот регистр

(45) Позови программиста )))
Или в табло (сервис - Табло) напиши ПолучитьСтруктуруХраненияБазыДанных().ВыбратьСтроку()

(46) Вот и ответ. Кто-то несколько порносериалов (или всю игру престолов ))) ) зафигачил в базу

(45) Возьми готовую обработку. Нашел в гугле:
https://ausevich.ru/wp-content/uploads/2016/05/GetDatabaseStructure_v2.epf

(49) её и заюзал )

(46) все врут (с) Дохтор Хата

какой прирост файла с тоит в скл?

какой процент заполнения файла?

(52) 1% unlimited

(46) а кто-то говорил что файлов в базе нет

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

там настройка есть такая

В журнале регистрации поставь отбор по данным на этот регистр, и начинай расследование.

Администрирование -> Настройки работы с файлами -> Хранить файлы в томах на диске

(59) Спасибо, нашел уже.

Всем огромное спасибо за помощь!

(56) >> как сделать, чтобы присоединяемые файлы хранились не в базе, а на каком-нибудь томе отдельно?

А ты точно уверен, что это правильно?
И кто потом будет отвечать, если какой-нибудь вирус-шифровальщик зашифрует тебе папочку, куда эти файлы буду складываться? Или вообще пользователь или админ случайно решат почистить эту пупку?

Там надо очень внимательно и осторожно всё настраивать по правам доступа на эту папку, если собрался файлы вне базы хранить. Ну и помнить, что при восстановлении из резервной копии базы могут появиться файлы ни на что не ссылающиеся в базе.

(62) Тоже сторонник монолитности. Стоимость жёсткого диска гораздо меньше стоимости сопровождения проблем и разгребания косяков

(62) (63) Судя по всему разжиться доп. хадом выходит проще и дешевле.

(62) всё зависит от задачи: если много удаленных филиалов, то, лучше эти файлы хранить на каждом отдаленном сервере. Тормозов будет меньше, когда "товароведы сканы к алкашке туда пихать" начнут, а потом их же печатать.

(65) ну и пилить придётся хранение и поиск этих файлов на клиенте.

(65) эта база в единственном варианте, у нас один офис без филиалов.

не забывай папочку бэкапить

(68) это само собой, все бэкапится, на внешнее хранилище.

Всего-то, а заварили сыр-бор будто хата горит)

А в (4) что.Автор

(62) Права на папочку даются ТОЛЬКО учетной записи, от которой работает сервер 1С. Никакой шифровальщик не зашифрует. Все остальные проблемы тоже пропадают - случайно почистить не получится. Ну и регламенты на что? Админ может случайно почистить базы на SQL сервере с таким же успехом.

(63) Вот надо тебе внести изменения в боевую базу. И ты ждешь, пока 100500 гигов приложенных файлов бэкапятся...

(65) >> всё зависит от задачи...
А никто и не спорит.

(72) >>  Права на папочку даются ...

Я это всё знаю. Вопрос - знает ли это автор ветки.
И кстати я ещё не упомянул проблему синхронизации архивации базы данных и архивации этой папки. Чтобы в случае тотального краха и последующего восстановления из резервных копий данные в базе соответствовали файлам в папке, а не получилось так, что архив базы на сегодняшнее утро, а архив папки с файлами недельной давности.

Короче говоря, есть целый ряд нюансов и особенностей, которые надо знать и уметь правильно всё настроить. Хранить файлы внутри БД значительно проще.

(72) >>  Вот надо тебе внести изменения в боевую базу. И ты ждешь...

Для этого есть регламент внесения изменений в конфигурацию продуктива, который должен быть спланирован таким образом, чтобы изменения накатывались после создания резервных копий.
Это не должно происходить посреди рабочего дня с изготовлением какого-то внеочередного бекапа.
Если же речь идёт о работе приглашенного нештатного спеца, который не может ждать до вечера, то в таких базах (за которыми нет штатного надсмотрщика - прога или админа) хранение файлов должно быть только внутри базы.

(74) За время создания бэкапа пользователи данные в базе могут изменить, и чем дольше бэкап делается - тем больше могут поменять. Поэтому тот бэкап, что делается периодически, непригоден для обновления, если только перед его началом не выгнать всех пользователей. Которые будут вынуждены в это время бездействовать. В таком случае он ничем не отличается от внеочередного бэкапа.

+(75) И да, по-хорошему, бэкап еще надо проверить на возможность восстановления, потому как совсем не факт, что в случае сбоя он развернется корректно. А это тоже время простоя.

(75) (76) Эти замечания в равной степени справедливы вне зависимости от того где и как хранятся файлы.
Ты же не будешь накатывать изменения "на живую", когда у тебя архив базы есть, а архив папки с файлами недельной давности?... Впрочем, читая твои сообщения, я в этом не уверен :(

(74) ценность инфы из файлов куда ниже чем данных.

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

(78) по разному бывает, бэкапить нужно всё

(80) нужно, но ценность все равно разная

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

(78) (81) Чистой воды твои личные домыслы, которые ты с банкой вазелина будешь директору излагать после того, как он из-за отсутствия или некорректности какого-нибудь файлика со сканом алкашного сертификата будет штраф налоговой перечислять.

(83) в алкашке весь обмен давно уже электронный

(82) Да всё это можно предусмотреть. Суть в том, что эти все нюансы надо очень и очень внимательно учитывать, принимая решение о хранении файлов вне базы.
Как минимум это
- вопросы доступа к папке (везде где я видел настроенное хранение файлов в папках, доступ к ней имел едва ли не любой пользователь).
- вопросы архивирования этой папки.
- вопросы синхронизации архивов БД с архивами файлов.

А если ценность файлов достаточно высока, то решив указанные вопросы, выясниться что никакого выигрыша от хранения файлов отдельно (кроме проблем со всеми этими настройками) ты не получаешь. Ну разве что повышается скорость создания архива за счет возможности запуска создания бекапа параллельно - базы и папки с файлами. Потребность реально нужная раз в 100 лет. (ведь вы же не накатываете изменения в продуктив каждый день посреди рабочего дня...).

(85) Если база работает круглосуточно - то простой пока выполняется бэкап - это убыток. Когда бы ты не накатывал обновления.

(84) Пример в (83) условный.
Главная ценность любой БД - согласованность и целостность данных.
Хранение файлов вне БД эту ценность ставит под угрозу.
Все описанные способы обхода этого недостатка - не более чем заплаты той или иной степени надёжности, не гарантирующей 100%-ной согласованности.

Обсуждать что-либо дальше смысла не вижу. Уже по третьему кругу пошли )))).

(86) Спасибо кэп )))

Поэтому в таких базах обновления накатываются крайне редко и в специально отведённое заранее запланированное время. С предварительным тщательным тестированием любых вносимых изменений.

(87) тут целостность нужна не 1к1, а такая чтобы файлы >= данные

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

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

Ещё иногда после обновления размер базы увеличивается.
Намедни ЗУП 3.1 обновлял. До обновления файл весил 4,5 Гига, после - 8.
В ТИИ последние два пункта сделал, 4,6 Гига.

(33) Картинку с цитатой

(0) Смотри на SQL, что именно выросло, либо БАЗА, либо Журнал транзакций :)