Аксапта. Производительность. Эпизод n+1-й

[itfs]

Цитата:

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

1. Если select завершается успешно - то дальше все идет нормально, т.е. на следующий день опять 10 минут. И так до следующего затыка. Кстати, сам инвойсинг, даже если селект был 3 часа - проходит быстро и без затычек.
2. З-звенка, тонкий клиент. Пробовал кстати запускать в двухзвенке прямо на сервере - никаких отличий.

Это была грубая попытка убедиться, что причина не прозаическая, т.е. что это не проблемы с сервером БД и не с пропускной способностью сети. Вроде, все нормально.

QUOTE=Falcon]
Может я глупость скажу, но такое ощущение, что в таблице время от времени появляются "неправильные" записи, на выборку которых тратится уйма времени. Вопрос, отчего они могут стать "неправильными"?...
[/QUOTE]
Ну в принципе, не такая уж глупость, можно и на эту тему подумать. Если индексное полу пусто (NULL), то такая строка соответствующим индексом не индексируется и при полной выборке, индекс использовать некорректно, система вынуждена отключить его использование. Но это очень специфический эффект, за тормоза редко ответственен именно он.

В вашем случае я бы поставил на возникновение конкуренции за таблицы со стороны других процессов. Т.е. этот процесс полного сканирования таблиц да еще и с блокировкой на обновление вполне может встретить много трудностей на своем пути.

С уважением, itfs.

[Vadik]

Цитата:

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

Если индексное полу пусто (NULL), то такая строка соответствующим индексом не индексируется и при полной выборке, индекс использовать некорректно, система вынуждена отключить его использование

Мы говорим об MSSQL? Какой версии? В любом случае - аксапта varchar поля null значениями не заполняет

Есть два предложения
- кластерный индекс по (DataAreaId, SalesId)
- отключение option fast на уровне конфигурации (знаю, что радикально, однако от этого, насколько мне известно, еще никто не умирал)

ну и своевременное обновление статистики, разумеется

[itfs]

Цитата:

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

В любом случае - аксапта varchar поля null значениями не заполняет

Ваша правда, и про varchar, и про не заполняет, везде стоит заполнение по default и всюду not Null constraints

[Recoilme]

Цитата:

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

Ваша правда, и про varchar, и про не заполняет, везде стоит заполнение по default и всюду not Null constraints

Интересно почему никто не добавляет при таких открытиях матные слова в её адрес? ))

[itfs]

Цитата:

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

Интересно почему никто не добавляет при таких открытиях матные слова в её адрес? ))

А чего петушиться? Не нравится лошадь, слез и пошел пешком ....
Хотя конечно иногда с непривычки челюсть приходится подвязывать.

Насчет 5-го RAID-а - присоединяюсь, для БД он менее всего подходит. Рекомендуется RAID 10 (0+1 или 1+0). Но то, что 5-й RAID именно на чтении тормозит, это не совсем правильно. У 5-ки страдает запись из-за вычисления и синхронной записи контрольных сумм. Так что конкретно указанную проблему пересборка RAID-а может не решить, хотя общий уровень подтянет.

Я бы все-таки продолжил рыть в сторону конкуренции.
А скажите пожалуйста, как вам удалось при таком кол-ве блокировок избежать эскалации? Вы что-то специально для этого делали? У вас получается очень "не агрессивный" процесс. Я бы не удивился, если бы ситуация была строго наоборот. Этот select for update полностью блокировал бы таблицу. Эта обработка отрабатывала бы стабильно, зато во время ее работы другие сессии испытывали бы затруднения при работе со строками заказов.

С уважением, itfs.