Имя: Пароль:
1C
1С v8
За 3 суток объем базы увеличился на 25Гб
0 soulectro
 
08.10.19
03:51
Конфа УТАП 11.4.9.83, платформа 8.3.13.1690, база MS SQL.

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

Трое суток назад файл базы весил 68Гб, сегодня заметил, что размер файла вырос почти на 25Гб, с чем может быть связан такой резкий и большой рост объема базы?
На что обратить внимание? В журнале регистрации ничего сверхъестественного нет.
1 seevkik
 
08.10.19
03:59
Конфа на поддержке?
Файлы хранятся в томах или в базе?
Слышал про базопузометр?
2 soulectro
 
08.10.19
04:02
(1) Конфа на поддержке, файлы базы хранятся на ссд, про базопузометр не слышал.
3 seevkik
 
08.10.19
04:07
(1) Не файлы базы, а присоединенные файлы, их можно хранить в базе или в томах на диске
4 soulectro
 
08.10.19
04:08
(3) никаких файлов присоедененных нет в базе ни в каком виде. Картинки и прочее не прикрепляем.
5 seevkik
 
08.10.19
04:08
Тогда базопузометр в руки
6 soulectro
 
08.10.19
04:08
(5) угу, спасибо за совет.
7 Fram
 
08.10.19
06:14
(0) Версионирование включено, скорее всего
8 shuhard
 
08.10.19
06:30
(0) режим архивации фулл иди симпл ?
9 Aleksey
 
08.10.19
06:37
Или кто то классификатор загрузил (адресный к примеру)
10 Nikoss
 
08.10.19
06:42
(9) классификатор на 25гб?)
11 Sserj
 
08.10.19
06:45
(10) Ну вообще полный ФИАС почти 300ГБ, так что очень даже запросто, если кто-то без отбора втянул.
12 Nikoss
 
08.10.19
07:06
(11) понял. Тяжело представляется такое количество данных
13 shuhard
 
08.10.19
07:12
(12) кладр в dbf тянут на 10 Гбайт =)
14 kzot
 
08.10.19
08:05
(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 байт)
15 seevkik
 
08.10.19
08:06
(14) 150 метров вся рашка?
16 soulectro
 
08.10.19
08:12
(7) версионирование отключено
(8) Режим архивации фулл.
17 Веселый собака
 
08.10.19
08:24
(0) Индексирование полнотекстового поиска включил, наверное.
18 vladko
 
08.10.19
08:44
(15) вся "рашка" - то 7 ГБ в архиве rar. Распаковывается в 37 ГБ.
19 ДенисЧ
 
08.10.19
08:45
Пузометром уже прошёлся?
20 ptiz
 
08.10.19
09:04
(0) Да какой-нибудь большой документ или регистр реструктуризировался.
21 unregistered
 
08.10.19
09:07
(17) И что?... Индекс ППД хранится отдельно от базы. Его размер никак не влияет на размер базы.
22 unregistered
 
08.10.19
09:11
Только пузомер покажет точно.

Возможные причины - рост таблиц итогов какого-нибудь регистра или сразу нескольких регистров.
Например, кто-нибудь опечатался, завёл и провёл документ сильно ранней датой или наоборот сильно далёкой. Например, 1019-м годом, 2119-м. Если итоги рассчитываются без ограничения периода, то регламент автоматического пересчета итогов (есть в типовых) рассчитал вам итоги на пару сотен лет вперёд или назад.
23 Vstur
 
08.10.19
09:37
(22) +1
Тоже ставлю на итоги
24 Fram
 
08.10.19
10:08
(16) > Режим архивации фулл

может тогда план архивирования перестал работать?
25 trk415e76
 
08.10.19
10:08
(23) + 1
Итоги. Была аналогичная ситуация, бух внесла документ 0019 годом. Итоги пересчитывались сутки, пришлось прервать. Раскопки выявили много интересных документов, практически одногодков Христа.
26 shuhard
 
08.10.19
10:10
(0) все версии возможны:
- итоги
- ldf
- классификатор

пока от ТС нет обратной связи гадать нечего
27 soulectro
 
09.10.19
08:03
Прошелся пузомером, в чем выражется пузатость?

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

Себестоимость товаров (СебестоимостьТоваров)        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
28 Cyberhawk
 
09.10.19
08:12
"файл базы весил 68Гб, сегодня заметил, что размер файла вырос почти на 25Гб" // Покажи на картинке
29 piter3
 
09.10.19
08:15
А замеры времени разве не чистится периодически?
30 Dmitry1c
 
09.10.19
08:16
(0) включили версионирование? +)
31 JeHer
 
09.10.19
08:40
Изменения в план обмена какие-нибудь.
32 Фрэнки
 
09.10.19
08:58
(27) по этому перечню не видно на чем вырос размер.

А по чем смотришь? По размеру каталога, в котором размещается файл-СУБД базы? Или по самому файлу?
33 soulectro
 
09.10.19
09:31
(28) Какую картинку показать? подключился к серверу, в проводнике посмотрел содержимое папки Data на SSD диске, где хранятся базы. Увидел размер файла базы 68Гб. Те же действия проделывал спустя 3 дня, посмотреть размеры лог файлов и обнаружил, что файл базы стал 92Гб.
(30) версионирование отключено
(31) изменений в план обмена не вносили

(32) ответил выше, по самому файлу .mdf
34 soulectro
 
09.10.19
09:34
Попробовал пузомером сформировать отчет по "Таблицы БД" с расчетом объема таблиц, валится с ошибкой "Время ожидания запроса истекло"...
35 Smile 8D
 
09.10.19
09:46
(34) Посмотри размеры таблиц на скуле. Потом найди синонимы этих таблиц (обработкой или кодом).
36 soulectro
 
09.10.19
09:46
(29) развернул бэкап, который был до роста базы, запустил позомер, и там вообще нет замеров времени.
37 JeHer
 
09.10.19
10:03
(33)>>>изменений в план обмена не вносили

Не в том смысле.
Может, завели новое рабочее место, создали Правило обмена без явных отборов, а УТАП с дуру записал изменения для этого узла. У меня таблица изменений только для регистра "Коды подключаемого оборудования" весит 14 Гб + индекс 14 Гб. Ломаю голову, как безболезненно сократить рост таких таблиц.
38 soulectro
 
09.10.19
10:06
(37) нет, такого точно не было, т.к. эта база используется для оптового учета, синхронизация только с БП и то в одну сторону.
39 soulectro
 
09.10.19
10:08
TableName               TotalRows        TotalSpaceKB   UsedSpaceKB     UnusedSpaceKB
_InfoRg19063    dbo    67966             63441720    63437976    3744
40 ДенисЧ
 
09.10.19
10:10
InfoRg19063 - это кто?
41 unregistered
 
09.10.19
10:10
(39) Ну и что это за регистр сведений?
42 soulectro
 
09.10.19
10:13
(41) вот как узнать что это за регистр?
43 dezss
 
09.10.19
10:14
(42) -> (35)
44 dezss
 
09.10.19
10:15
ПолучитьСтруктуруХраненияБазыДанных()
45 soulectro
 
09.10.19
10:18
(44) сорри, но я не программист, и врядли в рабочей базе это можно провернуть )
46 soulectro
 
09.10.19
10:24
РегистрСведений.ДвоичныеДанныеФайлов этот регистр
47 ДенисЧ
 
09.10.19
10:24
(45) Позови программиста )))
Или в табло (сервис - Табло) напиши ПолучитьСтруктуруХраненияБазыДанных().ВыбратьСтроку()
48 ДенисЧ
 
09.10.19
10:25
(46) Вот и ответ. Кто-то несколько порносериалов (или всю игру престолов ))) ) зафигачил в базу
49 DrWatson
 
09.10.19
10:25
(45) Возьми готовую обработку. Нашел в гугле:
https://ausevich.ru/wp-content/uploads/2016/05/GetDatabaseStructure_v2.epf
50 soulectro
 
09.10.19
10:26
(49) её и заюзал )
51 Джо-джо
 
09.10.19
10:26
(46) все врут (с) Дохтор Хата
52 pechkin
 
09.10.19
10:28
какой прирост файла с тоит в скл?
53 pechkin
 
09.10.19
10:29
какой процент заполнения файла?
54 soulectro
 
09.10.19
10:30
(52) 1% unlimited
55 pechkin
 
09.10.19
10:38
(46) а кто-то говорил что файлов в базе нет
56 soulectro
 
09.10.19
10:40
(55) да пробзделся, вообще из головы вылетело, что товароведы сканы к алкашке туда пихают :(( сорян, что ввел в заблуждение.
А как сделать, чтобы присоединяемые файлы хранились не в базе, а на каком-нибудь томе отдельно?
57 pechkin
 
09.10.19
10:41
там настройка есть такая
58 AlexPR111
 
09.10.19
10:42
В журнале регистрации поставь отбор по данным на этот регистр, и начинай расследование.
59 AlexPR111
 
09.10.19
10:45
Администрирование -> Настройки работы с файлами -> Хранить файлы в томах на диске
60 soulectro
 
09.10.19
10:46
(59) Спасибо, нашел уже.
61 soulectro
 
09.10.19
10:47
Всем огромное спасибо за помощь!
62 unregistered
 
09.10.19
11:00
(56) >> как сделать, чтобы присоединяемые файлы хранились не в базе, а на каком-нибудь томе отдельно?

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

Там надо очень внимательно и осторожно всё настраивать по правам доступа на эту папку, если собрался файлы вне базы хранить. Ну и помнить, что при восстановлении из резервной копии базы могут появиться файлы ни на что не ссылающиеся в базе.
63 strange2007
 
09.10.19
11:05
(62) Тоже сторонник монолитности. Стоимость жёсткого диска гораздо меньше стоимости сопровождения проблем и разгребания косяков
64 soulectro
 
09.10.19
11:11
(62) (63) Судя по всему разжиться доп. хадом выходит проще и дешевле.
65 JeHer
 
09.10.19
11:12
(62) всё зависит от задачи: если много удаленных филиалов, то, лучше эти файлы хранить на каждом отдаленном сервере. Тормозов будет меньше, когда "товароведы сканы к алкашке туда пихать" начнут, а потом их же печатать.
66 JeHer
 
09.10.19
11:13
(65) ну и пилить придётся хранение и поиск этих файлов на клиенте.
67 soulectro
 
09.10.19
11:14
(65) эта база в единственном варианте, у нас один офис без филиалов.
68 pechkin
 
09.10.19
11:15
не забывай папочку бэкапить
69 soulectro
 
09.10.19
11:16
(68) это само собой, все бэкапится, на внешнее хранилище.
70 seevkik
 
09.10.19
11:22
Всего-то, а заварили сыр-бор будто хата горит)
71 piter3
 
09.10.19
11:25
А в (4) что.Автор
72 dmpl
 
09.10.19
11:46
(62) Права на папочку даются ТОЛЬКО учетной записи, от которой работает сервер 1С. Никакой шифровальщик не зашифрует. Все остальные проблемы тоже пропадают - случайно почистить не получится. Ну и регламенты на что? Админ может случайно почистить базы на SQL сервере с таким же успехом.

(63) Вот надо тебе внести изменения в боевую базу. И ты ждешь, пока 100500 гигов приложенных файлов бэкапятся...
73 unregistered
 
09.10.19
11:53
(65) >> всё зависит от задачи...
А никто и не спорит.
74 unregistered
 
09.10.19
12:06
(72) >>  Права на папочку даются ...

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

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

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

Для этого есть регламент внесения изменений в конфигурацию продуктива, который должен быть спланирован таким образом, чтобы изменения накатывались после создания резервных копий.
Это не должно происходить посреди рабочего дня с изготовлением какого-то внеочередного бекапа.
Если же речь идёт о работе приглашенного нештатного спеца, который не может ждать до вечера, то в таких базах (за которыми нет штатного надсмотрщика - прога или админа) хранение файлов должно быть только внутри базы.
75 dmpl
 
09.10.19
12:17
(74) За время создания бэкапа пользователи данные в базе могут изменить, и чем дольше бэкап делается - тем больше могут поменять. Поэтому тот бэкап, что делается периодически, непригоден для обновления, если только перед его началом не выгнать всех пользователей. Которые будут вынуждены в это время бездействовать. В таком случае он ничем не отличается от внеочередного бэкапа.
76 dmpl
 
09.10.19
12:18
+(75) И да, по-хорошему, бэкап еще надо проверить на возможность восстановления, потому как совсем не факт, что в случае сбоя он развернется корректно. А это тоже время простоя.
77 unregistered
 
09.10.19
12:40
(75) (76) Эти замечания в равной степени справедливы вне зависимости от того где и как хранятся файлы.
Ты же не будешь накатывать изменения "на живую", когда у тебя архив базы есть, а архив папки с файлами недельной давности?... Впрочем, читая твои сообщения, я в этом не уверен :(
78 pechkin
 
09.10.19
13:11
(74) ценность инфы из файлов куда ниже чем данных.
79 pechkin
 
09.10.19
13:12
опять же для разработчиков базы будут поменьше
80 shuhard
 
09.10.19
13:15
(78) по разному бывает, бэкапить нужно всё
81 pechkin
 
09.10.19
13:23
(80) нужно, но ценность все равно разная
82 dmpl
 
09.10.19
14:54
(77) Доступ к папке можно закрыть на время внесения изменений. В таком случае достаточно планового бэкапа файлов. А для параноиков в раздельном хранении есть плюс: бэкап базы данных и бэкап файлов можно делать параллельно на разные устройства, что сокращает время.
83 unregistered
 
09.10.19
15:47
(78) (81) Чистой воды твои личные домыслы, которые ты с банкой вазелина будешь директору излагать после того, как он из-за отсутствия или некорректности какого-нибудь файлика со сканом алкашного сертификата будет штраф налоговой перечислять.
84 pechkin
 
09.10.19
15:49
(83) в алкашке весь обмен давно уже электронный
85 unregistered
 
09.10.19
15:54
(82) Да всё это можно предусмотреть. Суть в том, что эти все нюансы надо очень и очень внимательно учитывать, принимая решение о хранении файлов вне базы.
Как минимум это
- вопросы доступа к папке (везде где я видел настроенное хранение файлов в папках, доступ к ней имел едва ли не любой пользователь).
- вопросы архивирования этой папки.
- вопросы синхронизации архивов БД с архивами файлов.

А если ценность файлов достаточно высока, то решив указанные вопросы, выясниться что никакого выигрыша от хранения файлов отдельно (кроме проблем со всеми этими настройками) ты не получаешь. Ну разве что повышается скорость создания архива за счет возможности запуска создания бекапа параллельно - базы и папки с файлами. Потребность реально нужная раз в 100 лет. (ведь вы же не накатываете изменения в продуктив каждый день посреди рабочего дня...).
86 dmpl
 
09.10.19
15:56
(85) Если база работает круглосуточно - то простой пока выполняется бэкап - это убыток. Когда бы ты не накатывал обновления.
87 unregistered
 
09.10.19
15:57
(84) Пример в (83) условный.
Главная ценность любой БД - согласованность и целостность данных.
Хранение файлов вне БД эту ценность ставит под угрозу.
Все описанные способы обхода этого недостатка - не более чем заплаты той или иной степени надёжности, не гарантирующей 100%-ной согласованности.

Обсуждать что-либо дальше смысла не вижу. Уже по третьему кругу пошли )))).
88 unregistered
 
09.10.19
15:59
(86) Спасибо кэп )))

Поэтому в таких базах обновления накатываются крайне редко и в специально отведённое заранее запланированное время. С предварительным тщательным тестированием любых вносимых изменений.
89 pechkin
 
09.10.19
16:04
(87) тут целостность нужна не 1к1, а такая чтобы файлы >= данные
90 pechkin
 
09.10.19
16:05
опять же тк 1с не умеет в файловые группы, то держать большие файлы на быстрых дисках - это расточительно
91 dmpl
 
09.10.19
19:08
(88) И именно поэтому скорость бэкапа (как самого бэкапа, так и его восстановления) является критичным параметром, в отличие от надуманных сложностей с поддержанием синхронности данных.
92 Креатив
 
09.10.19
22:54
Ещё иногда после обновления размер базы увеличивается.
Намедни ЗУП 3.1 обновлял. До обновления файл весил 4,5 Гига, после - 8.
В ТИИ последние два пункта сделал, 4,6 Гига.
93 Cyberhawk
 
10.10.19
07:44
(33) Картинку с цитатой
94 DrZombi
 
гуру
10.10.19
08:44
(0) Смотри на SQL, что именно выросло, либо БАЗА, либо Журнал транзакций :)
Есть два вида языков, одни постоянно ругают, а вторыми никто не пользуется.