Уф. Пообещал..
Не буду говорить конкрентно о прогнозом - у нас оба подверглись изменениям, да и класс один. Также, чтобы не постить проекты и код (что даже не могу сделать по соображениям этичность к коллегам), буду просто предлагать свои личные соображения.
Сразу хочу предупредить - проблема многогранна. Что-то одно может и не помочь.
В соседней ветке уже писал, но сильно рекомендую:
1) Поставить KR3 + база в режиме 9-ки, + (уже писал на форуме) использовать SQL Native Driver (по статистике сервера самые большие ожидания на старом).
Кстати, не пропутите проект SQLTraceUtility из KR3, он лежит в папке "Navision\Client\Appl\"
2) Обязательно действовать наверняка !. Нужно точно знять - где проблемы. Сильно помогают скрипты отсюда
http://www.microsoft.com/technet/scr....mspx?mfr=true ННапример, в секции "Waitstats"
3) Если сводное используется с пересозданием плана, то, конечно, стоит написать на x++ код, которые генерирует TRUNCATE TABLE с нужными джойнами и просто за раз чистит таблицу.
4) Если п.3 невозможен - проверьте или просто поверьте, что при большой кол-ве одинаковых запросов на удаление или сложных агрегатов (с INVENTSUM), бывает очень выгодно - сначала по индексу проверить есть ли записи вообще (без джойнов на INVENTDIM, разумееется), а потом уже делать, что хотели. Возможно, покажеться, глупым, - попробуйте, удивитесь
Например (из RecCalc)
select firstonly recId from reqTrans where ...
5) Изучая план доступа для режима найдите такие запросы, которые не выбирают все поля таблицы - например только ITEMID, ITEMPLAINID, QNT - и сделайте по ним индекс. Не бойтесь новых индексов (даже с полями типа qnt), но и разумно тоже - начинает больше тормозить UPDATE, INSERT, DELETE, зато летает на SELECT.
Общий подход - как можно реже допускать вычитку из хипа (по кластерному ключу, и, особенно, по букмарку), раз уж надо перебрать 100 тыс записей - то только по индексу.
6) У меня, практически на всех "тяжелых" таблицах кластерный ключ по индексу RECID. Это было непростое решение, несколько раз отказывался, но все равно возвращался к этому. В первую очередь помогает там, где есть высокопроизводительные курсорные обновление (Аксапта генерирует обновление строки по reciD). Причин для этого много - можно даже небольшую статью писать ;-) Да, и не забудьте, что кластерный ключь по-умолчанию, включается в каждый не кластреный индекс.
7) Правила создания индексов надо знать - учитывать и селективность и порядок полей и стиль использование вообще. Если не уверен насчет индекса, - чатсо просто удляю его из кода - Юкон сам решит, и эффективнее меня.
8) Особенная проблема с INVENTDIM. Красиво по дизайну, но правильный план доступа делать тяжело. В конце концов: Кластер по recID, а вот рабочий индекс должны быть таким, чтобы первым шел inventDimID, а потом поля, наиболее селективные с точки зрения дизайна номенклатуры - у нас inventBatchId, InventLocationId. Практически везде, где было принципиально, запретил Акспте хинтовать эту таблицу на джойнах.
9) InventTrans - довольно самостоятельный принцип - кол-во индексов увеличил в 2 раза под различные группы плана доступа.
10) Если встречал "универлальные" хинтовалки - выключал, например в INVENTSUM::queryAddHint - это профанация.
11) Сразу убираем forcenestedlookup и forceselectorder
12) На InventSum у нас иключение - по причине большого числа открытых проводок, кластерный индекс, пока, Closed, ItemId
Ну и в завершение - процесс всегда итерационный.
Надо учитывать, что код кое-где код ориентируется на порядок извлекаемых записей. Изменение плана доступа на одной таблице может перкосить план доступа к другой, в джойне. По мере роста базы данных план доступа придеться менять, иногда координально.
Удачи !