Профилировщик SQL Server показывает, что хранимая процедура вызывается, но на самом деле не выполняется

У меня проблема, я постараюсь ее резюмировать:

Я запускаю SQL Server Profiler, чтобы отслеживать вызов хранимой процедуры. Он показывает, что хранимая процедура вызывается, но на самом деле не выполняется.

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

У меня закончились идеи, почему это происходит. SQL Server Profiler показывает, что хранимая процедура вызывается, но на самом деле она не вызывается!

Спасибо и привет.

РЕДАКТИРОВАТЬ: подробнее

  • Хранимая процедура отлично работает локально
  • Если мы запустим ТОЧНО ту же строку, которую показывает профилировщик, в целевой БД, отслеживаемой профилировщиком, хранимая процедура работает отлично.
  • Я запускаю его с помощью Entity Framework. Однако перед вызовом этой хранимой процедуры я вызываю некоторые другие хранимые процедуры, затем вызываю эту проблемную хранимую процедуру и сохраняю изменения. Также сохраняются изменения из предыдущих хранимых процедур.
  • Когда я вызываю хранимую процедуру локально, я получаю ОК, если я запускаю хранимую процедуру с теми же значениями, я получаю «ошибку параллелизма», потому что каждый вызов должен использовать другое значение в каком-то параметре (параллелизм). Зная, что если я запускаю профилировщик в своей локальной БД, я вижу, что хранимая процедура выполняется, затем я пытаюсь запустить ту же строку и получаю ошибку параллелизма, что означает, что хранимая процедура была запущена правильно. Когда я запускаю профилировщик в целевой БД, я вижу, что выполняется хранимая процедура, затем я пытаюсь запустить ту же строку и получаю ОК, означающее, что она никогда не запускалась. Если я попытаюсь запустить эту строку снова, у меня возникнет проблема с параллелизмом.

По сути, это какая-то странная вещь, наверное, самая странная, которую я когда-либо видел. Профилировщик SQL Server показывает вызываемую хранимую процедуру, но, по-видимому, она никогда не завершается, но хранимая процедура в порядке, зная тот факт, что если я запустил ТОЧНЫЙ ЖЕ вызов, который показал профилировщик, он будет работать нормально.

Это немного странно, но я надеюсь, что это немного проясняет ситуацию.


sql sql-server stored-procedures sql-server-profiler
person Wallack    schedule 09.05.2014    source источник
comment
Без подробностей, извините, это немного игра в угадайку. Может быть, ваш SP вызывается из транзакции, которая никогда не фиксируется? А может просто в вашем SP глюк? Пожалуйста, покажите код.   -  person Ruud Helderman    schedule 09.05.2014
comment
Нет транзакции. Я запускаю SP через entity framework. Перед запуском этого SP я запускаю еще несколько SP, затем проблемный, а затем сохраняю изменения. Все изменения, кроме этого, полностью сохраняются, хотя профилировщик показывает, что SP вызывается, но, по-видимому, никогда не завершается (если я запускаю тот же вызов напрямую, он работает).   -  person Wallack    schedule 09.05.2014
comment
Судя по вашему описанию (которое я все еще не понимаю после трехкратного прочтения), у вас сложный процесс, гораздо более вероятно, что в вашем процессе есть ошибка, чем ошибка в SQL Server. Возможно, вы могли бы опубликовать код, чтобы дать нам представление. Вы, вероятно, обнаружите ошибку, пока будете объяснять это.   -  person Nick.McDermaid    schedule 09.05.2014
comment
Покажите нам код C #, как EF вызывает SP. Я чувствую, что внутри вызывающего кода C # должен использоваться TransactionScope, который прерывает транзакцию, когда возвращается какое-либо исключение (ошибка параллелизма).   -  person Pranav Singh    schedule 09.05.2014

Ответы (2)


arrow_upward
1
arrow_downward

Мы исправили проблему, изменив настройку «ARITHABORT».

Самым неприятным при попытке найти проблему было то, что вызов хранимой процедуры, который не работал из среды сущностей, работал из SSMS, и это произошло потому, что SSMS переопределяет некоторые параметры, и мы не видели этой проблемы.

Мы установили старое приложение в ту же среду (ту же БД) и в другом месте приложения, оно показало эту ошибку:

ОБНОВЛЕНИЕ не удалось, потому что следующие параметры SET имеют неправильные настройки: «ARITHABORT». Убедитесь, что параметры SET подходят для использования с индексированными представлениями и / или индексами для вычисляемых столбцов и / или отфильтрованными индексами, и / или уведомлениями о запросах, и / или методами типа данных XML и / или операциями с пространственным индексом.

Итак, проблема заключалась в обновлении, но это обновление пришло не напрямую из SP, а из триггера, запущенного триггером, запущенным SP, поэтому у нас не было никакого журнала этого, как бы безумно это ни звучало.

К счастью для нас, старое приложение, которое мы пытаемся заменить «исправленным», подсказывает нам верное направление.

Спасибо всем за вашу помощь!

person Wallack    schedule 14.05.2014

arrow_upward
1
arrow_downward

У меня была точно такая же проблема, но в моем случае разрешение было другим.

SQL Profiler показывал вызываемую хранимую процедуру, например. exec NameOfProcedure @id=1234, который может вставить новую запись с предоставленным идентификатором.

Однако при просмотре содержимого таблицы SQL запись не была вставлена, и если вы скопировали и вставили указанную выше команду в новое окно SSMS, она выполнилась правильно, а затем запись была добавлена ​​в таблицу.

Причина оказалась в том, что у пользователя базы данных не было EXECUTE прав доступа к базе данных, но SQL Profiler не показал, что команда завершилась неудачно, как это было бы, если бы в коде была синтаксическая ошибка.

Исправление заключалось в создании новой роли с EXECUTE разрешениями и назначении ее пользователю, который решил проблему, и хранимые процедуры снова начали работать:

CREATE ROLE ExecuteProcedures
GRANT EXECUTE TO ExecuteProcedures
EXEC sp_addrolemember 'ExecuteProcedures', 'UserWithIssue';

Разрешения Execute также можно было назначить непосредственно пользователю, но таким образом более наглядно и удобнее назначать разрешения группам.

person Robin Wilson    schedule 08.08.2020