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

[TasmanianDevil]

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

[Vadik]

Цитата:

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

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

А можно пример? Тяжело с утра понять, о чем идет речь

[kashperuk]

Цитата:

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

А можно пример? Тяжело с утра понять, о чем идет речь

Насколько я понял, имеется ввиду, что в таблице соответствия старым RecId новых может случиться ситуация вида:

RecId (OLD) RecId (new)
124 1
45676 2
2 3

То есть произойдет замена уже замененного RecId.
Если неправильно понял, ТазманианДевил поправит.

Но такой ситуации не может быть, потому как RecId в таблице отсортированны по возрастанию. То есть таблица будет выглядеть так, на самом деле:

RecId (OLD) RecId (new)
2 1
124 2
45676 3

[Vadik]

Коллеги, одна таблица обновляется одним оператором UPDATE
Эта операция атомарная, в ней нет промежуточного состояния "первую строку обновили, вторую еще нет"
Точно так же оператор

update ledgerTrans set RecId = RecId + 1

не приводит к нарушению уникального индекса по RecId вне зависимости от того, по возрастанию индекс построен или по убыванию или как сервер будет страницы для UPDATE выбирать
ACID это называется

[kashperuk]

Ой, да. Это я Сусанин, не посмотрев код, не в ту степь повел.

Почему-то подумал, что вместо обновления потабличного (что намного производительнее, причем) делается позаписное (по RecId, и для каждого пробежка по всем таблицам).

Посмотрел код, действительно, все записи обновляются одним запросом, поэтому проблема эта - вообще не проблема.

[Poseidon-topex]

Доброго утра!

Ввиду большого кол-ва операций достигли ситуации когда RecId пошел на второй круг и в таблице CustInvoiceTrans начала появляться ошибка "Запись уже существует". Собственно, одна две записи допавляются без проблем, а вот заказ на 100 строк уже не разносится.
Т.к на других операциях ошибок не замечено, решено провести дифрагментацию RecId но только для ОДНОЙ таблицы. Т.е. дефрагметировать RecId в таблице CustInvoiceTrans и при этом счетчик глобальный счетчик RecId не трагать, так как nextValue порядка 1 млрд, а записей в CustInvoiceTrans около 100 млн. Соответственно, если дефрагментировать RecId только в этой таблице то все последующие вставки в таблицу будут проходить безошибок.

Вопрос: проделывал ли кто подобное? Аксапта 3.0 SP5, MS SQL 2005

Спасибо.

[anikulichev]

Добрый день.
Дефрагментацию recId выполняли уже несколько раз. На форуме уже писали, что и где надо подправить для ускорения. Вся операция на 80 gb базе занимает около 3.5 часов.
Поддерживаю glibs и TasmanianDevil.