Загрузка процессора на сервере БД

[Kozerog]

Добрый день!

Аксапта 3.0 СП4.

В последнее время несколько раз в день процессор сервера БД внезапно загружается на 100%, ситуация "лечится" только включением\выключением АОСа.

При этом в целом, нагрузка на систему небольшая, мало активных пользователей, нет блокировок и тд.

Не подскажите как выявить причину\процесс\функционал (если проблема в функционале)?

[kashperuk]

Может просто какой-то молодец отчетики строит напрямую на сервере? На СКЛ прямом?
Я помню у нас был один такой.

[Kozerog]

Однозначно - нет. Все под контролем.

[AndyD]

Сервер базы данных какой?

Надо смотреть, какая сессия нагружает, затем, что она делает.
А дальше по ситуации.

[Kozerog]

Процессор грузит SQL 2000

[gl00mie]

Цитата:

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

Процессор грузит SQL 2000

Ну и?.. Как говорится, все телепаты сейчас в отпуске Трассировку запросов на нем включали, смотрели? Счетчики производительности его смотрели?.. Или вы ждете, что по описанным симптомам кто-то сейчас выдаст "гениальную догадку", точно описывающую причины тормозов в вашем конкретном случае?

[mazzy]

Цитата:

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

Процессор грузит SQL 2000

Значит у вас SQL2000 постоянно занимается вычислением какой-нибудь функции.
Например, преобразованием кодовой страницы.

Для начала проверьте, что в ODBC вы выключили галочку Perform translation of character data.
http://axapta.mazzy.ru/lib/mssqlsetup/#090

Затем проверьте, что у вас установлена правильная кодовая страница. Не страница совместимости типа бла-бла-бла-Latin1-Win1251, а нормальная Cirilic_General_CI_AS

после того, как разберетесь с кодовыми страницами ищите другие функции, которые должен выплонять процессор SQL'я.

=======
А вообще говоря, позвали бы вы нормального спеца
телепатия конечно "весч", но гораздо проще посмотреть в параметры.

[egorych]

Есть такая утилитка - Qslice.exe. Ей можно посмотреть на АОСе какой юзер грузит АОС - думаю, что в этом случае и SQL. Ну и потом узнать - что юзер делает в этот момент.

[Kozerog]

mazzy: ODBC не используется в настройках (может быть стоит настроить?), кодовая страница стоит правильная.

egorych: Спасибо за совет, но АОС не грузится

[AndyD]

Посмотрите в Enterprise Manager какая сессия нагружает сервер.
Дальше, можно в профайлере посмотреть, что эта сессия делает на сервере, либо в Ax посмотреть в активных пользователях какой это пользователь и посмотреть что у него выполняется (если это Ax делает, кстати)
Вот ссылка, где это можно найти

[mazzy]

Цитата:

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

mazzy: ODBC не используется в настройках (может быть стоит настроить?),

Конечно стоит. По-умолчанию галочка включена.

[mazzy]

и еще. посмотрите план запроса.
есть ли там вычислимые функции?
какие?

[Kozerog]

В момент, когда процессор уходит в пике 100% нагрузки невозожно ничего делать: невозможно удаленно подключиться к серверу, невозможно открыть enterprise manager, все мертво...это создает проблему диагностики...

[AndyD]

Хм. А как вы тогда пришли к выводу, что загружает SQL?

[Kozerog]

Подконнектились к серверу, открыли диспетчер задачи и ждали...

[gl00mie]

запустите локально на сервере БД Performance Monitor, собирайте данные по счетчикам загрузки ЦП в целом по системе и по процессу SQL Server, поставьте соответствующему процессу mmc.exe высокий приоритет, чтобы он не затыкался, когда кто-то другой будет сильно грузить ЦП. так данные будут и более объективные, и сохраненные для последующего анализа, в отличие от графика, который рисует Task Manager

[Kozerog]

После настройки подключения АОС-а к базе через ODBC наблюдаем в логе трассирофки запросов в Аксапте следующе:

[Microsoft Business Solutions-Axapta] Unable to retrieve message for retval -1, ODBC call reason code 100,
SQLSTATE = [GNJ]
Error message []

[mazzy]

Цитата:

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

После настройки подключения АОС-а к базе через ODBC наблюдаем в логе трассирофки запросов в Аксапте следующе:

[Microsoft Business Solutions-Axapta] Unable to retrieve message for retval -1, ODBC call reason code 100,
SQLSTATE = [GNJ]
Error message []

значит неправильно настроили.

помните одно - барабашки нет!

[Alexius]

1. Вы уверены, что на сервере загрузку ЦП дает именно SQL ? Это могут быть и результаты работы например "ГиперВирусов" (почему-то их еще называют антивирусами). В этом может помочь Perfomance Monitor или Task Manager.
2. При загрузке SQL под 100%, когда Enterprise Manager не отвечает, можно попробовать найти "гадкий" процесс через Query Analyser с помощью системных ХП sp_who & sp_who2. В большинстве подобных "клинических" случаях это помогает получить информацию о spid, который грузит проц. Далее по spid из Аксапты можно попытаться узнать юзера, его породившего. Ну, а на сладкое: "допрос юзверга с пристрастием".
3. Как уже выше советовали, т.к. ситуация достаточно воспроизводимая, то запускаете с утреца Profiler, с событиями не только *Complited, но и *Started. В момент "кризиса", сбрасываете получившиеся данные в отдельную БД на другом сервере, перегружаете АОС и далее спокойно анализируете последние запросы в Query Analyser. Только не накладывайте в настройке фильтров на загрузку ЦП !!!

PS. Барабашки есть всегда и везде, просто обычно они умеют хорошо прятаться