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

[glibs]

Цитата:

Сообщение от DPO

...
Проблема в том, что RecId могут переполниться даже за год!
...
По прогнозам на следующий год RecId не хватит даже с учетом дефрагментации
...

За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?

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

Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.

[db]

Цитата:

Сообщение от DPO

Проблема в том, что RecId могут переполниться даже за год!

Как тут уже правильно заметили дело скорее всего в алгоритмах постоянно генерящих данные, которые живут недолго и снова и снова пересчитываются (какой нито самодельный модуль или сводное планирование). Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц

SystemSequence позволяет создавать свои нумераторы на основе того же механизма что используется для RecId и TransId

Пример могу дать, но попозже

[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 с помощью дефрагментации.

[DPO]

Цитата:

Сообщение от glibs

За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?

На данный момент у нас не 4 миллиарда с хвостиком, а примерно 2.5. Хранятся в основном в транзакционных таблицах InventTrans, InvetnTransPosting, LedgerTrans и тд.

Цитата:

Сообщение от glibs

Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.

Пока только 2.5 заполняются, но да, не мусором. Через год по прогнозам вполне вероятно и 4. От этого немусора за старые периоды избавляемся, но не чаще раза в год.

[DPO]

Цитата:

Сообщение от db

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

Сводного планирования нет. Самописные модули есть, генерят в районе 15% RecId в системе.

Цитата:

Сообщение от db

Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц

Очень интересно. Не понял, почему так можно делать только для "полувременных" таблиц. Почему тоже самое нельзя сделать с остальными?

Цитата:

Сообщение от db

Пример могу дать, но попозже

Хотелось бы примерчик. Буду очень-очень благодарен!

[glibs]

Скорость, с которой вы заполняете БД, впечатляет. С учетом того, что вы даже склад не закрываете (а то бы у вас InventSettlement был бы в числе больших таблиц). То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках. Но здесь развивать эту тему с учетом ваших планов не целесообразно.

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

[DPO]

Цитата:

Сообщение от glibs

То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках.

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

Цитата:

Сообщение от glibs

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

У нас отключены компании (-INTERNAL=NODATAAREAID). Так сложилось еще до меня, из-за производительности. Я тоже не рассматривал этот вариант потому как производительность у нас не на высоте. Но все равно спасибо, подумаю в эту сторону.

[db]

Обещанный пример "самодельных" RecId для 3.0
В вложении проект с парой классов и джобом

джоб также повторю здесь

static void recIdExtraTest(Args _args)
{
    mSequence_RecIdExtra    seq = new mSequence_RecIdExtra();
    RecIdExtraTest          recIdExtraTest;
    int                     i;
    ;
    // эта строка запрещает для таблицы раздачу стандартных RecId
    // должна быть выполнена до начала пользования новым нумератором
    // например можно поместить в appl.startupPost()
    new SystemSequence().suspendRecIds(tablenum(RecIdExtraTest));
    
    
    for (i = 1; i <= 1000; i++)
    {
        // Раздача самодельных RecId
        recIdExtraTest.(fieldnum(Common, RecId)) = seq.value();
        recIdExtraTest.insert();
    }
}

Если перекрывать insert() и писать код по присвоению RecId в нем, то имеет смысл сделать singleton для mSequence_RecIdExtra поместив его в GlobalCache или непосредственно в Applicаtion

Присвоение RecId только вручную. Возможности глобально сказать что для таких то таблиц брать RecId из нового нумератора нельзя (даже перекрыв insert() могут остаться вызовы doInsert() и вставка через RecordInsertList). Родной режим потабличного RecId в трешке хоть и есть, но неработоспособен (поищите на форуме)

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

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

В вашем случает наверняка имеет смысл сделать это для SalesParm*/PurchParm* таблиц

[glibs]

Цитата:

Сообщение от DPO

...
чем плохо такое соотношение записей в этих таблицах.
...

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

[Vadik]

DPO, простите, все же можете показать Ваши top 20 таблиц по количеству записей (из праздного любопытства пока спрашиваю)

Цитата:

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

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

[Vadik]

Я на выходных еще немного подумал и вот что получается
- Вам придется реорганизовывать ("укладывать параллельно") все таблицы, потому что иначе нельзя (ну, небезопасно по крайней мере) сдвигать "назад" счетчик в SystemSequences, чтобы потом не нарваться на неуникальность сгенерированного RecId
- Это означает что придется где-то прописать все связи по RecId
- Алгоритм ацки усложнится по сравнению со стандартным, который заточен на то, что значения RecId в пределах компании все же уникальны
Т.е. в общем случае решение довольно сложное и не очень живучее получается. С другой стороны, если у Вас только небольшая часть функционала используется, то можно попробовать

[kostass]

При анализе результатов запроса

Цитата:

Сообщение от Vadik

select dataareaid, name, nextval from systemsequences order by nextval desc

ориентируемся на самый большой nextval?

У нас самый большой прирост в компании dat, это нормальная картина в трешке?
dat SEQNO -780 699 868

У кого есть опыт достижения нуля по RecID, поделитесь.
Наша база 1, 292 ГБ и проводить операции по Проверке кодов записей затратно по времени, бизнес работает 24 на 7.

Есть ли вариант подцепить свежую БД с обнуленным RecID, ну естественно перезалив справочники, последние проводки?
Или это архи сложная задача "залить документы и проводки за месяц" из старой базы в новую?

[Logger]

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

[kostass]

Еще вопрос
По моему, после проведения операций Проверка кодов записей, запрос к systemsequence уже не покажет реальной картины?

[Kasper]

7 лет...

Цитата:

Сообщение от kostass

У кого есть опыт достижения нуля по RecID, поделитесь

Я это делал. И на Ax 3 и на Concorde XAL. Результат -- успешно.
Я делал средствами БД (MS SQL и Oracle на Concorde)
Это именно дефрагментация. Поэтому если всего в БД записей под 2^32 это поможет ненадолго.

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

На этом форуме я писал под ником Yaroslav Batozskiy,потом потерял пароль и завёл себя как Kasper