Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

За 3 суток объем базы увеличился на 25Гб

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Читай всё полезное и впитывай, а нападки игнорируй. Здесь так принято. aka AMIGO
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.