Имя: Пароль:
1C
1C 7.7
v7: Блокировка LCK_M_U при проведении документа
0 C0mmander_Alex
 
15.11.17
18:11
База бухгалтерия 7.7 sql 2008. При проведении документа Поступление товаров база наглуха виснет. Случается как-то выборочно не со всеми документами. Документы других видов проводятся нормально. При записи проблем не возникает.
При проведении такого документа в мониторе sql часто видна задача с состоянием SUSPENDED и блокировкой вида LCK_M_U.
Запрос к статистике sql
SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
                                    AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
                                    AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0  
        AND wait_type NOT IN
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
  'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
  'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
  'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
  'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
  'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
  'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

дал такие результаты:

LCK_M_U                1591344    1    5458354    27.816916661188242    0.000381937415735    27.816911564979464
PREEMPTIVE_OS_LIBRARYOPS    26499    0    26499    0.135044436392434    0.000000000000000    0.135044436392434
PREEMPTIVE_OS_PIPEOPS        25360    0    25360    0.129239854594971    0.000000000000000    0.129239854594971
PREEMPTIVE_OS_GENERICOPS    25355    0    25499    0.129948227615030    0.000000000000000    0.129948227615030
LCK_M_SIX            19131    0    19922    0.101526671263446    0.000000000000000    0.101526671263446
FT_IFTS_RWLOCK            15450    0    15450    0.078736425610895    0.000000000000000    0.078736425610895
LCK_M_X                15178    34    3553956    18.111875032806844    0.012985872134991    18.111701761708412
LCK_M_S                15005    0    202392    1.031431886876396    0.000000000000000    1.031431886876396
CXPACKET            14147    183857    7995218    41.682273806047467    70.221867444800494    40.745300148860258
PREEMPTIVE_OS_FILEOPS        3879    0    17126    0.087277671521824    0.000000000000000    0.087277671521824

Как видно, время ожидания по LCK_M_U довольно большое.
Perfmon на сервере не показывает большой нагрузки ни на процессор, ни на память, ни на димк.
Подозреваю, что проблемы с самой базой. Куда можно копнуть в данной ситуации?
1 DmitriyDI
 
15.11.17
18:12
(0) пусть этим админы занимаются, забей)
2 C0mmander_Alex
 
15.11.17
18:13
(1) Да интересно самому даже)
3 Дык ё
 
15.11.17
18:18
(2) LCK_M_U возникает когда задача ожидает получения блокировки на обновление. проблема не с базой, а с 7.7 - кури гибкие блокировки или переходи на восьмерку
4 C0mmander_Alex
 
15.11.17
18:20
(3) Такого просто раньше не было, началось только сегодня, странно
5 varelchik
 
16.11.17
12:54
(0) А как подружил 7.7 и SQL 2008?
Если не секрет.
Закон Брукера: Даже маленькая практика стоит большой теории.