Аномальное поведение AOS+БД

[demianimp]

Всем здравствуйте!

Друзья нужна ваша помощь, с моими проблемами.
Возможно проблема одна, но проявляется в разных местах.

Проблема №1:
Пользователи начали жаловаться на зависания в работе с таблицами CustInvoiceTable и CustInvoiceTrans. Помогает ручная переиндексация таблиц, через Администрирование SQL. Но у нас каждый день выполняется переиндексация индексов у которых количество страниц больше 30 и фрагментация больше 5%.
Нормально, что нужно каждый день "вручную" переиндексировать таблицы? Или у нас неправильно работает SQL? В какую сторону смотреть?

Проблема №2:
Есть некий алгоритм, который получает информацию из обменной таблицы. Обрабатывает ее и обновляет таблицу SalesTable через update_recordset.

Проблема в том, что в одно время он работает 4 минуту, в другое отрабатывает за 24 секунды. Набор данных один и тот же. Если в это время смотреть через MS SQL Server Management Studio, то загрузка на ЦП в районе 5%, блокировок нет, ожиданий нет. Трассировка запроса через Axapta при параметре 100 мс, аномального ничего не выдает. Есть 10 запросов, которые больше 100 мс и меньше 300 мс.
Из-за чего может быть разница в работе в 3,5 минуты? В какую сторону смотреть?

[Logger]

По вопросу 1 - возможно у вас сама табличка фрагментирована. Поройте эту тему.

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

[macklakov]

Quote:

Originally Posted by demianimp

Из-за чего может быть разница в работе в 3,5 минуты? В какую сторону смотреть?

Возможно, банально сеть между SQL и AOS ложится.
А версия у вас какая?

[demianimp]

Quote:

Originally Posted by Logger

По вопросу 1 - возможно у вас сама табличка фрагментирована. Поройте эту тему.

1. спасибо, посмотрю.

Quote:

Originally Posted by Logger

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

Quote:

Originally Posted by macklakov

Возможно, банально сеть между SQL и AOS ложится.
А версия у вас какая?

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

Axapta 2009 + MS SQL 2008

[Vadik]

Quote:

Originally Posted by demianimp

Пользователи начали жаловаться на зависания в работе с таблицами CustInvoiceTable и CustInvoiceTrans

Проблемные запросы отловить пытались, планы смотрели?

Quote:

Помогает ручная переиндексация таблиц, через Администрирование SQL

Это "гильотина как средство от головы". Да, статистика от перестройки индексов обновится и что самое важное сбросится кэш планов исполнения. Если это происходит регулярно, надо разбираться почему они у вас постоянно "протухают". Версия AX? Компаний больше одной? Распределение данных неравномерное?

Quote:

Но у нас каждый день выполняется переиндексация индексов у которых количество страниц больше 30 и фрагментация больше 5%
Нормально, что нужно каждый день "вручную" переиндексировать таблицы? Или у нас неправильно работает SQL?

Ежедневная реиндексация, что ручная, что автоматическая - это ненормально. Пинайте DBA, пусть собирает статистику по запросам, вертит ее по разным критериям, анализирует - в общем, работает вместо того чтобы заниматься отписками

Quote:

Проблема №2:
..
В какую сторону смотреть?

Tools for monitoring performance [AX 2012]

[Logger]

Quote:

Originally Posted by demianimp

В этом случае трассировка долгих запросов должны выдать сообщение?

Должна конечно.

[demianimp]

Quote:

Originally Posted by Logger

Должна конечно.

А инфологов нет Вот и приходить гадать на кофейней гуще

[demianimp]

Quote:

Originally Posted by Vadik

Ежедневная реиндексация, что ручная, что автоматическая - это ненормально. Пинайте DBA, пусть собирает статистику по запросам, вертит ее по разным критериям, анализирует - в общем, работает вместо того чтобы заниматься отписками

Было бы кого пинать, обязательно бы запинал А так пока во всем виноват программис

Quote:

Originally Posted by Vadik

Проблемные запросы отловить пытались, планы смотрели?

Это "гильотина как средство от головы". Да, статистика от перестройки индексов обновится и что самое важное сбросится кэш планов исполнения. Если это происходит регулярно, надо разбираться почему они у вас постоянно "протухают". Версия AX? Компаний больше одной? Распределение данных неравномерное?

Извините, но у меня только начальные знания по администрированию SQL.
Версия AX? 2009
Компаний больше одной? конкретно в этом приложении используется одна компания.
Распределение данных неравномерное? Что это значит? Я не понимаю, объясните пожалуйста

[gl00mie]

Quote:

Originally Posted by demianimp

Было бы кого пинать, обязательно бы запинал

Обычно на предмет производительности "пинают" штатного DBA, но что-то мне подсказывает, что в данном случае его нет

Quote:

Originally Posted by demianimp

Извините, но у меня только начальные знания по администрированию SQL.

Из вас решили сделать DBA "по бразильской системе"?

Quote:

Originally Posted by demianimp

Компаний больше одной? конкретно в этом приложении используется одна компания.
Распределение данных неравномерное? Что это значит? Я не понимаю

Если у вас одна компания, то вопрос про неравномерное распределение данных к вашему случаю не относится. Обычно неравномерность проявляется в том, что в БД - несколько компаний Аксапты, при этом 80-90% данных приходится на одну из них. Из-за этого могут возникать проблемы с неоптимальными планами SQL-запросов, которые СУБД изначально строит для одной компании (скажем, с 5% данных, где подходит один индекс), а затем использует повторно такой план для другой компании, где он совсем не подходит. Подробности см., скажем, в публикации Overcoming parameter sniffing issue in Microsoft Dynamics AX 2012-R2 – CU6
См. также Troubleshooting that elusive “slowdown” in AX using Performance Analyzer 1.20 for Microsoft Dynamics

[demianimp]

Quote:

Originally Posted by Logger

По вопросу 1 - возможно у вас сама табличка фрагментирована. Поройте эту тему.

Если выполнить команды

DBCC SHOWCONTIG ('CUSTINVOICEJOUR')
DBCC SHOWCONTIG scanning 'CUSTINVOICEJOUR' table...
Table: 'CUSTINVOICEJOUR' (2067993127); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 420067
- Extents Scanned..............................: 52536
- Extent Switches..............................: 57048
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 92.04% [52509:57049]
- Logical Scan Fragmentation ..................: 1.26%
- Extent Scan Fragmentation ...................: 64.65%
- Avg. Bytes Free per Page.....................: 1151.0
- Avg. Page Density (full).....................: 85.78%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC SHOWCONTIG ('CUSTINVOICETRANS')
DBCC SHOWCONTIG scanning 'CUSTINVOICETRANS' table...
Table: 'CUSTINVOICETRANS' (35531210); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 2062292
- Extents Scanned..............................: 257851
- Extent Switches..............................: 258098
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.88% [257787:258099]
- Logical Scan Fragmentation ..................: 0.05%
- Extent Scan Fragmentation ...................: 56.01%
- Avg. Bytes Free per Page.....................: 1266.0
- Avg. Page Density (full).....................: 84.36%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Если я правильно прочитал результат, то у меня не все так плохо.

[Vadik]

Quote:

Originally Posted by demianimp

Если я правильно прочитал результат, то у меня не все так плохо

У Вас просто проблема не во фрагментации, вот и все. Натравите на свое окружение DynamicsPerf, гарантирую массу открытий чудных

P.S. Документация у него конечно не ахти (в том смысле что разбросана по разным постам в блоге), поэтому основные шаги ниже

Performance Analyzer for Microsoft Dynamics 1.20 Deployment Guide Core Installation
Performance Analyzer for Microsoft Dynamics 1.20 Deployment Guide Dynamics AX Installation

[demianimp]

Quote:

Originally Posted by Vadik

У Вас просто проблема не во фрагментации, вот и все. Натравите на свое окружение DynamicsPerf, гарантирую массу открытий чудных

Действительно DynamicsPerf хороший инструмент
Осталось понять, куда смотреть и как анализировать информацию.

[Vadik]

Quote:

Originally Posted by demianimp

Действительно DynamicsPerf хороший инструмент
Осталось понять, куда смотреть и как анализировать информацию

Как закончите его разворачивать, прошерстите весь блог PFE, это Вас займет дней так на пару - как раз столько (примерно) времени надо DynamicsPerf чтобы более-менее релевантную статистику собрать. Если к тому моменту останутся какие-то вопросы - обращайтесь, постараюсь помочь

[AlexeyS]

Quote:

Originally Posted by demianimp

Проблема в том, что в одно время он работает 4 минуту, в другое отрабатывает за 24 секунды. Набор данных один и тот же. Если в это время смотреть через MS SQL Server Management Studio, то загрузка на ЦП в районе 5%, блокировок нет, ожиданий нет. Трассировка запроса через Axapta при параметре 100 мс, аномального ничего не выдает. Есть 10 запросов, которые больше 100 мс и меньше 300 мс.
Из-за чего может быть разница в работе в 3,5 минуты? В какую сторону смотреть?

в дополнение к советам:
1. проверьте очереди к диску в Мониторе ресурсов
2. проверьте процент попадания в кеш буфера, возможно sql-серверу банально не хватает физической памяти, например так:
SELECT ROUND(CAST(A.cntr_value1 AS NUMERIC) /
CAST(B.cntr_value2 AS NUMERIC),3) AS Buffer_Cache_Hit_Ratio
FROM ( SELECT cntr_value AS cntr_value1
FROM sys.dm_os_performance_counters WHERE object_name = 'SQLServer:Buffer Manager' AND counter_name = 'Buffer cache hit ratio') AS A,
(SELECT cntr_value AS cntr_value2 FROM sys.dm_os_performance_counters
WHERE object_name = 'SQLServer:Buffer Manager' AND counter_name = 'Buffer cache hit ratio base') AS B;

[demianimp]

Quote:

Originally Posted by AlexeyS

в дополнение к советам:
1. проверьте очереди к диску в Мониторе ресурсов
2. проверьте процент попадания в кеш буфера, возможно sql-серверу банально не хватает физической памяти, например так:
SELECT ROUND(CAST(A.cntr_value1 AS NUMERIC) /
CAST(B.cntr_value2 AS NUMERIC),3) AS Buffer_Cache_Hit_Ratio
FROM ( SELECT cntr_value AS cntr_value1
FROM sys.dm_os_performance_counters WHERE object_name = 'SQLServer:Buffer Manager' AND counter_name = 'Buffer cache hit ratio') AS A,
(SELECT cntr_value AS cntr_value2 FROM sys.dm_os_performance_counters
WHERE object_name = 'SQLServer:Buffer Manager' AND counter_name = 'Buffer cache hit ratio base') AS B;

2. Какое значение в идеале 1?

[gl00mie]

Совсем в идеале дисковые очереди должны быть в пределах 1-2 операций ввода-вывода на шпиндель См. также статью SQL Server Best Practices.

[Alexius]

Можно продолжить изучение DBCC SHOWCONTIG для остальных индексов (по умолчанию выдается информация по кластерному/псевдокластерному индексу)

А проблемы 1 и 2 не коррелируют по времени ?

[demianimp]

Quote:

Originally Posted by Alexius

Можно продолжить изучение DBCC SHOWCONTIG для остальных индексов (по умолчанию выдается информация по кластерному/псевдокластерному индексу)

А проблемы 1 и 2 не коррелируют по времени ?

1 начала возникать только утром, после обслуживания базы(переиндексации и обновлении статистики).

2 проблема плавающая. Может возникнуть в 14:00, может в 16:37, может в 18:20 и т.д.