Имя: Пароль:
1C
1С v8
Управление торговлей 11.4 - база больше 500 Гигов, начинать ли нервничать? Есть опыт?
0 lenkavovka
 
28.08.20
09:21
Всем привет!
Большая организация, больше сотни филиалов. Если раньше на тех же продажах база росла на 10-20% в год, то сейчас объём может скакнуть на 10% за месяц.
База прилично допилена разными франчами и нами, но большого размера самостоятельно добавленных объектов не видим.

Через .dt пробовали перезагружать, ощутимо не помогает.
ТИИ не сделать - за выходные не успеет, а на неделю организацию остановить никто не даст.

Поделитесь, пожалуйста, опытом и общепринятой практикой в таких случаях.
У какого какой максимальный размер УТ?

Что делать?
Глубоко копать архитектуру и данные SQL-таблиц?
Начать с 1 января работу в новой базе с чистого листа?
1 Aleksey
 
28.08.20
09:22
так а посмотреть причину? Может кто то решил хранить картинки в базе или включили историю данных
2 Aleksey
 
28.08.20
09:23
возъми копию и сравни какие таблички резко выросли
3 BeerHelpsMeWin
 
28.08.20
09:23
Посмотреть, какие таблицы весят больше всего и сделать выводы.
4 RomanYS
 
28.08.20
09:23
Полина сейчас конфигурации весят, может полтеррабайта?
5 Amra
 
28.08.20
09:23
Пол гига? Ты серьезно?
6 RomanYS
 
28.08.20
09:24
*(4) полгига
7 lenkavovka
 
28.08.20
09:25
(4) тьфу, точно - ПОЛТЕРРАБАЙТА
8 FormatC
 
28.08.20
09:28
может еще в сторону железа посмотреть, возможно пора делать апгрейд
9 Bigbro
 
28.08.20
09:31
размер базы вроде же не должен особо влиять на работу. если нет кривых каких то отчетов обработок которые данные от начала до конца времен перелопачивают.
добавляйте диски да память своевременно и пусть живет.
10 МихаилМ
 
28.08.20
09:34
ТИИ делают на копии.
размер базы влияет на скорость развертывания резервной копии.
база требует ухода. возможно не закрываются остатки.возможно неправильно настроено автоувеличение размера.
возможна дефрагментация.
11 lenkavovka
 
28.08.20
09:41
(1) Картинки в томе на диске, история версий включена. Но как оценить затраты места на историю версий?
(2),(3) - больше всего весят РегистрНакопления.СебестоимостьТоваров и РегистрНакопления.ТоварыКПоступлению. Они же и растут. Есть ещё пара самописных регистров, подумаем над их оптимизаций.
(8),(9) - железо только что проапргейдили, работает вроде вменяемо по скорости. Но пугает рост и необходимость больших объёмов для резервного копирования и технических операций.
12 lenkavovka
 
28.08.20
09:44
(10) почитаем про закрытие остатков и автоувеличение размера.
Дефрагментация SQL? Недавно переносили на новый сервер, меньше не стала.
13 Aleksey
 
28.08.20
09:47
(11) История версия - это регистр сведений
14 lenkavovka
 
28.08.20
09:49
(13) 12 гигов занимает... вроде пока терпимо.
15 Trance_1C
 
28.08.20
09:57
Была у меня такая база УПП 1.2, в таблицах документов по 5млн записей, удалять документы средствами 1С было нереально долго, о стандартной свертке можно было забыть. Быстрее всего удалить все документы из самых жирных таблиц запросами SQL за секунды удаляются миллионы документов, провести ТИИ, в регистрах автоматом будут удалены все движения без документов. После этого удалить все не используемые товары и контрагентов и другую НСИ, внести остатки на начало и вперед.
Можно (даже нужно) оставить 1год с документами, и внести остатки задним числом на начало прошлого года. Так даже надежнее потому что остатки уже не изменятся, а если начинать с чистой базы, нач. остатки будут постоянно корректироваться.
16 Галахад
 
гуру
28.08.20
10:00
(15) Тормозила, что-ли? Зачем резать-то?
17 Trance_1C
 
28.08.20
10:00
+(15) моя УПП занимала 750гб, была распределена на несколько дисков, т.е. файлы и лог базы были разделены на 20 или 30 файлов точно не помню. База летала, руководство просило свертку чтобы отчеты быстрее работали.
18 Trance_1C
 
28.08.20
10:01
1С может занимать и 5ТБ, какая вообще разница, главное правильно ее хранить на дисках, массив из ССД, разделенные файлы базы и все будет отлично.
19 Галахад
 
гуру
28.08.20
10:06
(17) Хм. Интересно. А для чего 20-30 файлов?
20 timurhv
 
28.08.20
10:23
(11) Регистр весит или таблицы остатков и текущих итогов?
21 timurhv
 
28.08.20
10:24
(20) и он был изменен по сравнению с типовым? Может добавили по измерению индексацию\доп.упорядочивание?
22 Garykom
 
гуру
28.08.20
10:29
(0) Начать с 1 января работу в новой базе с чистого листа!

Точнее заранее подготовить базу где будут остатки на 1-е января 2020 и движения за 2020 год, настроить онлайн синхронизацию с текущей полной базой и с 1 января 2021 перейти на нее гладко.
23 ptiz
 
28.08.20
10:29
(0) Если тормозов нет, работать дальше. А куда вы денетесь?
24 ptiz
 
28.08.20
10:30
(18) "разделенные файлы базы и все будет отлично." - зачем? Прекрасно базы > 1 Тб живут одним файлом.
25 assasu
 
28.08.20
10:50
чую, автор не знает ни про пересчет итогов, ни про закрытие регистров в ноль, ни про свертку
26 ptiz
 
28.08.20
10:58
(25) "не знает ни про пересчет итогов" - он уже через dt выгружал/загружал.
27 Trance_1C
 
28.08.20
11:27
(24) сегментация больших баз уменьшает нагрузку на память и диск, сиквел разные файлы перезаписывает, или читает сразу из нескольких что быстрее чем из одного большого файла, который медленнее инициализируется на дисках при обращении на запись.
28 H A D G E H O G s
 
28.08.20
11:37
(0) Попробовать запустить вот это
https://yadi.sk/d/LJ2xEA5Zj6pz9w

и посмотреть не вернет ли она какой нибудь дичи.
29 МихаилМ
 
28.08.20
12:47
(0) резервные копии бд полные, частичные или журнала делаются ?
и как часто и за какой период хранятся ?
30 craxx
 
28.08.20
13:22
(0) у нас объем базы 850 ГБ, полет нормальный. Планы обслуживания на скуле должны четко работать, тогда все будет нормально.
31 ptiz
 
28.08.20
16:24
(27) А есть какие-нибудь результаты тестов? В самом деле интересно.
32 Eiffil123
 
28.08.20
16:35
(0) если в dt при таком объеме выгружается, то значит итоги распухли. Скорее всего какой-то регистр не закрывается.
33 1Снеговик
 
гуру
28.08.20
16:47
(30) у вас тоже платны обслуживания на каких-то мега-скриптах?
Кто бы помог раз и навсегда понять периодичность и порядок обслуживания баз SQL.
34 ptiz
 
28.08.20
17:05
(33) Обычно под обслуживанием имеют ввиду реиндекс. Например: http://www.gilev.ru/dbreindex/
И обновление статистики. И настройку шага роста базы. А дальше sql сам справится :)

Бэкапы - отдельная песнь.
35 МихаилМ
 
28.08.20
17:22
(34)
все зависит от цели.
если цель администрирование -  обеспечение бесперебойной работы,
то задача намного шире - тут и производительность и надежность и резервирование.

просто реиндексация и принудительное обновление статистики - типовой шаблон , вообще бессмысленный  вне 1с8 .

А вот управление индексами - вполне живая задача, требующая периодического внимания в силу динамичного изменения состава данных
и смешанной модели 1с olap-oltp,  даже при наличии ssd .