Можно ли записывать входящие значения параметров в вызове процедуры при трассировке в SQL Server Profiler?

Используя SQL Server Profiler (я на SQL Server 2012), я пытаюсь создать полезную трассировку, которая показывает значения параметров, а не только SQL с именами переменных. Хранимая процедура просматривает большое количество данных инвентаризации, чтобы получить очень ценные результаты, и я пытаюсь задокументировать существующее поведение, чтобы я мог выполнить его модульное тестирование, точно определить его, а затем преобразовать в нечто вменяемое.

У меня есть хранимая процедура, которая выполняет подпроцедуру из 54 параметров внутри цикла, где хранимая процедура создает курсор, а затем выполняет цикл while. Вот упрощенный вид:

CREATE PROCEDURE 
   [dbo].[OuterProcedure]       
   (  @ProductCode varchar(8),          
     -- 41 more parameters omitted
   )
AS            
  SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED   
  SET NOCOUNT ON           
 DECLARE @AboutFourHundredLocalvariables -- omit about 400 local variable declarations.
 -- OMIT ABOUT 10 temporary table declarations.
 DECLARE  aCursor CURSOR FAST_FORWARD FOR         
   SELECT [ID],bkno,  -- about 40 fields omitted.
              FROM vwVeryComplexViewThatDoesALotOfVeryBrutalJoins         
              WHERE  (about_80_boolean_expressions AND omitted_here)
        ORDER BY some,keys,like,this

OPEN aCursor          
FETCH NEXT FROM aCursor /* Get First Record */         
    INTO @ID, @about_40_fields,.... 
WHILE (@@FETCH_STATUS = 0) AND         
          ( @About80MoreBooleanExpressionsHere)  
BEGIN   /* 1 */            
     -- about 700 lines of logic, math and if-parameter-this-then-that
     -- stuff omitted
            EXEC  @ConsiderItem = 
                      InnerProcedureCallWithinLoop
                                            @from_locn,        
                        @About53PARAMSOMITTED,
                                                ...

    FETCH NEXT FROM CurInventory /* Get Next Record */       
       INTO @ID,@MoreStuff,...    
END                   
CLOSE CurInventory          
DEALLOCATE CurInventory

Как получить трассировку для отображения всех значений параметров, переданных InnerProcedureCallWithinLoop ? Есть 54 параметра. Должен ли я написать по существу «54 строки debug-printfs» внутри моего SQL или я могу вывести все значения параметров вызова процедуры при выполнении трассировки SQL каким-либо образом?

Когда я получаю трассировку прямо сейчас, я получаю этот вывод:

EXEC  @ConsiderItem = InnerProcedureCallWithinLoop  @from_locn,        
                        @About53ParmsOmitted

Я хотел бы знать, что @from_locn = 1 и @About53ParmsOmitted = 'hello world'и так далее.

Это не говорит мне фактическое значение параметра @from_locn. В случае с этим первым параметром он передается в мою хранимую процедуру верхнего уровня, так что я знаю, что это 0 или 1, в зависимости от обстоятельств. Однако около 40 из 43 параметров в этой внутренней процедуре происходят изFETCH NEXT FROM aCursor операции внутри WHILEцикла.

Прямо сейчас трассировка говорит мне, сколько раз InnerProcedureCallWithinLoop вызывается и сколько времени занимает каждый из них, но не то, какими были значения параметров для этого вызова. Если бы я мог каким-то образом получить «запускаемые автономные сценарии SQL», которые копируют какой-то угловой случай, который я нахожу в своем коде, при трассировке этих сценариев, настройке этих грубых функций (я знаю, 54 параметра, это действительно грубые, но я не писал их!) я мог бы потратить час на то, чтобы набрать сценарий SQL, который позволил бы мне самому вызывать этот случай, за исключением этого огромного громкого рычага хранимых процедур SQL Server.

Это все часть усилий по детализации выражения SQL и созданию сценариев, которые могут проверять эти сложные хранимые процедуры.

Обновление Я нашел опцию записи RPC «Output Param», но не опцию записи «RPC IN PARAM».

— Уоррен П
источник

Это не только 54 параметра, которые являются грубыми :-) Все эти циклы для вызова курсора. Это брутто :-) Ты играл с Plan Sentry в Проводнике SQL? Вы можете использовать бесплатную версию или использовать пробную версию полной версии, и это может помочь вам, если у вас есть вызов со всеми параметрами - sqlsentry.net/plan-explorer/sql-server-query-view.asp

— Майк Уолш,

Можете ли вы сказать нам, какие события вы захватываете?

— Майк Уолш

Единственный раз, когда профилировщик ловит эти данные (я думаю), когда вы их вызываете? Попробуйте настроить таблицу аудита со всеми этими параметрами и просто вставьте ее перед тем, как зациклить курсор?

— Jcolebrand

RPC: Завершено показывает значения параметров, но на внешнем уровне.

— Майк Уолш

+1 за вопрос, как возмещение за вашу боль. Если бы я мог, я бы снова +1 за размещение вопроса без ругательств.

— Марк Стори-Смит

Я укушу пулю и скажу вам, что такой след не может быть установлен, потому что это не [предполагаемая] цель следов. Я всегда делал это так:

WHILE (@@ FETCH_STATUS = 0) И
(@ About80MoreBooleanExpressionsHere)
BEGIN / * 1 * /
- около 700 строк логики, математика и if-параметр-this-that-
вещи - опущено
INSERT InnerProcedureCallWithinLoop__TraceTable
VALUES (@from_locn, @ About53PARAMSOMITTED
EXEC @ConsiderItem =
InnerProcedureCallWithinLoop
@from_locn,
@ About53PARAMSOMITTED,
...

Если я знаю, что это когда-либо вызывается только из одного места. В противном случае, я делаю это в вызываемой, а не вызывающей стороне.

ALTER PROC InnerProcedureCallWithinLoop
    @from_locn int,
    @About53PARAMSOMITTED ...
AS
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET NOCOUNT ON;
INSERT InnerProcedureCallWithinLoop__TraceTable VALUES (@from_locn, @prm2, @prm3....
--- rest of proc

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

— 孔夫子
источник

Это то, о чем я думал.

— Уоррен П