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

[Falcon]

Вот говорят: если проблемы с производительностью, то проверьте, насколько оптимизированы ваши запросы.

Берем функцию Accounts Receivable->Periodic->Sales Update->Invoice (да простят меня за английские названия...).
Нажимаем кнопочку Select.
В ней указаны следующие поля:
SalesLine - Stopped = No
SalesTable - Giro money transfer slip on sales invoice = None.
Больше ничего не указано, хотя разумеется, есть скрытые поля ограничений (SalesLine-Type = SalesOrder, SalesLine-Status= Delivered...)
Нажимаем кнопочку OK

И тут случается чудо
Иногда "ответ" появляется в течение 10 минут
Иногда - через 3 часа (!)
Иногда выскакивает Deadlock on SalesLine (при том, заметьте, что в Аксапте один-единственный юзер!)

Пытаемся делать SQL Statement Trace Log (с ограничением: время запроса выше 1000 мс) - получаем такие результаты

Execution time Record size Records per fetch
2202 2962 8
5256 5315 4
1229 559 43
4917 5315 4
3861 2488 2

Execution time, разумеется, в миллисекундах.

То есть две записи из SalesLine выбираются в течение почти четырех (!) секунд.

Всего записей в SalesLine - 140 тыс, в SalesOrder - 60 тыс.

Почему так? Почему одна и та же выборка по одной и той же таблице, в одних и тех же примерно условиях (количество юзеров, нагрузка на систему и пр.) - занимает время, разнящаеся на порядки? В нормальном состоянии один fetch ведь по идее должен занимать десятки миллисекунд, не больше?

Да, и откуда вообще берутся дедлоки?

По-моему, проблема локализована до предела - и тем не менее, я не вижу, как ее решить.

Помогите, пожалуйста.

Спасибо.

П.С. Ax 3.0 SP2, Intl, IMTS выключена

[Morpheus]

А что в Канадских компаниях DBA для обслуживания баз данных на работу не берут?

[itfs]

Праздники на носу, стоит ли так расстраиваться?
До оптимизации запросов вы еще не добрались, следует посмотреть план запроса.
Что касается dead Lock-ов, в данном случае, по-моему, это не причина, а следствие. 3-х часовой запрос в ms-sql (я правильно угадал?) это уже криминал, на это "Софтверный гигант" никак не мог расчитывать ...

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

[Falcon]

А на что мне надо обратить внимании при изучении плана запроса?

В Канадских компаниях, равно как и в российских, предпочитают экономить и брать специалиста "все-в-одном". Впрочем, я уже четвертый год неплохо справляюсь.

[Falcon]

Цитата:

Праздники на носу, стоит ли так расстраиваться?

Между прочим, у кого праздники - а кому-то пахать без перерыва всю следующую неделю. Даже на маевку не отпустят, капиталисты проклятые!

[itfs]

Цитата:

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

А на что мне надо обратить внимании при изучении плана запроса?

Для начала на то, какие индексы используются для поиска записей. Если вы "все-в-одном", то можно не мучиться с планом сразу. А посмотреть для начала на таблице какие индексы созданы и соответствует ли это логике выборки данных в нашем случае, умозрительно, так сказать. Условия выборки должны так или иначе присутствовать в индексах.

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

[Falcon]

Индексы соответствуют.

Выборка идет по SalesID и LineNum, такой индекс в этой таблице есть.

Да и потом, если б дело было в индексах - то этот запрос каждый раз выполнялся бы долго. Логично? А так - он 2 дня работает нормально, а на третий... Раньше помогала перезагрузка сервера БД - но теперь и после нее затык...

[itfs]

Тогда конечно сложнее....

А уточните пожалуйста:
1. после того как затык наступает, производительность навсегда остается плохой или потом может "отпустить"?
2. Вы используете 2-х звенную или 3-х звенную конфигурацию?

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

[ALES]

Цитата:

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

Помогите, пожалуйста.
П.С. Ax 3.0 SP2, Intl, IMTS выключена

Текст этого запроса опубликуйте

[Falcon]

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

Может я глупость скажу, но такое ощущение, что в таблице время от времени появляются "неправильные" записи, на выборку которых тратится уйма времени. Вопрос, отчего они могут стать "неправильными"?...

Спасибо!!!!!!!!!!!!!!!!

[Falcon]

Цитата:

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

Текст этого запроса опубликуйте

Ну держитесь

SELECT A.SALESID,A.LINENUM,A.ITEMID,A.SALESSTATUS,A.LEDGERACCOUNT,A.NAME,A.EXTERNALITEMID,A.TAXGROUP,A.QTYORDERED,A.SALESDELIVERNOW,A.REMAINSALESPHYSICAL,A.REMAINSALESFINANCIAL,A.COSTPRICE,A.SALESPRICE,A.CURRENCYCODE,A.LINEPERCENT,A.LINEDISC,A.LINEAMOUNT,A.CONFIRMEDDLV,A.RESERVATION,A.SALESUNIT,A.DIMENSION,A.DIMENSION2_,A.DIMENSION3_,A.PRICEUNIT,A.INVENTTRANSID,A.CUSTGROUP,A.CUSTACCOUNT,A.SALESQTY,A.SALESMARKUP,A.INVENTDELIVERNOW,A.MULTILNDISC,A.MULTILNPERCENT,A.SALESTYPE,A.BLOCKED,A.COMPLETE,A.REMAININVENTPHYSICAL,A.TRANSACTIONCODE,A.TAXITEMGROUP,A.DEL_CONFIGID,A.TAXAUTOGENERATED,A.UNDERDELIVERYPCT,A.OVERDELIVERYPCT,A.BARCODE,A.BARCODETYPE,A.INVENTREFTRANSID,A.INVENTREFTYPE,A.INVENTREFID,A.ITEMBOMID,A.LINEHEADER,A.SCRAP,A.RETURNACTIONID,A.INVENTTRANSIDRETURN,A.INVENTDIMID,A.TRANSPORT,A.STATPROCID,A.ESTIMATEGROSS,A.ESTIMATENET,A.PORT,A.CUSTOMERLINENUM,A.PACKINGUNITQTY,A.PACKINGUNIT,A.INTERCOMPANYINVENTTRANSID,A.SICPARENTINVENTTRANSID,A.SICSALESQTYKITITEM,A.SICINVENTBOMJOURNALID,A.SALESPROJECTCODE,A.MODIFIEDDATE,A.MODIFIEDTIME,A.MODIFIEDBY,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.RECID FROM SALESLINE A(UPDLOCK)  WHERE ((DATAAREAID=?) AND (SALESID=?)) ORDER BY A.DATAAREAID,A.SALESID,A.LINENUM OPTION(FAST 9)

[Morpheus]

Цитата:

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

Раньше помогала перезагрузка сервера БД - но теперь и после нее затык...

Какая у Вас используется БД?

[Falcon]

Цитата:

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

Какая у Вас используется БД?

MS SQL Server 2000 SP3a

[Morpheus]

Цитата:

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

MS SQL Server 2000 SP3a

К примеру Oracle позволяет промониторить состояния индексов, таблиц, блокировок и т.д. через системные представления... А также все проблемы в базе пишет в log файл...

[itfs]

Цитата:

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

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

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

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

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

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

[Falcon]

Я для монироринга использую SpotLight by Quest Software. Только ни фига оно не мониторится. То есть показывает, что все ОК - кроме 200000 shared блокировок и периодического своппинга. Никаких проблем не обнаруживается.

[Falcon]

Цитата:

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

Я бы тоже на это поставил... если б не отсутствие зависимости этой глюки от количества юзеров. Т.е. хоть нас там 30 человек, хоть я один - все равно три часа. В таком случае, какие-такие могут быть "другие процессы", конкурирующие за "мою" таблицу? Аксапта вроде никакими внутренними пересчетами не занимается (IMTS, напомню, выключена!).
Барабашка?

[Wamr]

Запрос SELECT * FROM SalesLine A (UPDLOCK) WHERE ((DATAAREAID=?) AND (SALESID=?)) ORDER BY A.DATAAREAID,A.SALESID,A.LINENUM
по идеи, должен использовать индекс SalesLineIdx.
Складывается ощущение, что этого не происходит и тогда получается полный скан.
Предлагаю перестроить индекс и обновить статистики.

[ALES]

Цитата:

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

Ну держитесь

.. WHERE ((DATAAREAID=?) AND (SALESID=?)) ORDER BY A.DATAAREAID,A.SALESID,A.LINENUM OPTION(FAST 9)[/CODE]

это точно тот запрос?
"В ней указаны следующие поля:
SalesLine - Stopped = No
SalesTable - Giro money transfer slip on sales invoice = None.
Больше ничего не указано, хотя разумеется, есть скрытые поля ограничений (SalesLine-Type = SalesOrder, SalesLine-Status= Delivered...)"
ps: структуру этих таблиц не меняли перед появлением трабла?

[Falcon]

Это - непосредственно запрос сиквела.

Те поля, что я указал в начале - выбираются в Аксапте.
Наверное, это не единственный запрос, порождаемый моим нажатием кнопочки ОК - но именно он выдает сумасшедшие значения длительности выполнения.

Структуру не меняли уже несколько лет...