Partilhar via

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

  • Artigo

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'

ANDNAME = ' 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.

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

RecID Scripts.zip

Comments

  • Anonymous
    December 26, 2006
    Спасибо!
  • Anonymous
    December 28, 2006
    Спасибо за интересную статью!На самом деле хотел задать вопрос по поводу "Уменьшения дыр в нумерации RecID". Все закончилось на самом интересном месте - установке курсора в начало "дыры". А что дальше? Дыра рано или поздно закончится :-( И пойдут снова использованные RECID. Этот момент нужно же каким-то образом отследить и установить курсор в начало новой дыры.А если учесть тот факт, что RECID выделяются не по одному, а "пачками" по 25, по-моему, отследить момент становится еще тяжелее.Нет ли мыслей по этому поводу?У нас есть реальная проблема, связанная с этим. Диапазон RECID напоминает лоскутное одеяло. Почти в каждой сотне тысяч использовано по сотне RECID. Очень хочется "навести порядок". Но, база большая и штатная процедура будет работать очень долго. Поэтому очень важны и интересны любые, даже абсурдные идеи
  • Anonymous
    January 10, 2007
    Операция по использованию скриптов трудоемка и практически невозможна, если у Вас окружение 24х7 (невозможность останова делает невозможным РУЧНУЮ операцию по поиску и по выставлению нового номера).   На самом деле проблема выглядит так:
  • Оцените возможность перехода на Dynamics AX 4.0. Допустим, у Вас есть год, раньше переходить не собираетесь.
  • Подсчитайте рост данных в месяц, сделайте прогноз, хватит ли пула номеров до перехода.
  • Если нет – рассмотрите вариант приблизить срок перехода.
  • Если же и это невозможно, только тогда используйте скрипты.   Последовательность запуска:
  • Изменить и запустить gapFinder.sql. В результате Вы получите таблицу eeRECID, которую можно сортировать и просматривать по наибольшему количеству дубликатов. В скрипте есть пример для таблицы InventLocation.
  • Изменить и запустить gapFinder2.sql. Из созданной на первом шаге таблице можно получить доступные интервалы RecID. Пример результата есть в самом сценарии..
  • Пожалуйста, при необходимости, измените параметр сравнения во втором сценарии (по умолчанию – 10000000)
  • Когда получены параметры открытых интервалов, необходимо изменить значение в таблице SYSTEMSEQUENCES на начало большого открытого периода, как было описано ранее. Причем периоды должны быть достаточно большими для возможности работы (и заполнения RecID) в течение приемлемого времени.   Установка курсора в начало ‘дыры’ – ручная операция, отследить сложно, Вы правы. Но (зная номер конца пула из созданных ранее таблиц) можно установить оповещение и сравнивать текущее значение в таблице SYSTEMSEQUENCES с номером. Настоятельно рекомендуется запускать скрипты для тестовой базы данных, а не в рабочем окружении. Запуск первого скрипта идет достаточно долго и требует (обязательно) достаточного tempdb. Строго говоря, скрипты – заготовки, можете расширить, автоматизировать для облегчения своей задачи по решению  проблемы - замечательно.
  • Anonymous
    August 01, 2007
    Риторический вопрос - а зачем вообще было сделано размазывание уникального идентификатора по таблицам в рамках компании ? Какие преимущества это дает в отличии от стандартного автоинкрементного идентификатора путь даже не в таблице , а в рамках компании в таблице ?
  • Anonymous
    August 20, 2007
    Прошу прощения за задержку с ответом, не совсем понятен вопрос, что с чем сравнивается?