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

[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.