Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
Есть две таблицы, по обоим делаю update вида:
update table with (rowlock)  
set 
	date = date
where 
	number = 2

number - PK. По первой таблице это проходит за ~30 милисекунд, по второй ~1 секуду. В первой таблице в три раза больше записей, хотя для Update по PK это играет мало роли. Если посмотреть события в Профайлере, то при работе с обоими таблицами происходит много событий Lock:Aquuired/Lock:Released, но по той таблице, где тормоза в несколько раз больше. Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять. По словам разработчиков на "быстрой" таблице гораздо больше обращений пользователей. Индексы пересоздал, статистику обновил - не помогло.

Что еще может тормозить работу в таком случае? Может какие-то проблемы со структурой?

Спасибо.
2 фев 05, 17:19    [1295079]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Триггер на второй таблице? ФК на поле date? Каскадный?
2 фев 05, 17:22    [1295098]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
Нет ни триггеров, ни FK по date.
2 фев 05, 17:27    [1295122]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Сравните планы выполнения запросов. Разница уж больно большая. Планы должны отличаться.
2 фев 05, 17:29    [1295130]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
Планы абсолютно одинаковые, причем, запрос вида:

select * from table (rowlock) where 	number = 2
Проходит также хорошо как и на "быстрой" таблице.
2 фев 05, 17:36    [1295168]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Извиняюсь за повторный вопрос, Вы смотрели приблизительный или реальный план выполнения? Статиситку серверную?
2 фев 05, 17:37    [1295176]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
автор
Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять.


Так может действительно локи висят?
2 фев 05, 17:39    [1295189]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
pkarklin
Извиняюсь за повторный вопрос, Вы смотрели приблизительный или реальный план выполнения? Статиситку серверную?


План - реальный.
DBCC SHOW_STATISTICS ( Table, PK__number )
-------------------------------------------------------
Statistics for INDEX 'PK__number'.
Updated,Rows,Rows Sampled,Steps,Density,Average key length
Feb 2 2005 3:46PM ,273076,273076,6,3.6619842E-6,4.0

(1 row(s) affected)

All density,Average Length,Columns
3.6619842E-6,4.0,Table

(1 row(s) affected)

RANGE_HI_KEY,RANGE_ROWS,EQ_ROWS,DISTINCT_RANGE_ROWS,AVG_RANGE_ROWS
1,0.0,1.0,0,0.0
59383,59078.0,1.0,59078,1.0
61177,1535.0,1.0,1535,1.0
210606,148991.0,1.0,148991,1.0
274486,63466.0,1.0,63466,1.0
274487,0.0,1.0,0,0.0

(6 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
2 фев 05, 17:48    [1295231]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
pkarklin
автор
Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять.


Так может действительно локи висят?


Как это можно проверить?
2 фев 05, 17:49    [1295235]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Я ни эту статистику имел ввиду, а Ctrl+Shift+S в QA.
2 фев 05, 17:50    [1295241]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Roust_m
pkarklin
автор
Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять.


Так может действительно локи висят?


Как это можно проверить?


sp_lock в момент выполнения запроса.
2 фев 05, 17:51    [1295245]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
pkarklin
Я ни эту статистику имел ввиду, а Ctrl+Shift+S в QA.

Вот статистика. Получается, что большую часть времени запрос не выполняется, а ждет. sp_lock во время запроса не запустишь: запрос сликом короткий.

"Медленная" таблица:

Application Profile Statistics
Timer resolution (milliseconds) 0 0
Number of INSERT UPDATE DELETE statements 1 1
Rows effected by INSERT UPDATE DELETE statements 1 1
Number of SELECT statements 1 1
Rows effected by SELECT statements 2 2
Number of user transactions 14 14
Average fetch time 0 0
Cumulative fetch time 0 0
Number of fetches 0 0
Number of open statement handles 0 0
Max number of opened statement handles 0 0
Cumulative number of statement handles 0 0

Network Statistics
Number of server roundtrips 3 3
Number of TDS packets sent 3 3
Number of TDS packets received 15 15.5
Number of bytes sent 332 332
Number of bytes received 9044 9088

Time Statistics
Cumulative client processing time 46 58
Cumulative wait time on server replies 1.04E+08 1.04E+08

"Быстрая" таблица:

"Application Profile Statistics "
" Timer resolution (milliseconds) 0 0"
Number of INSERT UPDATE DELETE statements 1 1
Rows effected by INSERT UPDATE DELETE statements 1 1
Number of SELECT statements 1 1
Rows effected by SELECT statements 2 2
Number of user transactions 11 11
Average fetch time 0 0
Cumulative fetch time 0 0
Number of fetches 0 0
Number of open statement handles 0 0
Max number of opened statement handles 0 0
Cumulative number of statement handles 0 0

Network Statistics
Number of server roundtrips 3 3
Number of TDS packets sent 3 3
Number of TDS packets received 3 3
Number of bytes sent 298 298
Number of bytes received 1627 1627

Time Statistics
Cumulative client processing time 23 23
Cumulative wait time on server replies 10 10
2 фев 05, 18:02    [1295301]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pitsa
Member

Откуда:
Сообщений: 2
Простите за глупый вопрос. А зачем date = date?
3 фев 05, 08:09    [1296032]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
aleks2
Guest
Roust_m
Есть две таблицы, по обоим делаю update вида:
update table with (rowlock)  
set 
	date = date
where 
	number = 2

number - PK. По первой таблице это проходит за ~30 милисекунд, по второй ~1 секуду. В первой таблице в три раза больше записей, хотя для Update по PK это играет мало роли. Если посмотреть события в Профайлере, то при работе с обоими таблицами происходит много событий Lock:Aquuired/Lock:Released, но по той таблице, где тормоза в несколько раз больше. Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять. По словам разработчиков на "быстрой" таблице гораздо больше обращений пользователей. Индексы пересоздал, статистику обновил - не помогло.

Что еще может тормозить работу в таком случае? Может какие-то проблемы со структурой?

Спасибо.


Индексы тоже блокируются при обновлении.

>>Если посмотреть события в Профайлере, то при работе с обоими таблицами происходит много событий Lock:Aquuired/Lock:Released, но по той таблице, где тормоза в несколько раз больше.

Не худо бы установить на какие ресурсы блокировки идут
3 фев 05, 08:51    [1296083]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
А эти PK кластерные?
3 фев 05, 09:43    [1296189]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
pitsa
Простите за глупый вопрос. А зачем date = date?

Чтобы данные в таблице не менять. Реальные запросы задают конкретное значение, а мой - тестовый.
3 фев 05, 09:57    [1296236]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
tpg
А эти PK кластерные?

Да, кластерные.
3 фев 05, 09:57    [1296238]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Roust_m
tpg
А эти PK кластерные?

Да, кластерные.
А что если попробовать пересоздать их?
3 фев 05, 10:00    [1296249]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
tpg
Roust_m
tpg
А эти PK кластерные?

Да, кластерные.
А что если попробовать пересоздать их?


Уже пробовал переместить PK в другую файловую группу, а потом обратно. Это ведь равносильно пересозданию?
3 фев 05, 10:07    [1296284]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
Roust_m
Member

Откуда: Сидней
Сообщений: 1157
aleks2
Roust_m
Есть две таблицы, по обоим делаю update вида:
update table with (rowlock)  
set 
	date = date
where 
	number = 2

number - PK. По первой таблице это проходит за ~30 милисекунд, по второй ~1 секуду. В первой таблице в три раза больше записей, хотя для Update по PK это играет мало роли. Если посмотреть события в Профайлере, то при работе с обоими таблицами происходит много событий Lock:Aquuired/Lock:Released, но по той таблице, где тормоза в несколько раз больше. Получается, что большую часть времени запрос пытается залочить ту запись, которую пытается менять. По словам разработчиков на "быстрой" таблице гораздо больше обращений пользователей. Индексы пересоздал, статистику обновил - не помогло.

Что еще может тормозить работу в таком случае? Может какие-то проблемы со структурой?

Спасибо.


Индексы тоже блокируются при обновлении.

>>Если посмотреть события в Профайлере, то при работе с обоими таблицами происходит много событий Lock:Aquuired/Lock:Released, но по той таблице, где тормоза в несколько раз больше.

Не худо бы установить на какие ресурсы блокировки идут


Вот что выдает профайлер:

SELECT OBJECT_NAME ( ObjectID ) ObjName, count(*) Count
FROM update (nolock)
group by OBJECT_NAME ( ObjectID )
order by 2 desc
------------------------------------------------------
ObjName	                                               Count
sysindexes	                                  2312
syscolumns	                                  1642
sysobjects	                                  600
NULL 	                                               283
sysdatabases	                                  176
sysusers	                                               156
sysreferences	                                  70
systypes	                                               56
sysdepends	                                  46
sp_MSUpgradeConflictTable	                     17
syscomments	                                  6
sp_scriptxdelproc	                                  4
sp_MSscript_ExecutionMode_stmt	        4
sp_cursorprepare	                                  1
sp_executesql	                                  1
3 фев 05, 10:40    [1296421]     Ответить | Цитировать Сообщить модератору
 Re: Два update по PK  [new]
pitsa
Member

Откуда:
Сообщений: 2
Roust_m
pitsa
Простите за глупый вопрос. А зачем date = date?

Чтобы данные в таблице не менять. Реальные запросы задают конкретное значение, а мой - тестовый.


Спасибо. А я думал, что тут что-то выходящее за рамки моего понимания sql. :)
4 фев 05, 08:21    [1299172]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить