誰かが私のログオントリガーでパフォーマンスの問題を見ていますか？

Question

誰かが私のログオントリガーでパフォーマンスの問題を見ていますか？

このトリガーを本番SQL Serverにプッシュする前に、オーバーヘッドを減らしてパフォーマンスの問題を回避しようとしています。

私は現在、開発SQLサーバでログオントリガを使用しています。私はそれが過去の週末に実行させ、私の監査ログテーブルに50,000以上の行を置く。私は、ログオンのためにどこのレコードの95％が「NT AUTHORITY/SYSTEM」に気づいた。だから私は 'NT AUTHORITY％'で何かをフィルタリングし、それらのレコードを挿入しないことにしました。私が考えているのは、これらの「NT AUTHORITY」レコードにフィルターをかけて、これらの挿入に保存するリソースの量がIFステートメントのチェックのコストを補うということです。私もPrefmonを見てきましたが、トリガが有効な間に何か変わったことはありませんが、私の開発サーバーは生産と同じ量の活動をしていません。

USE [MASTER] 
GO 

CREATE TRIGGER AuditServerAuthentication 
ON ALL SERVER 
WITH EXECUTE AS SELF 
FOR LOGON 
AS BEGIN 

DECLARE @event XML, @Logon_Name VARCHAR(100) 
SET @Event = EVENTDATA() 
SET @Logon_Name = CAST(@event.query('/EVENT_INSTANCE/LoginName/text()') AS VARCHAR(100)) 

IF @Logon_Name NOT LIKE 'NT AUTHORITY%' 
BEGIN 
    INSERT INTO Auditing.Audit.Authentication_Log 
     (Post_Time,Event_Type,Login_Name,Client_Host,Application_Name,Event_Data) 
    VALUES 
     (
      CAST(CAST(@event.query('/EVENT_INSTANCE/PostTime/text()') AS VARCHAR(64)) AS DATETIME), 
      CAST(@event.query('/EVENT_INSTANCE/EventType/text()') AS VARCHAR(100)), 
      CAST(@event.query('/EVENT_INSTANCE/LoginName/text()') AS VARCHAR(100)), 
      CAST(@event.query('/EVENT_INSTANCE/ClientHost/text()') AS VARCHAR(100)), 
      APP_NAME(), 
      @Event 
     ) 
END 
END 
GO 

Answer 1

私は私の中に非常に類似したトリガーを使用サーバー、そして私はパフォーマンスの問題を経験していません。プロダクションDBは1秒あたり約10回のログインを行います。これにより、時間の経過とともに膨大な量のデータが作成され、バックアップなどの大容量化につながります。

一部のサーバでは、ログインするべきではないユーザがいるテーブルを作成しました。これにより、ログインを拒否することもできます時間

私のトリガーとの違いは、私がトリガで呼び出すストアドプロシージャをいくつか作成して監査目的でDBを作成したことです。トリガーはこのようになります

alter TRIGGER [tr_AU_LogonLog] ON ALL SERVER 
WITH EXECUTE AS 'AUDITUSER' 
FOR LOGON 
AS 
BEGIN 
    DECLARE 
     @data XML 
     , @rc INT 
    SET @data = EVENTDATA() 
    EXEC @rc = AuditDB.dbo.LogonLog @data 
END ; 

プロダクションDBは1秒あたり約10回のログインを取得します。これは時間が経つにつれて膨大な量のデータを作成し、より大きなバックアップに変換します。

EDIT：特定のユーザーをトリガーとして作成する場合、そのシナリオでは危険な可能性があります。

EDIT2：execute asステートメントhereに関するいくつかの有益な情報があります。ああ、トリガーを実装している間は注意してください。誤って自分自身をロックすることができます。ちょっとした場合でも接続を開いておくことをおすすめします:)

Answer 2

それは私には全く高価なIF文のようには見えません（それはあなたがデータベースから何かを選択しているようではない）と、あなたが言うように、あるINSERTを実行するよりもはるかに少ないコストがかかります95％の時間が必要ではありません。しかし、私はDBAではなくデータベースプログラマに過ぎないので、ここで修正することをお勧めします。

私は、しかし、少し奇妙ななぜあなたはこれをしていますか？ SQL Serverにはすでにa built-in mechanism for Login Auditingを使用できませんか？

Answer 3

すぐに分かることはありません。事実、INSERTを保護するIFです。私が検証する唯一のことは、XML解析がどれほど高価なのかです。私はまだSQL Serverで使用していないので、私には分かりません。

Microsoftは、メタデータ（EVENTDATA()）を取得する簡単な方法を提供し、まだ解析することが高価に、まだ知らない人の事が起こっていることのために確かに、それは奇妙に思えるだろう...