Регенерация RecID

[Gelios]

Добрый день.

Мы столкнулись с очень серьезной проблемой. А именно с необходимостью регенерировать RecID в одной из компаний нашего клиента. Axapta 3.0 SP2 работает чуть более полутора лет. БД на MS SQL около 70GB. Проблема в том, что для этого у нас есть окно в 24 часа. Клиент работает 24 часа 7 дней в неделю и согласен остановить бизнес только на 1 сутки!

В тестовой базе регенерация станадтнымы средствами Аксапты заняла около 40 часов. Причем 90% этого времени занимает регенерация 7 самых крупных таблиц.

Есть ли у кого-нибудь опыт оптимизации этого процесса?

Мои личные испытания привели к улучшению на 20%, что все равно недостаточно. Я добился этого путем изменения индекса на переходной таблице AXOLDTONEWRECIDS. В оригинале было
CREATE INDEX AXOLDTONEWRECIDSIDX ON AXOLDTONEWRECIDS (OLDRECID)
изменил на
CREATE INDEX AXOLDTONEWRECIDSIDX ON AXOLDTONEWRECIDS (OLDRECID,NEWRECID)
Это позволило уменьшить количество операций чтения по этой таблице, т.к. SQL получает всю информацию из индекса и нет необходимости читать саму таблицу.

Может у кого есть получше идеи, покоординальнее?

В принципе, теоретически существует возможность регенерации RecID в онлайн режиме. Может кто-то уже делал это?

Заранее благодарен за ответы.

[Gelios]

Я смог добится еще 48% ускорения за счет удаления индексов, содержащих RECID перед UPDATE и последующим индексированием.

В сочетании с "улучшенным" индексом по AXOLDTONEWRECIDS описанным ранее ускорение составило 68%!

Если раньше, по стандартному алгоритму Аксапты, обновление RecID в CUSTINVOICETRANS занимало 4 часа 2 минуты, то теперь у меня на это ушло 1 час 14 минут вместе с переиндексированием. Переиндексирование заняло 3 минуты (Это ничто по сравнению с основным update'ом)

Может кто сможет лучше?

[DmitrySt]

Цитата:

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

А именно с необходимостью регенерировать RecID в одной из компаний нашего клиента.

А Вы могли бы объяснить, отчего возникла такая потребность - перегенерировать Recid, что под собой подразумевает этот процесс, что получается в результате и зачем это вообще надо?

[glibs]

Цитата:

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

...
Может кто сможет лучше?
...

При оптимизации производительности нечасто можно дать совет, который даст ощутимый эффект во всех случаях (при различном стечении обстоятельств (количество записей в таблицах, по которым выполняется запрос; особенности самих данных, например, количество компаний в терминах Аксапты, которые в одной базе живут; особенности конфигурации железа и ПО; ну и т.д.) та или иная ручная оптимизация запросов может дать как положительный, так и отрицательный эффект). Исключением является явная ошибка разработчика, когда закладывается ошибка, которая приводит к тому, что запрос работает плохо во всех или почти во всех случаях. Как, например, в данном случае, когда перед массовым обновлением таблицы в ней не удаляются индексы, в которых есть обновляемые запросом поля, особенно, если такие индексы являются кластерными (это первое, что мне сразу пришло в голову, когда мне пришлось оптимизировать процедуру дефрагментации RecId).

Не могу сказать, лучше это или нет...

В общем, мне на MS SQL Server существенно помогло принудительное использование loop join вместо hash join в указанном вами запросе. Могу увереноо сказать, что данное действие даст ощутимый эффект только в том случае, если обе (надеюсь, все понимают, о чем идет речь) таблицы не будут помещаться в кэше SQL Server. И оно вполне может не дать (тесты не проводил) ощутимого эффекта, если база относительно невелика, а оперативной памяти на сервере относительно много.

Если кому-нибудь понадобится сделать дефрагментацию на большой базе, я готов предоставить готовый код для тестирования (пока он не оттестирован на большой базе и не доказал свою эффективность, выкладывать его не вижу смысла). Самому пока проверить его на большой базе не доводилось, к сожалению.

Ну и очень много чего зависит в данной процедуре от того, насколько шустрым является дисковый массив. Судя по скорости работы стандартной процедуры, у Gelios он довольно мощный. Это как раз тот редкий случай, когда имеет смысл поиграться ручной оптимизацией размещения файлов на диске (вынести AXOLDTONEWRECIDS на отдельный диск).

А за науку про оптимизацию запроса за счет использования обращения только к индексу с меня лично большой респект.