aEremenko: Дефрагментация RecID

[Blog bot]

Источник: http://blogs.msdn.com/aeremenk/archi...6/1365941.aspx
==============



RecID является уникальным идентификатором в Dynamics AX (DAX), используемым для ссылок. Практически каждая пользовательская таблица имеет поле RecID по умолчанию. Системные таблицы не содержат данное поле. В DAX 3.0 RecID генерируется в рамках компании. Существует также возможность генерации RecID в разрезе таблиц, но такая опция имеет ряд проблем и не поддерживается.

Дыры в нумерации RecID могут возникнуть, например, вследствие импорта данных, удаления и последующего импорта. Таким образом, при первом импорте был выделен пул номеров для записей, при удалении записей этот пул не восстанавливается, нумерация для последующего импорта продолжит ряд с последнего значения выделенного ранее RecID. Образовалась дыра в нумерации, когда записей нет, а номера задействованы. Проблема в том, что количество номеров конечно.



Ситуация в DAX 3.0

Максимальное число RecID в одной компании равно 2^32-1 (около 4 миллиардов). Число RecID базируется на типе integer/int (32-бит).

Дефрагментация RecID состоит из 2-х фаз:

· Очистка неиспользуемых записей для прошлых / закрытых периодов

· Сжатие, уменьшение дыр в нумерации RecID



Удаление неиспользуемых данных для прошлых / закрытых периодов

Для удаления неиспользуемых данных можно использовать стандартные процедуры очистки. Они существуют практически для каждого модуля, например, Расчеты с клиентами\ Периодические функции\ Очистка\ Очистка истории обработки заказов.

Данная тема очень хорошо описана у Сергея Мазуркина



Уменьшение дыр в нумерации RecID

Результат может быть достигнут двумя путями:

1. Стандартный путь с использованием всех таблиц. Данный путь достаточно затратен по времени. Процедура может быть запущена из Администрирование\ Периодические операции\ SQL Администрирование\ Проверка кодов записей.

2. Обновление пула RecID вручную подразумевает использование прилагаемых сценариев (скриптов) SQL для идентификации больших дыр в нумерации. Сценарии выполняет следующие операции:

· Создание таблицы со всеми значениями RecID для всех таблиц;

· Просмотр созданной таблицы на наличие дыр в нумерации;

· Запись найденных интервалов дыр в другую таблицу.



Рекомендуется запускать сценарии в тестовом окружении. Прилагаемые сценарии и описываемая процедура ручного обновления RecID не являются официально поддерживаемыми процедурами компании - вендора.

После нахождения интервалов дыр, необходимо обновить значение следующего выделяемого номера RecID, установив его в начало найденного большого интервала разрыва в нумерации (дыры). Обновить значение в системной таблице, содержащей следующее значение RecID можно запросом вида:



UPDATE SYSTEMSEQUENCES

SET NEXTVAL = ######

WHERE DATAAREAID = 'dat'

AND NAME = 'SEQNO'



Где ###### - следующий номер для RecID.





Кроме того, можно использовать системный класс \System Documentation\Classes\systemSequence для управления RecID, но делать это без достаточно серьезного тестирования не рекомендуется.



Ситуация в DAX 4.0

Версия 4.0 содержит 64-битный пул RecID, RecID базируется на новом типе int64. Также, в DAX 4.0, можно сегментировать RecID в разрезе таблиц. Этого более чем достаточно для очень крупной компании лет на 100. Более того, планируется, что в 4.1. появится процедура архивации данных, позволяющая управлять данными за прошлые года и очищать их при необходимости.

Следовательно, в 4.0 проблема исчезла. Очень рекомендуется рассмотреть вопрос о переходе на DAX 4.0, если в DAX 3.0 много записей и есть проблемы с нумерацией RecID.

Если миграция невозможна в короткие сроки, можно использовать сценарии описанные выше.

Источник: http://blogs.msdn.com/aeremenk/archi...6/1365941.aspx

[СибирскийКлещ]

За статью спасибо.
А вот ...

Quote:

Originally Posted by Blog bot

RecID базируется на новом типе int64.

Не смешите.Новый он только для системы Dynamix Ax. Все остальные (компиляторы, СУБД, программы конкурентов) давно его используют.

P.S. Интересно, а был ли когда-нибудь дан ответ на вопрос "Каков сакральный смысл размазывания RecId по компании, порождающий все эти проблемы ?"

[mazzy]

Quote:

Originally Posted by СибирскийКлещ

а был ли когда-нибудь дан ответ на вопрос

Да, был. Ищите на форуме.
В двух словах - recid появился очень давно, еще когда каждая компания создавала собственную СУБД, а промышленных стандартов не было.
Сейчас recid используется по соображениям совместимости.