Всем привет!

Очень нужна помощь! Какая-то шляпа происходит, сломал всю голову...

Дано:
1. У клиента развернута клиент-серверная архитектура из двух сред: ТЕСТ и ПРОД.
2. Соответственно, есть виртуальные сервера ПРОД_Приложений, ПРОД_SQL, ТЕСТ_Приложений, ТЕСТ_SQL.
3. Все сервера приложений работают под одним доменным пользователем domain_user_1c. У этого же пользователя в SQL права db_owner.
4. В консоли серверов базы регистрируются без указания пользователя и пароля, авторизация в SQL происходит под пользователем, под которым работает сервер 1С.
5. Версия SQL 2012, версия 1С 8.3.15.2107

Ситуация:
В какой-то момент на ТЕСТ_SQL закончилось место и одновременно с этим при попытке запуска любых баз 1С, зарегистрированных на ТЕСТ_Приложений, стала возвращаться ошибка SHOWPLAN permission denied in <Имя базы SQL> (не tempdb!)
Т.е. выглядит так, что у 1С нет прав на операцию SHOWPLAN в базе 1С, расположенной на ТЕСТ_SQL.
НО! Если эту же базу 1С, расположенную на ТЕСТ_SQL, подцепить к серверу приложений ПРОД_Приложений, то всё работает!
И наоборот: если к серверу ТЕСТ_Приложений подцепить базу, расположенную на ПРОД_SQL, то получим ту же ошибку SHOWPLAN permission denied in <Имя базы SQL>

Т.е. получается, что проблема в ТЕСТ_Приложений, а с ТЕСТ_SQL всё в порядке.

Пробовал проделать следующее, но ничего не помогло:
1. Удалить/поставить SQL Native client на ТЕСТ_Приложений
2. Выполнить скрипт:
USE <Имя базы SQL>
GO
GRANT SHOWPLAN TO domain_user_1c
GO
3. Удалить/установить сервер 1С в другую папку + прописать другую папку srvinfo

Сейчсас создаем нового юзера для ТЕСТ_Приложений, но это не быстрый процесс.

Нужны еще идеи! В чем может быть причина и куда еще копать?

Т.е. вместо того чтобы зайти на скуль и проверить права ты пошел путем гадания на форуме?

https://raresql.com/2015/07/30/sql-server-fix-error-262-showplan-permission-denied-in-database/

Перепроверь на проблемном скуле трансляцию логина domain_user_1c в юзеров баз dbo. Если транслируется не в dbo, то роли db_owner, ЕМНИП, действительно может быть недостаточно для каких-то действий. Надо чего-то там еще досыпать.

(1) Я написал, что права на скуле есть. И да, проблема проверить права тоже есть, т.к. скуль обслуживается американцами, у которых день благодарения)
И я так же написал, что с другого сервера приложений, работающего под тем же пользователем, базы на скуле цепляются и работают без проблем. Временно так и сделали: перецепили тестовые базы к проду приложений.

(2) запрос, приведенный по ссылке, выполняли, я об этом тоже написал

(3) В том-то и дело, что проблемный не скуль, а приложений.

Кстати, сдедали еще один эксперимент: развернули новый SQL, перенесли одну из баз на него, но ошибка осталась.

У вас точно менеджер и рабочие процессы из под одного пользователя работают?
C swpuser.ini (https://its.1c.ru/db/v8320doc#bookmark:adm:TI000000418) не игрались на проблемном кластере?

бывает иногда нужно пользователя на скуле пересоздать

(0) А где те, кто это все "разворачивал"? Почему это твоя проблема?

(10) Клиент - крупная международная компания, у которой поддержка по линиям Россия->Индия->США (к сожалению, крупная не значит, что все процессы круто налажены и работают как часы. Скорее много лишней бюрократии и более долгие сроки решения даже простых вопросов). И вся эта поддержка ничего не знает про 1С. И еще во вторник всё работало и никаких проблем не было. В таком виден инфраструктура работала минимум год, т.е. это не заново развернутая инфраструктура.
Но в ночь со вторника на среду что-то произошло и теперь ситуация такова, что с точки зрения поддержки всё работает отлично и только сервер 1С ругается. Поэтому говорят разбирайтесь со своим сервером 1С, с SQL всё ровно.

(8) Вряд ли, могу уточнить, первый раз слышу о таком файле. Ссылка не открывается :( Как загуглить вопрос? По swpuser.ini много разного вываливается в поиске.

(11) > И вся эта поддержка ничего не знает про 1С.

OK, а кто тогда поддерживал 1С все это время?

> И еще во вторник всё работало и никаких проблем не было.

Значит, шерстите всякие логи на предмет что же такого натворили в это время.

(13) Поддерживали совместными усилиями. Логи шерстим. Но из заметного, что произошло - это, как я писал, кончилось дисковое пространство на ТЕСТ_SQL. Поэтому поначалу грешили на ТЕСТ_SQL, но опыты показали, что с ним всё хорошо, а вот с ТЕСТ_Приложений что-то произошло, что он и с другими SQL-серверами не хочет работать.

(15) Рестартовали, когда освобождали место? смотрите внимательно ошибки в момент рестарта.

А так включайте ТЖ и ловите там.

Сервер ожил как-то сам... Никто не признался, но всё заработало.

Спасибо всем откликнувшимся!

Если вдруг что-то прояснится: как решилось и/или в чем была причина - напишу сюда.