И все таки он существует
. Да, бизнес генерит много 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 с помощью дефрагментации.