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

[DPO]

Да, извиняюсь, что сразу не рассказал.

У нас будет старт с чистого листа в эту замечательную новогоднюю ночь, видимо то, что вы имеете ввиду под архивированием. То есть текущая база станет архивной, а в новую боевую перенесутся справочники, всяческие остатки и работа начнется в чистой базе.
Проблема в том, что RecId могут переполниться даже за год! В прошлый раз подобная процедура архивирования выполнялась 2 года назад. До этого нового года дотянули со скрипом и дефрагментацией. По прогнозам на следующий год планируется увеличение отгрузок в системе. При таком росте до следующего нового года мы дотягиваем, а вот до 2013 уже нет (хотя там может и не важно, в 2012 году-то ).
Делать процедуру рхивирования чаще раза в год не вариант из-за проблем с годовой отчетностью и общей ее геморойностью. Поэтому рассматриваем такой экстремальный способ спасения.

Что думаете на этот счет? В сравнении например с переходом на новую версию?

[Vadik]

Цитата:

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

Что думаете на этот счет?

Бизнес, генерящий столько транзакций, чтобы переполнить диапазон RecId (4 миллиарда записей) за год, причем на 3.0 - как-то слабо верится. Логистика к примеру в трешке такого не вытянет, разве что самописный модуль какой-то
Либо чего-то Вы не договариваете, либо что-то не то считаете, либо как-то не так дефрагментируете (imho)
Каков текущий размер БД (в терабайтах, я полагаю) ?

[glibs]

Цитата:

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

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

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

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

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

[DPO]

Цитата:

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

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

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

Цитата:

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

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

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

[db]

Цитата:

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

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

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

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

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

[DPO]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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