Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
waszkiewicz Member Откуда: Сообщений: 1089 |
update proc_packs set station=109 where id=3456789 такой запрос выполняется более 10 мин (дальше ждать не захотелось) в таблице порядка 40 лимонов записей. Вот таблица
В плане 80% - Clustered Index Update. Развернул бэкап ,,fps на другом сервере - все окэ - запрос исполняется, как положено. В куда смотреть? |
|
14 янв 13, 16:28 [13767923] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Для начала - на блокировки. |
14 янв 13, 16:36 [13767980] Ответить | Цитировать Сообщить модератору |
sergei.mironenko Member Откуда: Сообщений: 11 |
+ посмотреть как ведет себя дисковая подсистема "Data File IO" через Activity Monitor. |
14 янв 13, 16:44 [13768028] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Блин, раздуплилось все. Теперь даже воспроизвести не могу. Куда теперь смотреть? |
14 янв 13, 16:48 [13768055] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Кто-то блокипровал таблицу. |
||
14 янв 13, 17:12 [13768230] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Серверные админы сказали, что физическими винтами все окэ, никаких траблов не было. Сейчас журнал Винды глянем. |
14 янв 13, 17:14 [13768239] Ответить | Цитировать Сообщить модератору |
sergei.mironenko Member Откуда: Сообщений: 11 |
Как сказал Glory, возмножно были блокировки. В помощь, exec sp_lock |
||||
14 янв 13, 17:19 [13768265] Ответить | Цитировать Сообщить модератору |
sergei.mironenko Member Откуда: Сообщений: 11 |
В более читаемом виде:create table #sp_lock_results ( spid smallint, dbid smallint, ObjId int, IndId smallint, Type nchar(4), Resource nchar(32), Mode nvarchar(8), Status nvarchar(5) ) insert into #sp_lock_results exec sp_lock select spid, dbid, db_name(dbid), ObjId, object_name(ObjId), IndId, Type, Resource, Mode, Status from #sp_lock_results where object_name(ObjId) = 'proc_packs' order by spid drop table #sp_lock_results |
14 янв 13, 17:24 [13768294] Ответить | Цитировать Сообщить модератору |
Алексей Куренков Member [заблокирован] Откуда: Москва Сообщений: 567 |
waszkiewicz, Да блокировки смотреть нужно... думаю вначале проще посмотреть что за процессы блокируют и кто кого блокирует (исполняйте в отдельном окне) без детализации блокируемых ресурсов: select o.text, p.* from sys.sysprocesses p outer apply sys.dm_exec_sql_text(p.sql_handle) o where p.blocked>0 or p.spid in ( select blocked from sys.sysprocesses where blocked > 0 ) По мимо блокировок, помогает очень сильно перестройка индексов, что нибудь типа (в окне отработайте реиндексацию - мне помогло не так давно): alter index all on proc_packs |
14 янв 13, 17:34 [13768347] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
К превеликому сожалению таблица #sp_lock_results пуста... |
14 янв 13, 17:35 [13768362] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Разумеется. Раз "раздуплилось все", то блокировки уже нет. |
||
14 янв 13, 17:38 [13768383] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
А логи где-то почитать можно? |
14 янв 13, 17:49 [13768461] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
|
||
14 янв 13, 17:49 [13768464] Ответить | Цитировать Сообщить модератору |
Алексей Куренков Member [заблокирован] Откуда: Москва Сообщений: 567 |
waszkiewicz, Логи Вашего апдейта по умолчанию не ведутся. Используйте PROFILER если нужны логи - на время выполнения операции. |
14 янв 13, 17:50 [13768475] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Блокировки - это нормальный механизм. А не ошибка системы. |
||
14 янв 13, 17:52 [13768493] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Я имел ввиду логи блокировок |
14 янв 13, 17:52 [13768497] Ответить | Цитировать Сообщить модератору |
Алексей Куренков Member [заблокирован] Откуда: Москва Сообщений: 567 |
waszkiewicz, Вам же написали - логи блокировок не ведутся. Нужно использовать либо Profiler либо Extended Events либо еще какие придуманные механизмы (внешние утилиты) для логирования блокировок. |
14 янв 13, 17:56 [13768542] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Мог ли рекурсивный триггер привести к блокировке? (и как тогда "раздуплилось"?) |
14 янв 13, 17:59 [13768562] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Любая команда в TSQL использует хоть какую то блокировку. |
||
14 янв 13, 18:01 [13768581] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Получается, что в триггере на таблицу (AFTER UPDATE) вызывается опять же UPDATE её же, как минимум ROWLOCK уже есть (или нет?), соответственно дальше триггер не вызывается, ошибки с глубиной рекурсии не имеем? Так? Тогда неясно, почему "раздуплилось" и нет ошибки с глубиной? |
14 янв 13, 18:08 [13768624] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Причем тут рекурсия ? Кто-то написал в другом коннекте select * from mytable(xlock) и пошел пить кофе Потом вернулся и закрыл коннект |
||
14 янв 13, 18:11 [13768646] Ответить | Цитировать Сообщить модератору |
sergei.mironenko Member Откуда: Сообщений: 11 |
Скорее всего не в триггере дело, а в блокировках на саму таблицу. |
||
14 янв 13, 18:12 [13768653] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
Походу, в нем. При отключенным триггере запрос отрабатывал. Опять же, как быть с превышением глубины рекурсии - триггер ошибочен и явно рекурсивный |
14 янв 13, 18:18 [13768677] Ответить | Цитировать Сообщить модератору |
sergei.mironenko Member Откуда: Сообщений: 11 |
Можно сам триггер в студию? |
||
14 янв 13, 18:23 [13768701] Ответить | Цитировать Сообщить модератору |
waszkiewicz Member Откуда: Сообщений: 1089 |
ALTER TRIGGER Consume ON dbo.[proc_packs] AFTER UPDATE AS SET NOCOUNT ON UPDATE proc_packs SET cday = (SELECT po FROM proc_prunits pp WHERE pp.prunit = 52) FROM proc_packs ppp JOIN deleted d ON ppp.id = d.id WHERE ppp.rtype = 12 AND ppp.station = 109 |
14 янв 13, 18:30 [13768737] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |