Есть Windows Server 2008 R2,intel i5,ОЗУ 16 ГБ.SSD. 1С УТ 11.1 на майкрософт SQL. Если зайти на сервер с правами Администратора время на открытие документа продаж порядка 1 сек , если зайти на сервер с правами Пользователь , то документ в 1С открывается порядка 6 сек. Ошибок никаких нет. Просто медленно работает открытие , проведение документов. В чем может быть проблема?
(1) в базе есть роли, они как собаки набрасываются на пользователя и все его запросы идут с джойнами доступа. А вот админа роли побаиваются и держатся подальше.
Но суть не в этом, конечно. 6 сек - это круто! База пустая?
(1) надо искать узкое место на которое уходит время.
для начала в отладчике замер времени включите и под пользователем откройте документ. может быть найдете подсказку на что время тратится.
профайлер SQL тоже гляньте,
может индексов каких в базе не хватает
(13) Значит ошибку надо искать не в конфигурации.
Сгрузите проблему на админов сервера SQL. Пусть скажут какие запросы выполняются долго и почему.
Так вы найдете таблицы, которые стали тормозить. Но вероятней всего, что сервер загружен отчетами, которые кто-то без перерыва снимает и тормозит базу в целом.
(9) шагов окромя перезагрузки не делал. Пользователю давал права админа на время , но это не помогло, все без изменений. также пробовал во время когда никто не работает с базой , также все висит.
Проблема в RLS. Если нет необходимости пользователю блокировать доступ к части объектов, то просто можно из всех ролей пользователя в конфигураторе удалить RLS (а еще лучше - из всех ролей вообще). Причина в том, что при наличии разных RLS для разных ролей для одного пользователя они отрабатывают по ИЛИ, что приводит к скану таблицы вместо поиска по двоичному дереву индекса. Т.е. сервер вместо того, чтобы найти запись за O(Log2(N)/2) чтений, ищет ее в среднем за O(N/2) чтений, а это весьма длительная операция.
(8) значит, нужно переписать RLS так, чтобы они были у всех ролей одинаковые. Тогда 1С генерит одно дополнительное условие (в трассировке сервера это можно посмотреть) и, если повезет и элемент отбора является ключом индекса, то проблема уйдет.
(14) поделилось пополам, ибо в 50% случаев мы найдем менее чем за половину шагов, во вторых 50% случаев - больше чем за половину шагов. В среднем тут как с блондинкой и динозавром - или да, или нет, т..е. 50%.