Обрезка большой 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-сервисы.
Если свертка производится на уровне таблиц базы данных, то можно дополнительно верифицировать данные по таблично, например сверять хэш-суммы по таблицам, которые не подвергались обрезке.
Проверка выполнения ключевых регламентных операций
Должны быть идентичные результаты расчета в обрезанной бд с контрольной БД.
- Расчет себестоимости
- Закрытие отчетного периода
- Какие-то производственные операции

Этап 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С. Кому интересно, вот список статей с соответствующими примерами: