Методика похудения для 1С – 100%

28.07.22

База данных - Свертка базы

Удаление архивных данных из базы - это непростая задача как для 1С, так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С.

Какой вес опасен для здоровья  базы? Большая не значит с лишним весом

 

 

У людей все просто – оптимальный вес вычисляется как соотношение роста и веса, + используются дополнительные показатели (возраст, пол …) для определения индекса массы тела. Калькулятор роста веса Конечно, всем не угодишь – например, культуристы могут возмутиться.

С оптимальным размером базы все гораздо сложнее – оптимальный объем базы определяется бизнес-процессом и потоком данных,  но и здесь можно сформулировать четкие критерии. Далее все изложено для финансового и управленческого учета 1С, поскольку в других сферах могут  быть другие пропорции идеального веса базы.

База имеет оптимальный размер, если:

  • В ней содержатся только данные, которые входят в период оперативной доступности данных для  учета.
  • Данные обеспечивают необходимую детализацию в периоде оперативной доступности данных
  • Сроки восстановления базы укладываются в целевые сроки восстановления (Recovery Time Objective) и согласуются с Business continuity planning
  • Допустимые простои на обслуживание согласно Business continuity planning
  • Стоимость хранения данных устраивает бизнес
  • Подготовка тестовых баз с реальными данными не требует больших усилий

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

Оперативную доступность можно пояснить на примере: допустим, у вас есть займ, сделка с датой поставки и датой оплаты. Очевидно, чтобы производить расчеты с периодом действия займа, или датой оплаты\ поставки эта операция должна быть доступна – даже если сама дата операции была 3 года назад. То же самое относится к амортизации основных средств, где важна дата приема основного средства, период действия. Хороший пример - период регистрации\период действия в 1С Зарплата и кадры.

В целом большая база вызывает противоречивые чувства – с одной стороны, гордость за объемы, которыми оперируем, с другой стороны - постоянное напряжение от обратного отсчета дискового пространства. Разница в ощущениях и квалификации как у капитана прогулочного судна  против капитана морского танкера.

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

Объем обрабатываемых данных за 1.5 года создает объем данных 5 Терабайт для базы 1С (включая детальные сделки\трансферы\проводки 1С и т.д.) на MS SQL 2019 с учетом мероприятий по обслуживанию индексов и устранению фрагментации. Размер сжатого бэкапа 0.5 Терабайт

Для процесса обработки\сверки данных (формирование проводок по исходным сделкам и операциям)  применяются роботы (обработки запускаемые по расписанию), а пользователи уже работают с готовыми расчетами. По сути мы получаем нагруженную OLTP систему, полностью реализованную средствами  1С.

Буфер сообщений (за периметром 1С) из шины данных RabbitMQ  – 3 терабайта каждые 2 месяца

Такой объем данных уже не позволяет использовать обычные средства платформы 1С для переиндексирования, сжатия таблиц, выгрузки бэкапа через dt файл, удаления помеченных на удаление объектов и т.д.

 

Временные метрики

 

Мероприятие

Время

Время полного бэкапа

2 часа 30 минут

Время полного восстановления с сети

1 час – 1 час 30 минут

Время копирования бэкапа в резервный ЦОД по WAN с задержкой 60мс

3-4 часа

Перестроение одного индекса по самой большой таблице

2-3 часа

 

 

 

 

 

Временные окна

 

Зарезервированный период времени

 

Пн-Пт 6.00-11.00

Импорты операций\изменений поступивших с 0.00 до 6.00 ,пересчеты за предыдущие три дня

Пн-Пт 13.00-15.00

Импорты  и пересчеты с учетом текущего дня

Пн-Пт 9.00-22.00

Работа пользователей в разных часовых поясах

Пн-Пт с  22.00 – 1.00

Резервное копирование

Пн-Вс  с 1.00- 4.00

Импорты за предыдущие сутки, обновление агрегатов

Сб 6.00 – 16.00

Пересчет недели

Вс

Свободно для регламентных операций

 

Самые большие таблицы

В колонке Reserved можно видеть полный размер с данными и индексами

 

Table Name

# Records

Reserved (KB)

Data (KB)

Indexes (KB)

Unused (KB)

dbo._InfoRg19541

2 129 006 521

935 854 848

330 776 488

605 006 384

71 976

dbo._InfoRg18843

2 249 531 309

868 625 224

404 594 224

463 926 136

104 864

dbo._InfoRg18800

474 701 158

464 440 080

237 170 176

226 214 496

1 055 408

dbo._InfoRg18860

210 648 091

364 976 152

161 322 160

202 245 752

1 408 240

dbo._InfoRg19155

213 300 609

288 223 232

147 725 760

139 103 120

1 394 352

dbo._InfoRg17958

950 225 249

272 452 928

112 304 896

160 024 808

123 224

dbo._AccRg640

173 846 826

216 363 688

114 061 808

100 367 624

1 934 256

dbo._AccRgED677

719 075 121

210 720 168

85 568 344

124 133 600

1 018 224

dbo._InfoRg17039

370 016 366

187 902 208

38 467 072

149 404 080

31 056

dbo._Document16379

124 261 741

157 270 936

87 645 272

69 585 416

40 248

dbo._InfoRg17540

465 538 086

130 361 760

48 378 552

81 972 648

10 560

dbo._InfoRg19532

319 591 053

117 715 648

36 970 224

80 632 544

112 880

dbo._AccumRgAgg1efff3h18432

35 654 182

113 249 992

16 904 528

96 339 088

6 376

dbo._Document16378

44 003 768

109 851 688

58 681 312

50 688 960

481 416

dbo._InfoRg19498

85 023 186

109 818 320

29 883 608

79 798 344

136 368

dbo._Document17199

75 350 013

96 437 040

50 024 488

46 376 920

35 632

dbo._AccumRg16920

55 665 218

72 446 544

34 478 320

36 183 960

1 784 264

dbo._Document17554

46 735 956

61 361 048

30 128 088

31 202 152

30 808

 

Зарезервированное время, не всегда используется полностью, но  в пиковых нагрузках приходится выходить за границы. Финансовый\Управленческий учет с высокой детализацией требует ресурсов и создает объемы. Из таблиц видно, что работа построена довольно плотно, и даже вклинится с регламентными процедурами не так просто

 

Обслуживание для plus size  модели

 

 

Такие размеры базы налагают определенные условия на мероприятия по обслуживанию:

  1. Нужно забыть регламентных заданиях обновления статистики SQL  это долго, хорошо жить с флагом трассировки-Т2371 - он изменяет порог обновления статистики на более частый. Если его не включить – вставка\обновление нескольких миллионов записей уже искажает статистику и влияет на запросы . Формально считается, что он не влияет на SQL 2016 - 2019 но есть нюансы
  2. Вы должны быть внимательны к режиму совместимости вашей базы даже, если вы ее перенесли на SQL Server 2019 . Напр. при переносе базы c SQL 2008 на SQL  2019 по умолчанию ставится режим совместимости с 2008. Во много это определяется изменившимся режимом оптимизатора в котором Microsoft видимо не уверен. Я бы тоже был осторожен при таком кардинальном изменение кардинальности см тут Улучшенная кардинальность в MS SQL
  3. Раз в полгода нужна переиндексация НЕкластерных  индексов с наибольшей фрагментацией. В 1С напр. много обновляющихся(insert, delete)  таблиц (напр. итоги)  в которых растет фрагментация. В такой базе как наша это позволяет выиграть 3 - 4 сотни гигабайт за мероприятие . Для эффективности используйте ALTER INDEX <Index_Name> ON dbo.<Table_Name> REBUILD WITH (SORT_IN_TEMPDB = ON). Это предотвратит рост размера файловой группы, ведь ее потом трудно сжать обратно не смотря на свободное место.
  4. После свертки остатков и удаления лишних данных проведите реиндексацию кластерных индексов. С фрагментацией и перестройкой кластерных индексов сложнее – фактически нужно место равное размеру таблицы, но это решаемо

Такие размеры выявляют несовершенство оптимизатора SQL, я неоднократно сталкивался со случаями, когда вдруг запрос на одном дне работает очень медленно, а если период расширить до +N дней, то быстро. Если пересчитать статистику все начинает работать быстро на любых периодах.

Программист 1С в этом случае должен трансформироваться минимум в Эксперта 1С по технологическим вопросам, а в идеале знать в совершенстве Performance and tuning из сертификации DBA. 1С это всего лишь удобный инструмент для генерации запросов, как сыграешь на нем, так и будет работать.

Анонс: В целом детали управления слоном в клетке ЦОД это отдельная статья, поскольку избыточного места равного размеру базы почти никогда нет. Сложностей добавляет структура таблиц\индексов 1С которые генерируют метаданные.

 

Снижение веса как стиль жизни

 

 

При таком потоке данных разовыми мероприятиями по удалению лишнего не обойтись, нужно встраивать это в архитектуру. Рассмотрим варианты от самого плохого до самого хорошего

Удаление миллионов – дорого и долго.

Удаление миллионов средствами 1С будет в любом случае самым долгим, поскольку это можно делать либо по регистратору, либо по измерениям регистра с условием на равенство. Даже если это запустить в параллельных фоновых заданиях,  маштабируя горизонтально,  вы будете сталкиваться с waits на обновлении данных таблиц и что не маловажно индексов. Ведь любой удаляемый набор записей SQL Server должен исключить не только из таблицы, но и всех индексов.

Если вы решили ускорить удаление, делая это напрямую через SQL Server  в цикле DELETE TOP 1000 FROM 1CTable, вас ожидает две проблемы:

  1. В Цикле в один поток это будет медленно.
  2. Распараллелить данный оператор на уровне SQL это прямой путь к блокировкам. Еще в MS SQL (Transact SQL) нет хороших средств распараллелить ваш код кроме механизма Jobs.

Если кто-то хочет сделать просто DELETE * FROM 1CTables – оцените влияние объемов на Transaction log и Вы много поймете в архитектуре СУБД.

Анонс: Вообще делать часть кода на MS SQL (Transact SQL ) это плохая затея, несмотря на кажущуюся эффективность. Тема для отдельной статьи.

Даже если вы все-таки удалили миллионы этим способом, MS SQL на этом не закончил – вы там обнаружите … призрака

Выглядит он так

 

 

Это процесс очистки фантомных записей MS SQL. Забавно, что не только 1С умеет “помечать” на удаление, но и MS SQL, см. Ghost clean up guide

А в качестве бонуса всей процедуры удаления Вы получите хорошую фрагментацию файловой группы. См

Reorganize and rebuild indexes

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

Партицирование миллионов  - дешево и сердито.

Для больших таблиц современные СУБД (MS SQL 2019 в Standard edition) предлагают механизм партицирования. Напр периодический регистр сведений можно партицировать по дате,  а потом:

  1. Данные старых партиций сохранять в архив
  2. Удаление старых данных  в одной партиции производить операцией TRUNCATE TABLE WITH (PARTITIONS(N)), быстро, без фрагментаций и других неприятных последствий описанных выше;

Подробнее можно почитать тут: Партицированные таблицы

И инструкция с примером тут: Пример создания партицированных таблиц

Казалось бы, вот хорошее решение, но проблемы кроются в деталях:

  1. Партицирование возможно только по одной Partitioning column, т.е. использовать составной ключ для партицирования типа (Разделитель данных, Дата) которые часто используются в типовых конфигурациях невозможно
  2. Partition column должна присутствовать во всех индексах таблицы иначе вы сможете делать только DML операции, но не DDL TRUNCATE TABLE WITH (PARTITIONS(N));
  3. Многие метаданные 1С напр, Регистр бухгалтерии по структуре состоит из нескольких таблиц, его партицировать невозможно. Т.е. в общем случае возможность эффективного использования партицирования должна быть заложена на уровне платформы, а этого нет.
  4. Партицирование позволяет быстро удалить данные партиции, используя TRUNCATE TABLE WITH (PARTITIONS(N)); но не позволяет быстро поместить в архив и это сужает применение партицирование для узких задач. Напр хранение данных буфера сообщений для RabbitMQ, это сильно облегчает жизнь, но не решает общую проблему быстрого снижения веса.

Про помещение в архив стоит остановится подробнее. В партицировании есть операция SWITCH позволяющая переключить на уровне метаданных SQL (не путать с метаданными 1С)  данные из партиции в таблицу той же структуры. Делается это мгновенно на уровне метаданных SQL, но пользы для быстрого архивирования нет

  1. Переключение идет только в рамках той же файловой группы, мы не можем сделать  SQL бэкап отдельно партиции с ее индексами. Только бэкап всей базы или файловой группы
  2. Бэкап можно сделать только через стандартную утилиту копирования таблиц MS SQL BCP , которая не сжимает данные и работает медленней чем SQL Backup на уровне экстентов

Получается, что партицирование позволяет только быстро удалять данные, но не быстро архивировать\восстанавливать и как следствие эффективно только для некоторых таблиц. Учитывая вышеперечисленные недостатки для 1С проще использовать другой метод.

 

Методика похудения для 1С – 100%

 

 

«Я беру камень и отсекаю всё лишнее.» - так творил шедевры Микеланджело, но это было долго.

В СУБД есть более простой способ - «Я беру все нужное и ничего лишнего». В этом нам поможет утилита BCP, которая позволяет выгрузить и загрузить данные таблицы в Native формате.  Допустим, мы  хотим оставить в базе данных данные оборотов в регистре бухгалтерии, только за 2022 год

  1. Сворачиваем остатки своей процедурой и фиксируем их под регистратором Документ.СворачиваниеОстатков на 31.12.2021
  2. Выгружаем через BCP данные из таблиц проводок включая проводки за 2022 год включая проводки Документ.СворачиваниеОстатков
  3. Делаем Truncate всех таблиц регистра бухгалтерии
  4. Отключаем все индексы регистра бухгалтерии кроме кластерных
  5. Загружаем через BCP данные сохраненные в пункте 2) обратно
  6. Включаем, выключенные индексы регистра бухгалтерии
  7. Пересчет итогов

Далее примеры скрипта для некоторых таблиц и индексов регистра бухгалтерии

Детально про BCP можно почитать тут:  Утилита BCP

 

П 1

_RecorderTRef = 0x00004248 документ регистратор остатков

П 2

bcp "SELECT * FROM [%2].[dbo].[_AccRgED677] WHERE _Period > CONVERT(datetime, '%3 %4', 120) OR _Period = CONVERT(datetime, '%3 %4', 120) AND _RecorderTRef = 0x00004248" queryout %5\_AccRgED677.bcp -a 16384 -b 10000 -S %1 -d %2 -N -T -e %5\_AccRgED677_unload_error.log -o %5\_AccRgED677_unload_report.log

П 3

sqlcmd -S %1 -d %2 -Q "TRUNCATE TABLE [%2].[dbo].[_AccRgED677]" -o %5\_AccRgED677_truncate_report.log

П 4

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByRecorder_RNN ON [%2].[dbo].[_AccRgED677] DISABLE"

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByExtDim_RR ON [%2].[dbo].[_AccRgED677] DISABLE"

П 5

bcp [%2].dbo.[_AccRgED677] IN %5\_AccRgED677.bcp -a 16384 -b 10000 -h "TABLOCK" -S %1 -E -N -T -e %5\_AccRgED677_load_error.log -o %5\_AccRgED677_load_report.log

П 6

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByRecorder_RNN ON [%2].[dbo].[_AccRgED677] REBUILD"

sqlcmd -S %1 -d %2 -Q "ALTER INDEX _AccRgED677_ByExtDim_RR ON [%2].[dbo].[_AccRgED677] REBUILD"

П 7

Пересчет итогов

 

Про предварительные бэкапы, и контрольные отчеты до и после включая аналитику я писать не буду, поскольку это не инструкция для американских домохозяек. Структура базы данных подробно изложена тут Структура базы данных 1С совершенно открыто поэтому не стоит боятся манипуляций с данными напрямую

Есть один принципиальный момент – это сортировка загружаемых данных – она должна соответствовать сортировке кластерных индексов , от этого зависит фрагментация кластерного индекса и скорость. Далее цитата из ссылки про bcp

«The sort order of the data in the data file. Bulk import performance is improved if the data being imported is sorted according to the clustered index on the table, if any. If the data file is sorted in a different order, that is other than the order of a clustered index key, or if there is no clustered index on the table, the ORDER clause is ignored. The column names supplied must be valid column names in the destination table. By default, bcp assumes the data file is unordered. For optimized bulk import, SQL Server also validates that the imported data is sorted.»

Минус у такой методики один – невозможность в BCP делать сжатые бэкапы таблиц. Размеры *.bcp файлов получаются большими, при том, что там только данные без индексов

Дальше одни плюсы

  1. Место для *.bcp файлов может быть где угодно, на любых носителях и сетевых дисках
  2. Время только тратится на выгрузку и загрузку
  3. Можно параллельно выгружать\загружать разные таблицы увеличивая общую скорость
  4. Сразу решатся вопрос с фрагментацией , а ее нужно решать при любых вариантах
  5. Можно использовать сложные выборки для актуальных данных учитывая даты оплаты и поставки.

Для большей скорости Вам нужно использовать большие размеры пакетов в BCP (параметр -a_ ) .

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

Анонс:  Увеличить широту пропускания сети либо технологиями Teamed Lan либо используя сетевые карты  с технологией RDMA. В целом настройка сети это тема отдельной статьи

Анонс: Практическая реализация подсистемы очистки это хорошая тема для отдельной статьи.

 

Коллективная ответственность за вес базы, мифы и реальность?

 

 

В любой крупной организации можно выделить системы

  • FrontOffice (где заключаются сделки, контракты, оформляются продажи)
  • BackOffice (где производятся взаиморасчеты, отражается работа по контрактам и закрытие продаж)
  • Финансовый  учет
  • Управленческий учет

Они могут совмещаться или делится в разных комбинациях, но суть в том что большинство информации там дублируется . Кроме того для финансового и управленческого учета требуются расшифровки с исходными сделками для сверок, проверок, аудиторов. И все эти базы требуют RAID с избыточным количеством дисков.  Как правило пока все умещается на текущие сервера это  устраивает разные ответственные подразделения, но когда количество сделок\операций во FrontOffice планируется увеличить на несколько сот тысяч в день, тогда простые расчеты показывают, что дублирование  начинает грозить стабильности бизнес процессов

  1. Во-первых, это все нужно обработать в регламентное время на всех уровнях без ночных смен сотрудников
  2. Во-вторых, хранить на избыточных RAID, которые тянут за собой много другой ИТ инфраструктуры

 

И этот момент хорош для внедрения агрегирования операций хотябы на уровне BackOffice – Фин\Упр учет иначе в потоке данных потонут все ИТ отделы, и это хорошая мотивация. Агрегация это непростой вопрос, поскольку она должна обязательно позволять обратную расшифровку и обновятся при изменениях задним числом.

Анонс: Варианты агрегации с расшифровкой это тема отдельной статьи.

Теперь можно подвести итоги:

Держать базу в фиксированной форме, означает внедрение подсистемы, которая работает на регулярной основе. Мы живем во время производства избыточных данных. Делитесь своими приемами обрезки базы, подключайтесь в наш канал. Как создать удобную подсистему по обрезке данных в 1С  – тема отдельной статьи, пишите, если эта тема интересна. 

Администрирование Партицирование Сжатие Удаление Данных Свертка

См. также

Оптимизированная свертка Бухгалтерии 3.0

Свертка базы Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Платные (руб)

Расширение позволяет за 1-2 дня свернуть базу с десятками миллионов документов. Использует оптимизированный алгоритм определения документов, на которые нет ссылок, для последующего удаления 16 фоновыми заданиями. Не помечает документы на удаление.

38400 руб.

08.02.2024    480    7    0    

2

Многофункциональная выгрузка из 1С:УТ 11/ УТ 10 в 1С:БП2, БП3 (соответствия товаров, контрагентов, складов, статей ДДС)+Свёртка по НДС

Обмен между базами 1C Оптовая торговля Свертка базы Платформа 1С v8.3 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Хотите точно знать, что вы выгружаете? Хотите сворачивать товары по НДС или фильтровать товары по доп. реквизиту? Вы волшебник, которому необходимо превращать одних контрагентов в других? Хотите при выгрузке превратить группу товаров в один? Или просто нужен удобный OLE обмен между 1C:Управление торговлей (ред. 11 или 10) и 1С:Бухгалтерия предприятия (ред. 2 или 3). Тогда эта обработка для вас!

10900 руб.

19.04.2013    168422    350    395    

327

Обрезание базы 1С

Свертка базы 8.3.8 Конфигурации 1cv8 Россия Управленческий учет Платные (руб)

Механизм обрезания базы 1С. Описан процесс переноса среза остатков в копию базы. Представлено прикладное решение - обработка по переносу данных. Реализован способ обмена между базами без длительного отключения рабочей базы.

7200 руб.

27.03.2023    4166    11    2    

13

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7632    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5976    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8862    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16181    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. МихаилМ 28.07.22 16:58 Сейчас в теме
Феодальное мышление в ит автору мешает.
непонятно кто автор: админ бд или программист.
как автор допустил такие времена резервирования-восстановления.
автор рассмотрел базы не как админ , а как прикладник.
дискового пространства должно быть как грязи.
похоже бд смешанного типа олап-олтп. это и удобство и проблема.



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

посмотрел размер таблиц - база микроскопическая - несколько гигабайт. обычно проблемы начинаются с стократ большего.
kser87; Gilev.Vyacheslav; Светлый ум; palsergeich; Ilia_Bastrykin; +5 Ответить
3. 1CUnlimited 304 28.07.22 17:53 Сейчас в теме
(1)
(1)
посмотрел размер таблиц - база микроскопическая - несколько гигабайт. обычно проблемы начинаются с стократ большего.

Непонятно какая у Вас функциональная роль на работе (менеджер, программист , администратор?) , но с цифрами невнимательны
Пример самая большая таблица с индексами которую я привел - 935 854 848 Кб это 892 Гб .
А цифры это важно, для всех
И там только топ таблиц.
Времена резервирования - восстановления не допускаются , а согласовываются. Напр фронт и бэк требуют короткого времени восстановления поэтому в MS SQL применяют Always on , а в Oracle stand by database на резервном сервере.
Для Фин,Упр учета где всеравно идут пересчеты Т-3 политика более либеральна.
Когда решение с горизонтальным маштабированием по нагрузке см предыдущую https://infostart.ru/1c/articles/1683197/ решение типа Always on потребует хорошего пространства для хранения архиво transaction log (ms sql ) или redo log (oracle)
Кстати по поводу
(1)
дискового пространства должно быть как грязи.

оно недешевое у HP даже если это HDD , а почему некоторые компании выбирают брендовое а не сборку РФ вендоров это управленческий вопрос. Хотя я мне нравится сервис\и надежность HP пусть оно было недешево.
А капиталистический подход как раз требует чтобы ИТ директор снижал всеми силами cost ownership иначи RAID на всех не напасешься.
14. redfred 01.08.22 07:53 Сейчас в теме
(3)
Напр фронт и бэк требуют короткого времени восстановления поэтому в MS SQL применяют Always on , а в Oracle stand by database на резервном сервере


Погодите, а как соотносится восстановление и Always on?
17. 1CUnlimited 304 01.08.22 12:50 Сейчас в теме
(14) always on это не просто реплика это способ восстановления после сбоя https://docs.microsoft.com/ru-ru/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16
Чем то напоминает standby database у oracle


"Первичная реплика делает базы данных-источники доступными для соединений с клиентами для чтения и записи. первичная реплика отправляет записи журнала транзакций каждой базы данных-источника в каждую базу данных-получатель. Этот процесс, называемый синхронизацией данных, происходит на уровне базы данных. В каждой вторичной реплике кэшируются записи журнала транзакций (фиксируется журнал), а затем эти записи применяются в соответствующей базе данных-получателе. Синхронизация данных выполняется между базой данных-источником и каждой подключенной базой данных-получателем независимо от остальных баз данных. Поэтому приостановка или сбой базы данных-получателя не затрагивает другие базы данных-получатели, а приостановка или сбой базы данных-источника не затрагивает остальные базы данных-источники."
18. redfred 01.08.22 14:49 Сейчас в теме
(17) Ну, грубо говоря, это RAID для базы. А RAID, как известно, не бэкап. Т.е. если кто-то поудаляет документы на мастере, они точно так же поудаляются на репликах, разве нет? И где тут короткое время восстановление, про которое вы пишете, если всё равно придется поднимать полноценный бэкап?
24. 1CUnlimited 304 01.08.22 16:50 Сейчас в теме
(18) Восстановление до нужной Recovery point (времени в прошлом) делают на практике только, если был непоправимый сбой (напр медленно падал диск с bad блоками, которые развалили таблицы бд) . Из за пользователя который поудалял что нибудь - такое будут делать только в случае временной выгоды (ведь нужно еще всех уговорить переввести данные от Recovery point till now) и отсуствия конфликтов интересов (напр. с клиентом).
Always on в асинхронном режиме по сути равен Standby database в Oracle и можно управлять запаздыванием в асинхронности.
У microsoft и oracle решения на эту тему похожи, но картинки у Oracle интересне см
https://www.oracle.com/a/tech/docs/cloud-maa-overview.pdf
20. nicxxx 254 01.08.22 15:58 Сейчас в теме
(1)Глаза режет. Сначала научитесь писать грамотно по-русски, используя знаки препинания и нужные падежи.
2. МихаилМ 28.07.22 17:35 Сейчас в теме
"см мою старую статью на эту тему http://selis76.narod.ru/matnetw1.html#bookmark1"
статья недописанная - только введение.
4. 1CUnlimited 304 28.07.22 17:56 Сейчас в теме
(2)
Там если по содержанию слева прокликать все выводится, я когда то написал ее в WebMaker нужно освежить.
5. Virikus 61 28.07.22 19:34 Сейчас в теме
Немного непонятно сколько времени занимает копирование данных за 2022 год и обратно. Если таблица большая, значит полчаса на это не хватит, а при таких объемах технологическое окно как правило не более полчаса в сутки. И тут секционирование более выгодно смотрится. Там можно спокойно удалять старые данные в процессе работы пользователей.
1CUnlimited; +1 Ответить
6. 1CUnlimited 304 28.07.22 20:09 Сейчас в теме
(5) Мы можем обеспечить себе технологическое окно в воскресенье 100% + субботу если необходимо. Скорость копирования зависит от носителя + скорость сети куда копируешь. Еще заметьте при таком способе через BCP , сохраняется меньше данных чем удаляется.
Не помню точных цифр но полную свертку остатков по регистру бухгалтерии с удалением лишнего + пересчет делали часов за 6

Но если технологические окна очень маленькие, то да секционирование без вариантов. Просто в 1С все всеравно все не секционируешь (банально документ с табчастью или регистр бухгалтерии), как следствие делать систему 24\7 на основе 1С бессмысленно с точки зрения архитектуры.
9. Virikus 61 29.07.22 16:27 Сейчас в теме
(6) Тогда не совсем понятно на какую группу статья расчитана, если у вас есть технологическое окно в часть субботы и воскресенья, то спокойно можно делать delete с отбором, никто все равно не мешает. Для небольших предприятий с большими базами так даже удобней, скрипты будут проще и контроль за ними требует меньше подготовки от специалиста. Даже удалять можно в 100 потоков, если отключить табличные и страничные блокировки и отбор накладывать например по неделе.

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

Подход конечно интересный, но судя по таблице у вас там в основном регистры сведений. Может стоит немного архитектуру поменять? Например хранить буфер сообщений не 2 месяц, а например 3 дня или сколько вам необходимо, для разбора обращений. Или выгружать часть данных в сторонние системы, а по мере надобности через web, http их получать. 5Tb конечно база не маленькая, но и не такой прямо великий размер, чтобы создавались большие неудобства для работы с ней.
10. 1CUnlimited 304 30.07.22 07:24 Сейчас в теме
(9) к bcp мы пришли именно на удалении движений регистра бухгалтерии после свертки средствами 1с. Весь цикл еле укладывался в выходные и запаса на рост данных не было. Bcp сразу много проблем решает.
Вы не можете растянуть удаление после свертки остатков на несколько техно окон. Тоже для регистров опер учета
Регистры сведений/документв можно чистить порционно по выходным с распарралеливанием.
Но потом Вам нужно большое тех окно на устранение фрагментации
Вы еще бонусом получаете мощную обработку для создания тестовых баз
Те у кого маленькие окна должны в архитектуре закладывать обслуживание бд частями что кстати bcp метод позволяет
Есть еще один момент связанные обьекты напр по ведущему измерению - обычным удалением это будет еще дольше
По поводу удаления в 100 потоков вы просто посмотрите на waits
P S буфер это просто sql база вне 5тб 1с. Там xml запросы и скорость импорта обеспечивается. Он партицирован
Как нибудь про него отдельную статью напишу
11. 1CUnlimited 304 30.07.22 07:31 Сейчас в теме
(9) Статья прежде рассчитана на тех кто хочет знать техпределы 1с и кому надоела неповоротливая база :)
KilloN; METAL; +2 Ответить
7. ixijixi 1775 28.07.22 21:58 Сейчас в теме
5Tb! Мое почтение)) Максимум 100Гб база, которую обслуживал. Ну и один раз видел базу в 1.5Тб =)
NeLenin; smit1c; 1CUnlimited; +3 Ответить
8. 1CUnlimited 304 28.07.22 23:20 Сейчас в теме
(7) Импортозамещение скоро сделает большие размеры баз 1C частым являением :)
METAL; SergeyTerentyev; NeLenin; Krotov_Valery; ixijixi; +5 Ответить
12. CheBurator 3119 30.07.22 19:26 Сейчас в теме
" в целевые сроки восстановления (Recovery Time Objective) и согласуются с Business continuity planning"
Business continuity planning - синонима на вменяемом русском не нашлось?
13. 1CUnlimited 304 31.07.22 15:04 Сейчас в теме
(12) термины это не только слова это еще методика / решения которую разрабатывают за бугром . Поэтому стараюсь приводить их в исходном виде чтобы было проще найти. Когда Россия будет ИТ лидером
мы сможем насаждать свои термины как со спутником
15. Nikola23 696 01.08.22 10:35 Сейчас в теме
Партицирование таблиц средствами платформы обещали в 23м релизе.
Может быть будет полезным, может нет для задачи урезания БД.
Будем посмотреть.
16. 1CUnlimited 304 01.08.22 11:55 Сейчас в теме
(15)а есть ссылки на источники? Просто для регистра сведений и справочников 1с может это сделать без изменения структуры таблиц, а для остальных метаданных уже придется фундаментально менять
21. nicxxx 254 01.08.22 16:04 Сейчас в теме
(16) "Управление табличными пространствами базы данных (возможность размещения части БД на самом быстром диске) "
https://wonderland.v8.1c.ru/blog/obnovlyen-plan-zadach-na-versiyu-8-3-23-platformy-1s-predpriyatie-4/
23. kembrik 10 01.08.22 16:38 Сейчас в теме
(21) Так партицирование немного про другое, нет?
CRE ATE   TABLE bigtable_y2021m03 (   
    CHECK (created_at >= '2021-03-01'::DATE AND created_at < '2021-04-01'::DATE) 
  ) INHERITS (bigtable);
CRE ATE   TABLE bigtable_y2021m04 (    
    CHECK (created_at >= '2021-04-01'::DATE AND created_at < '2021-05-01'::DATE)  
  ) INHERITS (bigtable);


Вот тут партицирование - третий квартал отдельно, четвертый отдельно - к Airflow раздельно прикрутили и наслаждаемся

А то что 1С в 23 платформе предлагают - условно говоря отдельные таблички, скажем бинарники с содержимым файлов в отдельные БД вынести
29. 1CUnlimited 304 02.08.22 11:37 Сейчас в теме
(23)

(23)
Вот тут партицирование - третий квартал отдельно, четвертый отдельно - к Airflow раздельно прикрутили и наслаждаемся


Делить таблицы с Airflow итересная вещь, с точки зрения автоматизации скриптов. Но непонятно как 1С будет иметь доступ к таким таблицам. Ведь в теории можно их во view объединить с именем таблицы 1С, но оно будет неполноценно для всех операций
(могу только для MS SQL утверждать, Postgres не изучал)
https://docs.microsoft.com/en-us/sql/relational-databases/views/modify-data-through-a-view?view=sql-server-ver15

Партицирование реализовано по более продвинутой идеологии (кратко с примером тут)

https://habr.com/ru/post/464665/?ysclid=l6bx25fkez388567642
25. 1CUnlimited 304 01.08.22 16:59 Сейчас в теме
(15)
(21) Я тут погуглил по термину ""Управление табличными пространствами базы данных" и нашел свежее
https://wonderland.v8.1c.ru/blog/segmentatsiya-dannykh/?ysclid=l6at8zdglq290137106
Короче это банальное разделение таблиц и индексов по разным файловым группам, и к партицированию вообще не имеет отношение.
27. nicxxx 254 02.08.22 05:52 Сейчас в теме
(25) (23) Киберпанк, который мы заслужили :)
Пусть хоть это будет...
evgeniti; 1CUnlimited; +2 Ответить
35. evgeniti 3 08.08.22 18:00 Сейчас в теме
(27) когда-нибудь будет всё в 1с. И свистелки и прочие п..ремудрости.
19. Velifer 01.08.22 15:54 Сейчас в теме
Тю, я б ваши 5 терабайт за ночь свернул бы готовым отлаженным за 7 лет решением и методикой с контролем ссылок, без какого либо битья

Простой минимальный, конфа любая, целостность базы полная, таблицы - любые

Но есть люди принципиальные - тратят месяцы своего времени и на порядки большие деньги компании, чтобы сделать свой велосипед, сначала моноколесо, потом трехколесный, потом четыре колеса ... в общем, проходя все ошибки предшественников
22. redfred 01.08.22 16:21 Сейчас в теме
(19) Где можно почитать про ваше решение?
26. Velifer 01.08.22 18:39 Сейчас в теме
(22) Если интересно, напишите в личку.
Но вообще я много про свои методики рассказываю и не один год.
Сейчас я минимум одну новую базу в месяц сворачиваю, от 80 Гб до нескольких терабайт

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

Также несколько лет разрабатываю решения для разделения и слияния баз 1С

Например, вы хотите выделить некоторые организации в отдельный узел РБД или просто продать часть бизнеса и отдать базу.
Я это делаю за 30-40 минут

Или наоборот, хотите сделать слияние распределенной базы. Я это делаю обычно за ночь.
Решения проверенные, так что всем желающим могу помочь :)
Светлый ум; +1 Ответить
36. evgeniti 3 08.08.22 18:40 Сейчас в теме
(26) Глядишь, придет время и можно будет в менеджере пакетов выбрать пакет MegaChistka авторства топикстартера, вашей или чьей-нибудь ещё и каждый сможет свернуть 100 тб базу.
38. garbal1 18.05.23 16:08 Сейчас в теме
(26) интересен метод в личку не могу написать
39. Velifer 19.05.23 10:45 Сейчас в теме
28. olexandrit 02.08.22 11:01 Сейчас в теме
(26) Добрый день! Где можно почитать про Вашу методику? Спасибо.
30. 2tvad 70 03.08.22 23:05 Сейчас в теме
Странно. Если у вас это торговые операции, то маржа вполне должна позволить поставить очень хорошее оборудование.

Хотя я сталкивался с тем, что дилинговые операции тянули в бухгалтерию.

А вы не пробовали решить задачу от обратного, т.е. создавать базу на каждый год, путём переноса справочников и остатков?
31. 1CUnlimited 304 04.08.22 09:10 Сейчас в теме
(30) обрудование очень хорошее. Еще в 14 году raid из 2 тб ssd и 5 тб hdd и все HP. Новый кластер 2021 года еще лучше.
Просто учитывать приходилось операции 4 систем и никто не хотел давать direct access для расшифровок из системы источника даже внутри компании. Это для крупных ит систем не просто.
Перенос в новую базу сложнее -нужно все подсистемы сворачивать и резать одновременно. А так это можно делать по частям. В файловых группах появится свободное место. Да самим группам shrink file будет сделать проблематично изза разбросанных экстентов, но достаточно держать базу в фиксированном размере и этого достаточно
32. 2tvad 70 04.08.22 14:21 Сейчас в теме
(31) Еще в 14 году raid из 2 тб ssd и 5 тб hdd и все HP.

У меня домашний сервер - 8 дисков sas в 6 рейде + ssd nvme PCI RAID 0 под базы. Ну это под меня одного =)

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

перенос вам нужен только справочников и остатков. Сворачивать и резать не обязательно.
33. 1CUnlimited 304 04.08.22 16:12 Сейчас в теме
(32)
(32)
перенос вам нужен только справочников и остатков. Сворачивать и резать не обязательно

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

И не сравнивайте серверные SSD и домашние SSD они очень разные. При тех IOPS которые у нас за 8 лет ни один не вылетел, а на персоналках падают регулярно
- просто посмотрите картинку не самого лучшего и ценники
https://buy.hpe.com/emea_europe/en/options/drives-storage/solid-state-drives/storage-solid-state-drives/hpe-msa-1-92tb-sas-12g-read-intensive-sff-2-5in-m2-3yr-wty-ssd/p/r0q47a
34. kser87 2438 05.08.22 17:06 Сейчас в теме
37. kembrik 10 09.08.22 17:05 Сейчас в теме
(29) У нас задача немного не такая. Есть управленческий регистр накопления, который в 1С хранить нет необходимости да и незачем. Есть симулякр создание движения по этому регистру "как нам надо"

В Postgres создаем мастер-таблицу и к ней дочерние партиции наследованием (inherits), в 1c сервис со справочником, где СКД-шки к нужным данным с периодом "между".

В airflow один поток на одну партицию, обновили партицию - данные доступны в мастер-таблице. Причем к этой мастер таблице можно подцепиться хоть внешним источником данных.

Но вот касательно к теме "похудения" наш вариант отношения не имеет, у нас задачи чуть другие)
1CUnlimited; +1 Ответить
Оставьте свое сообщение