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

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

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

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

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

(1) Почему?
Работать-то работает, но очень медленно.

(2) В нормально спроектированной базе скорость не зависит от объема.

(2) удаление контрагентов ничего не даст.

(0) КД будет не оптимально, в вашем случае я бы задумался о прямой работе с sql базой

(5) если он поудаляет в sql например весь приход товара, как он потом будет там восстанавливать остатки?  Напрямую в sql?

(2) Потому что настораживает твоя уверенность в том, что причина тормозов в объеме базы

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

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

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

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

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

Все это не говорит ничего хорошего о твоем уровне, поэтому и рекомендация лучше не соваться в это дело, наломаешь дров по неопытности

(0) Выяснить в каких местах и по каким причинам тормоза. Долго думать. Где голосовалка?

(8) +1

(7) +100500
Но иногда базу резать все же есть смысл. Если инфа действительно не нужная, то обслуживать / работать с маленькой базой всегда быстрее / удобнее, чем с гигантской.
Судя по тому, что это сильно переписанная УПП я рискну предположить, что это чисто "управленческая" база, из которой идут выгрузки в бух/зуп.

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

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

Я бы начала с анализа размеров таблиц. Может оказаться, что очень большой процент занимает таблица незакрывающегося РН, который можно быстро и безболезненно свернуть на начало года.

(0) Случайно база стала тормозить не после перехода с 8.2 на 8.3?

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

Вот смотри, если у тебя есть где пользователи жалуются, там замер проведи и вычисли причины торможения. Смоделируй одну и ту-же ситуацию на 8.2 и на 8.3.
Потратишь день, но точно будешь знать что проблема не в объемах данных базы.
А все остальное - не одна неделя работы.

Свертку базы (если это база в 8.3) делают не для улучшения производительности, а для исключения из нее вредной, лишней или просо неактуальной инфы.

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

Технически будет намного легче просто "закрыть" неактуальное, чем сделать качественную свертку.

(0) может вложиться в железо? SSD, RAM это все?

Поставь технологический журнал и замеряй производительность, в чем косяки, где виснет

(0) если есть бюджет на оптимизацию, напиши в ЛС.

Для общей ясности не помешало бы озвучить параметры железа.

(0) "из старой базы в пустую через КД 2.1"

Очень тормозной вариант. Я бы сказал мегатормозной. Справочники ещё может туда-сюда, а основные данные будешь переносить долго. КД это для небольших баз. Лучше создай план обмена РИБ, включи в него нужные объекты, отключи авторегистрацию. Напиши обработку, которая пробежится по базе и зарегистрирует нужные объекты. Потом выгрузи из этого плана обмена стандартными средствами и загрузи в пустую базу. Естественно порциями. Стандартный обмен данными XML в десятки раз производительнее КД

(14) Сергей, а вы замеряли производительность через ТЖ?

Всем спасибо, прочитал сообщения, узнал много интересного и появились новые мысли.

А как можно узнать, какой РН или другой объект занимает больше места? Доступа (прямого) к базе SQL нет, в принципе можно,  но проблемно. Есть какая-нибудь обработка для этого, или как самому написать?

(19) Обработки есть. Но для них нужен доступ к серверу СКЛ )))

(20) (19) договорись о доступе к SQL

(17) Вот кстати да, РИБ проще КД и надежнее

:-)

С чего бы РИБ был проще? Вы в какой версии баз это все обсуждаете? Ах да, в версии старой УПП - тогда согласен, что там РИБ довольно простой.

(20)(21) Обработки на 1С? Доступ к SQL есть только тот, по которому подключается 1С. А какой нужен доступ?

А чем РИБ от КД отличается,если мы объект в объект переносим?
выгрузка-хагрузка xml будет не сильно медленнее плана обмена,так как там та же самая сериализация xml.
а вот определение связанных объектов-это отдельная история.

Немного не правильно обозначил тему вопроса, поскольку ещё не владел всей информацией )

На самом деле, там полностью самописная конфигурация (а не на базе УПП), причем еще на 8.2, объем базы несколько сот Гб, работает все очень медленно... Может, завтра выясню, где именно "тормозит", тогда будет понятней.

Интересно регламенты выполняются по пересозданию индексов, сбору статистики? Там где тормозить можно заменить производительность и посмотреть на чём тормозит...

Кто-нибудь работал с отчетом Статистика ИБ 8.1 с Инфостарта (http://catalog.mista.ru/public/15052/)? Она нормально работает на 8.2?

Мне надо вычислить объем регистров в базе SQL.

(28) А зачем для этого обработка? У тебя украли SQL Studio?

(29) Да у меня доступа нет, хотелось бы из 1С...

(30) (24) Нужен логин-пароль. С соответствующими правами.

(0) огласите полтора десятка самых больших таблиц

если самописка, то может быть итоги не посчитаны или РН не закрываются

Есть обработка "Получение реквизитов SQL" , можно узнать по Объекту 1с  соответствующие таблицы SQL.
А как наоборот?

(32) не сможет
(34) а это не одно и то же?

(30) Трудно стоя в гамаке...Если взялся за это дело, то добейся админских прав

(35) По отчету MSSMS я нашел самую большую таблицу dbo._AccRgEd1387  , как узнать к чему она относится в 1с?

(37) Взять обработку из (34) и посмотреть в регистрах накопления. Глазками.

(38) Спасибо.

Нашел полезную инфу по таблицам, может кому пригодится

https://its.1c.ru/db/metod8dev/content/1798/hdoc

(37)
Вы не справитесь, позовите специалиста.

(41) Справлюсь с чем?
Все уже нашел, у меня все отлично работает, чисто ради интереса .

(42) Ну и отлично.

У нас самые большие таблицы - это "_InfoRgChngRхххх", "_InfoRgхххх" и "_Documentхххх". Самая большая - первая, > 160000000 Кб. Я правильно понимаю - это связано с планом обмена (регистрация изменений), с РС и с докуменами?

Не подскажете, где можно найти обработку "Получение реквизитов SQL"? Нигде найти не могу...

(44) Кто то за собой не чистить регистрацию? Или у вас "потеряшка", т.е. настроили обмен и забыли?

"Получение реквизитов SQL" - возьми "инструменты разработчика" там точно есть

(45) похоже на то, гггг, что у них обмены не чищены. Наверное, есть пару мертвых узлов обмена, отсюда и тормоза при записи

(28) я работал, весьма часто. удобная хрень

(47) И объем базы из-за этого тоже? Просто он вырос настолько, что они даже архивную копию не делают - некуда.
А что можно сделать в такой ситуации?

(49) Позвать специалиста.

(40) эту инфу никто и не терял

(49) "Просто он вырос настолько, что они даже архивную копию не делают - некуда"

База грохнется и будет уроком. Сразу придёт понимает что дешевле: мёртвую базу реанимировать или хранилку под архивные копии приобрести

(49) В УПП есть стандартная обработка - регистрация изменений для обмена, там можно посмотреть зарегистрированные изменения по всем узлам, и если есть неиспользуемый узел, можно удалить регистрацию.

Так-то написать запрос по таблицам регистрации изменений можно даже обычным конструктором запросов - было бы на то желание и интерес. Оно все не засекречено, а доступно.

(50) А сколько по времени/оплате это будет стоить, примерно?

(55) на подчистку регистрации изменений 4 часа * 1800 руб в час

(0) Скачай инструменты разработчика (http://devtool1c.ucoz.ru/) и посмотри что там больше всего занимает место. Подумай, можно ли безболезненно удалить эти данные. Обычно это или регистры с разьехавшимеся остатками, версии объектов, планы обмена, или какой то лог кто-то прикрутил в регистры сведений.

Если удалять нечего - то придется делать архивную БД и переносить остатки и начинать все с чистого листа. Ну или если БД SQL, то можно как вариант для больших таблиц создать ColumnCtore индекс, но могут быть проблемы с 1С, она может этот индекс убивать или выдавать ошибку на структуру.

(56) А если нет архивной копии ? :)

(59) планы обмена можно удалить и без архивной копии. Но архивную копию иметь надо. Купите себе уже немного HDD

(59) Какого же размера у вас база?

Наша УПП в 600гигов , имеет скульный бэкап в 65 гиг.  Неужели так трудно найти место под копии?

(61) диск 2Тб стоит 5к, если не ошибаюсь. Вот не понимаю этого.

(62) Что такое 2Тб - это максимум бекапы за месяц - и все место кончилось

(63) Ну потом заново бэкапите, затирая старый, например бэкапы от 1 до 31 по дням.
Ну а вообще, посчитайте цену попадалова при сбое базы. Восстановить ее без бэкапа будет стоить от 100.000 рублей, думается и то без гарантии, что получится.

(63) Или купите 5 дисков по 2Тб, бывают диски и по 8 Тб диски. ;-)

А вообще если база сжимается до 8 Гб, пишите ее на DVD или блюрей одноразовый.

Как страшно жить... А у нас на работе размер основной базы достиг 11 ТБ, я сам в ахуе...

(67) SQL? Шринкать не пробовали (сжимать лог транзакций). Не думаю, что там сама база весит столько, скорее всего лог (за годы!) накопился

(67) на стриммерах бэкапите?

(62) В теме Где хранить архивные копии на винтах? пациент говорит, что 3 тыщи в год на облако это дорого. Но это же другое, понимать надо, чьи 3 тыщи!

(68) Нет, это сама база. Как бэкапят, яхз, но каждый день 3 тестовых базы с данными на вчера в распоряжении разработки.

(69) Сережа увидел цифры, которые не укладываеются в мировоззрение пригородного фрилансера, и поэтому отрицает их.

(70) не путай архивацию бизнес-данных и личных, "дохтур"

(71) ну вот видишь, могут же, если захотят

(74) Конечно, поэтому советы безотносительно бюджета смысла имеют не очень много.

(60) (61) Вы ребята видимо что то спутали. Я же не топикстартер.

(63) а зачем хранить много бэкапов?

(77) количество выходных + 3 и срезы по отчетности

(77) Потому что к примеру отчетность по НДС сдают раз в квартал, и когда приходит очередной период выясняется, что данные в базе за прошлый период и то что сдали различаются. Соответственно поднимаешь бекап на момент сдачи и сравниваешь, где и кто задним числом поправил. А так как фирм несколько десятков, то кто то сдает 5-го кто то 10го, а кто то и до 25-го тянет.  Плюс есть еще и ежемесячные отчеты. Короче минимум за последние 6-7 месяцев нужно наиболее полный пак бекапов держать. Более поздние тоже нужны но уже по схеме (78)

у нас было несколько бэкапов с разной периодичностью и сроком хранения. ежедневные за 2 недели, еженедельные которые хранились 3 месяца, ежемесячные за 3 года и полугодовые которые хранились вечно.
достаточно универсальная схема - устраивала всех.

(0) Файлы в базе храните ? или отдельно на диске?

(37) ПолучитьСтруктуруХраненияБазыДанных() > в табдок > Показать()

Еще можно версионирование отключить. Если соответствующий регистр распух. И сам регистр обнулить

(3) >  В нормально спроектированной базе скорость не зависит от объема.

Если регламенты настроены и объема мемори хватает.

(82) Зачем отключать? Могу обработкой поделиться, которая режет регистр "Версии объектов" до определенной даты.

(84) чтобы проблема не повторялась - очевидно же.
а обработка называетя ПроизвольныйКод и в ней пишется строк 10 ))

(28) да. Пользуюсь Статистика ИБ 8.3 SQL (занимаемое место).erf. Могу отправить на почту