삭제 트리거에 레코드를 삭제 한 사람에 대한 정보 전달

감사 내역을 설정할 때 누가 테이블에서 레코드를 업데이트하거나 삽입하는지 추적하는 데 문제가 없지만 레코드를 삭제하는 사람을 추적하는 것이 더 문제가있는 것 같습니다.

"UpdatedBy"필드를 삽입 / 업데이트에 포함시켜 삽입 / 업데이트를 추적 할 수 있습니다. 이를 통해 INSERT / UPDATE 트리거가를 통해 "UpdatedBy"필드에 액세스 할 수 있습니다 inserted.UpdatedBy. 그러나 삭제 트리거를 사용하면 데이터가 삽입 / 업데이트되지 않습니다. 누가 레코드를 삭제했는지 알 수 있도록 삭제 트리거에 정보를 전달하는 방법이 있습니까?

삽입 / 업데이트 트리거는 다음과 같습니다.

ALTER TRIGGER [dbo].[trg_MyTable_InsertUpdate] 
ON [dbo].[MyTable]
FOR INSERT, UPDATE
AS  

INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
VALUES (inserted.ID, inserted.LastUpdatedBy)
FROM inserted 

SQL Server 2012 사용

누가 레코드를 삭제했는지 알 수 있도록 삭제 트리거에 정보를 전달하는 방법이 있습니까?

예 :라는 매우 시원하고 기능이 부족한 기능을 사용합니다 CONTEXT_INFO. 본질적으로 모든 범위에 존재하며 트랜잭션에 의해 제한되지 않는 세션 메모리입니다. 서브 프로세스 / EXEC 호출 사이에서 앞뒤로 트리거하기 위해 정보 (모든 정보-제한된 공간에 맞는 정보)를 전달하는 데 사용할 수 있습니다. 그리고 나는이 똑같은 상황을 위해 그것을 전에 사용했습니다.

• 컨텍스트 정보는 VARBINARY (128)입니다.

• SET CONTEXT_INFO 를 통해 설정

• 경유 : CONTEXT_INFO ()

작동 방식을 확인하려면 다음을 테스트하십시오. CHAR(128)이전으로 변환 중 CONVERT(VARBINARY(128), ..입니다. 이것은 빈 패딩을 강제로 빼기 위해 s로 오른쪽이 채워져 있기 때문에 쉽게 VARCHAR꺼낼 수 있도록합니다 .CONTEXT_INFO()VARBINARY(128)0x00

SELECT CONTEXT_INFO();
-- Initially = NULL

DECLARE @EncodedUser VARBINARY(128);
SET @EncodedUser = CONVERT(VARBINARY(128),
                            CONVERT(CHAR(128), 'I deleted ALL your records! HA HA!')
                          );
SET CONTEXT_INFO @EncodedUser;

SELECT CONTEXT_INFO() AS [RawContextInfo],
       RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())) AS [DecodedUser];

결과 :

0x492064656C6574656420414C4C20796F7572207265636F7264732120484120484121202020202020...
I deleted ALL your records! HA HA!

함께 모아서:

1. 앱은 레코드를 삭제하는 UserName (또는 기타)을 전달하는 "삭제"저장 프로 시저를 호출해야합니다. 이미 삽입 및 업데이트 작업을 추적하는 것처럼 들리기 때문에 이미 사용중인 모델이라고 가정합니다.

2. "삭제"저장 프로시 저는 다음을 수행합니다.

   DECLARE @EncodedUser VARBINARY(128);
   SET @EncodedUser = CONVERT(VARBINARY(128),
                               CONVERT(CHAR(128), @UserName)
                             );
   SET CONTEXT_INFO @EncodedUser;
   
   -- DELETE STUFF HERE

3. 감사 트리거는 다음을 수행합니다.

   -- Set the INT value in LEFT (currently 50) to the max size of [UserWhoMadeChanges]
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, COALESCE(
                        LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50),
                        '<unknown>')
      FROM DELETED del;

4. @SeanGallardy가 주석에서 지적했듯이이 테이블에서 레코드를 삭제하는 다른 프로 시저 및 / 또는 임시 쿼리로 인해 다음 중 하나 일 수 있습니다.

   • CONTEXT_INFO설정되지 않았으며 여전히 남아 있습니다 NULL.

     이러한 이유로 나는 기본값 INSERT INTO AuditTable을 사용하기 COALESCE위해 위의 내용 을 업데이트했습니다 . 또는 기본값을 원하지 않고 이름이 필요한 경우 다음과 유사한 작업을 수행 할 수 있습니다.

     DECLARE @UserName VARCHAR(50); -- set to the size of AuditTable.[UserWhoMadeChanges]
     SET @UserName = LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50);
     
     IF (@UserName IS NULL)
     BEGIN
        ROLLBACK TRAN; -- cancel the DELETE operation
        RAISERROR('Please set UserName via "SET CONTEXT_INFO.." and try again.', 16 ,1);
     END;
     
     -- use @UserName in the INSERT...SELECT

   • CONTEXT_INFO유효한 UserName 이 아닌 값으로 설정 되었으므로 AuditTable.[UserWhoMadeChanges]필드 크기를 초과 할 수 있습니다 .

     이런 이유로 나는 LEFT움켜 잡은 것이 무엇이든 CONTEXT_INFO깨지지 않도록 하는 기능을 추가했습니다 INSERT. 코드에서 언급했듯이 필드 50의 실제 크기 로 설정하면 됩니다 UserWhoMadeChanges.

SQL Server 2016 이상 업데이트

SQL Server 2016은 세션 별 메모리의 향상된 버전 인 세션 컨텍스트를 추가했습니다. 새로운 세션 컨텍스트는 본질적으로 "Key"유형 sysname(즉 NVARCHAR(128))이고 "Value" 인 키-값 쌍의 해시 테이블입니다 SQL_VARIANT. 의미:

1. 이제 값이 분리되어 다른 용도와 충돌 할 가능성이 줄어 듭니다.
2. 다양한 유형을 저장할 수 있으며 더 이상 값을 가져올 때 이상한 동작에 대해 걱정할 필요가 없습니다 CONTEXT_INFO()(자세한 내용은 내 게시물을 참조하십시오 : CONTEXT_INFO ()가 SET CONTEXT_INFO에 의해 설정된 정확한 값을 반환하지 않는 이유는 무엇입니까? )
3. 당신이 얻을 훨씬 더 많은 공간을 : 8000 "값"당 최대 바이트, 최대 모든 키에서 256킬로바이트의 총 (128 비교하는 것은의 최대 바이트 CONTEXT_INFO)

자세한 내용은 다음 설명서 페이지를 참조하십시오.

• sp_set_session_context
• SESSION_CONTEXT

응용 프로그램 수준 1이 아닌 SQL Server 사용자 ID를 기록하지 않는 한 그렇게 할 수 없습니다.

DeletedBy라는 열이 있고 필요에 따라 열을 설정하면 업데이트 트리거가 실제 삭제를 수행하거나 (또는 ​​레코드를 보관, 가능한 경우 합법적 인 경우 하드 삭제를 피할 수 있음) 감사 내역을 업데이트 할 수 있습니다. . 이런 식으로 삭제를 수행하려면 on delete오류를 발생 시키는 트리거를 정의하십시오 . 실제 테이블에 열을 추가하지 않으려는 경우 열을 추가하는 뷰를 정의 instead of하고 기본 테이블 업데이트를 처리하기위한 트리거를 정의 할 수 있지만 너무 과도 할 수 있습니다.

누가 레코드를 삭제했는지 알 수 있도록 삭제 트리거에 정보를 전달하는 방법이 있습니까?

네, 분명히 두 가지 방법이 있습니다 ;-). 여기에 다른 답변에서CONTEXT_INFO 제안한대로 사용에 대한 예약이있는 경우 다른 코드 / 프로세스와 기능적으로 분리 된 다른 방법을 생각했습니다. 로컬 임시 테이블을 사용하십시오.

임시 테이블 이름에는 동일한 세션에서 실행될 수있는 다른 코드와 분리 할 수 ​​있도록 테이블 이름이 삭제되어야합니다. 다음과 같은 내용이 있습니다.
#<TableName>DeleteAudit

로컬 임시 테이블에 대한 한 가지 이점 CONTEXT_INFO은 다른 특정 프로세스의 누군가가 어떻게 든이 특정 "삭제"프로 시저에서 호출 된 경우 동일한 임시 테이블 이름을 잘못 사용하면 하위 프로세스가 a) 새 로컬을 작성한다는 것입니다 요청 된 이름의 임시 테이블 (이 초기 임시 테이블과 이름이 같더라도) 및 b) 하위 프로세스의 새 로컬 임시 테이블에 대한 DML 문은 데이터의 데이터에 영향을 미치지 않습니다. 여기에서 상위 프로세스에서 로컬 임시 테이블이 작성되므로 데이터를 겹쳐 쓰지 않습니다. 물론, 서브 프로세스가 같은 이름의 CREATE TABLE을 먼저 발행하지 않고이 임시 테이블 이름에 대해 DML 문을 발행하면 해당 DML 문 은 이 테이블의 데이터에 영향을줍니다. 하지만이 시점에서 우리는 정말겹치는 사용 가능성보다 훨씬 더 엣지-케이시 CONTEXT_INFO(그렇습니다, 나는 그것이 일어났다는 것을 알고 있습니다. "나는 결코 일어나지 않을 것"보다는 "에지-케이스"라고 말합니다).

1. 앱은 레코드를 삭제하는 UserName (또는 기타)을 전달하는 "삭제"저장 프로 시저를 호출해야합니다. 이미 삽입 및 업데이트 작업을 추적하는 것처럼 들리기 때문에 이미 사용중인 모델이라고 가정합니다.

2. "삭제"저장 프로시 저는 다음을 수행합니다.

   CREATE TABLE #MyTableDeleteAudit (UserName VARCHAR(50));
   INSERT INTO #MyTableDeleteAudit (UserName) VALUES (@UserName);
   
   -- DELETE STUFF HERE

3. 감사 트리거는 다음을 수행합니다.

   -- Set the datatype and length to be the same as the [UserWhoMadeChanges] field
   DECLARE @UserName VARCHAR(50);
   IF (OBJECT_ID(N'tempdb..#TriggerTestDeleteAudit') IS NOT NULL)
   BEGIN
      SELECT @UserName = UserName
      FROM #TriggerTestDeleteAudit;
   END;
   
   -- catch the following conditions: missing table, no rows in table, or empty row
   IF (@UserName IS NULL OR @UserName NOT LIKE '%[a-z]%')
   BEGIN
     /* -- uncomment if undefined UserName == badness
      ROLLBACK TRAN; -- cancel the DELETE operation
      RAISERROR('Please set UserName via #TriggerTestDeleteAudit and try again.', 16 ,1);
      RETURN; -- exit
     */
     /* -- uncomment if undefined UserName gets default value
      SET @UserName = '<unknown>';
     */
   END;
   
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, @UserName
      FROM DELETED del;

   이 코드를 트리거로 테스트했으며 예상대로 작동합니다.