Как выполнять дефрагментирование RecID

[DPO]

И все таки он существует. Да, бизнес генерит много RecId.
На данный момент за месяц счетчик RecId увеличивается на 250 000 000 в месяц. Из них примерно 160 000 000 - существующие записи, остальное - пустоты в RecId. Для комфортного существования системы в течение 14 месяцев без экстренной дефрагментации на грани, скорость потребления RecId быть меньше чем 4 200 000 000 / 14 = 300 000 000 RecId в месяц, что в условиях растущего количества отгрузок может быть достигнуто достаточно быстро, уже в следующем году, а дальше - больше. Взял 14 месяцев потому что архивирование базы предполагает закрытие года в старой (архивной) базе, это с запасом.
То есть проблемы есть, не обманываю я вас.

Проблемы с производительностью тоже есть, но в следующем году их планируется решить переходом на новое оборудование и новый оракл. Понятно, что тройка с ее узким местом в inventSum`е помрет и на самом производительном железе. Продление жизни бизнеса на аксцапте 3.0 описанным выше способом рассматривается только как временная мера до перехода на САП.

Поэтому, коллеги, помогите чем можите. Хотелось бы услышать ваше мнение о реализации потабличного RecId с помощью дефрагментации.