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

Откуда:
Сообщений: 426
Все началось с того, что есть некая функция, код которой представлю ниже. Если выполнять
select * from fnFact_LS_countRegPeople(@YYYYMM)

со значениями @YYYYMM от 201001 до 201109 - то план такой как надо, запрос выполняется за 2 минуты.

Но тут вдруг запрос
select * from fnFact_LS_countRegPeople(201110)  -- вот именно для этого месяца

дико тупит - выполняется 4 часа...

Смотрю в план по селекту для месяца 201110 и глаза на лоб лезут - что он там вытворяет... И почему только для этого месяца - ума не приложу. Те таблицы, что в коде fnFact_LS_countRegPeople используются, секционированы по YYYYMM и по еще одному полю, причем обе одиннаково (на одной и той же схеме). join идет по этим двум полям. Не могу понять чем таким особенным является месяц 201110 - почему селект из fnFact_LS_countRegPeople(201110) имеет совершенно другой план?

Ну ладно, думаю "пошло оно подальше" - создам я ему план-гайд, и пускай работает по нему. Делаю так:
sp_create_plan_guide @name = N'Plan_RegPeople',
	@stmt = N'select * from fnFact_LS_countRegPeople(@YYYYMM)',
	@type = N'SQL',
	@module_or_batch  = NULL,
	@params = '@YYYYMM int',
	@hints = N'OPTION (OPTIMIZE FOR(@YYYYMM = 201109))'


Скажу честно - первый раз использую эту вещь, но доку читал перед использованием на протяжении 2-х часов и разбирался по этой статье.

Так вот, когда запускаю select * from fnFact_LS_countRegPeople(201110) - то получаю опять тормоз и вижу старый план, как будто для него нету никакого план-гайда.

Что я не так делаю? Как вдолбать серверу чтобы он для всех месяцев юзал тот же самый план, который он сейчас юзает для 201109?

Спасибо за внимание.


Код вьюхи:
ALTER function [dbo].[fnFact_LS_countRegPeople](@YYYYMM int) returns table
as
return
-- первая часть дает нам те записи в Fact_LS_countRegPeople по которым площадь прописана
select 
	cod_pl,
	0 as id,
	@YYYYMM as period_YYYYMM,
	@YYYYMM * 100 + 1 as period_YYYYMM01,
	count_reg
from 
	dbo.Fact_LS_countRegPeople
where 
	period_YYYYMM = @YYYYMM
	
union all

select 
	t.cod_pl, -- таблица t даст нам те ЛС, по которым есть начисления, но которых нету в Fact_LS_countRegPeople
	0 as id,
	@YYYYMM as period_YYYYMM,
	@YYYYMM * 100 + 1 as period_YYYYMM01,
	(select top 1 count_reg -- для каждого такого ЛС кореллированный запрос выдернет последнюю запись из Fact_LS_countRegPeople
		from Fact_LS_countRegPeople z
		where period_YYYYMM < @YYYYMM
		and z.cod_pl = t.cod_pl
		order by period_YYYYMM desc)
	as countRegPeople
from 
(
	-- здесь мы выберем те ЛС по которым начисления есть, но записи в  Fact_LS_countRegPeople нету
	select distinct x.cod_pl
	from Fact_Nach x
	where b_period_YYYYMM = @YYYYMM
	and s_nach <> 0
	and not exists
		(-- эта выборка даст 1 если по этому ЛС есть запись в Fact_LS_countRegPeople
		select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = x.b_period_YYYYMM  and y.cod_pl = x.cod_pl 
		)
) t

версия сервера - SQL 2008R2 со всеми последними обновлениями на сегодняшний день. В таблице Fact_Nach секции по полю b_period_YYYYMM, кластерный индекс по (b_period_YYYYMM, cod_pl, и еще несколько полей). Каждая секция - по 50 млн. строк.
В таблице Fact_LS_countRegPeople пол миллиона записей, секция по полю period_YYYYMM по той же схеме, пол миллиона строк в секции, кластер по (period_YYYYMM, cod_pl).
16 дек 11, 07:20    [11775631]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Если запустить этот код не через функцию с данными параметрами. Быстро отрабатывает?
16 дек 11, 07:29    [11775640]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
вот план для 9-го месяца - здесь все хорошо.

К сообщению приложен файл. Размер - 32Kb
16 дек 11, 07:30    [11775641]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
Deff
Если запустить этот код не через функцию с данными параметрами. Быстро отрабатывает?

да, быстро отрабатывает. даже со значением 201110.

Вопрос в том, что этот селект идет в секции ОЛАП-куба, то есть там написать вот такой здоровенный код конечно же можно, но что-то бы не хотелось это делать...
16 дек 11, 07:33    [11775645]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
а вот план для 201110:

К сообщению приложен файл. Размер - 36Kb
16 дек 11, 07:37    [11775648]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
заменить кусок кода
select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = x.b_period_YYYYMM  and y.cod_pl = x.cod_pl 


На
select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = @YYYYMM  and y.cod_pl = x.cod_pl 


Попробуйте.
16 дек 11, 07:46    [11775654]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

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

Уже делал. Вначале так и было написано - here y.period_YYYYMM = @YYYYMM and y.cod_pl = x.cod_pl .
Результат такой же.

Я уже заменял тот селект на вот такой
from 
(
	-- здесь мы выберем те ЛС по которым начисления есть, но записи в  Fact_LS_countRegPeople нету
	select distinct x.cod_pl
	from 
		Fact_Nach x
		left join Fact_LS_countRegPeople y on 
			y.period_YYYYMM = x.b_period_YYYYMM 
			and y.cod_pl = x.cod_pl 
	where
		x.b_period_YYYYMM = @YYYYMM
		and s_nach <> 0
		and y.cod_pl is null
) t

- тоже не помогло. Вот именно при 201110 оно криво себя ведет.
16 дек 11, 08:01    [11775667]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Игорь Бобак,

Протестируйте функции вот так. Принудительно поставте в начале.

SET @YYYYMM = 201110 --201109 и это тоже, если первое не заработает.
16 дек 11, 08:20    [11775692]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
aleks2
Guest
Если использование inline-функции не является священной коровой, то преписывание запроса через табличные переменные - спасет отца русской демократии.
16 дек 11, 11:26    [11776415]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 197
А по моему сервер все честно сказал, чего ему не хватает.
На "плохом" запросе сверху чего написано?
Missing index и impact у него большой.

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

Вариантов могу придумать кучу.
Например:

1. Отсутствие индексов. Для этого достаточно:
1.1. Версия сервера энтерпрайз
1.2. В базе есть индексированая вьюха основанная на таблицах из запроса, у которой есть покрывающие индексы по партициям ниже 201010 и нет по 201010

2. Партиция 2010 создается автоматом и на предидущих партициях руками включили DATACOMPRESSION, а на этой нет.
Неоднократно видел, как сервер выбирает неоптимальный индекс, только потому, что он сжат и занимает меньше места.

Ну в принципе гадать можно долго, вышлите все же какой индекс он просит.
16 дек 11, 11:41    [11776533]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
MIKakaHunter
Member

Откуда: Тюмень
Сообщений: 11
Возможно все проще.
Если этот подзапрос:
(select top 1 count_reg -- для каждого такого ЛС кореллированный запрос выдернет последнюю запись из Fact_LS_countRegPeople
from Fact_LS_countRegPeople z
where period_YYYYMM < @YYYYMM
	and z.cod_pl = t.cod_pl
order by period_YYYYMM desc)

заменить на такой вариант:
select count_reg 
from Fact_LS_countRegPeople z
where
     z.cod_pl = t.cod_pl and 
     period_YYYYMM = 
        	(select MAX(period_YYYYMM) 
	         from Fact_LS_countRegPeople F
                 where F.period_YYYYMM < @YYYYMM
               		and F.cod_pl = t.cod_pl)


Может быть чем больше данных нужно сортировать тем труднее определиться с выбором оптимизатору, соответственно другие планы и другая производительность.
16 дек 11, 12:24    [11776841]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Игорь Бобак,

А сколько Estimated Number of Rows будет в предполагаемом плане до и после группировки для такого запроса?

select distinct x.cod_pl
	from Fact_Nach x
	where b_period_YYYYMM = 201110
	and s_nach <> 0


И можно планы выкладывать в виде xml, а не как картинки?
16 дек 11, 23:24    [11781030]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

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

ваш подзапрос исправил ситуацию для случая 201110, но для 201111 та же картина что и была. так что не помогло.
16 дек 11, 23:32    [11781068]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
LogrusAS
А по моему сервер все честно сказал, чего ему не хватает.
На "плохом" запросе сверху чего написано?
Missing index и impact у него большой.

Сергей, стоит кластерный индекс по паре полей period_YYYYMM, cod_pl.
при этом он секционирован по полю period_YYYYMM. Вижу это своими глазами - если хотите скриншот выложу.
Если еще раз посмотреть на код запроса - переписал ниже с учетом замечаний Михаила, то видно что в нем есть только один кусок который дергает несколько секций - это тот что

from Fact_LS_countRegPeople z
where z.period_YYYYMM =
(select MAX(period_YYYYMM)

а остальные могут дергать только ОДНУ секцию. Вот зачем оно просит еще один некластерный индекс по полям (cod_pl, period_YYYYMM) если у него уже есть КЛАСТЕРНЫЙ индекс по этим же полям? Маразм.

При этом если смотреть план запроса
select * from [fnFact_LS_countRegPeople](201109)
- то все хорошо, индексов не просит.

Вот если смотреть
select * from [fnFact_LS_countRegPeople](201111)
- то говорит "дай индекс".

Ну блин, слов нету... зачем ему индекс если он уже есть?

Запрос:
alter function [dbo].[fnFact_LS_countRegPeople](@YYYYMM int) returns table
as
return
-- первая часть дает нам те записи в Fact_LS_countRegPeople по которым площадь прописана
select 
	cod_pl,
	0 as id,
	@YYYYMM as period_YYYYMM,
	@YYYYMM * 100 + 1 as period_YYYYMM01,
	count_reg
from 
	dbo.Fact_LS_countRegPeople
where 
	period_YYYYMM = @YYYYMM
	
union all

select 
	t.cod_pl, -- таблица t даст нам те ЛС, по которым есть начисления, но которых нету в Fact_LS_countRegPeople
	0 as id,
	@YYYYMM as period_YYYYMM,
	@YYYYMM * 100 + 1 as period_YYYYMM01,
	(select count_reg -- для каждого такого ЛС кореллированный запрос выдернет последнюю запись из Fact_LS_countRegPeople
	from Fact_LS_countRegPeople z
		where z.period_YYYYMM = 
				(select MAX(period_YYYYMM) 
				from Fact_LS_countRegPeople z2
				where z2.period_YYYYMM < @YYYYMM
					and z2.cod_pl = t.cod_pl)
			and z.cod_pl = t.cod_pl)
			as countRegPeople
from 
(
	-- здесь мы выберем те ЛС по которым начисления есть, но записи в  Fact_LS_countRegPeople нету
	select distinct x.cod_pl
	from Fact_Nach x
	where b_period_YYYYMM = @YYYYMM
	and s_nach <> 0
	and not exists
		(-- эта выборка даст 1 если по этому ЛС есть запись в Fact_LS_countRegPeople
		select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = x.b_period_YYYYMM  and y.cod_pl = x.cod_pl 
		)
) t
16 дек 11, 23:41    [11781106]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
Удалось немного сузить задачу. Тупит не тот первый подзапрос, а второй -тот что внизу.
Если запустить вот так

select distinct x.cod_pl
	from Fact_Nach x
	where 
	b_period_YYYYMM = 201109
	and s_nach <> 0
	
	and not exists
		(select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = x.b_period_YYYYMM  and y.cod_pl = x.cod_pl 
		)

то все хорошо, но если запустить то же самое только по месяцу 201111

select distinct x.cod_pl
	from Fact_Nach x
	where 
	b_period_YYYYMM = 201111
	and s_nach <> 0
	
	and not exists
		(select 1 from Fact_LS_countRegPeople y 
		where y.period_YYYYMM = x.b_period_YYYYMM  and y.cod_pl = x.cod_pl 
		)

то будет иная картина:

К сообщению приложен файл. Размер - 43Kb
17 дек 11, 00:34    [11781238]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
при этом еще раз подчеркиваю: в обеих таблицах кластерный индекс с первым полем YYYYMM, второе поле cod_pl.
Секционирование по полю YYYYMM на одной и той же схеме.

Секции априори не могут быть разными, потому что их создает одна и та же сторед процедура, которая вызывается из C# кода, который вначале наполняет ХД а потом процессит кубы. В C# коде реализована логика которая не будет процессить кубы (то есть запускать вот эти запросы) если вдруг отвалилось создание индексов на секциях.

Фрагментацию индекса смотрел - 0%, что и не удивительно: ведь вначале загружается с другого сервера вся секция в отдельную таблицу балком, по которой создаются те же индексы что в секционированной таблице, а потом она вставляется через switch to partition в главную таблицу.

Количество данных:
Fact_Nach секция 201109 - 5567319 строк
Fact_Nach секция 201111 - 5843460 строк
Fact_LS_countRegPeople секция 201109 - 363149 строк
Fact_LS_countRegPeople секция 201111 - 354362 строк

то есть почти равное количество.
Вот почему в одном случае план будет нормальный, а в другом - аж настолько тормознутый?
17 дек 11, 00:55    [11781288]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
лолл
Member

Откуда:
Сообщений: 450
интересно, почему в первом случае обе таблицы обрабатываются параллельно в разных потоках, а во втором - последовательно? не в этом ли причина? возможно ли это проверить установкой хинта maxdop 1 для первого случая?
17 дек 11, 01:19    [11781345]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Игорь Бобак
Количество данных:
Fact_Nach секция 201109 - 5567319 строк
Fact_Nach секция 201111 - 5843460 строк
Fact_LS_countRegPeople секция 201109 - 363149 строк
Fact_LS_countRegPeople секция 201111 - 354362 строк
то есть почти равное количество.
Вот почему в одном случае план будет нормальный, а в другом - аж настолько тормознутый?

А вы уверены что сервер знает эти цифры? Толщина стрелок в планах ни о чем не говорит? И еще раз, тут не форум дизайнеров, нам не интересны ваши картинки, нам интересны цифры, планы в XML! Right click -> Save Execation Plan As ... .sqlplan
Смотрите статистику, скорее всего там проблемы.
17 дек 11, 01:45    [11781398]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
лолл
интересно, почему в первом случае обе таблицы обрабатываются параллельно в разных потоках, а во втором - последовательно? не в этом ли причина? возможно ли это проверить установкой хинта maxdop 1 для первого случая?

Пальцем в небо. Во втором случае сервер похоже решает что там очень мало строк, так нафига разные потоки создавать. Параллелизм или нет это уже следствие, а не причина.

К тому же проблема не с первый запросом, а со вторым, так чего первый то курочать?
17 дек 11, 01:48    [11781407]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

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

вот мне только что человек, который вообще ничего не знает о SQL Server и вообще не является программером, посоветовал заново перезагрузить данные в ХД. Я выполнил эту перезагрузку. Источник, из которого загрузка шла, никто не менял (это я знаю точно, потому что с этой базой только я работаю). У нас пишется очень детальный лог чего и сколько загрузилось, четко вижу что контент вгрузился тот же.

То есть, инфа с секций 201110, 201111, 201112 во всех таблицах ХД выбросилась путем switch в отдельные таблицы и потом drop, а новая пришла в отдельные таблицы + switch их как секции в секционированные.

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


Вы правы насчет картинок. Я жалею что не сохранил XML планов. Статистика индексов, ....

Но вот вопрос: почему она нормально не построилась при первой загрузке? Делаем bulk insert в отдельную таблицу, потом по ней create index таких же индексов как в секционированной (и вот здесь построение статистики и глюкануло в первый раз), потом switch в главную таблицу. Или может когда делаем switch то оно не обновляет статистику секционированной таблицы...

Хоть прям бери и запускай вручную после перезаливки по всем таблицам UPDATE STATISTICS.
А еще DBCC FREEPROCCACHE на всякий случай.

Что посоветуете делать для профилактики после перезагрузки данных в ХД, чтобы такое-вот не вылезло повторно в будущем?
17 дек 11, 02:07    [11781432]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Игорь Бобак
Member

Откуда:
Сообщений: 426
лолл
интересно, почему в первом случае обе таблицы обрабатываются параллельно в разных потоках, а во втором - последовательно? не в этом ли причина? возможно ли это проверить установкой хинта maxdop 1 для первого случая?

Я это делал (еще перед перезагрузкой данных в ХД, которая решила проблему).
Так вот, если для первого запроса установить maxdop 1, то скорость отработки была 3 секунды. Если без maxdop1 - 1 секунда. Второй же нагло строил не тот план и не важно какой был maxdop.

Виной всему кривая статистика на некоторых секциях. Вот вопрос в том, как уберечь себя от того, чтобы она опять не была кривой после нормальной штатной загрузки последующих месяцев.
17 дек 11, 02:21    [11781445]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Игорь Бобак
Mind,

вот мне только что человек, который вообще ничего не знает о SQL Server и вообще не является программером, посоветовал заново перезагрузить данные в ХД. Я выполнил эту перезагрузку. Источник, из которого загрузка шла, никто не менял (это я знаю точно, потому что с этой базой только я работаю). У нас пишется очень детальный лог чего и сколько загрузилось, четко вижу что контент вгрузился тот же.
Знаете так можно советовать создать новую базу и перелить данные из старой в новую. Да чет там мелочится, новый сервер с новой виндой и все заного перелить, вот это задача для настоящего DBA :)
Я бы на вашем месте был бы поосторожнее со следованием таким советам. Случись что, за сервер и данные того человека не спросят.

Игорь Бобак
Но вот вопрос: почему она нормально не построилась при первой загрузке? Делаем bulk insert в отдельную таблицу, потом по ней create index таких же индексов как в секционированной (и вот здесь построение статистики и глюкануло в первый раз), потом switch в главную таблицу. Или может когда делаем switch то оно не обновляет статистику секционированной таблицы...
А кто её обновляет? Я не очень спец в партиционированных таблицах, но если помыслить логически можно прийти к следующим выводам. Есть пустая таблица, вставили туда 5 миллионов строк, статистика должна пересчитатся потому что изменилось 100% строк, хорошо. Но потом когда мы делаем switch в главную таблицу, я себе не могу представить как сервер может сделать MERGE статистики с этих 2х таблиц. Особенно если говорить о статистиках по столбцам которые не учавствуют в секционировании. Статистика должна быть пересчитана полностью. Таким образом вероятно остается та же статистика что и была для основной таблицы, а со вторичной просто игнорируется. Если у кого есть по этому поводу инфа поделитесь плиз, потому что в гугле я ничего не нашел.

Игорь Бобак
Хоть прям бери и запускай вручную после перезаливки по всем таблицам UPDATE STATISTICS.
Что посоветуете делать для профилактики после перезагрузки данных в ХД, чтобы такое-вот не вылезло повторно в будущем?

Именно так и надо делать, вручную запускать UPDATE STATISTICS, потому что сревер этим озаботится только если изменится больше 20% таблицы, я сомневаюсь что столько данных у вас в одной секции. Хорошо если бы была возможность пересчитать только новую партицию, а не всю таблицу, но майкрософту на наши хотелки пофик http://connect.microsoft.com/SQLServer/feedback/details/468517/update-statistics-at-the-partition-level
17 дек 11, 02:40    [11781468]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Да, я проверил, все правильно, так и есть со статистикой на секционированных таблицах.

Допустим есть таблицы TableMain и Table201105 со своими посчитанными статистиками. Если мы делаем SWITCH Table201105 в TableMain, то на Table201105 статистика пересчитается при следующем обращении к таблице так как обновились все записи. В TableMain же никакого автоматического обновления не произойдет и в статистике за период 201105 будет просто пусто до тех пор пока не сделать пересчет вручную.

Если же скажем сделать выгрузку периода 201001 в Table201001, то опять таки при селекте из Table201001 статистика будет автоматически пересчитана, в то время как в TableMain за период 201001 все еще будет висеть наши "5 миллионов строк", которые будут учитываться оптимизатором при построении плана.

Так что пересчитывайте статистику вручную на основной таблице после любых манипуляций с секциями.
17 дек 11, 03:25    [11781501]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Partitioned Table and Index Strategies Using SQL Server 2008
Note Whenever you switch data into or out of a partitioned table, it is important to update statistics on the table. A partitioned table keeps statistics at the table, not the partition level. If you manually update statistics on a static fact table after each new partition is loaded, you can turn off automatic statistics updating.

http://download.microsoft.com/download/D/B/D/DBDE7972-1EB9-470A-BA18-58849DB3EB3B/PartTableAndIndexStrat.docx
17 дек 11, 04:58    [11781576]     Ответить | Цитировать Сообщить модератору
 Re: SQL строит кривой план запроса. Делаем план-гайд - ноль на массу...  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 197
Вышел Cumulative update package 4 for SQL Server 2008 R2 Service Pack 1
Оттуда:
818844 2624527 FIX: Clustered index is not used in the execution plan in SQL Server 2008 R2 if a query uses two or more partitions

Таки баг?
20 дек 11, 18:52    [11799274]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить