Ax2009 SP1 RU6. Пользователи не могут зайти, но уже авторизованные продолжают работать

[Maximin]

Цитата:

Сообщение от rashuf

Для чего нужен доступ к crl.microsoft.com?

Позволю себе дать ссылку на свой же тред:
Долгий запуск клиента Dynamics Ax - решение
Там еще много полезных советов.

А далее надо анализировать, что происходит сразу перед зависанием - какой запрос отправляется на SQL, что происходит на локальной машине (запустить Sysinternals Process Monitor или взять Sysinternals Process Explorer свежий).
Попробуйте отключите еще антивирус на сервере (если он там есть, вообще - это зло) и клиенте.

[rashuf]

Здравствуйте!
Локализовали причину "зависания".
Вообще наблюдали 2 типа зависания - во время импорта или просмотра меток и "случайный", без видимой причины.
Причиной в первом случае оказались битые файлы меток для всех языков, кроме русского. Битые, потому что в них были пропущены целые диапазоны меток, например, @RSL14643-@RSL14790, @RSL14799-@RSL15605 и др. Подозреваем, что эти блоки были пропущены во время автогенерации меток. Обнаружили, потому что аксапта зависала во время вызова SysLabel.new() для языка fr-ca. Мы просто удалили файлы всех языков для RSL-меток, кроме русского (*.ald-файлы). Проверили импорт - все нормально, не зависает. Удаленные файлы больше не создались (2 недели прошло). Правда, и новые метки пока не создаем и не импортируем.

Во втором случае блокируется таблица Batch. Выяснили с помощью AxTraceParser'а, стандартного отчета MS SQL Все транзакции/Все блокирующие транзакции и запроса.
AxTraceParser показал, что в сессии AOS последними запросами при логине клиента во время зависания являются выбор записи пользователя из UserInfo, вызов хранимой процедуры CREATEUSERSESSIONS и подсчет количества записей по пользователю в SysClientSessions. При этом при нормальной работе AOS еще "мелькают" запросы обновления Batch, BatchJob для запускаемых пакетных заданий. В зависшей сессии таких запросов нет. Пробовали завершать сессии в MS SQL с помощью kill, закрывать порты (TCP-порты 2719) с помощью CurrPorts. Эти меры не помогают "пробудить" AOS, и потом при подключении клиентов выходит ошибка, что AOS вроде бы недоступен, при этом служба работает.

Я видел, что есть исправление KB 3216955 Continuous dead locks in batch tables. Обсуждалось на форуме. Возможно, портирование этого исправления нам тоже поможет, но я не смог его найти (нет доступа) и не понял из сообщения gl00mie, что и где поменялось.
Коллеги, кто-нибудь занимался адаптацией этого обновления на AX 2009? Что изменилось? Может, с учетом новых наблюдений, вообще в другую сторону надо копать?

PS: запрос

SELECT 
	L.request_session_id               AS SPID, 
	DB_NAME(L.resource_database_id)    AS DatabaseName,
	O.Name                             AS LockedObjectName, 
	P.object_id                        AS LockedObjectId, 
	L.resource_type                    AS LockedResource, 
	L.request_mode                     AS LockType,
	ST.text                            AS SqlStatementText,        
	ES.login_name                      AS LoginName,
	ES.host_name                       AS HostName,
	TST.is_user_transaction            AS IsUserTransaction,
	AT.name                            AS TransactionName,
	CN.auth_scheme                     AS AuthenticationMethod
	FROM sys.dm_tran_locks L
    
	JOIN sys.partitions P
		ON P.hobt_id = L.resource_associated_entity_id
    
	JOIN sys.objects O
		ON O.object_id = P.object_id
    
	JOIN sys.dm_exec_sessions ES
		ON ES.session_id = L.request_session_id
    
	JOIN sys.dm_tran_session_transactions TST
		ON ES.session_id = TST.session_id
    
	JOIN sys.dm_tran_active_transactions AT
		ON TST.transaction_id = AT.transaction_id
    
	JOIN sys.dm_exec_connections CN
		ON CN.session_id = ES.session_id
    
	CROSS APPLY sys.dm_exec_sql_text(CN.most_recent_sql_handle) AS ST
	
	WHERE resource_database_id = db_id()

ORDER BY L.request_session_id