Обрезка большой 1С. Обрезать или не обрезать?

На протяжении уже лет пятнадцати мы сталкиваемся с вопросом типа: «А вы уверены, что без обрезки (свёртки) никак?». Речь идет о многотерабайтных базах 1C: десять лет назад это были базы 1-2 Тб, а сейчас это уже десятки Тб. Специалисты меняются, железо становится мощнее, но вопрос остаётся.

Пожалуй, можно поделить участников этого опроса на две группы: «Резать к чёртовой матери» и «Полный бред резать базу – нужно правильно обслуживать и заложить нормальную архитектуру». Мы не адепты ни той, ни другой позиции, хотя статья и посвящена обрезке. Всё зависит от ситуации, симптоматики, и мы постоянно занимаемся обоими направлениями. Где-то можно оптимизацию проводить и купировать боль, а где-то требуется уже смотреть в сторону свёртки. Если у вас большая база, то почти всегда процесс проходит так – сначала попытки оптимизации, а только потом, после взвешивания всех рисков, – обрезка. И вот это «потом» может растянуться на несколько лет.

В интернете много написано как резать, чем резать, но после прочтения вопросов становится только больше. И самый главный: «Нам уже резать или есть еще способы удержать систему на плаву без скальпеля?».

Поговорим о том, что обычно остаётся за кадром: о причинах, рисках, сомнениях и этапах, которые придётся пройти обеим командам — заказчику и исполнителю. Инструменты тоже немного затронем – куда без них.

Да, сразу оговорюсь: буду чередовать по тексту «свёртка» и «обрезка», так как, если не вдаваться в этимологию терминов, это, в общем-то, всё об одном и том же с точки зрения конечного результата.

Зачем резать, если и так всё работает?

Еще раз акцентирую внимание, что речь идёт о больших базах данных размером 3, 5, 10, 20 и более Тб. Любые манипуляции с такими базами сами по себе всегда длительные и высокорискованные. Да и их администрирование тоже не подарок. Перечислю ряд особенностей, которые сопровождают такие системы и которые в конечном итоге, вместе или по отдельности, и становятся триггером к началу проекта обрезки:

Регламентное обслуживание: не пересчитанные статистики и индексы

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

Как раз в больших базах данных существующего технологического окна зачастую не хватает даже для пересчета статистик, я уж не говорю про индексы, и часть из них остаётся не пересчитанными. Соответственно при дальнейшем росте объема базы данных обновление статистик будет происходить всё хуже (не успевать за тех.окно), одновременно будет нарастать эффект падения производительности из-за неверного выбора плана запроса. По той же причине будет расти негативных эффект из-за необслуженных индексов (фрагментация).

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

Для MS SQL: Записки оптимизатора 1С (ч.14.1). Любите свою базу данных и не забывайте обслуживать
Для Postgres: Записки оптимизатора 1С (ч.14.3). Отличия в обслуживании статистик в MS SQL и в PostgreSQL
Архивирование: размер бэкапов и скорость снятия/восстановления

Тоже важная метрика, которая может иметь решающее значение. Математика тут простая: чем больше размер БД, тем больше размер бэкапов и тем дольше производятся копирование и восстановление из резервных копий. Скорость восстановления напрямую влияет на требования к отказоустойчивости – скорости отработки инцидент падения базы.

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

А еще не забываем про парк тестовых копий/стендов, где разные группы специалистов что-то разрабатывают, тестируют, оптимизируют, и им постоянно нужно разворачивать копии, переносить их и т.п.
Обновление конфигурации 1С (не хватает времени на реструктуризацию)

Это, наверное, одна из наиболее весомых метрик для владельцев системы. Невозможность обновить или своевременно обновить конфигурацию несет значительные финансовые риски для бизнеса.

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

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

В конце концов какая-то одна или сразу несколько проблем обязательно станет решающей в вашей большой 1С, и вы произнесете: «Всё, давайте начинать проект обрезки».

Других сценариев нет, но все стоят до последнего)).

Поэтому поговорим теперь о ТЗ, т.к. это очень интересный этап проекта, который вскрывает и вытаскивает на поверхность много сопутствующих проблем в вашей ИТ-системе.

Особенности обрезки больших баз данных

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

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

Ресурсоёмкость операций свёртки – сильно нагружается оборудование. При свёртке не просто физически удаляется большой массив данных, но также выполняется множество сопутствующих ресурсоемких операций: различные отборы, проверки, группировки, индексация, логирование, перемещение данных между таблицами и прочее. Этот факт особенно важен потому, что сворачиваемая база данных, как правило, и без того является высоконагруженной, и избытка мощностей у неё нет.
Помехи пользователям. Выполнять свёртку непосредственно в рабочей БД параллельно с работой пользователей крайне затруднительно или вовсе невозможно из-за высокой дополнительной нагрузки и блокировок, создаваемых процессом свёртки. На таких масштабах баз при адекватном сроке выполнения обрезки блокировки практически неизбежны, даже если резать чисто скриптами на уровне СУБД. И вместе с высокой нагрузкой они станут стоп-фактором.
Нет технологического окна. Технологического окна достаточной длительности, когда не работают пользователи, для выполнения свертки просто нет. Ведь процесс свёртки для баз такого размера – это обычно десятки часов или несколько дней. Мы встречали пример, где заказчик сворачивал базу несколько недель.
Высокие риски при свёртке непосредственно рабочей базы. Подход, когда алгоритм свёртки применяется непосредственно в рабочей базе, сам по себе является высоко рисковым по целому ряду причин. Одна из них – возможности для финальной верификации результатов свёртки очень ограничены (нет времени).
Неприемлемая длительность итерационного подхода. Можно попробовать обойти узкое место технологического окна, выполняя обрезку в продуктивной базе небольшими порциями, размер которых подбирается под доступные окна. Однако этот путь обычно неприменим: процесс растягивается на недели или месяцы, механизм свёртки усложняется, значительно растут издержки на поддержку бесперебойной обрезки в течение столь длительного срока и риски проекта в целом.
Как сжать пустоты в файле данных? В ходе удаления исторической информации из базы, её файл данных на самом деле не уменьшается (а зачастую даже несколько увеличивается), просто внутри него возникают огромные пустоты. И от них надо как-то избавиться, чтобы файл данных уменьшился. Иначе теряется выигрыш с точки зрения дискового пространства. Один из вариантов — выполнить типовой SHRINK. А на таких объёмах это весьма длительная процедура (многие часы, или даже десятки часов).

Все это нужно иметь в виду и составлять ТЗ, учитывая эти задачи.

Немного о техническом задании на обрезку большой 1С

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

Перечислю несколько моментов, к которым стоит внимательно отнестись: что-то сразу прописать, а что-то запланировать на будущее.

Возможное упрощение требований.

В большинстве случаев заказчик понимает, что просто выбрать дату обрезки – недостаточно, всегда есть подводные камни, нюансы, усложнения. Т.е. нельзя написать ТЗ одной фразой: «Пусть это будет 31 декабря 20хх года, отрежьте всё, что ранее этой даты», и требуется провести анализ базы данных.

В контексте задачи обрезки объекты 1С можно условно разделить по следующим укрупненным признакам:
- Периодические таблицы – те таблицы, в которых по колонке с датой можно однозначно интерпретировать, к какому периоду учета относится эта запись. Как правило объем именно этих таблиц имеет наибольшее значение при обрезке базы данных.
  
  В частности это:
  - Заголовки (шапки) документов и связанные с ними их табличные части
  - Журналы документов
  - Периодические регистры сведений
  - Регистры накопления
  - Бухгалтерские регистры
- Непериодические таблицы – условно постоянные: справочники, регистры сведения (непериодические), константы. Зачастую и среди этой категории таблиц находятся такие, которые удаётся обрезать, и тем самым получить существенный дополнительный выигрыш по объёму. Но так бывает не всегда. Поэтому для грубой прикидки можно считать, что эти данные по большей части остаются в системе как есть. По крайней мере, на первой итерации.
- Индексы. Их размер тоже вносит весомую долю в общий объем, поэтому их не забываем учитывать.
Есть еще вспомогательные/служебные таблицы, но их доля в общей массе, как правило, очень мала.

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

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

Здесь работает правило Парето – 80% объема находится в 20% таблиц (регистры сведений, накопления, бухгалтерский). На самом деле пропорция даже круче получается, учитывая общее количество таблиц в базе 1С. Основной вклад вносит не 20% таблиц, а буквально 1-2 таблицы какого-нибудь регистра бухгалтерии.

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

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

Это другая крайность. Заказчик говорит, что «У нас так много исключений, столько ветвлений – этот регистр можно обрезать только по эту дату, а этот вид документов вообще трогать нельзя» и т.п.

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

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

Заказчик долго настаивал на «сложном ТЗ», четыре месяца анализировал свою систему: распутывал клубок взаимосвязей объектов, бизнес-процессов и т.п. Он три раза выходил к нам с якобы завершённым описанием, но при нашем анализе каждый раз обнаруживались неучтённые ветки. В итоге заказчик признал: учесть все сложности изначально выбранным подходом в разумные сроки и бюджет невозможно. Зато анализ показал альтернативные пути – что упростить, чем пожертвовать, даже переписал отдельные механизмы. Получилось прозрачное ТЗ с хорошим эффектом.

Еще пример. В некоторых компаниях часто встречаются требования с неравномерной глубиной хранения данных. Например, страховые компании могут пожелать хранить данные по договорам по 15+ лет в оперативной базе. Естественно, при таком требовании обрезка как-то сразу выглядит печальной. Нужно искать компромисс. Один из таких вариантов ниже.
Создание архивной базы.

Архивные базы делятся на два типа:
- «База-памятник», в которой содержатся данные от начала времен до даты обрезки. И всё. Новых данных в ней не появляется. Таковой становится исходная база по состоянию на дату обрезки и больше не обновляется – замораживается.
- Архивная база в актуальном состоянии. В этом случае в базе остаются не только все исторические данные, но и постоянно дополняются свежими оперативными данными. И вот как раз такая концепция архивной базы помогает упростить ТЗ и расширить спектр свёртки, более смело порезав какие-то сложные объекты. Схематично статусы баз данных можно изобразить так:
  
  БД1 – исходная база до обрезки. Может стать «базой-памятником» при выборе такой стратегии.
  
  БД2 – обрезанная БД1, которая стала новой оперативной базой, и все пользователи переключились на работу в ней.
  
  БД3 – архивная база, постоянно обновляемая из оперативной БД2. В ней работают (эпизодически) только те пользователи, которым нужны исторические данные, отсутствующие в БД2.
Естественно, архивная база, которая непрерывно синхронизируется с оперативной базой гораздо более привлекательный вариант.
Гигантские таблицы в базе. Обычно это какой-то регистр сведений с blob-полями. Но он настолько большой, что в продуктивной системе базе его трогать нельзя – сразу блокировки, нагрузка на диск, сильное потребление памяти. Даже если его обрезать, все равно остается проблема shrink. Так что, если у вас есть такие таблицы, нужно обратить внимание на стратегию их обрезки.

Методика обрезки

Проблематика озвучена, предпосылки тоже. Теперь про подход Softpoint к обрезке. Он не единственно возможный, он лишь тот, который мы для себя наработали и обкатали на десятках проектах за 15 лет, начиная еще с 1С 7.7.

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

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

В основе подхода – принцип обеспечения непрерывности работы системы, даже в период непосредственной обрезки. Обрезке подвергается не рабочая база, а её копия. Поэтому сама процедура обрезки, а также следующие за ней операций сжатия (shrink) и верификации данных пользователям, могут быть любой требуемой длительности.

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

Постарался визуализировать процесс обрезки, разбив его на этапы.

Этап 1. Подготовка. Разворачивается копия продуктивной БД, которая и будет обрезаться. Параллельно запускается и настраиваться механизм репликации посредством программы DB Replication, которая последовательно, с точностью до транзакции, накапливает в своей базе все изменения, которые происходят в исходной базе данных. Т.е. временем начала обрезки можно считать момент создания копии продуктивной базы + запуск DB Replication. Объём накапливаемых изменений в принципе не ограничен и определяется скорее предоставленным дисковым пространством, нежели какими-то жесткими границами. По нашему опыту максимальный период изменений, который приходилось накапливать в DB Replication – 1,5 месяца. Но чаще он измеряется несколькими днями. А основное время на проекте – это различные подготовительные и организационные работы, подготовка скриптов, пробные обрезки, стресс-тестирование и т.д, так называемый этап 0, который за рамками этой статьи.

Этап 2. Обрезка.

Пока накапливаются изменения в DB Replication, разработчики начинают применять тот механизм, который они опробовали и в котором уверены. Это может быть что-то на базе типовой свертки от 1С или что-то самописное. Не имеет значения. Главное, нет жестких временных рамок – сколько нужно, столько времени и режь. В копии базы никто не работает, нет взаимного влияния разработчиков и пользователей, процесс прогнозируем и управляем.

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

Важное замечание. Поскольку база данных очень большая, то даже простой/обычный Select становится тяжелым. Поэтому очень важны характеристики дисков. Очень! В идеале не должно быть ограничений по IOPs или пропускной способности (Мб/сек), что сплошь и рядом встречается в облачных сервисах. Если вы планируете сворачиваться в облаке, то обращайте внимание на свой тариф и предоставляемые характеристики по дискам и CPU – верхняя планка должна быть достаточно высокой.

Этап 3. Финальное тестирование, верификация

Вопросы функционального тестирования относятся скорее к подготовительному этапу 0, его я не описываю. А здесь имеется в виду верификация данных, т.к. очень легко обрезать что-то лишнее и заметить это не сразу. Естественно, на нулевом этапе верификация тоже предусмотрена и проводится, а на финальном тестировании тестировщики обычно идут по готовым скриптам, ничего нового не изобретая. Но случаи бывают разные. Например, не раз бывало такое, что, несмотря на детальную проверку в тестовой среде на нулевом этапе, заказчик проверял систему на третьем этапе более недели (а однажды – больше месяца) – тщательно и всесторонне с привлечением специалистов разного профиля.

Для проверок разворачивается копия(и) обрезанной БД (на схеме ее нет, чтобы еще больше не загромождать), и все сверки пользователи проводят в ней, не боясь что-то испортить.

Приведу перечень проверок. Кому-то он покажется избыточным, кому-то наоборот. Все зависит от постановки задачи – что будет подвергнуто обрезке.

Проверка итогов регистров. В контрольной БД и в свёрнутой БД сформировать различные отчеты с идентичными настройками/параметрами. Результат должен быть идентичным.
Проверка отсутствия битых ссылок. В свернутой БД построить различные отчеты за период сразу после обрезки, проверить отображение регистраторов. Битых ссылок быть не должно.
Проверка полноты справочников. Количество элементов в эталонной и обрезаемой БД совпадает. Отсутствуют битые ссылки.
Проверка полноты регистров сведений. Количество элементов в эталонной и обрезаемой БД совпадает. Если речь идет о периодических РС, то количество должно совпадать за выбранный период.
Проверка закрытого периода. В контрольной БД и в свёрнутой БД сравнить дату периода и список пользователей, которым разрешено вносить изменения в закрытом периоде. Дата и список пользователей должны совпадать.
Проверка различных настроек БД. Сравнить Константы и настройки: обмен с внешними системами, с мобильными приложениями, уведомления, web-сервисы.
Проверка выполнения ключевых регламентных операций

a.       Расчет себестоимости
b.       Закрытие отчетного периода
c.       Какие-то производственные операции

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

Этап 4. Прокачка очередей (изменений) из DB Repliction

Прокачка запускается тогда, когда все процедуры верификации завершены и обрезанная база признана успешной. Далее осталось загрузить в нее все те изменения, которые вносились пользователями на протяжении всей обрезки и накапливались в виде очередей на сервере DB Replication. Прокачка очередей занимает от нескольких часов до нескольких дней. Зависит от интенсивности работы пользователей с исходной базой, а также от абсолютного времени на этапах 1-3. Поскольку прокачка очередей – это не мгновенное событие, то в параллель с нею продолжает накопление новых данных. Пользователи работают, старые очереди прокачиваются, а новые – накапливаются. И в какой-то момент времени обе базы становятся полностью синхронными. В таком состоянии базы могут работать неограниченное количество времени, которое требуется, например, для подготовки инфраструктуры к переключению пользователей.

Этап 5. Переключение пользователей

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

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

Создание архивной базы

Правильнее написать, что это «Этап 6. Архивная база». На схеме его нет. Он касается дальнейшей судьбы исходной, а теперь уже архивной БД. Как говорил выше – она может остаться в статическом состоянии, а может стать постоянно обновляемой, и все данные в ней бут актуальными.

Про первый сценарий всё понятно, он не сильно интересный, хотя чаще всего в головах именно он.

Поговорим лучше про второй. Если на проекте заранее обговаривается присутствие в ИТ-контуре компании актуальной архивной базы данных, то в момент переключения пользователей в обрезанную базу данных репликация DBReplication включается в обратную сторону, и теперь все изменения, которые вносятся в обрезанную базу автоматически попадают в архивную.

Такой сценарий использования архивной БД позволяет более гибко подойти к правилам обрезки и оставить в оперативной базе действительно самое необходимое, а редкоиспользуемые данные оставить на уровне архивной БД, но при этом при необходимости пользователи могут получать отчеты любой глубины, включая интервалы с текущими оперативными данными. Причём, даже самый «тяжёлый» отчёт никак не повлияет на производительность оперативной базы данных, потому как будет сформирован в архивной базе.

Отмечу еще одну полезность от использования DBReplication в режиме «Оперативная БД » Архивная БД». Раз уж этот инструмент в вашей ИС теперь используется на постоянной основе, то имеет смысл этим же инструментом поддерживать парк тестовых копий БД. Оперативная база большая даже после обрезки, и каждый раз разворачивать свежий бэкап для тех или иных задач – это время. Поэтому схему выше можно легко расширить и подключить к репликации дополнительные базы-получатели. На рисунке ниже они названы «Парк тестовых копий».

Итого

Предвосхищу возражение, что, мол, можно порезать всё штатными средствами, без всяких DB Replication. Скорее да, чем нет. Но это будет стоить нервов и разных других полезных ресурсов.

Ещё раз. Помним, что у нас огромная база с терабайтами данных. Если методами 1С резать ее на живую, то это ОЧЕНЬ медленно, блокировки и нагрузка на ресурсы. В этот момент работать пользователям практически нельзя. На копии, по схожей методике, тоже можно, но следует держать в уме, что синхронизация такой огромной базы средствами типовых обменов 1С – это большая нагрузка на сеть, большое число блокировок и большая вероятность потерь в данных. Но попробовать стоит – у вас есть этап 0, где всё сразу станет понятно.

Чем больше мы выполняем таких проектов (обрезка или миграция), тем больше убеждаемся, что в них присутствует очень большой уклон в сторону производительности. И компетенции в ней важны чуть ли не больше, чем скриптология и понимание бизнес-логики: нужно уметь и делать замеры различных метрик производительности, контролировать оптимальные планы запросов, контролировать и создавать нужные индексы и т.д. Обязательно это имейте в виду – в команде по обрезки должны быть такие специалисты.

Зафиксируем все плюшки от обрезанной БД:

Сокращение времени регламентного обслуживания базы данных:
- Обновление статистик будет укладываться в технологическое окно;
- Появится возможность настроить периодический пересчет наиболее важных фрагментированных индексов;
И как следствие — можно ожидать увеличения производительность базы данных.
Сокращение времени на резервное копирование и восстановление из резервных копий.
Снижение потребности в дисковых ресурсах за счет уменьшения объёма базы, объема её бэкапов, и парка ее тестовых копий;
Сокращение времени обновления конфигурации 1С в тех случаях, когда требуется реструктуризация крупных объектов 1С, подвергшихся обрезке; это особенно актуально в тех случаях, когда в ИС 1С используется «обычный» режим реструктуризации;
В некоторых случаях также возможно снижения продолжительности пересчета текущих итогов (и итогов за иной ограниченный период) по крупным регистрам, подвергшимся обрезке;
Для запросов, план которых подразумевает сканирование таблицы/кластерного индекса, можно ожидать серьёзного ускорения, т.к. скорость такого запроса линейно зависит от размера таблицы. Например, это могут быть какие-то поиски с «LIKE», выборки с условиями, не попадающими в селективный индекс или попадающие, но значения в отборе не селективные и т.п.
Когда механизм обрезки однократно разработан и применён, появляется возможность применять его регулярно для повторных обрезок (например, раз в год), тем самым предотвращая чрезмерное увеличение базы в будущем.

Особенности обрезки с помощью DB Replication:

Отсутствие риска порчи данных – все операции удаления данных выполняются исключительно в копии базы.
В период обрезки копии базы, пользователи продолжают работать в системе обычным образом и вносить в нее новые данные. Программа DB Replication зафиксирует все внесённые изменения и отразит их в копии базы с сохранением транзакционной целостности и последовательности по завершении процедуры обрезки.
Создание архивной базы данных, которая всегда содержит актуальные данные посредством онлайн репликации программой DB Replication. Такая база будет полезна для пользователей, создающих тяжелые аналитические отчеты с большой глубиной данных и при этом не мешающих оперативной работе остальных пользователей.

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

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

P.S. Данная методика и технология используется нами не только для обрезки больших баз, но и для миграции ИТ-систем на другую СУБД (MSSQL -> Postgres) или обновления платформы 1С. Кому интересно, вот список статей с соответствующими примерами:

ссылка на оригинал статьи https://habr.com/ru/articles/1029472/