Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Cуть проблемы.
Есть SSAS партиция для группы мер, в группе мер partitioning - по годам.
С некоторого момента - процессинг начал "падать" по тайм-ауту, то есть в течение часа записи из запроса даже не начинают "отфетчиваться".
Но, если добавить в тот же запрос еще условие по месяцу, начало "вывода" записей происходит в разумные сроки.
Упростил вьюху, сравнил два запроса:
select * from [vOlap901IncomeBySpecWork] v where year(v.move_date)=2013 
select * from [vOlap901IncomeBySpecWork2] v where year(v.move_date)=2013 [b]and month(v.move_date)=3[/b]

Второй, с условием по месяцу, начинает "вывод строк" почти мгновенно,первый - минут через пять.
Смотрю estimated query plan, - абсолютно идентичны, и там и там начинаются с Index Seek по дате.
Почему такая разница? Как можно повлиять?
Спасибо.
11 авг 14, 16:12    [16426784]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Konst_One
Member

Откуда:
Сообщений: 11621
а с чего вы взяли, что запросы у вас одинаковые?
11 авг 14, 16:14    [16426801]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
абсолютно идентичны, и там и там начинаются с Index Seek по дате.

Какой может быть Index Seek по дате, если у вас функция извлечения из даты года и месяца ?
11 авг 14, 16:14    [16426804]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Konst_One
а с чего вы взяли, что запросы у вас одинаковые?

Прошу прощения, скопипастил не глядя..
Первый из двух запросов таже включает вьюху [vOlap901IncomeBySpecWork2]
11 авг 14, 16:22    [16426846]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Konst_One
Member

Откуда:
Сообщений: 11621
так всё равно для сервера это разные запросы, вы актуальные планы бы показали
11 авг 14, 16:23    [16426851]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
McCar
абсолютно идентичны, и там и там начинаются с Index Seek по дате.

Какой может быть Index Seek по дате, если у вас функция извлечения из даты года и месяца ?

Наверно у MS SQL хватает ума преобразовать это условие в диапазон дат и пробросить его до нужного индекса.
См план запроса во вложении..

К сообщению приложен файл. Размер - 148Kb
11 авг 14, 16:25    [16426862]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Konst_One
Member

Откуда:
Сообщений: 11621
ну попробуйте через >= < переписать условие по дате

например так

... v.move_date >= '20130301' and v.move_date < '20130401'
11 авг 14, 16:29    [16426884]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
Наверно у MS SQL хватает ума преобразовать это условие в диапазон дат и пробросить его до нужного индекса.

Вы это увидели в плане или сами придумали ?
На обрезаном скриншоте как минимум два Index Seek - они что оба типа по дате ?

McCar
См план запроса во вложении..

И что делать с этой картинкой ? Распечатать и повесить на стену ?
11 авг 14, 16:29    [16426885]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
McCar
Наверно у MS SQL хватает ума преобразовать это условие в диапазон дат и пробросить его до нужного индекса.

Вы это увидели в плане или сами придумали ?
На обрезаном скриншоте как минимум два Index Seek - они что оба типа по дате ?

McCar
См план запроса во вложении..

И что делать с этой картинкой ? Распечатать и повесить на стену ?

1)Тот, что по [IX_L_MOVE_MOVE_DATE] - да.
2) План в формате .plan - во вложении.

К сообщению приложен файл (xxx.zip - 14Kb) cкачать
11 авг 14, 16:43    [16426977]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Konst_One
так всё равно для сервера это разные запросы, вы актуальные планы бы показали

Сравнил актуальные.
Тоже идентичны, разница - только в cost.
Вопрос, что при идентичных планах запроса может еще повлиять на время начало вывода result set-а клиенту?
11 авг 14, 16:58    [16427064]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Konst_One
Member

Откуда:
Сообщений: 11621
соберите клиентскую статистику выполнения обеих вариантов запроса, посмотрите на что время тратится
11 авг 14, 16:59    [16427080]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
McCar,

Батенька, у вас что-то много NESTED LOOPS в плане. Индексы на справочниках надо бы создать, даже если они маленькие.

Используйте between как советовали выше.

У меня партиционирование таблиц фактов выглядит вот так. Строки начинают отдаваться мгновенно.
SELECT [id]
      ,[id_doc]
      ,[dt]
      ,[pk_date]
      ,[chrt_id]
      ,[TS_id]
      ,[NM_id]
      ,[IMT_id]
      ,[brand_cod]
      ,[subject_id]
      ,[quantity]
      ,[days_on_site]
      ,[days_from_Accept]
      ,[id_stock_age_days]
      ,[supplier_id]
      ,[cost_price]
      ,[price]
	  ,Price_Range_Id
      ,[kind_id]
      ,[collection_id]
      ,[f1]
	  ,[WhPrice]
FROM [Facts].[Vw_Stock] F
WHERE F.pk_date BETWEEN 
	[Facts].[udf_PartitionStartDate]('...', '...', 201408) AND 
	[Facts].[udf_PartitionEndDate]  ('...', '...', 201408)
11 авг 14, 17:37    [16427287]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
a_voronin
McCar,

Батенька, у вас что-то много NESTED LOOPS в плане. Индексы на справочниках надо бы создать, даже если они маленькие.

Используйте between как советовали выше.

[/src]

1)Вы точно уверены, что правильно понимаете логику оператора NESTED LOOPS ?
Возможно, прочитав например вот это
http://www.olegaxenow.com/2011/04/sql-execution-plan.html
вы что-то для себя переосмыслите..
2)between действительно поменяла план запроса. Но по прежнему за год "время начала отфетчивания не удалось дождаться.
Оно... конечно знак, что пора переходить на "помесячное" партиционирование группы мер, но хотелось бы понять, почему такая разница для запросов с одинаковым планом..
11 авг 14, 18:32    [16427481]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
McCar,

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

Вы не спорьте, вы попробуйте создать индексы. Если там OUTER APLLY на одну запись, то всё логично -- NESTED LOOP, а вот если там JOIN и записей некоторое кол-во, но не факт, что NESTED LOOP правилен. Возможно где-то индекс не нужен. У вас NESTED LOOP по крайней мере на одну толстую стрелку.

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

Порядка десяка -- не факт, что эта цифра всегда верна.
11 авг 14, 19:11    [16427639]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Ещё, вы не хотите сначала сделать эти JOIN, положить результат в таблицу фактов, а потом уже подавать в куб из этой таблицы с кластерным индексом хорошо партиционированным по дате? Причём если логика позволяет можно наращивать эту таблицу инкрементально.
11 авг 14, 19:14    [16427657]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
McCar
Наверно у MS SQL хватает ума преобразовать это условие в диапазон дат и пробросить его до нужного индекса.
См план запроса во вложении..
Index Seek это что, всегда хорошо? И не важно по каким условиям этот поиск идет? Откройте для себя то, что кроме картинок есть еще куча информации которую надо читать. Вот например ваш якобы Index Seek:

К сообщению приложен файл. Размер - 31Kb
11 авг 14, 20:09    [16427871]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
McCar
2)between действительно поменяла план запроса. Но по прежнему за год "время начала отфетчивания не удалось дождаться.
Вы нам предлагаете угадать как теперь выглядит план запроса?
McCar
Оно... конечно знак,
Ванга
McCar
что пора переходить на "помесячное" партиционирование группы мер, но хотелось бы понять, почему такая разница для запросов с одинаковым планом..
Может быть все что угодно, вплоть до того, что данные на диске лежат более удачно для второго запроса.
Вы сначала добейтесь, чтобы у вас запрос был оптимальный и оценки правильные (а не как в вашем плане), а потом уже занимайтесь прочей фигней. Партиционирование не панацея от всех бед.


Konst_One
соберите клиентскую статистику выполнения обеих вариантов запроса, посмотрите на что время тратится
Не понятно как это поможет оценить, что происходит на сервере?


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

Порядка десяка -- не факт, что эта цифра всегда верна.
А я вообще думал, что это классический случай для Hash Join, хотя конечно очень сильно зависит от селективности условий выборки на обеих таблицах.
11 авг 14, 20:24    [16427914]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Моё мнение, что здесь надо сделать хорошую, полноценную схему звезда.

https://ru.wikipedia.org/wiki/Схема_звезды

Если она не сделана, то партиции куба будут процесситься медленно. В таблице должны быть внешние ключи и показатели. Индекс должен быть ориентирован на партиционирование, принятое в кубе. Джойны, где это возможны, должны быть сделаны на этапе ETL, до загрузки в куб. Тогда всё будет летать.
11 авг 14, 20:46    [16427989]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Mind
McCar
Наверно у MS SQL хватает ума преобразовать это условие в диапазон дат и пробросить его до нужного индекса.
См план запроса во вложении..
Index Seek это что, всегда хорошо? И не важно по каким условиям этот поиск идет? Откройте для себя то, что кроме картинок есть еще куча информации которую надо читать. Вот например ваш якобы Index Seek:

Вынужден признать уместность ваших саркастических интонаций, спасибо.
Действительно. получается никакого "пробрасывания условия" в вьюху нет.
Я правда не понял, почему в Predicate указано внешнее условие по дате, а в Seek Predicate -внутреннее (в теле вьюхи - lm.MOVE_DATE < DATEADD(d, 1, GETDATE())).
Ну да ладно.. есть повод почитать в чем разница.
Привожу полный текста вьюхи.
USE [forMSAS]
GO

/****** Object:  View [dbo].[vOlap901IncomeBySpecWork2]    Script Date: 12.08.2014 11:10:41 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO



alter      View [dbo].[vOlap901IncomeBySpecWork2] as  

SELECT        lm.C_MOVE, lm.DTCR, lm.C_MOVE_TYPE, lm.C_DOC_P,  lm.C_ACC, lm.MOVE_DATE, 
--dv26.C_TARGET AS C_TARGET_FOR_DOC26,
 spec.C_CALC_ITERATION_NUMBER, sw.C_SPEC_WORK, sw.C_ROLE, sw.C_LOCATION, lm.Q_MOVE,
 lm.Q_MOVE  *sw.COST AS Q_901_INCOME_SPEC_WORK_COST, 
 lm.Q_MOVE*sw.WORK_TARIFF*EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF  as Q_901_INCOME_SPEC_WORK_TARIF /*Сдельная*/,  
 lm.Q_MOVE*HOUR_TARIFF/sw.LOAD_LOC *EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF as Q_901_INCOME_SPEC_HOUR_TARIFF/*Часовая*/, 
 lm.Q_MOVE*(sw.PR/100)*(sw.WORK_TARIFF+sw.HOUR_TARIFF/sw.load_loc)*EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF as  /* Премиальная PR из -значение процента (PR/100)*(Сдельная+Часовая/коэф. загрузки)*(1+9/100)*RATE_PRC*(BRAC_PRC+1)*FOT_KOEF  */ Q_901_INCOME_SPEC_HOUR_PR  
 
FROM            L_MOVE  AS lm
--WITH (FORCESEEK ([IX_L_MOVE_MOVE_DATE_BY_901] (MOVE_DATE))) 

JOIN l_cost_period   lcp on   lm.move_date between lcp.PERIOD_START and  lcp.PERIOD_END  
left JOIN L_COST_DETAIL cd with (forceseek) on  cd.C_WARE=lm.c_ware and  cd.C_MODEL =lm.c_model and  cd.C_WARE_DESCR =lm.c_ware_descr and lm.C_MODEL_DESCR= cd.C_MODEL_DESCR
 and lcp.C_COST_PERIOD=cd.C_COST_PERIOD 
 --
  cross apply (select 1.09 as EESN /*Эффективная ставка единого соц налога*/) constants
 outer apply
 (select 1 as C_CALC_ITERATION_NUMBER, cd.C_SPEC
 union all
 select 2 as C_CALC_ITERATION_NUMBER, cd.C_SPEC_SEC_PASS C_SPEC
 ) spec
join   L_SPEC_WORK sw  WITH (FORCESEEK) on  sw.C_SPEC=spec.c_spec
where lm.C_QTY=901  and lm.Q_MOVE>0 
and      lm.MOVE_DATE < DATEADD(d, 1, GETDATE())
 --AND lm.MOVE_DATE >='20130101' --and  Year(m.MOVE_DATE)=2014 and month(m.MOVE_DATE)=3
 and  lm.DTCR=0 /*для приходов на некоторые склады нам интересно знать еще кое что из спец себестоимости*/ and 
   lm.C_ACC IN (.......)/*ДЛЯ ЭТОЙ МЕРЫ НАМ НУЖЕН ФИКС ПЕРЕЧЕНЬ СКЛАДОВ*/
12 авг 14, 11:29    [16430065]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
А хинты в запрос кто придумал наставить ?
12 авг 14, 11:35    [16430112]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
a_voronin
McCar,

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

Вы не спорьте, вы попробуйте создать индексы. Если там OUTER APLLY на одну запись, то всё логично -- NESTED LOOP, а вот если там JOIN и записей некоторое кол-во, но не факт, что NESTED LOOP правилен. Возможно где-то индекс не нужен. У вас NESTED LOOP по крайней мере на одну толстую стрелку.

Все равно не понял.
Индексы там везде где происходит джойн - есть, например
[forMSAS].[dbo].[L_SPEC_WORK].[I_L_SPEC_WORK_REF_SPEC] [sw], по этому индексу проходит условие в вьюех
join   L_SPEC_WORK sw  WITH (FORCESEEK) on  sw.C_SPEC=spec.c_spe
, но Nested Loops То тут при чем?
12 авг 14, 11:42    [16430157]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
, но Nested Loops То тут при чем?

У вас о крайне правого Index Seek выходной набор из 3 млн записей
Это значит цикл из 3млн итеранций для выбоки еще каких то данных из этой же таблицы, по ссылке на кластеный ключ
Вы считаете, что это будет быстро ?
12 авг 14, 11:46    [16430174]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
a_voronin
Ещё, вы не хотите сначала сделать эти JOIN, положить результат в таблицу фактов, а потом уже подавать в куб из этой таблицы с кластерным индексом хорошо партиционированным по дате? Причём если логика позволяет можно наращивать эту таблицу инкрементально.

Ну.. вопрос степени нормализации данных в таблице фактов это к DWH теме больше..
Можно конечно свалить все в физическую таблицу фактов, но тогда будет отдельная головная боль - апдейтисть эту таблицу всякий раз, когда меняется что то в приджойненных "Справочниках".
12 авг 14, 11:47    [16430181]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
McCar
Mind
пропущено...
Index Seek это что, всегда хорошо? И не важно по каким условиям этот поиск идет? Откройте для себя то, что кроме картинок есть еще куча информации которую надо читать. Вот например ваш якобы Index Seek:

Вынужден признать уместность ваших саркастических интонаций, спасибо.
Действительно. получается никакого "пробрасывания условия" в вьюху нет.
Я правда не понял, почему в Predicate указано внешнее условие по дате, а в Seek Predicate -внутреннее (в теле вьюхи - lm.MOVE_DATE < DATEADD(d, 1, GETDATE())).
Ну да ладно.. есть повод почитать в чем разница.
Привожу полный текста вьюхи.
USE [forMSAS]
GO

/****** Object:  View [dbo].[vOlap901IncomeBySpecWork2]    Script Date: 12.08.2014 11:10:41 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO



alter      View [dbo].[vOlap901IncomeBySpecWork2] as  

SELECT        lm.C_MOVE, lm.DTCR, lm.C_MOVE_TYPE, lm.C_DOC_P,  lm.C_ACC, lm.MOVE_DATE, 
--dv26.C_TARGET AS C_TARGET_FOR_DOC26,
 spec.C_CALC_ITERATION_NUMBER, sw.C_SPEC_WORK, sw.C_ROLE, sw.C_LOCATION, lm.Q_MOVE,
 lm.Q_MOVE  *sw.COST AS Q_901_INCOME_SPEC_WORK_COST, 
 lm.Q_MOVE*sw.WORK_TARIFF*EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF  as Q_901_INCOME_SPEC_WORK_TARIF /*Сдельная*/,  
 lm.Q_MOVE*HOUR_TARIFF/sw.LOAD_LOC *EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF as Q_901_INCOME_SPEC_HOUR_TARIFF/*Часовая*/, 
 lm.Q_MOVE*(sw.PR/100)*(sw.WORK_TARIFF+sw.HOUR_TARIFF/sw.load_loc)*EESN*sw.RATE_PRC*(sw.BRAK_PRC+1)*sw.FOT_KOEF as  /* Премиальная PR из -значение процента (PR/100)*(Сдельная+Часовая/коэф. загрузки)*(1+9/100)*RATE_PRC*(BRAC_PRC+1)*FOT_KOEF  */ Q_901_INCOME_SPEC_HOUR_PR  
 
FROM            L_MOVE  AS lm
--WITH (FORCESEEK ([IX_L_MOVE_MOVE_DATE_BY_901] (MOVE_DATE))) 

JOIN l_cost_period   lcp on   lm.move_date between lcp.PERIOD_START and  lcp.PERIOD_END  
left JOIN L_COST_DETAIL cd with (forceseek) on  cd.C_WARE=lm.c_ware and  cd.C_MODEL =lm.c_model and  cd.C_WARE_DESCR =lm.c_ware_descr and lm.C_MODEL_DESCR= cd.C_MODEL_DESCR
 and lcp.C_COST_PERIOD=cd.C_COST_PERIOD 
 --
  cross apply (select 1.09 as EESN /*Эффективная ставка единого соц налога*/) constants
 outer apply
 (select 1 as C_CALC_ITERATION_NUMBER, cd.C_SPEC
 union all
 select 2 as C_CALC_ITERATION_NUMBER, cd.C_SPEC_SEC_PASS C_SPEC
 ) spec
join   L_SPEC_WORK sw  WITH (FORCESEEK) on  sw.C_SPEC=spec.c_spec
where lm.C_QTY=901  and lm.Q_MOVE>0 
and      lm.MOVE_DATE < DATEADD(d, 1, GETDATE())
 --AND lm.MOVE_DATE >='20130101' --and  Year(m.MOVE_DATE)=2014 and month(m.MOVE_DATE)=3
 and  lm.DTCR=0 /*для приходов на некоторые склады нам интересно знать еще кое что из спец себестоимости*/ and 
   lm.C_ACC IN (.......)/*ДЛЯ ЭТОЙ МЕРЫ НАМ НУЖЕН ФИКС ПЕРЕЧЕНЬ СКЛАДОВ*/


Всё-таки хочу вам предложить принципиально изменить подход. Предрасчитать всё это и уложить в таблицу, которую инкрементально наращивать. Вы можете до бесконечности оптимизировать, и у вас будет отваливаться. Второе у вас в кубе календарь на какой ключ завязан? Надо бы переделать его на INT 20140812 , или 201408 а не развлекаться всякими Year(m.MOVE_DATE)=2014 and month(m.MOVE_DATE)
12 авг 14, 11:52    [16430207]     Ответить | Цитировать Сообщить модератору
 Re: Время начала вывода строк для результатов запросов в одинаковым планом запроса.  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
А хинты в запрос кто придумал наставить ?

Задача была построить запрос так, чтобы он начал вывод данных по возможности сразу, пускай даже в ущерб общему времени выполнения.
12 авг 14, 12:20    [16430365]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить