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

[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. кстати, глобальную компиляцию пробовали?

[Qaz Qwerty]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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



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

[sukhanchik]

Цитата:

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

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

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

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

PHP код:

DBCC SHOWCONTIG('tablename') 


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

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