|
За 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, что именно выросло, либо БАЗА, либо Журнал транзакций :)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |