Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
Всем привет наблюдаю картину, примерно, 2 сессии выполняются параллельно и выполняют запросы в порядке: 1. select from tableX with (nolock) - LCK_M_SCH_S (среднее время выполнения 1 минута) 2. не ждет 1ую, drop table tableX - LCK_M_SCH_M обе висят оч долго. Как это работает? Могут ли 1/2 блокировать друг друга? Почему первая не может начать работу, а вторая не ждет когда закончит первая ? но это только наблюдения, если так это и должно работать, тогда - какое условие еще должно выполниться, чтобы обе сессии залипли ? Спасибо! p.s. если из новой сессии выполнить select без (nolock) - она тоже зависнет. 1ый select выполнится только после kill 2nd session ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2018, 12:08 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
Ну вот где вы блокировки смотрели, там же и номер сессии блокирующей где-то должен быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2018, 12:16 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
ethX, вероятно, Вы не видите всей картины. Блокировки взаимоисключающие и вторая будет применена после первой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2018, 13:54 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
ethX, sp_who2 запустите, и посмотрите, какие соединения к серверу существуют, их состояния и какие из них какие блокируют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2018, 23:46 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
Пожалуй не буду городить новую тему, а спрошу здесь... Заголовок - то что нужно ) Имею крайне острую проблему в виде ожидания LCK_M_SCH_S metadatalock subresource=STATS classid=object_id = 1870121903, stats_id = 44 dbid=5 lockPartition=2 id=lock8bc89b6e00 mode=Sch-M Появилась после перехода с 2012SP2 на 2017RTM. Не думаю что связь есть, но все же... 2017 работает успешно много где. А подобного рода ожидание встретил впервые. Проблема возникает на SELECTe... Тяжелом селекте. Иногда он виснет и является Head Blocker для данного вида блокировки. Что за это за ожидание - объяснять не нужно. Блокировка схемы, LCK_S_SCH_S устанавливается условно при любом селекте, LCK_M_SCH_S - при обновлении статистики, LCK_M_SCH_M - при реструктуризации базы. Это ERP 1C, ничего мимо платформы "не выдумано". RCSI. Других поводов для данной блокировки в 1С кажется нет (хотя можете меня просветить) Блокировка ждет обновление статистики. Объект встречается разный, но их не много (т.е. несколько штук). Иногда помогает (помогало) обновление статистик таблицы с FULL SCAN. Теперь уже не помогает. Вопросы: - "откуда она берется" какого черта ? (риторический) - почему она возникает (время ожидания - десятки минут и более, вместо нормальных микросекунд), что ее провоцирует? - как ее избегать? Научите... )) CPU: 20-60% Память: есть Время жизни страницы в памяти - 1000-6000, но... - кроме этого все-таки есть подозрения вымывание данных из памяти, ряд запросов показывает потребление до 5Гб ОЗУ (омг: больше-выше-сильнее) - на "поломанные" статистики (такое вообще возможно ? может пробовать удалить проблемные? Это же она: stats_id = 44?) Сегодня предложил отключить автообновление статистики в качестве эксперимента (пока не сделали этого). Ну и да... В момент возникновения проблем никаких регламентов не выполняется. Сервер - физический. Одна база на инстанс. Диски - SSD с отличной минимальной задержкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2019, 15:59 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
nvv, индексы параллельно не перестраиваете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2019, 16:35 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
Авто-обновление статистики? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2019, 16:47 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичАвто-обновление статистики? хотя наверное ближе. С 2014 поменялось событие на атообновление ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2019, 16:59 |
|
||
|
Объясните плз механизм LCK_M_SCH_S/LCK_M_SCH_M
|
|||
|---|---|---|---|
|
#18+
авториндексы параллельно не перестраиваете?Никаких регламентов или "ручного участия" - НЕТ. Исключено. Виновник четко определен - вполне конкретный запрос и строчка кода в приложении. авторАвто-обновление статистики?Да. Статистика обновляется асинхронно. Но вкл или выкл - не заметил изменения частоты возникновения проблемы. Вот ВЫКЛ AUTO UPDATE вообще - вариант. Никогда его не практиковал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2019, 17:44 |
|
||
|
|

start [/forum/topic.php?desktop=1&fid=46&tid=1687925]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
155ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 473ms |

| 0 / 0 |
