DAX 2009: Работает очень медленно

[Qaz Qwerty]

Уважаемые коллеги, очень нужна помощь. Любые действия, связанные с большими запросами к базе данных, выполняются очень медленно. Выборки для отчетов, запрос балансов. Вот теперь переименование счетов... Тестирую в старой базе, DAX 4, переименование счета проходит за 3 минуты. В новой - за 30. Структура virtual tables и прочего, что могло бы влиять - одинаковая. Hardware никакой нагрузки не показывает, с памятью и с процессором все нормально. По всем признакам проблема с базой данных, но в чем может быть проблема - нет ни одной идеи. Что проверить?

[lev]

скорее всего в базе AX2009 берутся кривые планы запросов (используются неправильные индексы). Поэтому я бы посоветовал:
1. Выполнить реиндексацию базы из аксапты. (под рукой нет аксапты, на память находится в Администрирование \ Периодические операции, форма SQL администрирование).
2. Обновить статистику в БД.

[Wamr]

смотрите что у вас с дисками творится.

[Qaz Qwerty]

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

[Qaz Qwerty]

To Lev
1. переиндексация сделана, толку - 0. (именно из-под аксапты)
2. что такое обновить статистику не понимаю...

To Warm:
Админы уверяют что с дисками все нормально, я же вижу только место на дисках - действительно нормально.

[mazzy]

все правильно вам советуют.
поищите - обсуждалось неоднократно.

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

Цитата:

Сообщение от Qaz Qwerty

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

это правильно.
если Аксапта "считает", что изменений в таблице много (алгоритм определения недокументирован),
то аксапта начнет не изменять таблицу, а создаст новую, скопирует данные туда с изменениями, после этого удалит старую таблицу и переименует.
это делается для надежности за счет снижения скорости.

известно, что после перехода аксапта начинает считать что изменений много достаточно часто.

[lev]

Цитата:

Сообщение от Qaz Qwerty

2. что такое обновить статистику не понимаю...

поищите на sql.ru думаю найдете там ответы на свои вопросы.

[Qaz Qwerty]

Нету админа BD, а я не знаю. Хорошо, сейчас сделаю все процедуры maintenance и прочитаю что еще писали на эту тему.
Кстати еще одно странное явление - запускаю обычный while select по плану счетов и система делает выборку в странном порядке, должна же в алфавитном порядке по коду счета выбирать. Кажется с индексами беда какая то. Буду смотреть.

[Ivanhoe]

Проверьте collation в БД и SQL сервере - по-хорошему должно быть Cyrillic_General_CI_AS.

[Qaz Qwerty]

Возвращаясь к старой теме:
Мы перешли на DAX2009. Нам нужно совершить (нагрузочную) операцию в системе (переименование счетов). Это действие началось несколько дней назад и до сих пор проблемы. Переименование выполняется очень медленно. Другие проявления тоже есть... например запрос формы плана счетов с одновременным показом баланса занимает несколько минут, для бухгалтеров это повод сходить попить чай .

AOS и база данных крутятся на одной машине, сама база и приложение лежат там же. Надо все это разнести конечно, но размер базы детский (10GB без индексов) и 10-15 одновременно работающих пользователей. На 4-ке такая конфигурация жила без больших проблем, но говорят что новая версия нуждается в больших ресурсах, особенно в части временного файла базы данных (tempdb), который должен быть на быстром диске. Somebody в одном из обсуждений на форуме рекомендовал: Прежде чем разносить отдельные таблицы, всё-таки убедиться, что на уровне SQL-сервера физически разнесены данные, логи и tempdb... “. Но egorych ему ответил что это имеет смысл если база большая. «1. разделение лога и базы по разным дискам имеет смысл при условии большой базы - ну в террабайт хотя-бы. 2. тоже самое касается выделения таблиц в файловые группы + к этому зависат сильно от железа - если можете положить ФГ на отдельный ФИЗИЧЕСКИЙ RAID, то можно пробовать, если нет - пустое. 3. очень желательно выделить tempdb в отдельный массив на RAID0 хотя-бы. не обязательно супер быстрые диски.»
Я конкретно сейчас вижу торможение дисков, особенно в части tempdb, вопрос только может ли скорость дисков так катастрофически влиять? Неужели может?

Процессов слегка загружен (больше 30%) в обычных запросах, при операция с SQL перегружен.
Памяти на виртуалке 4GB (мне кажется маловато, наверное надо до 8 увеличить).

Проблемы постоянно – не периодически. Сам по себе сервер работает нормально, не заметно, чтобы другие приложения как то тормозили.

Настройки БД вроде ничем не вызывают сомнения. Никакие периодические нагрузочные процедуры из под аксапты не выполняются, да и maintenance базы данных отсутствует (вроде делается бекап всего сервера).
Autoshrink отключен, autoupgrade for statistic отключен по рекомендациям, до этого был включен – ничего не изменилось. Cyrillic_General_CI_AS collation.
Recovery mode – simple, бекап делается full еженедельно (но весь сервер пишется на ленту ежедневно).
Index Hint в AOS выключен.
Обновление статистики и реиндексация сделаны мной, сначала в SQL reorganize index à update statistic, потом обновление индексов в аксапте . Результатов я лично не вижу.

[Qaz Qwerty]

Вот три скриншота на мониторинг ресурсов

[Qaz Qwerty]

Все таки меня напрягает вот какой момент. Есть job простой как 2 копейки:
Так вот во-первых, этот job завершает работу, пройдя не по всему плану счетов, без всяких сообщений об ошибке. Во-вторых, он выбирает счета не в алфавитном порядке, хотя должен выбирать согласно индексу на AccountNum. Это полный бред. Может это как то связано, что план счетов в виртуальной компании (shared table)? но такого никогда не было.

   while select forupdate LedgerTable
             {
              if (substr(LedgerTable.AccountNum,1,1) != 'A')
              {
                  ttsbegin;
                         LedgerTable.AccountNum = "A"+LedgerTable.AccountNum;
                         LedgerTable.renamePrimaryKey();
                   ttscommit;
               }
             }

[lev]

все как то очень странно... но чудес не бывает

покажите запрос, который уходит в базу, по последнему примеру (выборке по LedgerTable).

P.S. кстати, глобальную компиляцию пробовали?

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

Так вот во-первых, этот job завершает работу, пройдя не по всему плану счетов, без всяких сообщений об ошибке.

вы делаете выборку ВНЕ транзакции, а потом ЭТУ ЖЕ выборку обновляете изнутри (renamePrimaryKey - это тот же update с доп.действиями). Поведение курсора для таких случаев не определено - такая выборка может как остановится, так и пройстись несколько раз по одной записи.

если уж так хотите внутреннюю транзакцию, то заведите LedgerTrans2 и обновляйте его.

Цитата:

Сообщение от Qaz Qwerty

Во-вторых, он выбирает счета не в алфавитном порядке, хотя должен выбирать согласно индексу на AccountNum. Это полный бред.

Нет, это нормально.
В запросе не указан ни индекс, ни сортировка. Поэтому SQL может выбрать любой порядок, удобный для него.



виртуальность компании не должна влиять.

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

Вот три скриншота на мониторинг ресурсов

изображения на форуме можно публиковать проще Как загрузить документ/изображение на форум (upload, закачать).

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

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

*поперхнулся пивом*
ни фига себе вы выбрали операцию.

есть несколько моментов, которые вносят значительные помехи:
1. план счетов - сильно кэшируемая таблица (CacheLookup = EntireTable) поэтому апдейт этой таблицы происходит не так как апдейт других таблиц
2. переименование - это апдейт не одной таблицы, а всех, где участвует счет из плана счетов.
3. счет из плана счетов - поле очень часто входящее в индексы у многих таблиц

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

еще раз: почитайте на форуме про оптимизацию/производительность.
вы ж не первый, кто столкнулся с этой задачей.

Цитата:

Сообщение от Qaz Qwerty

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

не хотите сами почитать, наймите специалистов что-ли.
не должно так быть. и не происходит так.

Цитата:

Сообщение от Qaz Qwerty

На 4-ке такая конфигурация жила без больших проблем, но говорят что новая версия нуждается в больших ресурсах

не говорите ерунды.
и не верьте кто вам такое говорит.

Цитата:

Сообщение от Qaz Qwerty

Я конкретно сейчас вижу торможение дисков, особенно в части tempdb, вопрос только может ли скорость дисков так катастрофически влиять? Неужели может?

конечно может.
если любая выборка вместо индекса приводит к копированию и к сортировке в tempdb, то tempdb будет тормозить что вы с ним ни сделайте.

Цитата:

Сообщение от Qaz Qwerty

Обновление статистики и реиндексация сделаны мной, сначала в SQL reorganize index à update statistic, потом обновление индексов в аксапте . Результатов я лично не вижу.

а они до конца выполнились?
какие-нибудь сообщения об ошибках/удачном завершении были?
сколько выполнялось хоть, можете сказать?

тормоза
производительность
оптимизация

[sukhanchik]

Цитата:

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

В запросе не указан ни индекс, ни сортировка. Поэтому SQL может выбрать любой порядок, удобный для него.

Маленькая поправка. Если в запросе не указан ни индекс, ни сортировка, но на таблице присутствует кластерный индекс - то выборка будет осуществляться с сортировкой по кластерному индексу (просто так данные на диске в таком порядке расположены).
Собственно - на всех справочниках в АХ обычно присутствует кластерный индекс, ибо Best Practice его ставить рекомендует на ключевое поле совместно с первичным индексом.

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

PHP код:

DBCC SHOWCONTIG('tablename') 


для отдельно взятой таблицы.

НО! Тут надо смотреть. Если проблема на табличке без кластерного индекса - то тогда "это оно". Если нет, и проблема явно в дисках - то тут нужно думать в другом направлении. Если бы у Вас был бы Recovery Model=Full - то я бы обратил внимание на то, на какой диск пишется Shipping Log - ибо частые снимки базы не могут не напрягать диски.

[Wamr]

ребята, о чем вы, какая оптимизация индексов и бд. Этож виртуалка с АОСом и БД и 4гигами.
Попробуйте простой тест - возьмите большой файл и скопируйте его из одной папки в другую (не перемещать, а именно копировать), посмотрите скорость передачи данных.

[sukhanchik]

Цитата:

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

ребята, о чем вы, какая оптимизация индексов и бд. Этож виртуалка с АОСом и БД и 4гигами.
Попробуйте простой тест - возьмите большой файл и скопируйте его из одной папки в другую (не перемещать, а именно копировать), посмотрите скорость передачи данных.

Кстати, да - дельное предложение - я упустил момент что это виртуалка.

[Qaz Qwerty]

Цитата:

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

покажите запрос, который уходит в базу, по последнему примеру (выборке по LedgerTable).
P.S. кстати, глобальную компиляцию пробовали?

Компиляцию пробовали, конечно. Сколько ж раз ее можно делать?
А запрос, который делается в случае rename primary key, я даже ловить не буду. Думаю это куча запросов, на основе перебора всех reference к ledgertable.