ошибка красной сельди "У пользователя нет прав на выполнение этого действия"

Question

При выполнении хранимой процедуры мы получаем ошибку 297

«У пользователя нет прав на выполнение этого действия»

Это происходит во время большой нагрузки (регулярно, когда задание триммера выполняется одновременно). Ошибка устраняется, когда служба, обращающаяся к SQL Server, перезапускается (и, скорее всего, задание обрезки также завершено), поэтому, очевидно, это не проблема с реальными разрешениями. Ошибка сообщается в строке хранимой процедуры, которая обращается к функции, которая, в свою очередь, обращается к динамическим представлениям управления.

В каких ситуациях может возникнуть ошибка, подобная этой, когда на самом деле это не проблема с разрешениями?

Возможно, включение флага трассировки 4616 исправит это, согласно этой статье ? Я бы хотел просто попробовать, но мне нужно больше информации. Кроме того, меня сбивает с толку тот факт, что это периодически возникающая проблема, возникающая только в периоды высокой активности.

Я пытался воспроизвести эту же ошибку в других ситуациях (в которых также не было реальных проблем с разрешениями), и обнаружил, что при запуске этого на SQL Server 2005 у меня возникает проблема с разрешениями:

select * from sys.dm_db_index_physical_stats(66,null,null, null, null)

(66 - недействительный DBID.)

Однако мы не используем dm_db_index_physical_stats с неправильным DBID. Мы используем dm_tran_session_transactions и dm_tran_active_transactions, но они не принимают параметры, поэтому я не могу получить ошибку с ними. Но я подумала, возможно, что проблема связана.

Спасибо за любые идеи.

Answer 1

Будет ли это связано с проблемами параллелизма?

Например, обрабатываются ли те же данные или глобальная временная таблица? Если это так, вы можете рассмотреть sp_getapplock

И использует ли каждое соединение разные учетные данные с разным набором разрешений? У всех пользователей GRANT VIEW SERVER STATE TO xxx?

Наконец, в связи с обеими идеями, указанными выше, вы используете EXECUTE AS в любом месте, которое не может быть возвращено и т. Д.?

Совершенно случайная идея : Я видел это раньше, но только когда пропустил GO между концом сохраненного определения proc и следующим оператором GRANT. Поэтому SP попытался установить свои собственные разрешения. Возможно ли, что из-за тайм-аута или проблемы с параллелизмом запускается какой-то код, который обычно не выполняется?

Answer 2

Спасибо всем за ваш вклад. То, что я сделал (похоже, это исправило проблему на данный момент), изменило ежедневную работу по подрезке. Теперь он значительно дольше ожидает между удалениями, а также удаляет гораздо меньший кусок записей за раз.

Я обновлю это позже с дополнительной информацией, как только получу.

Еще раз спасибо.

Answer 3

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

Кроме того, всегда ли это выполняется одинаково? Например, он запускается как задание агента SQL? или вы иногда запускаете вручную, а иногда запускаете его как работу. Я думаю, что, возможно, он работает как diff. пользователи в разное время.

Может также взглянуть на это Сообщение в блоге