Непредсказуемый update (MS SQL 2000)
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
Непредсказуемый update (MS SQL 2000)
Помогите, господа! Может кто-нибудь на такие грабли натыкался...
Есть update:
UPDATE i
SET Domain='C'
FROM tblFacilityInventory i
JOIN tblFacilityHierarchy h ON h.FaxId=i.FaxId
JOIN rcvSystemInventory s ON h.Position LIKE s.Position+'.%'
WHERE s.Domain='C'
tblFacilityInventory = ~ 2,200,000 rows
tblFacilityHierarchy= ~ 5,600,000 rows
rcvSystemInventory= ~ 19,000 rows
Ни одна таблица не имеет никаких на нее глядящих foreign keys.
На всех машинах отрабатывает за 5-10 секунд.
На одной машине (гораздо более мощной) не работает вообще - отжирает все 4 CPU под 100% и не дышит.
Данные на всех машинах приблизительно одинаковые. +/- 100,000 rows в первых двух таблицах.
Попробовали разбить так:
SELECT h.FaxId
INTO #tempinv
FROM tmpFacilityHierarchy h
JOIN rcvSystemInventory s ON h.Position LIKE s.Position+'.%'
WHERE s.Domain='C'
UPDATE i
SET Domain='C'
FROM tmpFacilityInventory i
JOIN #tempinv t ON t.FaxId=i.FaxId
Выполняется за 8-10 секунд...
Встречаю подобную аномалию уже третий или четвертый раз.
Это я что-то не так делаю или SQL server?
P.S. Когда выполняется UPDATE или вернее пытался выполниться, врубается параллелизм и в основном процессе CXPACKET может висеть минутами и часами.
P.P.S. Размеры всех баз и транзакшн логов более чем достаточные...
Буду благодарен за любые идеи...
Есть update:
UPDATE i
SET Domain='C'
FROM tblFacilityInventory i
JOIN tblFacilityHierarchy h ON h.FaxId=i.FaxId
JOIN rcvSystemInventory s ON h.Position LIKE s.Position+'.%'
WHERE s.Domain='C'
tblFacilityInventory = ~ 2,200,000 rows
tblFacilityHierarchy= ~ 5,600,000 rows
rcvSystemInventory= ~ 19,000 rows
Ни одна таблица не имеет никаких на нее глядящих foreign keys.
На всех машинах отрабатывает за 5-10 секунд.
На одной машине (гораздо более мощной) не работает вообще - отжирает все 4 CPU под 100% и не дышит.
Данные на всех машинах приблизительно одинаковые. +/- 100,000 rows в первых двух таблицах.
Попробовали разбить так:
SELECT h.FaxId
INTO #tempinv
FROM tmpFacilityHierarchy h
JOIN rcvSystemInventory s ON h.Position LIKE s.Position+'.%'
WHERE s.Domain='C'
UPDATE i
SET Domain='C'
FROM tmpFacilityInventory i
JOIN #tempinv t ON t.FaxId=i.FaxId
Выполняется за 8-10 секунд...
Встречаю подобную аномалию уже третий или четвертый раз.
Это я что-то не так делаю или SQL server?
P.S. Когда выполняется UPDATE или вернее пытался выполниться, врубается параллелизм и в основном процессе CXPACKET может висеть минутами и часами.
P.P.S. Размеры всех баз и транзакшн логов более чем достаточные...
Буду благодарен за любые идеи...
All bubble-blowing babies will be beaten senseless...
-
- Уже с Приветом
- Posts: 569
- Joined: 14 Dec 2003 04:06
- Location: Львов->Киев->Торонто
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
-
- Уже с Приветом
- Posts: 28294
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
-
- Уже с Приветом
- Posts: 1099
- Joined: 30 Sep 1999 09:01
- Location: Bryansk,RUSSIA >> Dublin, Ireland
Вы ничего не написали про индексы, ничего - про статистику, вернее ее актуальность.
Я бы все-таки советовал дождаться завершения выполнения апдейта на медленной машине и посмотренть планы - хотя если запрос "висит часами" первое про что бы я подумал - блокировки, где-то висит незакрытая транзакция.
Я бы все-таки советовал дождаться завершения выполнения апдейта на медленной машине и посмотренть планы - хотя если запрос "висит часами" первое про что бы я подумал - блокировки, где-то висит незакрытая транзакция.
Удачи@С.Смирнов
-
- Уже с Приветом
- Posts: 28294
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
YellowMan wrote:Вы ничего не написали про индексы, ничего - про статистику, вернее ее актуальность.
Я бы все-таки советовал дождаться завершения выполнения апдейта на медленной машине и посмотренть планы - хотя если запрос "висит часами" первое про что бы я подумал - блокировки, где-то висит незакрытая транзакция.
Да, я забыл написать, что индексы на всех табицах на разных машинах одинаковые.
К таблицам кроме этого update вообще никто не обращается - блокировок там быть не может. Да и вообще, машина которая не может выполнить этот update практически не используется - активность на ней минимальная...
All bubble-blowing babies will be beaten senseless...
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
Dmitry67 wrote:Мое предположение
На мощной машине используется парралелизм
Может используется на всех, Но на одной это происходит неудачно
Hintами отключите парралелизм для этого запроса
Из-за того что в Процессах на одном процессе стоит часами CXPACKET - я тоже подозреваю, что может быть дело в параллелизме...
All bubble-blowing babies will be beaten senseless...
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
Dmitry67 wrote:Мое предположение
На мощной машине используется парралелизм
Может используется на всех, Но на одной это происходит неудачно
Hintами отключите парралелизм для этого запроса
Из-за того что в Процессах на одном процессе стоит часами CXPACKET - я тоже подозреваю, что может быть дело в параллелизме...
All bubble-blowing babies will be beaten senseless...
-
- Уже с Приветом
- Posts: 28294
- Joined: 29 Aug 2000 09:01
- Location: SPB --> Gloucester, MA, US --> SPB --> Paris
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
-
- Уже с Приветом
- Posts: 1099
- Joined: 30 Sep 1999 09:01
- Location: Bryansk,RUSSIA >> Dublin, Ireland
-
- Уже с Приветом
- Posts: 936
- Joined: 04 Jul 2000 09:01
- Location: KZN, RU - ATL, GA
YellowMan wrote:MAXDOP 1 совершенно верно...
Но блокировками все-же не пренебрегайте - я тоже много раз видел как на базах с выставленными auto growth для лога или данных попытка откусить еще места для базы и одновременный insert/update вгоняли базу в кому на неопределенное время...
Да... Но 100% на всех CPU без особой дисковой активности?
All bubble-blowing babies will be beaten senseless...
-
- Уже с Приветом
- Posts: 7723
- Joined: 29 Mar 2000 10:01
- Location: Kirkland,WA