MSSQL. Не напомните, из-за чего и как обойти?

← →
OW © (2011-09-29 15:12) [0]

пишу было

declare @FD DateTime, @SD DateTime
set @FD = "29.09.2011"
set @SD = "30.09.2011"
select
*
from
Request r
left join Stage S on S.id_request = R.id_request
where
r.start_time between @FD and @SD
order by
R.id_request

очень долго.. более минуты
Не дожидаюсь, т.к. неприемлимо уже.
|--Parallelism(Gather Streams, ORDER BY:([r].[id_request] ASC)) |--Sort(ORDER BY:([r].[id_request] ASC)) |--Hash Match(Left Outer Join, HASH:([r].[id_request])=([S].[id_request]), RESIDUAL:([ccc].[dbo].[stage].[id_request] as [S].[id_request]=[ccc].[dbo].[request].[id_request] as [r].[id_request])) |--Bitmap(HASH:([r].[id_request]), DEFINE:([Bitmap1004])) | |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([r].[id_request])) | |--Clustered Index Scan(OBJECT:([ccc].[dbo].[request].[PK_requests] AS [r]), WHERE:([ccc].[dbo].[request].[start_time] as [r].[start_time]>=[@FD] AND [ccc].[dbo].[request].[start_time] as [r].[start_time]<=[@SD])) |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([S].[id_request]), WHERE:(PROBE([Bitmap1004])=TRUE)) |--Clustered Index Scan(OBJECT:([ccc].[dbo].[stage].[PK_stages] AS [S])) (8 row(s) affected)

select
*
from
Request r
left join Stage S on S.id_request = R.id_request
where
r.start_time between "29.09.2011" and "30.09.2011"
order by
R.id_request

несколько секунд.
|--Nested Loops(Inner Join, PASSTHRU:([IsBaseRow1003] IS NULL), OUTER REFERENCES:([S].[id_stage])) |--Nested Loops(Left Outer Join, OUTER REFERENCES:([r].[id_request], [Expr1005]) WITH ORDERED PREFETCH) | |--Sort(ORDER BY:([r].[id_request] ASC)) | | |--Nested Loops(Inner Join, OUTER REFERENCES:([r].[id_request], [Expr1004]) OPTIMIZED WITH UNORDERED PREFETCH) | | |--Index Seek(OBJECT:([ccc].[dbo].[request].[IX_request_st] AS [r]), SEEK:([r].[start_time] >= "2011-09-29 00:00:00.000" AND [r].[start_time] <= "2011-09-30 00:00:00.000") ORDERED FORWARD) | | |--Clustered Index Seek(OBJECT:([ccc].[dbo].[request].[PK_requests] AS [r]), SEEK:([r].[id_request]=[ccc].[dbo].[request].[id_request] as [r].[id_request]) LOOKUP ORDERED FORWARD) | |--Index Seek(OBJECT:([ccc].[dbo].[stage].[IX_stage_id_request] AS [S]), SEEK:([S].[id_request]=[ccc].[dbo].[request].[id_request] as [r].[id_request]) ORDERED FORWARD) |--Clustered Index Seek(OBJECT:([ccc].[dbo].[stage].[PK_stages] AS [S]), SEEK:([S].[id_stage]=[ccc].[dbo].[stage].[id_stage] as [S].[id_stage]) LOOKUP ORDERED FORWARD)

← →
Ega23 © (2011-09-29 16:24) [1]

Сначала дождись результата

> очень долго.. более минуты

Потом выполни

DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE

Потом снова дождись результата

> несколько секунд.

Время меняется или нет?

← →
OW © (2011-09-29 16:40) [2]

> > несколько секунд.
> Время меняется или нет?

нет
5-6 секунд

> DBCC DROPCLEANBUFFERS
> DBCC FREEPROCCACHE
>

пока делать не буду.
на ночь сделаю
===========

с др. стороны, запрос то один и тот же
а планы разные.

← →
Ega23 © (2011-09-29 16:59) [3]

Кстати. А ты уверен, что там именно LEFT JOIN, а не INNER JOIN?

← →
Ega23 © (2011-09-29 17:10) [4]

set @FD = cast("29.09.2011" as datetime) set @SD = cast("30.09.2011" as datetime)

← →
Кщд (2011-09-29 17:37) [5]

>OW © (29.09.11 15:12)
статистика собрана?
при явном указании способа соединения и метода доступа(хинты) не получается?

сегодня отработало

вот честно, пока админ болел - я его замещал, ничего не делал :) - проблем с БД не было. Как вышел админ - опять какие-то работы пошел делать, опять какие-то проблемы странные пошли.. Лучше бы он не приходил :)

а еще 2 джоба свалилось ночью не отработали. Сейчас отлично опять.
Я убью тебя, лодочник (с)

Вспасибо, ребят,за помощь и прошу извинений за панику :)

MSSQL. Не напомните, из-за чего и как обойти? Найти похожие ветки