Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Добрый день.
Есть SQL Server 2005x64 SE установлен на ОС Win2003x64 EE R2. На сервере установлено 16Гб ОЗУ. Процессоры - Xeon 3.0 x 2. Файлы ОС, tempdb, файлы БД (5 файлов) и лога разнесены по разным физическим дискам. БД работает под системой MS Axapta 3.0
Все было довольно спокойно, пока позавчера не начались жалобы пользователей на тормоза в Системе. Началав анализ, установил, что время выполнения запрос выросло примерно в 2 раза ( а некоторых и того больше :(( ), Один из длинных запросов приведен ниже. Перезагрузка сервера, удаление/создание индексов - делал. Положительного результата это не дало :(. Обновление статистики делается как минимум раз в месяц (в первой половине) автоматически (через задание агента). Самое интересное в данной ситуации то, что на другом сервере с такой же платформой но на 4Гб ОЗУ, ОС 2003 ЕЕ х32 R2 и все файлы БД находятся на одном физическом диске этот же запрос выполняется с таким же планом выполнения, но быстрее почти не половину! Помогите понять причину такого явления. Таблица LedgerTrans - около 6Гб
SELECT A.ACCOUNTNUM,A.TRANSDATE,A.VOUCHER,A.TXT,A.AMOUNTMST,A.AMOUNTCUR,A.CURRENCYCODE,A.TRANSTYPE,
A.DIMENSION,A.DIMENSION2_,A.DIMENSION3_,A.DIMENSION4_,A.DIMENSION5_,A.DIMENSION6_,A.DIMENSION7_,A.DIMENSION8_,A.QTY,A.PURCHLEDGERID,A.DOCUMENTDATE,
A.JOURNALNUM,A.ALLOCATELEVEL,A.POSTING,A.CORRECT,A.DEL_CLOSEDID,A.CREDITING,A.DOCUMENTNUM,A.PAYMREFERENCE,A.PERIODCODE,A.OPERATIONSTAX,A.TOACCOUNT,
A.FROMACCOUNT,A.PAYMMODE,A.FURTHERPOSTINGTYPE,A.LEDGERPOSTINGJOURNALID,A.TAXREFID,A.DEL_OFFSETACCOUNTNUM_RU,A.BONDBATCHTRANS_RU,A.BONDBATCH_RU,A.RTSLFROMCOMPANYID,A
.RTSLSESSIONTRANSID,A.NMF_SYSRECORD,A.NMF_ADJEXCHRATEDATE,A.NMF_EMPLID,A.NMF_EXCHRATE,
A.MODIFIEDDATE,A.MODIFIEDTIME,A.MODIFIEDBY,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.CREATEDTRANSACTIONID,A.RECID,
B.ACCOUNTNUM,B.TRANSDATE,B.VOUCHER,B.TXT,B.AMOUNTMST,B.AMOUNTCUR,B.CURRENCYCODE,B.TRANSTYPE,
B.DIMENSION,B.DIMENSION2_,B.DIMENSION3_,B.DIMENSION4_,B.DIMENSION5_,B.DIMENSION6_,B.DIMENSION7_,B.DIMENSION8_,B.QTY,B.PURCHLEDGERID,B.DOCUMENTDATE,
B.JOURNALNUM,B.ALLOCATELEVEL,B.POSTING,B.CORRECT,B.DEL_CLOSEDID,B.CREDITING,B.DOCUMENTNUM,B.PAYMREFERENCE,B.PERIODCODE,B.OPERATIONSTAX,B.TOACCOUNT,
B.FROMACCOUNT,B.PAYMMODE,B.FURTHERPOSTINGTYPE,B.LEDGERPOSTINGJOURNALID,B.TAXREFID,B.DEL_OFFSETACCOUNTNUM_RU,B.BONDBATCHTRANS_RU,B.BONDBATCH_RU,B.RTSLFROMCOMPANYID,
B.RTSLSESSIONTRANSID,B.NMF_SYSRECORD,B.NMF_ADJEXCHRATEDATE,B.NMF_EMPLID,B.NMF_EXCHRATE,
B.MODIFIEDDATE,B.MODIFIEDTIME,B.MODIFIEDBY,B.CREATEDDATE,B.CREATEDTIME,B.CREATEDBY,B.CREATEDTRANSACTIONID,B.RECID
FROM LEDGERTRANS A,LEDGERTRANS B
WHERE ((A.DATAAREAID='UGK')
AND ((((((A.CREDITING=1)
AND 
NOT ((A.BONDBATCH_RU=' ')))
AND 
NOT ((A.BONDBATCHTRANS_RU=0)))
AND ((A.TRANSDATE>={TS '2009-08-01 00:00:00.000'})
AND (A.TRANSDATE<={TS '2009-08-31 00:00:00.000'})))
AND (A.ACCOUNTNUM='   641.004'))
AND (A.DIMENSION='УГК_01')))
AND ((B.DATAAREAID='UGK')
AND ((((((B.CREDITING=0)
AND (((B.ACCOUNTNUM>='   311.101')
AND (B.ACCOUNTNUM<='   311.519')) OR ({FN IFNULL({FN LTRIM(B.ACCOUNTNUM)},B.ACCOUNTNUM)} LIKE '311%' ESCAPE '\' )))
AND (A.VOUCHER=B.VOUCHER))
AND (A.TRANSDATE=B.TRANSDATE))
AND (A.BONDBATCH_RU=B.BONDBATCH_RU))
AND (A.BONDBATCHTRANS_RU=B.BONDBATCHTRANS_RU)))
ORDER BY A.DATAAREAID,A.ACCOUNTNUM,A.TRANSDATE,A.PERIODCODE,A.CREDITING OPTION(FAST 17)
А вот, собственно план запроса
  |--Nested Loops(Inner Join, WHERE:([NMF_Work].[dbo].[LEDGERTRANS].[VOUCHER] as [A].[VOUCHER]=[NMF_Work].[dbo].[LEDGERTRANS].[VOUCHER] as [B].[VOUCHER] AND [NMF_Work].[dbo].[LEDGERTRANS].[TRANSDATE] as [A].[TRANSDATE]=[NMF_Work].[dbo].[LEDGERTRANS].[TRANSDATE] as [B].[TRANSDATE] AND [NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCH_RU] as [A].[BONDBATCH_RU]=[NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCH_RU] as [B].[BONDBATCH_RU] AND [NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCHTRANS_RU] as [A].[BONDBATCHTRANS_RU]=[NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCHTRANS_RU] as [B].[BONDBATCHTRANS_RU]))
       |--Filter(WHERE:([NMF_Work].[dbo].[LEDGERTRANS].[DIMENSION] as [A].[DIMENSION]='УГК_01' AND ([NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCH_RU] as [A].[BONDBATCH_RU]<' ' OR [NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCH_RU] as [A].[BONDBATCH_RU]>' ') AND ([NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCHTRANS_RU] as [A].[BONDBATCHTRANS_RU]<(0) OR [NMF_Work].[dbo].[LEDGERTRANS].[BONDBATCHTRANS_RU] as [A].[BONDBATCHTRANS_RU]>(0))))
       |    |--Nested Loops(Inner Join, OUTER REFERENCES:([Bmk1000]))
       |         |--Index Seek(OBJECT:([NMF_Work].[dbo].[LEDGERTRANS].[I_225NMF_RRGIDX] AS [A]), SEEK:([A].[DATAAREAID]='UGK' AND [A].[ACCOUNTNUM]='   641.004' AND [A].[TRANSDATE] >= '2009-08-01 00:00:00.000' AND [A].[TRANSDATE] <= '2009-08-31 00:00:00.000'),  WHERE:([NMF_Work].[dbo].[LEDGERTRANS].[CREDITING] as [A].[CREDITING]=(1)) ORDERED FORWARD)
       |         |--RID Lookup(OBJECT:([NMF_Work].[dbo].[LEDGERTRANS] AS [A]), SEEK:([Bmk1000]=[Bmk1000]) LOOKUP ORDERED FORWARD)
       |--Filter(WHERE:(([NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]>='   311.101' AND [NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]<='   311.519' OR isnull(ltrim([NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]),[NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]) like '311%' escape '\' ) AND [NMF_Work].[dbo].[LEDGERTRANS].[CREDITING] as [B].[CREDITING]=(0)))
            |--Nested Loops(Inner Join, OUTER REFERENCES:([Bmk1003]))
                 |--Index Seek(OBJECT:([NMF_Work].[dbo].[LEDGERTRANS].[I_225DATEIDX] AS [B]), SEEK:([B].[DATAAREAID]='UGK' AND [B].[TRANSDATE] >= '2009-08-01 00:00:00.000' AND [B].[TRANSDATE] <= '2009-08-31 00:00:00.000') ORDERED FORWARD)
                 |--RID Lookup(OBJECT:([NMF_Work].[dbo].[LEDGERTRANS] AS [B]), SEEK:([Bmk1003]=[Bmk1003]) LOOKUP ORDERED FORWARD)
11 сен 09, 12:16    [7646871]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Agers
Member

Откуда:
Сообщений: 209
Didukh,

Сколько записей в каждой из таблиц, какие индексы есть ?
11 сен 09, 12:28    [7646942]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Konst_One
Member

Откуда:
Сообщений: 11513
 ({FN IFNULL({FN LTRIM(B.ACCOUNTNUM)},B.ACCOUNTNUM)} LIKE '311%' ESCAPE '\' )))

копайте в этом направлении, уж очень плохое решение
11 сен 09, 12:39    [7646999]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Agers

Сколько записей в каждой из таблиц, какие индексы есть ?

записей - 10млн
Индексы есть:
I_225ACDate: AccountNum, TransDate, Voucher, AmountMST
I_225VoucherDateIdx: Voucher, TransDate
I_225DateIdx: TransDate
I_225TransactionLogIdx: createdTransactionId
I_225FurtherPostingType: FurtherPostingType
I_225PostingJournaIdxl: LedgerPostingJournalId, Voucher, TransDate
I_225JournalizeIdx: JournalizeSeqNum
I_225BondBatchIdx_RU: BondBatch_RU, BondBatchTrans_RU,Crediting
I_225NMF_RRGIdx: AccountNum, TransDate, PeriodCode, Crediting
11 сен 09, 12:54    [7647100]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Crimean
Member

Откуда:
Сообщений: 13148
как вариант - заменить ISNULL на UNION
при наличии индексов может существенно полегшать
11 сен 09, 12:55    [7647111]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Konst_One
 ({FN IFNULL({FN LTRIM(B.ACCOUNTNUM)},B.ACCOUNTNUM)} LIKE '311%' ESCAPE '\' )))

копайте в этом направлении, уж очень плохое решение


что именно плохое? Дело в том, что этот код генерится ядром Система (стандартная форма запроса) и изменить его чуток проблемно :(.
11 сен 09, 13:01    [7647165]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
"Самое интересное в данной ситуации то, что на другом сервере с такой же платформой но на 4Гб ОЗУ, ОС 2003 ЕЕ х32 R2 и все файлы БД находятся на одном физическом диске этот же запрос выполняется с таким же планом выполнения, но быстрее почти не половину! Помогите понять причину такого явления. Таблица LedgerTrans - около 6Гб"

Не говорит НИ О ЧЕМ!!!!
Надо смотреть как загружен сервер в момент выполнения запроса.Что он еще делает. Может торомоза из-за нехватки ресурсов или тупо из-за блокировок.

Запустите этот запрос на тестовом сервере или в момент наименьшей нагрузки.
Если отработает быстро, то причина в другом.
11 сен 09, 13:06    [7647195]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Crimean
как вариант - заменить ISNULL на UNION
при наличии индексов может существенно полегшать

:-) возможно но у меня в запросе ISNULL нету ;-)
11 сен 09, 13:07    [7647199]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
--__Александр__--,

нет, блокировок точно нету. А вот с загрузкой процессора хуже - при выполнение данного запроса загрузка процессора составляет 30-50%. На мониторе видно, что один из 4 логических процов загружен под 100% остальные 10-30%. Запрос проверялся на тестовом и на рабочем сервере без пользователей, и на рабочем сервере с пользователями. Дело в том, что еще два дня назад все работало нормально!!! И там точно никто ничего дополнительного не далал!
11 сен 09, 13:12    [7647229]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Didukh
Crimean
как вариант - заменить ISNULL на UNION
при наличии индексов может существенно полегшать

:-) возможно но у меня в запросе ISNULL нету ;-)


да что вы?

автор
Filter(WHERE:(([NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as .[ACCOUNTNUM]>=' 311.101' AND [NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]<=' 311.519' [b]OR isnull(ltrim([NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]),[NMF_Work].[dbo].[LEDGERTRANS].[ACCOUNTNUM] as [B].[ACCOUNTNUM]) like '311%' escape '\' ) AND [NMF_Work].[dbo].[LEDGERTRANS].[CREDITING] as [B].[CREDITING]=(0)))


OR да еще и + ISNULL, который сам по себе OR...
11 сен 09, 13:24    [7647320]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Crimean,

ой, извиняюсь, я что-то в план не посмотрел...
11 сен 09, 13:31    [7647372]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
Didukh
--__Александр__--,

нет, блокировок точно нету. А вот с загрузкой процессора хуже - при выполнение данного запроса загрузка процессора составляет 30-50%. На мониторе видно, что один из 4 логических процов загружен под 100% остальные 10-30%.


Конечно будет один проц загружен. У вас же план без распараллеливания.
Попробуйте с хинтом OPTION(maxdop 4)
11 сен 09, 13:55    [7647540]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
--__Александр__--,
:-) вообще-то оптимизатор сам выбирает степень распараллеливания (значение по умолчанию). Но хинт я тоже пробовал - результат тот же :(
11 сен 09, 13:59    [7647586]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Glory
Member

Откуда:
Сообщений: 104760
--__Александр__--
Didukh
--__Александр__--,

нет, блокировок точно нету. А вот с загрузкой процессора хуже - при выполнение данного запроса загрузка процессора составляет 30-50%. На мониторе видно, что один из 4 логических процов загружен под 100% остальные 10-30%.


Конечно будет один проц загружен. У вас же план без распараллеливания.
Попробуйте с хинтом OPTION(maxdop 4)

Этот хинт ограничивает число процессоров, но не обязывает оптимизатор строить планы с параллелизмом
11 сен 09, 14:04    [7647619]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
"вообще-то оптимизатор сам выбирает степень распараллеливания"
Он может иногда ошибаться.

А если без ORDER BY запустить, за скока отработает ?
И вообще, сколько строк запрос возвращает и за сколько секунд запрос должен отработать?
11 сен 09, 14:06    [7647634]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
Glory
Этот хинт ограничивает число процессоров, но не обязывает оптимизатор строить планы с параллелизмом


Да, попутал.
На распараллеливание можно повлиять через cost threshold for parallelism.
11 сен 09, 14:11    [7647686]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Добрый день. Извини не было доступу до инету не мог ответить :-((
--__Александр__--
"вообще-то оптимизатор сам выбирает степень распараллеливания"
Он может иногда ошибаться.

А если без ORDER BY запустить, за скока отработает ?

пару секунд!!!

--__Александр__--
И вообще, сколько строк запрос возвращает и за сколько секунд запрос должен отработать?

а строк то запрос вообще не возвращает, по таким условиям!!! (в смысле с такими критериями записей нету :-))
14 сен 09, 10:22    [7653807]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Crimean
Member

Откуда:
Сообщений: 13148
>> А если без ORDER BY запустить, за скока отработает
> пару секунд!!!

индексы "кривые" (для этого запроса) + распоределение данных "не в вашу пользу"
14 сен 09, 10:25    [7653822]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Didukh
Member

Откуда:
Сообщений: 74
Crimean,
с индексами - что то слышал что делать, что за "распоределение данных"? Как это можно попробовать исправить? ;-)
14 сен 09, 10:43    [7653907]     Ответить | Цитировать Сообщить модератору
 Re: Жутко долгое выполнение запроса :-(  [new]
Crimean
Member

Откуда:
Сообщений: 13148
индексы, если это "дозволено" и в принципе возможно для вашей схемы хранения, можно сделать "покрывающими" для запроса
14 сен 09, 11:24    [7654143]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить