Здравствуйте!

В базе смоделировал дедлоки.
Дедлоки обнаружены менеджером блокировок СУБД.
Вот эти события не попадают в файлы ТЖ (Почему ?):

lka (Признак того, что поток является виновником транзакционных блокировок СУБД)

lkaid (Список номеров запросов к СУБД, «кто кого заблокировал», обнаруживших в течение события, что поток является виновником блокировок. Например, ‘271,273,274’.)

lkato (Время в секундах, прошедшее с момента обнаружения, что поток является виновником блокировок.)

lkp (Признак того, что поток является жертвой транзакционной блокировки СУБД)

lkpid (Список номеров запросов к СУБД, «кто кого заблокировал», обнаруживших в течение события, что поток является жертвой блокировок. Например, ‘271,273,274’.)

lkpto (Время в секундах, прошедшее с момента обнаружения, что поток является жертвой блокировки)

lksrc (Номер соединения виновника блокировки, если поток является жертвой)

Конфиг ТЖ обычный, проще не придумать:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
<dump create="false"/>
<log location="D:\Обработки 1С\Темп\" history="168">
  <event>
   <eq property="name" value="dbmssql"/>
  </event>
  <property name="all">
  </property>
</log>
</config>

Спасибо за внимание.

ап

вообще техножурналов два - один настраивается на сервере, а второй - на клиенте. ты в обоих посмотрел?

(2)смотрел на тот который на сервере

(0) Упр или автомат?

"Дедлоки обнаружены менеджером блокировок СУБД."

Таймауты и дедлоки возникшие на уровне СУБД фиксируются в ТЖ событием EXCP

(4)Управояемые
(5)Да в EXCP есть поле descr об описании ошибки. И там я видел сообщение которое выдает 1С при дедлоке. - Но как понять кто кого заблокировал и по каким ресурсам ?

тоже интересно как инициировать устойчивое появление свойств lka,lkaid,.. при моделировании дедлока СУБД

Например, ведь ЦУП предоставляет информацию по взаимоблокировкам и это он делает исходя из анализа логов технологического журнала.

(6) В пользовательском режиме, например, SQL Profiler.

(8) ЦУП использует трассировки СУБД.
В мастере настройки подключения есть специальные шаги, посвященные сбору трассировок. Если их пропустить, ЦУП будет беспомощен.

(9)все понятно. Видимо он анализирует дедлоки при помощи дедлок графа - как то так получается ?

а как же со свойствами  lka,lkaid,.?

подниму ?

(10) Почему вы считаете что эти свойства должны фиксироваться для события DBMSSQL ?

(12)я сделал такой вывод исходя из обработки с ИТС по настройке ТЖ - Может я ошибаюсь в том что эти свойства принадлежат dbmssql, но хотелось бы конечно знать как получить эту информацию

(13) Какую практическую задачу Вы хотите решить при помощи этой информации?

(14)дедлоки

(15) На уровне СУБД? Какова интенсивность их возникновения?

(16) на уровне СУБД дэдлоки идут, если в коде конфигурации идет эскалация (например заблокировали неисключительно, через некоторое время заблокировали исключительно).
ну, или если сам скуль с ума от нагрузки сходит, но тут 146% что не такой случай

(17) это не эскалация, а повышение уровня блокировки

(17) "но тут 146% что не такой случай" зачем тогда об этом писать в данной ветке?

подниму ветку ?
очень актуально. В БД есть дедлоки, хочу разобраться при помощи ТЖ.
Есть в нем все таки возможность просматривать данные свойства:
lka,lkaid,.. ???

(19) потому что бывает и такой случай

подниму ?

На платформе 8.3.4 пишутся. Режим блокировок в конфе: управляемый. Режим совместимости 8.2.16 включил, чтобы READ COMMITED был без снэпшота. Вот смоделировал дедлок в СУБД чтением остатков после записи движений из 2-х параллельных транзакций без установки свойства БлокироватьДляИзменения:

16:32.451000-0,EXCP,6,process=rphost,p:processName=exp_83,t:clientID=598,t:applicationName=1CV8C,t:computerName=DPV,t:connectID=78,SessionID=120,AppID=1CV8C,Exception=DataBaseException,Descr='Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 10.0: Транзакция (идентификатор процесса 59) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно.
HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=33, Severity=D, native=1205, line=1
',Context='Данные.Провести
Документ.Реализация.МодульОбъекта : 77 : Результат = Запрос.Выполнить();'
16:32.451001-9500993,DBMSSQL,5,lkp=1,lkpid=3,lksrc=79,lkpto=-1786027984

Последней версией обработки для 8.3 пользовался с ИТС для создания logcfg.xml

Снял всю картину для наглядности:
1) Исключение EXCP
2) Виновник DBMSSQL
3) Жертва DBMSSQL
Текст запроса SQL в 2 и 3 одинаковый


15:48.522001-0,EXCP,6,process=rphost,p:processName=exp_83,t:clientID=634,t:applicationName=1CV8C,t:computerName=DPV,t:connectID=83,SessionID=130,AppID=1CV8C,Exception=DataBaseException,Descr='Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 10.0: Транзакция (идентификатор процесса 59) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно.
HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=33, Severity=D, native=1205, line=1
',Context='Данные.Провести
Документ.Реализация.МодульОбъекта : 77 : Результат = Запрос.Выполнить();'


15:48.522002-1497982,DBMSSQL,5,process=rphost,p:processName=exp_83,t:clientID=634,t:applicationName=1CV8C,t:computerName=DPV,t:connectID=83,SessionID=130,AppID=1CV8C,Trans=1,dbpid=59,Sql='SELECT *ТекстЗапроса*',
lka=1,lkaid=5,lkato=-1785675935,Context='Данные.Провести
Документ.Реализация.МодульОбъекта : 77 : Результат = Запрос.Выполнить();'


15:48.522010-1514007,DBMSSQL,5,process=rphost,p:processName=exp_83,t:clientID=635,t:applicationName=1CV8C,t:computerName=DPV,t:connectID=84,SessionID=133,AppID=1CV8C,Trans=1,dbpid=69,Sql='SELECT *ТекстЗапроса*',
Rows=0,RowsAffected=0,lkp=1,lkpid=5,lksrc=83,lkpto=-1785675935,Context='Данные.Провести
Документ.Реализация.МодульОбъекта : 77 : Результат = Запрос.Выполнить();