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

Откуда:
Сообщений: 283
Доброго дня.
Подскажите, насколько вероятна ситуация сверхдолгого (более суток) выполнения операции Clustered Index Merge, при условии, что ожидаемый план запроса показывает адекватное количество строк, а целевая таблица пуста? На вход подается таблица с 320млн строк, условие when matched проверяет с помощью "or" несовпадение хотя бы по одному из 8 атрибутов при совпадение по 2м ключевым.
Заранее спасибо.
18 апр 16, 11:45    [19071037]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
Дополняю планом и изображением с частью плана, включающей merge join

К сообщению приложен файл. Размер - 28Kb
18 апр 16, 11:46    [19071044]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
Просьба предоставить текст запроса. Прикрепить план выполнения в формате sqlplan. Показать структуру таблиц и индексы. Тогда будет возможность осмысленно ответить на Ваш вопрос.
18 апр 16, 11:50    [19071060]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
iljy
Member

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

а еще есть прямой смысл проверить блокировки.
18 апр 16, 11:53    [19071075]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
Glory
Member

Откуда:
Сообщений: 104751
baza906
Подскажите, насколько вероятна ситуация сверхдолгого (более суток) выполнения операции Clustered Index Merge, при условии,

- Какова вероятность, что выйдя на улицу, вы встретите динозавра ?
- 50%
- ???
- Ну либо встречу, либо не встречу.
18 апр 16, 11:54    [19071088]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
Glory,
здесь вероятно встретить человека с опытом подобных проблем. С динозавром - вряд ли.
18 апр 16, 12:00    [19071119]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
AlanDenton,
план, во вложении


--ЗАПРОС
merge into T1  o 
using T2 i on (i.DEAL_RK = o.DEAL_RK and i.EFFECTIVE_FROM_DT = o.EFFECTIVE_FROM_DT)
when matched and ((i.EFFECTIVE_TO_DT <> o.EFFECTIVE_TO_DT and i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is null) 
			or (i.CO_DEAL_AMT <> o.CO_DEAL_AMT and i.CO_DEAL_AMT is not null and o.CO_DEAL_AMT is not null
			or i.CO_DEAL_AMT is null and o.CO_DEAL_AMT is not null
			or i.CO_DEAL_AMT is not null and o.CO_DEAL_AMT is null) or (i.CI_PRINC_P <> o.CI_PRINC_P and i.CI_PRINC_P is not null and o.CI_PRINC_P is not null
			or i.CI_PRINC_P is null and o.CI_PRINC_P is not null
			or i.CI_PRINC_P is not null and o.CI_PRINC_P is null) or (i.TOTAL_P <> o.TOTAL_P and i.TOTAL_P is not null and o.TOTAL_P is not null
			or i.TOTAL_P is null and o.TOTAL_P is not null
			or i.TOTAL_P is not null and o.TOTAL_P is null) or (i.OVERPAY_AMT <> o.OVERPAY_AMT and i.OVERPAY_AMT is not null and o.OVERPAY_AMT is not null
			or i.OVERPAY_AMT is null and o.OVERPAY_AMT is not null
			or i.OVERPAY_AMT is not null and o.OVERPAY_AMT is null) 
			or (i.T_OVERPAY_AMT <> o.T_OVERPAY_AMT and i.T_OVERPAY_AMT is not null and o.T_OVERPAY_AMT is not null
			or i.T_OVERPAY_AMT is null and o.T_OVERPAY_AMT is not null
			or i.T_OVERPAY_AMT is not null and o.T_OVERPAY_AMT is null)) 
then 
update set 
	o.EFFECTIVE_TO_DT =  i.EFFECTIVE_TO_DT, 
	o.CO_DEAL_AMT =  i.CO_DEAL_AMT, 
	o.CI_PRINC_P =  i.CI_PRINC_P, o.TOTAL_P =  i.TOTAL_P, 
	o.PROCESSED_DTTM = getdate(), 
	o.OVERPAY_AMT =  i.OVERPAY_AMT, 
	o.T_OVERPAY_AMT =  i.T_OVERPAY_AMT 
when 
not matched by target then 
insert into T1 (DEAL_RK, EFFECTIVE_FROM_DT, EFFECTIVE_TO_DT, CO_DEAL_AMT, CI_PRINC_P, TOTAL_P, PROCESSED_DTTM, OVERPAY_AMT, T_OVERPAY_AMT) 
select DEAL_RK, EFFECTIVE_FROM_DT, EFFECTIVE_TO_DT, CO_DEAL_AMT, CI_PRINC_P, TOTAL_P, PROCESSED_DTTM, OVERPAY_AMT, T_OVERPAY_AMT);

--Структура индексов
CLUSTERED INDEX T1
[DEAL_RK] ASC,
[EFFECTIVE_FROM_DT] ASC,
[EFFECTIVE_TO_DT]

CLUSTERED INDEX T2
ACCOUNT_RK, 
EFFECTIVE_FROM_DTTM

--Список столбцов обеих таблиц одинаков:
--DEAL_RK, EFFECTIVE_FROM_DT, EFFECTIVE_TO_DT, CO_DEAL_AMT, CI_PRINC_P, TOTAL_P, PROCESSED_DTTM, OVERPAY_AMT, _OVERPAY_AMT
--int        datetime             datetime       numeric     numeric    numeric   datetime         numeric       numeric  


К сообщению приложен файл (merge.zip - 15Kb) cкачать
18 апр 16, 12:02    [19071132]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
iljy, параллельно никаких процессов не выполняется
18 апр 16, 12:04    [19071147]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
У Вас на плане вторая таблица - это куча. О какой производительности можно говорить?
18 апр 16, 12:07    [19071159]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
baza906,

table scan... жутко поплохело :)
18 апр 16, 12:07    [19071164]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
_djХомяГ
Guest
Да еще с буевой тучей записей
18 апр 16, 12:10    [19071184]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
Glory
Member

Откуда:
Сообщений: 104751
baza906
здесь вероятно встретить человека с опытом подобных проблем.

А почему вы решили, что проблема в одном шаге вашего плана ?
18 апр 16, 12:13    [19071207]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
Glory,
это не гарантировано и снижает вероятность. но она не становится нулевой
18 апр 16, 12:15    [19071223]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
Glory
Member

Откуда:
Сообщений: 104751
baza906
это не гарантировано и снижает вероятность. но она не становится нулевой

Если вы НЕ знаете, почему ваш запрос так работает, то НЕ надо выдвигать бредовые предположение насчет "вероятности ситуации зависимости производительности от Clustered Index Merge"
18 апр 16, 12:18    [19071254]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
baza906,
в ваш merge, ко всему прочему приходит 762kk строк... может стоит как-то ограничить/разбить сей опус...
18 апр 16, 12:19    [19071259]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
AlanDenton,
точно, невнимательно посмотрел. На нее создается некластеризованный индекс вместо кластеризованного. Попробую перезагрузить, пересоздав индекс в кластеризованный
18 апр 16, 12:20    [19071269]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
Glory,
99% выполнения в ожидаемом плане не дает оснований выдвигать предположения, подобные моим?
18 апр 16, 12:21    [19071277]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
baza906
Glory,
99% выполнения в ожидаемом плане не дает оснований выдвигать предположения, подобные моим?

нет... 100% нет :)
18 апр 16, 12:22    [19071285]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
_djХомяГ
Guest
Вы сначала определитесь по каким полям создавать кластерный индекс + дейлайте это на тестовом окружении а то есть вероятность что можете просто как бы - "завесить" систему
Вообщем как в пословице - 7 раз отмерь один отрежь
18 апр 16, 12:24    [19071304]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
Glory
Member

Откуда:
Сообщений: 104751
baza906
99% выполнения в ожидаемом плане не дает оснований выдвигать предположения, подобные моим?

Право выдвигать - дает. Хоть 0%, хоть 99%.
18 апр 16, 12:25    [19071316]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4823
Хочу предложить писать полегче

(i.EFFECTIVE_TO_DT <> o.EFFECTIVE_TO_DT and i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is null) 


ISNULL(i.EFFECTIVE_TO_DT, '1900-01-01') <> ISNULL(o.EFFECTIVE_TO_DT, '1900-01-01')
18 апр 16, 12:38    [19071388]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
baza906, самое хорошее что можно сделать - это определиться с индексом кластреным (по каким полям будет и тд). Далее нужно прочитать про минимальное протоколирование. И понять как лучше основной кусок данных перелить в другую таблицу. MERGE для этого подходит не сильно хорошо (именно при первой заливке данных). Относительно того что на плане у Вас 99% показывает один оператор... это ни о чем не говорит. План то у Вас ожидаемый, а не реальный. К слову XML методы на плане тоже переоцениваются сильно.
18 апр 16, 12:39    [19071397]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
a_voronin
Хочу предложить писать полегче

(i.EFFECTIVE_TO_DT <> o.EFFECTIVE_TO_DT and i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is null and o.EFFECTIVE_TO_DT is not null
			or i.EFFECTIVE_TO_DT is not null and o.EFFECTIVE_TO_DT is null) 


ISNULL(i.EFFECTIVE_TO_DT, '1900-01-01') <> ISNULL(o.EFFECTIVE_TO_DT, '1900-01-01')

есть подозрение что у автора ещё и со скобками проблема
18 апр 16, 12:50    [19071452]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
baza906
Member

Откуда:
Сообщений: 283
AlanDenton,
Спасибо. Но в том то и проблема, что полная заливка - это разовая возникшая необходимость. Вообще процедура, использующая высланный мной скрипт, выполняет merge на основе данных, пришедших за последнюю загрузку (от 300тыс да 500тыс строк). По этому хотелось бы загрузить, ничего в ней не меняя, не используя insert into with(tablocx). Если не получится - придется менять логику потока данных, так как иного решения не останется.
18 апр 16, 13:00    [19071505]     Ответить | Цитировать Сообщить модератору
 Re: Проблема производительности на шаге Clustered Index Merge  [new]
invm
Member

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

Полного сканирования T2 вам не избежать. Потому что присутствует предложение not matched в merge.

Кластерный индекс на T2 ничем не поможет. Даже если он будет по (DEAL_RK, EFFECTIVE_FROM_DT). Даже если он будет уникальным. Даже если вы на T1 существующий кластерный сделаете уникальным.
Потому что, если таблицы и будут соединяться по merge join, то из-за условия соединения это будет many-to-many merge. В данном случае hash join будет эффективнее.
18 апр 16, 13:14    [19071575]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить