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

[egorych]

Провожу сейчас исследование на тему дефрагментации, поскольку RecID уже за -1.6 млрд перевалил. Что обнаружил, применимо к Oracle -
строка 103, mainLoop -

this.executeUpdate('CREATE TABLE AXOLDTONEWRECIDS (OLDRECID NUMERIC(12), NEWRECID NUMERIC(12), CONSTRAINT PK_AXOLDTONEWRECIDS PRIMARY KEY (OLDRECID)) ORGANIZATION INDEX');

убрав слова "ORGANIZATION INDEX" - получил уменьшение времени расчета с 2 СУТОК до 2 ЧАСОВ!
Собственно CONSTRAINT PK_AXOLDTONEWRECIDS ИМХО можно безболезненно убрать!

[Vadik]

Недавно вместе с одним из пожелавших остаться неизвестным участников "отдефрагментировали" RecId :

Вводная:
- Несколько (порядка 10) компаний, три крупных
- Одна виртуальная компания
- Максимальный RecId 1843756363
- Размер БД около 280Гб (SQL Server 2008)

Проблемы:
- основная, разумеется, размер БД и ограниченное временное окно на выполнение процедуры
- стандартный механизм обладает некоторыми "особенностями":
- при запуске по всем компаниям компаний эффект "сжатия RecId" может снижаться или полностью отсутствовать
- при запуске по одной компании неправильно делается обновление ссылок по RecId на таблицы в виртуальных компаниях и "общие" (SaveDataPerCompany=No) таблицы
- хотелось хранить историю маппинга "старых" и "новых" значений RecId для разбора непредвиденных проблем

Как обходили:
- модифицирован класс SysRecRepair, добавлен небольшой фреймворк для регистрации "проблемных" ссылок (описание "проблемных" ссылок см. выше, определение ссылок делается вручную)
- исключили (средствами фреймворка) из обработки некоторые большие "непостоянные" таблицы (SysDatabaseLog, SysUserLog, xRef)
- переконфигурировали некоторые параметры БД на время обработки (отключение RCS, auto update statistics и пр.)
- настроили partitioning по DataAreaId
- временно удалили некластерные индексы с RecId на таблицах, где их более одного
- сохраняем временную таблицу маппинга "старых" значений RecId на "новые"

Результат:
- Количество обработанных записей по всем компаниям - 2850036022
- Максимальный RecId - 180862996 (сжатие приблизительно в 10 раз, благо были достаточно большие "дырки" в выделенных RecId)
- Вся процедура заняла около 12 часов, из них работа класса SysRecIdRepair около 7 часов.

Ограничения:
- Анализ имеющихся проблемных ссылок по RecId в виртуальные компании не автоматизирован (выполняется вручную)
- Версии для Oracle нет (пока)
- Обработка нескольких виртуальных компаний есть, но не протестирована

Код не выкладывается (по крайней мере пока), воспринимайте данный пост как некий whitepaper плюс "тестовый забег"

P.S. - в "простых" случаях (одна компания) стандартный механизм работает корректно

[Vadik]

Также см. альтернативный подход от Gustav