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

Варианты для сжатия базы и увеличения производительности

Варианты для сжатия базы и увеличения производительности
Я
   slafor
 
13.12.20 - 02:33
Есть сильно переработанная конфигурации на базе УПП, в неё добавлена масса новых объектов - справочники, документы, РС, РН, даже перечисления и проч.

За несколько лет работы база сильно выросла в размере. Теперь это несколько сот гигов на SQL-сервере. Но основная часть этой информации уже не нужна. Вернее, нужна, но из этой базы нужно сделать другую, чтобы она была гораздо меньше, и не зависала при каждом вызове. И в этой новой базе будет лишь одна организация, и несколько контрагентов - поставщиков и клиентов.

Как проще и быстрее это сделать, и какой путь эффективнее? В голову приходит только два варианта:
1. Написать обработку для удаления ненужных контрагентов, и всех привязанных к ним объектов БД - документов и пр.
2. Настроить одноразовый перенос данных по нужным контрагентам из старой базы в пустую через КД 2.1. Почему 2.1? Потому что от старой УПП там остался только ооочень давнишний релиз типовой + новые объекты.

Что безопаснее, что быстрее, что эффективнее с точки зрения уменьшения объема и увеличения быстродействия?
   PR
 
1 - 13.12.20 - 03:02
Судя по твоему описанию лучше убрать от базы руки и ничего не делать, пока все работает
   slafor
 
2 - 13.12.20 - 03:05
(1) Почему?
Работать-то работает, но очень медленно.
   H A D G E H O G s
 
3 - 13.12.20 - 03:08
(2) В нормально спроектированной базе скорость не зависит от объема.
   hhhh
 
4 - 13.12.20 - 03:12
(2) удаление контрагентов ничего не даст.
   Garykom
 
5 - 13.12.20 - 04:23
(0) КД будет не оптимально, в вашем случае я бы задумался о прямой работе с sql базой
   hhhh
 
6 - 13.12.20 - 04:29
(5) если он поудаляет в sql например весь приход товара, как он потом будет там восстанавливать остатки?  Напрямую в sql?
   PR
 
7 - 13.12.20 - 04:48
(2) Потому что настораживает твоя уверенность в том, что причина тормозов в объеме базы

А в варианте поудалять лишнее или вообще перенести выборочно данные в другую базу у тебя главная проблема как это сделать побыстрее и через какой инструмент, а не мысль о том, что будет со закрытыми периодами, сданной отчетностью, обменами с другими системами и пр.

Варианта проанализировать таблицы на предмет их размера от тебя не прозвучало

В сторону анализа скорости работы базы и поиска узких мест опять же ты ничего не сказал

Даже про диск ты ничего не сказал, HDD у тебя, SSD или что

В общем только хардкор только помахать скальпелем по живой базе

Все это не говорит ничего хорошего о твоем уровне, поэтому и рекомендация лучше не соваться в это дело, наломаешь дров по неопытности
   МимохожийОднако
 
8 - 13.12.20 - 08:53
(0) Выяснить в каких местах и по каким причинам тормоза. Долго думать. Где голосовалка?
   Провинциальный 1сник
 
9 - 13.12.20 - 08:59
(8) +1
   ReaLg
 
10 - 13.12.20 - 09:11
(7) +100500
Но иногда базу резать все же есть смысл. Если инфа действительно не нужная, то обслуживать / работать с маленькой базой всегда быстрее / удобнее, чем с гигантской.
Судя по тому, что это сильно переписанная УПП я рискну предположить, что это чисто "управленческая" база, из которой идут выгрузки в бух/зуп.

Если этот так - то я бы вообще смотрел в сторону переноса остатков и начала ведения "с чистого листа" с 2021 года, например (после всех выгрузок), а старую базу в режиме ридонли оставить для отчетов по предыдущему периоду.

Ну, или, если отчеты очень часто нужны за последний год, например, то свернуть по последний год.

Я бы начала с анализа размеров таблиц. Может оказаться, что очень большой процент занимает таблица незакрывающегося РН, который можно быстро и безболезненно свернуть на начало года.
   Lama12
 
11 - 13.12.20 - 09:54
(0) Случайно база стала тормозить не после перехода с 8.2 на 8.3?

Я бы начал с замеров производительности. Выяснил узкое место. Склоняюсь к (3). Наверняка при переходе с 8.2 на 8.3 оптимизацию и рефакторинг своих доработок, с учетом рекомендаций 1С не делали. А взаимодействие клиент/сервере идет совсем по другому, особенно неявные вызовы.

Вот смотри, если у тебя есть где пользователи жалуются, там замер проведи и вычисли причины торможения. Смоделируй одну и ту-же ситуацию на 8.2 и на 8.3.
Потратишь день, но точно будешь знать что проблема не в объемах данных базы.
А все остальное - не одна неделя работы.
   Фрэнки
 
12 - 13.12.20 - 10:03
Свертку базы (если это база в 8.3) делают не для улучшения производительности, а для исключения из нее вредной, лишней или просо неактуальной инфы.

Например, инфа от 2010 года в оперативной базе может служить дополнительным источником ошибок. Не источником снижения скорости работы СУБД, а источником ошибок в оперативной работе пользователя.

Технически будет намного легче просто "закрыть" неактуальное, чем сделать качественную свертку.
   Гений 1С
 
13 - 13.12.20 - 10:08
(0) может вложиться в железо? SSD, RAM это все?
   Гений 1С
 
14 - 13.12.20 - 10:08
Поставь технологический журнал и замеряй производительность, в чем косяки, где виснет
   Dmitry1c
 
15 - 13.12.20 - 10:12
(0) если есть бюджет на оптимизацию, напиши в ЛС.
   VladZ
 
16 - 13.12.20 - 11:21
Для общей ясности не помешало бы озвучить параметры железа.
   Конструктор1С
 
17 - 13.12.20 - 11:30
(0) "из старой базы в пустую через КД 2.1"

Очень тормозной вариант. Я бы сказал мегатормозной. Справочники ещё может туда-сюда, а основные данные будешь переносить долго. КД это для небольших баз. Лучше создай план обмена РИБ, включи в него нужные объекты, отключи авторегистрацию. Напиши обработку, которая пробежится по базе и зарегистрирует нужные объекты. Потом выгрузи из этого плана обмена стандартными средствами и загрузи в пустую базу. Естественно порциями. Стандартный обмен данными XML в десятки раз производительнее КД
   H A D G E H O G s
 
18 - 13.12.20 - 12:01
(14) Сергей, а вы замеряли производительность через ТЖ?
   slafor
 
19 - 13.12.20 - 14:29
Всем спасибо, прочитал сообщения, узнал много интересного и появились новые мысли.

А как можно узнать, какой РН или другой объект занимает больше места? Доступа (прямого) к базе SQL нет, в принципе можно,  но проблемно. Есть какая-нибудь обработка для этого, или как самому написать?
   ДенисЧ
 
20 - 13.12.20 - 14:43
(19) Обработки есть. Но для них нужен доступ к серверу СКЛ )))
   Гений 1С
 
21 - 13.12.20 - 15:01
(20) (19) договорись о доступе к SQL
   Гений 1С
 
22 - 13.12.20 - 15:01
(17) Вот кстати да, РИБ проще КД и надежнее
   Фрэнки
 
23 - 13.12.20 - 15:05
:-)

С чего бы РИБ был проще? Вы в какой версии баз это все обсуждаете? Ах да, в версии старой УПП - тогда согласен, что там РИБ довольно простой.
   slafor
 
24 - 13.12.20 - 15:37
(20)(21) Обработки на 1С? Доступ к SQL есть только тот, по которому подключается 1С. А какой нужен доступ?
   Сияющий в темноте
 
25 - 13.12.20 - 23:32
А чем РИБ от КД отличается,если мы объект в объект переносим?
выгрузка-хагрузка xml будет не сильно медленнее плана обмена,так как там та же самая сериализация xml.
а вот определение связанных объектов-это отдельная история.
   slafor
 
26 - 14.12.20 - 00:54
Немного не правильно обозначил тему вопроса, поскольку ещё не владел всей информацией )

На самом деле, там полностью самописная конфигурация (а не на базе УПП), причем еще на 8.2, объем базы несколько сот Гб, работает все очень медленно... Может, завтра выясню, где именно "тормозит", тогда будет понятней.
   ViSo76
 
27 - 14.12.20 - 01:18
Интересно регламенты выполняются по пересозданию индексов, сбору статистики? Там где тормозить можно заменить производительность и посмотреть на чём тормозит...
   slafor
 
28 - 14.12.20 - 09:52
Кто-нибудь работал с отчетом Статистика ИБ 8.1 с Инфостарта (http://catalog.mista.ru/public/15052/)? Она нормально работает на 8.2?

Мне надо вычислить объем регистров в базе SQL.
   ДенисЧ
 
29 - 14.12.20 - 09:53
(28) А зачем для этого обработка? У тебя украли SQL Studio?
   slafor
 
30 - 14.12.20 - 10:09
(29) Да у меня доступа нет, хотелось бы из 1С...
 
 
   ДенисЧ
 
31 - 14.12.20 - 10:10
(30) (24) Нужен логин-пароль. С соответствующими правами.
   CHerypga
 
32 - 14.12.20 - 11:14
(0) огласите полтора десятка самых больших таблиц
   Timon1405
 
33 - 14.12.20 - 11:31
если самописка, то может быть итоги не посчитаны или РН не закрываются
   1c-kind
 
34 - 14.12.20 - 11:40
Есть обработка "Получение реквизитов SQL" , можно узнать по Объекту 1с  соответствующие таблицы SQL.
А как наоборот?
   JeHer
 
35 - 14.12.20 - 11:45
(32) не сможет
(34) а это не одно и то же?
   МимохожийОднако
 
36 - 14.12.20 - 11:46
(30) Трудно стоя в гамаке...Если взялся за это дело, то добейся админских прав
   1c-kind
 
37 - 14.12.20 - 11:47
(35) По отчету MSSMS я нашел самую большую таблицу dbo._AccRgEd1387  , как узнать к чему она относится в 1с?
   ДенисЧ
 
38 - 14.12.20 - 11:48
(37) Взять обработку из (34) и посмотреть в регистрах накопления. Глазками.
   1c-kind
 
39 - 14.12.20 - 11:49
(38) Спасибо.
   1c-kind
 
40 - 14.12.20 - 11:55
Нашел полезную инфу по таблицам, может кому пригодится 

https://its.1c.ru/db/metod8dev/content/1798/hdoc
   H A D G E H O G s
 
41 - 14.12.20 - 12:03
(37)
Вы не справитесь, позовите специалиста.
   1c-kind
 
42 - 14.12.20 - 12:08
(41) Справлюсь с чем?
Все уже нашел, у меня все отлично работает, чисто ради интереса .
   H A D G E H O G s
 
43 - 14.12.20 - 12:09
(42) Ну и отлично.
   slafor
 
44 - 14.12.20 - 18:17
У нас самые большие таблицы - это "_InfoRgChngRхххх", "_InfoRgхххх" и "_Documentхххх". Самая большая - первая, > 160000000 Кб. Я правильно понимаю - это связано с планом обмена (регистрация изменений), с РС и с докуменами?

Не подскажете, где можно найти обработку "Получение реквизитов SQL"? Нигде найти не могу...
   Aleksey
 
45 - 14.12.20 - 18:24
(44) Кто то за собой не чистить регистрацию? Или у вас "потеряшка", т.е. настроили обмен и забыли?
   Aleksey
 
46 - 14.12.20 - 18:26
"Получение реквизитов SQL" - возьми "инструменты разработчика" там точно есть
   Гений 1С
 
47 - 14.12.20 - 21:57
(45) похоже на то, гггг, что у них обмены не чищены. Наверное, есть пару мертвых узлов обмена, отсюда и тормоза при записи
   Гений 1С
 
48 - 14.12.20 - 21:58
(28) я работал, весьма часто. удобная хрень
   slafor
 
49 - 15.12.20 - 01:55
(47) И объем базы из-за этого тоже? Просто он вырос настолько, что они даже архивную копию не делают - некуда.
А что можно сделать в такой ситуации?
   H A D G E H O G s
 
50 - 15.12.20 - 02:37
(49) Позвать специалиста.
   Конструктор1С
 
51 - 15.12.20 - 05:15
(40) эту инфу никто и не терял
   Конструктор1С
 
52 - 15.12.20 - 05:19
(49) "Просто он вырос настолько, что они даже архивную копию не делают - некуда"

База грохнется и будет уроком. Сразу придёт понимает что дешевле: мёртвую базу реанимировать или хранилку под архивные копии приобрести
   DmVl76
 
53 - 15.12.20 - 06:18
(49) В УПП есть стандартная обработка - регистрация изменений для обмена, там можно посмотреть зарегистрированные изменения по всем узлам, и если есть неиспользуемый узел, можно удалить регистрацию.
   Фрэнки
 
54 - 15.12.20 - 09:51
Так-то написать запрос по таблицам регистрации изменений можно даже обычным конструктором запросов - было бы на то желание и интерес. Оно все не засекречено, а доступно.
   slafor
 
55 - 15.12.20 - 11:53
(50) А сколько по времени/оплате это будет стоить, примерно?
   Гений 1С
 
56 - 15.12.20 - 11:58
(55) на подчистку регистрации изменений 4 часа * 1800 руб в час
   pvase
 
57 - 15.12.20 - 12:10
(0) Скачай инструменты разработчика (http://devtool1c.ucoz.ru/) и посмотри что там больше всего занимает место. Подумай, можно ли безболезненно удалить эти данные. Обычно это или регистры с разьехавшимеся остатками, версии объектов, планы обмена, или какой то лог кто-то прикрутил в регистры сведений.
   pvase
 
58 - 15.12.20 - 12:12
Если удалять нечего - то придется делать архивную БД и переносить остатки и начинать все с чистого листа. Ну или если БД SQL, то можно как вариант для больших таблиц создать ColumnCtore индекс, но могут быть проблемы с 1С, она может этот индекс убивать или выдавать ошибку на структуру.
   arsik
 
59 - 15.12.20 - 12:13
(56) А если нет архивной копии ? :)
   Гений 1С
 
60 - 16.12.20 - 14:51
(59) планы обмена можно удалить и без архивной копии. Но архивную копию иметь надо. Купите себе уже немного HDD
 
 
   1c-kind
 
61 - 16.12.20 - 14:53
(59) Какого же размера у вас база?

Наша УПП в 600гигов , имеет скульный бэкап в 65 гиг.  Неужели так трудно найти место под копии?
   Гений 1С
 
62 - 16.12.20 - 15:37
(61) диск 2Тб стоит 5к, если не ошибаюсь. Вот не понимаю этого.
   Aleksey
 
63 - 16.12.20 - 17:23
(62) Что такое 2Тб - это максимум бекапы за месяц - и все место кончилось
   Гений 1С
 
64 - 16.12.20 - 18:23
(63) Ну потом заново бэкапите, затирая старый, например бэкапы от 1 до 31 по дням.
Ну а вообще, посчитайте цену попадалова при сбое базы. Восстановить ее без бэкапа будет стоить от 100.000 рублей, думается и то без гарантии, что получится.
   Гений 1С
 
65 - 16.12.20 - 18:24
(63) Или купите 5 дисков по 2Тб, бывают диски и по 8 Тб диски. ;-)
   Гений 1С
 
66 - 16.12.20 - 18:25
А вообще если база сжимается до 8 Гб, пишите ее на DVD или блюрей одноразовый.
   Арбузов
 
67 - 16.12.20 - 18:26
Как страшно жить... А у нас на работе размер основной базы достиг 11 ТБ, я сам в ахуе...
   Гений 1С
 
68 - 16.12.20 - 18:36
(67) SQL? Шринкать не пробовали (сжимать лог транзакций). Не думаю, что там сама база весит столько, скорее всего лог (за годы!) накопился
   Гений 1С
 
69 - 16.12.20 - 18:36
(67) на стриммерах бэкапите?
   acht
 
70 - 16.12.20 - 18:49
(62) В теме Где хранить архивные копии на винтах? пациент говорит, что 3 тыщи в год на облако это дорого. Но это же другое, понимать надо, чьи 3 тыщи!
   Арбузов
 
71 - 16.12.20 - 18:51
(68) Нет, это сама база. Как бэкапят, яхз, но каждый день 3 тестовых базы с данными на вчера в распоряжении разработки.
   acht
 
72 - 16.12.20 - 19:01
(69) Сережа увидел цифры, которые не укладываеются в мировоззрение пригородного фрилансера, и поэтому отрицает их.
   Гений 1С
 
73 - 16.12.20 - 19:02
(70) не путай архивацию бизнес-данных и личных, "дохтур"
   Гений 1С
 
74 - 16.12.20 - 19:02
(71) ну вот видишь, могут же, если захотят
   Арбузов
 
75 - 16.12.20 - 19:23
(74) Конечно, поэтому советы безотносительно бюджета смысла имеют не очень много.
   arsik
 
76 - 16.12.20 - 21:09
(60) (61) Вы ребята видимо что то спутали. Я же не топикстартер.
   Конструктор1С
 
77 - 17.12.20 - 03:55
(63) а зачем хранить много бэкапов?
   Йохохо
 
78 - 17.12.20 - 04:01
(77) количество выходных + 3 и срезы по отчетности
   Aleksey
 
79 - 17.12.20 - 04:23
(77) Потому что к примеру отчетность по НДС сдают раз в квартал, и когда приходит очередной период выясняется, что данные в базе за прошлый период и то что сдали различаются. Соответственно поднимаешь бекап на момент сдачи и сравниваешь, где и кто задним числом поправил. А так как фирм несколько десятков, то кто то сдает 5-го кто то 10го, а кто то и до 25-го тянет.  Плюс есть еще и ежемесячные отчеты. Короче минимум за последние 6-7 месяцев нужно наиболее полный пак бекапов держать. Более поздние тоже нужны но уже по схеме (78)
   Bigbro
 
80 - 17.12.20 - 04:38
у нас было несколько бэкапов с разной периодичностью и сроком хранения. ежедневные за 2 недели, еженедельные которые хранились 3 месяца, ежемесячные за 3 года и полугодовые которые хранились вечно.
достаточно универсальная схема - устраивала всех.
   АнализДанных
 
81 - 17.12.20 - 09:08
(0) Файлы в базе храните ? или отдельно на диске?
   ДядяМитяй
 
82 - 17.12.20 - 10:10
(37) ПолучитьСтруктуруХраненияБазыДанных() > в табдок > Показать()

Еще можно версионирование отключить. Если соответствующий регистр распух. И сам регистр обнулить
   trdm
 
83 - 17.12.20 - 10:15
(3) >  В нормально спроектированной базе скорость не зависит от объема.

Если регламенты настроены и объема мемори хватает.
   1c-kind
 
84 - 17.12.20 - 10:17
(82) Зачем отключать? Могу обработкой поделиться, которая режет регистр "Версии объектов" до определенной даты.
   ДядяМитяй
 
85 - 17.12.20 - 10:21
(84) чтобы проблема не повторялась - очевидно же.
а обработка называетя ПроизвольныйКод и в ней пишется строк 10 ))
   ИС-2
 
86 - 17.12.20 - 10:24
(28) да. Пользуюсь Статистика ИБ 8.3 SQL (занимаемое место).erf. Могу отправить на почту


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.