Сопоставление пользователей SSMS медленно загружается или не отвечает

У меня возникла проблема в SSMS версий 14, 18 и 19, из-за которой загрузка сопоставления пользователей для любого заданного имени входа занимает много времени, иногда до часа, или просто никогда не загружается вообще и не отвечает.

Кто-нибудь сталкивался с этим раньше и/или мог дать какие-либо рекомендации по решению этой проблемы?

Я пробовал следующее:

• Подтверждено, что не имеет значения, является ли это входом в AD или входом в SQL.
• Обновление версии SQL Server с 2016 по 2022 год.
• Обновление версии SSMS с 14 до 18 и до 19.
• Проверено на наличие блоков SQL (их нет)
• Пробовал несколько разных логинов (кажется, все они испытывают это)
• В этом экземпляре SQL имеется 25 баз данных и всего около 50 имен входа.

К сожалению, эта проблема невероятно затрудняет управление безопасностью пользователей и сопоставлением баз данных без написания SQL-запроса.

Любая поддержка или руководство будут оценены по достоинству!

РЕДАКТИРОВАТЬ. Я запустил трассировку SQL и определил следующий запрос как нарушителя:

USE [database_name]
SELECT
u.name AS [Name],
CAST(CASE dp.state WHEN N'G' THEN 1 WHEN 'W' THEN 1 ELSE 0 END AS bit) AS [HasDBAccess],
ISNULL(u.default_schema_name,N'') AS [DefaultSchema]
FROM
sys.database_principals AS u
LEFT OUTER JOIN sys.database_permissions AS dp ON dp.grantee_principal_id = u.principal_id 
and dp.type = @_msparam_0
WHERE
(u.type in ('U', 'S', 'G', 'C', 'K' ,'E', 'X'))
and
(ISNULL(suser_sname(u.sid),N'')=@_msparam_1)

Он запускается после выбора БД для запуска и является четвертым запросом для запуска.

РЕДАКТИРОВАТЬ 2. Именно эта часть вызывает проблему, и я понятия не имею, почему:

    and
(ISNULL(suser_sname(u.sid),N'''')=@_msparam_1)

РЕДАКТИРОВАТЬ 3. Я почти уверен, что это функция «suser_sname», протестировав ее на разных БД и разных логинах. Он просто зависает и никогда не завершается, вынуждая меня закрыть SQL.

Любые дальнейшие рекомендации будут оценены по достоинству, спасибо.

РЕДАКТИРОВАТЬ 4. Дальнейший контекст, извините за первоначальное исключение этой информации.

Эта проблема возникает в отдельном домене — нашей среде разработки. Именно здесь восстанавливаются наши производственные базы данных, и в рамках этого восстановления соответствующие учетные записи SQL обновляются для работы в домене DEV, где это необходимо.

Я задавался вопросом, возможно, некоторые потерянные учетные записи SQL вызывали эту проблему из-за некоторого несоответствия SID в sys.database_principals. Да, были некоторые потерянные учетные записи, но после их исправления с помощью sp_change_users_login эта проблема все еще возникает.