Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

SQL Server-Trigger – Teil 2 DDL- und LOGON-Trigger

In SQL Server sind Trigger Datenbankobjekte, die immer dann ausgeführt werden, wenn ein auslösendes Ereignis auf der Datenbank oder dem Server eintritt. Auslöser spielen eine Schlüsselrolle bei der Erfüllung von Geschäftsanforderungen, wie z. B. der Benachrichtigung von Zielpersonen basierend auf einer erreichten Bedingung, dem Beginn eines Jobs oder anderen Vorgängen. Im vorherigen Artikel über DML-Trigger haben wir über Trigger, Triggertypen und verschiedene für DML-Trigger verfügbare Triggeroptionen gesprochen. In diesem Artikel untersuchen wir SQL DDL- und LOGON-Trigger.

DDL-Trigger

DDL-Trigger können für eine Vielzahl von server- oder datenbankbezogenen Ereignissen ausgelöst werden, darunter sowohl DDL- als auch DCL-Befehle. DDL steht für Data Definition Language, die zum CREATE, ALTER, DROP aller Objekte verwendet wird, und DCL steht für Data Control Language-Anweisungen wie GRANT-, DENY- und REVOKE-Befehle. Nachfolgend sind die Merkmale von SQL-DDL-Triggern aufgeführt.

  1. DDL-Trigger können auf Datenbankebene oder Serverinstanzebene erstellt werden und decken eine Vielzahl von DDL-Vorgängen oder DDL-ähnlichen Vorgängen ab, z. DCL-Befehle.
  2. DDL-Trigger können nur als FOR- oder AFTER-Trigger aufgerufen oder ausgelöst werden. SQL Server unterstützt INSTEAD OF DDL Trigger nicht und wir können sehen, wie einige DDL-Operationen über DDL-Trigger verhindert werden können.
  3. SQL Server verfügt über integrierte Funktionen wie EVENTDATA() und IS_MEMBER() zur Verwendung in DDL-Triggern, um weitere Informationen zu den Triggerereignissen zu erhalten.
      Die Funktion
    1. EVENTDATA() gibt vollständige Details zu datenbank- oder serverbezogenen Ereignissen im XML-Format innerhalb des Bereichs des datenbank- oder serverbezogenen DDL-Triggers oder der Logon-Trigger zurück. Die EVENTDATA()-Funktion gibt die vollständigen Ereignisdetails für die Sitzung zurück, die die DDL- oder Anmeldeaktivitäten ausführt. EVENTDATA() gibt die folgenden Details zurück
      • EventType – Typ des Ereignisses, das den in der Tabelle sys.trigger_event_types verfügbaren DDL-Trigger auslöst.
      • PostTime – Uhrzeit, zu der das Ereignis ausgelöst oder gepostet wurde.
      • SPID – Sitzungs-ID des Ereignisses.
      • ServerName – Name der SQL Server-Instanz, in der das Ereignis ausgelöst wurde.
      • LoginName – SQL Server-Anmeldename, der das Ereignis ausgeführt hat.
      • UserName – Benutzername des Logins, der standardmäßig dbo ist.
      • DatabaseName – Datenbankname, unter dem der DDL-Trigger ausgelöst wurde.
      • SchemaName – Schemaname des betroffenen Objekts.
      • ObjectName – Name des betroffenen Objekts.
      • ObjectType – Typ des SQL Server-Objekts wie Tabelle, Ansicht, gespeicherte Prozedur.
      • TSQLCommand – T-SQL-Skript, das von einem Benutzer ausgeführt wurde, der den DDL-Trigger aufgerufen hat.
      • SetOptions – SET-Optionen, die vom Benutzer oder Client wie SSMS verwendet werden, während der TSQLCommand ausgeführt wurde.
      • CommandText – Tatsächliche DDL- oder DCL-Anweisungen mit dem in der Tabelle sys.trigger_event_types angegebenen DDL-Ereignis.
      2. Die Funktion
    2. IS_MEMBER() gibt zurück, ob der aktuelle Benutzer Mitglied der Windows-Gruppe oder der SQL Server-Datenbankrolle ist oder nicht.
  4. System DMV sys.triggers speichert die Liste aller datenbankbezogenen Trigger. Wir können die folgende Abfrage verwenden, um die Details aller DDL-Trigger im Datenbankbereich abzurufen.
SELECT * 
FROM sys.triggers
WHERE type = 'TR';
  1. System DMV sys.server_triggers speichert die Liste aller serverbezogenen Trigger und wir können die folgende Abfrage verwenden, um die Details zu allen serverbezogenen DDL-Triggern abzurufen.
SELECT * 
FROM sys.server_triggers;
  1. DDL-Trigger-Definitionen können angezeigt werden, wenn der Trigger nicht verschlüsselt ist, indem Sie eine der folgenden Optionen von sys.sql_modules oder die Funktion OBJECT_DEFINITION() oder die gespeicherte Prozedur sp_helptext verwenden.
SELECT OBJECT_SCHEMA_NAME(object_id, db_id()) Schema_name, OBJECT_NAME(object_id) Trigger_Name, definition
FROM sys.sql_modules  
WHERE object_id = OBJECT_ID(<trigger_name>);   

SELECT OBJECT_DEFINITION (OBJECT_ID(<trigger_name>)) AS ObjectDefinition; 

EXEC sp_helptext '<trigger_name>';
  1. Alle möglichen DDL-Ereignisse sind in der Tabelle sys.trigger_event_types verfügbar und können mit der folgenden Abfrage angezeigt werden.
SELECT *
FROM sys.trigger_event_types;

Die Syntax eines DDL-Triggers lautet:

CREATE TRIGGER <trigger_name>
ON < ALL SERVER | DATABASE > 
[ WITH <DDL_trigger_option> [ ,...n ] ]  
{ FOR | AFTER } <event_type>
AS { sql_statement | EXTERNAL NAME <method specifier> }

Datenbankbezogenen DDL-Trigger erstellen

Lassen Sie uns einen datenbankbezogenen Trigger erstellen, um alle Tabellenerstellungen zu verfolgen und uns mit dem folgenden Skript bei einer Protokollierungstabelle mit dem Namen Track_DDL_Changes anzumelden.

CREATE TABLE Track_DDL_Changes (EventData xml, PostDtm datetime)
GO
CREATE TRIGGER TR_D_CREATETABLE
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
	INSERT INTO Track_DDL_Changes
	SELECT EVENTDATA(),GETDATE()
END
GO

Lassen Sie uns eine neue Tabelle namens trigger_test erstellen und überprüfen, ob das CREATE TABLE-Ereignis geprüft wurde oder nicht, indem Sie das folgende Skript verwenden.

CREATE TABLE Trigger_Test ( a int, b datetime);

Die Auswahl der Daten aus der Tabelle Track_DDL_Changes zeigt, dass das obige CREATE_TABLE-Ereignis erfolgreich erfasst wurde, wie unten gezeigt:

Durch Klicken auf den EventData-Wert wird der XML EVENTDATA()-Wert wie unten gezeigt in einem neuen Fenster geöffnet.

Wir sind in der Lage, die vollständigen Details über das auslösende Ereignis über die EVENTDATA()-Funktion zu überprüfen, und daher würde die EVENTDATA()-Funktion eine bedeutende Rolle für alle DDL- oder LOGON-Trigger spielen.

Wir können unseren DDL-Trigger mit Hilfe der EVENTDATA()-Funktion und XML-Parsing weiter verbessern und verhindern, dass irgendjemand eine Tabelle in der Testdatenbank mit dem unten angegebenen Skript erstellt:

CREATE TRIGGER TR_D_PREVENT_CREATETABLE
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
   SELECT EVENTDATA().value  
        ('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)')  
   RAISERROR ('Creation of New tables restricted in this database, Kindly contact DBA.', 16, 1)   
   ROLLBACK  
END
GO

Die Erstellung des datenbankbezogenen Triggers wurde erfolgreich abgeschlossen. Lassen Sie uns dies überprüfen, indem Sie mit dem folgenden Skript eine weitere Tabelle erstellen.

CREATE TABLE Trigger_Test1 (a int, b datetime);

Der Auslöser hat uns daran gehindert, neue Tabellen in dieser Datenbank zu erstellen, und den Benutzern auch eine aussagekräftige Nachricht hinterlassen. Wir können auf ähnliche Weise alle anderen DDL- oder Server-bezogenen Ereignisse verarbeiten, um die Anforderungen zu erfüllen.

Um den datenbankbezogenen DDL-Trigger zu löschen, müssen wir die folgende Syntax verwenden:

DROP TRIGGER <trigger_name> ON DATABASE;

Und um den Trigger, den wir gerade erstellt haben, zu löschen, wäre das Skript

DROP TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;

Um die datenbankbezogenen DDL-Trigger in SSMS anzuzeigen, erweitern Sie die Testdatenbank -> Programmierbarkeit -> Datenbank-Trigger wie unten gezeigt.

Ähnlich wie SQL-DML-Trigger können DDL-Trigger gelöscht, deaktiviert oder aktiviert werden, indem Sie einfach mit der rechten Maustaste auf den Triggernamen klicken, wie unten gezeigt.

Über T-SQL können wir den datenbankbezogenen DDL-Trigger mit der folgenden Syntax löschen, deaktivieren oder aktivieren:

-- DROP Database scoped DDL Trigger
DROP TRIGGER <trigger_name> ON DATABASE;
-- Enable Database scoped DDL Trigger
ENABLE TRIGGER <trigger_name> ON DATABASE;
-- Disable Database scoped DDL Trigger
DISABLE TRIGGER <trigger_name> ON DATABASE;

Um den von uns erstellten Trigger zu deaktivieren, müssen wir möglicherweise das folgende Skript verwenden.

-- DROP Database scoped DDL Trigger
DROP TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;
-- Enable Database scoped DDL Trigger
ENABLE TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;
-- Disable Database scoped DDL Trigger
DISABLE TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;

DDL-Trigger im Serverbereich erstellen

Der DDL-Trigger im Serverbereich folgt derselben Syntax wie der DDL-Trigger im Datenbankbereich, mit der Ausnahme, dass die Ereignisse auf dem Serverbereich basieren.

Versuchen wir, einen serverbezogenen DDL-Trigger zu erstellen, um zu verhindern, dass Benutzer mit dem folgenden Skript eine neue Datenbank auf dieser Serverinstanz erstellen.

CREATE TRIGGER TR_S_PREVENT_CREATEDATABASE
ON ALL SERVER
FOR CREATE_DATABASE
AS
BEGIN
   SELECT EVENTDATA().value  
        ('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)')  
   RAISERROR ('Creation of New Databases restricted in this Instance, Kindly contact DBA.', 16, 1)   
   ROLLBACK  
END
GO

Beim Versuch, eine neue Datenbank mit dem folgenden Befehl zu erstellen, erhalten wir eine Fehlermeldung wie unten gezeigt.

CREATE DATABASE DATABASE_TEST;

In SSMS serverbezogene DDL-Trigger unter Trigger im Abschnitt Serverobjekte, wie unten gezeigt.

Wir können den serverbezogenen DDL-Trigger löschen, deaktivieren oder aktivieren, indem Sie einfach mit der rechten Maustaste auf den serverbezogenen DDL-Trigger klicken, wie unten gezeigt.

Über T-SQL können wir mit dem folgenden Befehl löschen, deaktivieren oder aktivieren.

-- DROP Server scoped DDL Trigger
DROP TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;
-- Disable Server scoped DDL Trigger
DISABLE TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;
-- Enable Server scoped DDL Trigger
ENABLE TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;

Der Zweck von DDL-Triggern

  1. Zur Prüfung aller DDL-Ereignisse, die auf Datenbank- oder Serverebene auftreten.
  2. Um zu verhindern, dass DDL-Ereignisse auf Datenbank- oder Serverebene auftreten.
  3. Zur Benachrichtigung, wenn DDL-Ereignisse auf Datenbank- oder Serverebene auftreten.

Anmeldeauslöser

Anmeldeauslöser werden, wie der Name schon sagt, für LOGON-Ereignisse in SQL Server ausgeführt. Sobald die Authentifizierungsphase für ein Anmeldeereignis abgeschlossen ist, wird das LOGON-Trigger-Skript zusätzlich zur Anmeldeaktivität ausgeführt. Wenn die Anmeldung nicht erfolgreich authentifiziert wird, werden keine LOGON-Trigger ausgelöst. Anmeldeauslöser werden in SSMS im Abschnitt „Auslöser“ der Serverobjekte aufgeführt. Die Syntax eines LOGON-Triggers lautet wie folgt:

CREATE TRIGGER <schema_name.trigger_name>
ON ALL SERVER
{ FOR| AFTER } LOGON    
AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier >  [ ; ] }

Trigger erstellen

Lassen Sie uns einen einfachen LOGON-Trigger erstellen, um weitere Informationen über das LOGON-Ereignis von der EVENTDATA()-Funktion zu erfassen, wie unten gezeigt.

CREATE TABLE Track_LOGON_EVENTS (EventData xml, PostDtm datetime)
GO
CREATE TRIGGER TR_LOGON
ON ALL SERVER
FOR LOGON
AS
BEGIN
	INSERT INTO Track_LOGON_EVENTS
	SELECT EVENTDATA(),GETDATE();
END
GO

Der obige LOGON-Trigger erfasst alle Details zu einer Anmeldeaktivität, ähnlich dem, was wir bei der Verwendung der EVENTDATA()-Funktion in DDL-Trigger bemerkt haben. Wir sollten bei der Planung der Verwendung von LOGON-Triggern vorsichtig sein, denn wenn es logische Fehler im Trigger gibt, würde dies niemandem oder den meisten Benutzern erlauben, sich mit der Instanz von SQL Server zu verbinden.

Um LOGON-Trigger zu löschen, zu deaktivieren oder zu aktivieren, können wir das folgende Skript verwenden.

-- DROP LOGON Trigger
DROP TRIGGER TR_LOGON ON ALL SERVER;
-- Disable LOGON Trigger
DISABLE TRIGGER TR_LOGON ON ALL SERVER;
-- Enable LOGON Trigger
ENABLE TRIGGER TR_LOGON ON ALL SERVER;

Der Zweck von LOGON-Triggern

  1. Zur Prüfung aller LOGON-Ereignisse, die auf dem Server stattfinden.
  2. Um zu verhindern, dass LOGON-Ereignisse auf dem Server stattfinden
  3. Um zu benachrichtigen, wenn LOGON-Ereignisse auf dem Server stattfinden.

Trigger-Eigenschaften

sp_settriggerorder

sp_settriggerorder wird verwendet, um die Reihenfolge der Triggerausführung nur für den ersten und den letzten Trigger zu definieren. Wenn es mehr als 2 DML-Trigger in einer Tabelle gibt, sagen wir 5 DML-Trigger, können wir den ersten DML-Trigger und den letzten DML-Trigger definieren, aber nicht die Reihenfolge der mittleren 3 Trigger.

Hinweis: Das Festlegen der FIRST- oder LAST-Option ist spezifisch für eine bestimmte Ereigniskategorie für DML-Trigger. Beispielsweise können wir in einer Tabelle mit 3 INSERT-Triggern definieren, welcher INSERT-Trigger der ERSTE und welcher INSERT-Trigger der LETZTE ist. Wenn Sie 3 Trigger in einer Tabelle haben, wie INSERT, UPDATE und DELETE, dann ist es nicht nötig, die Bedingung für die Trigger-Reihenfolge festzulegen.

Die Syntax zum Festlegen der Trigger-Reihenfolge wäre wie folgt:

exec sp_settriggerorder @triggername = '<trigger_schema_name.trigger_name>' 
    , @order = 'FIRST' | 'LAST'   
    , @stmttype = '<trigger event type>'   
    , @namespace = 'DATABASE' | 'SERVER' | 'NULL'

Für DDL-Trigger können wir den ersten und letzten Trigger im Bereich des Servers und dann den ersten und letzten Trigger im Bereich der Datenbank definieren. Wenn wir zum Beispiel 5 serverbezogene Trigger und 5 datenbankbezogene Trigger haben, kann die Reihenfolge wie folgt definiert werden:

  1. Erster Trigger für serverbezogenen DDL-Trigger
  2. 3 andere serverbezogene DDL-Trigger in zufälliger Reihenfolge
  3. Letzter Trigger für serverbezogenen DDL-Trigger.
  4. Erster Trigger für DDL-Trigger im Datenbankbereich (einer pro Datenbank)
  5. 3 andere DDL-Trigger im Datenbankbereich in zufälliger Reihenfolge
  6. Letzter Trigger für DDL-Trigger im Datenbankbereich.

In Bezug auf die Einstellung der ersten oder letzten Option können die datenbankbezogenen DDL-Trigger innerhalb der Datenbank und die serverbezogenen DDL-Trigger auf Instanzebene angeordnet werden.

Obwohl wir mit SQL Server viele Trigger für eine Tabelle erstellen können, wird empfohlen, die Anforderungen des Triggers sorgfältig zu analysieren, um die Wartung und Fehlerbehebung zu verbessern.

Rekursive Trigger

SQL Server unterstützt auch das rekursive Aufrufen von Triggern für DML-Trigger. Rekursive Trigger können wie unten gezeigt als direkt oder indirekt klassifiziert werden.

Direkte rekursive Trigger – Benutzer oder Anwendung aktualisiert einen Datensatz in Tabelle A. UPDATE-Trigger A in Tabelle A wird ausgelöst und aktualisiert Tabelle A erneut. Da der Datensatz in Tabelle A über Trigger aktualisiert wurde, wird UPDATE Trigger A erneut aufgerufen, und dies geschieht rekursiv.

Lassen Sie uns mit dem folgenden Skript einen direkten rekursiven Trigger für die Sales-Tabelle erstellen:

CREATE TRIGGER TR_UPD_Recursive_Sales ON Sales
FOR UPDATE 
AS
BEGIN
  UPDATE Sales 
  SET SalesDate = GETDATE() 
  WHERE SalesId = (SELECT SalesId FROM Inserted)
END
GO

Führen Sie das folgende Skript aus:

UPDATE Sales 
SET SalesDate = GETDATE() 
WHERE SalesId = 3;

Indirekte rekursive Trigger – Der Benutzer oder die Anwendung aktualisiert einen Datensatz in Tabelle A. Der UPDATE-Trigger A in Tabelle A wird ausgelöst und aktualisiert einen Datensatz in Tabelle B. Wenn Tabelle B einen UPDATE-Trigger hat, um Datensätze zurück in Tabelle A zu aktualisieren, wird der UPDATE-Trigger in aufgerufen Tabelle A, die rekursiv passieren wird.

Lassen Sie uns mit dem folgenden Skript einen indirekten rekursiven Trigger für die Tabellen IDR_Test1 und IDR_Test2 erstellen:

DROP TABLE IDR_Test1
DROP TABLE IDR_Test2

CREATE TABLE IDR_Test1 (PK int NOT NULL);
GO
INSERT INTO IDR_Test1 
values (10),(20)
GO
CREATE TABLE IDR_Test2 (PK int NOT NULL);
GO
INSERT INTO IDR_Test2
values (10),(20)
GO

CREATE TRIGGER TR_IDR_Test1
ON IDR_Test1
FOR UPDATE 
AS
BEGIN
	UPDATE IDR_Test2
	SET PK = 30
	WHERE PK IN (SELECT PK FROM inserted);
END
GO
 
CREATE TRIGGER TR_Temp2
ON IDR_Test2
FOR UPDATE 
AS
BEGIN
	UPDATE IDR_Test1
	SET PK = 30
	WHERE PK IN (SELECT PK FROM inserted);
END
GO

Führen Sie das folgende Skript aus:

UPDATE IDR_Test1
SET PK = 1
WHERE PK = 10;

Um diese Art des Aufrufs von rekursiven Triggern auf Datenbankebene zu vermeiden, verfügt SQL Server über eine Option namens RECURSIVE_TRIGGERS auf jeder Datenbankebene, um das Auslösen von rekursiven Triggern zu unterbrechen. Standardmäßig ist die Option „Rekursiver Trigger“ für eine Datenbank auf „False“ gesetzt. Aktivieren Sie dies nur bei Bedarf nach sorgfältiger Abwägung der Auswirkungen auf die Leistung oder der damit verbundenen Datenänderungen.

Klicken Sie in SSMS mit der rechten Maustaste auf unsere Testdatenbank -> Wählen Sie Eigenschaften -> Klicken Sie auf Optionen und scrollen Sie nach unten, um zu sehen, ob die Option „Rekursive Trigger“ aktiviert ist oder nicht, wie unten gezeigt. Für Test Database ist es auf False gesetzt, da False der Standardwert für die Option Recursive Triggers ist. Um die Option „Rekursive Trigger“ für eine bestimmte Datenbank zu aktivieren, klicken Sie einfach auf den Dropdown-Wert, ändern Sie ihn in „True“ und klicken Sie auf „OK“.

Über T-SQL können wir die Option Recursive Trigger der Test-Datenbank überprüfen, indem wir die is_recursive_triggers_on-Spalte von sys.databases DMV überprüfen, wie unten gezeigt.

select name, is_recursive_triggers_on
from sys.databases
where name = 'test'

Um die Option Rekursive Trigger für eine Datenbank zu ändern (Test in meinem Beispiel), können wir das folgende Skript ausführen.

ALTER DATABASE [Test] SET RECURSIVE_TRIGGERS ON WITH NO_WAIT
GO

Um es für eine Datenbank (Test in meinem Beispiel) wieder in den falschen Status (Standardstatus) zu versetzen, führen Sie das folgende Skript aus.

ALTER DATABASE [Test] SET RECURSIVE_TRIGGERS OFF WITH NO_WAIT
GO

Verschachtelte Auslöser

Rekursive Trigger sind ein klassisches Beispiel für verschachtelte Trigger, aber es kann einige andere Fälle geben, die zu einer Verschachtelung mehrerer Trigger führen. SQL Server ermöglicht das Verschachteln von Triggern bis zu einer maximalen Anzahl von 32 Ebenen, und jeder Trigger, der diese Verschachtelungsebene überschreitet, wird von SQL Server abgebrochen. SQL Server verfügt über eine instanzweite Konfiguration zum Deaktivieren der Option „Geschachtelte Trigger“. Bitte beachten Sie, dass die Verschachtelung von SQL Server-Triggern mit CLR-Code oder verwaltetem Code nicht unter die Grenze von 32 Ebenen fällt, da sie außerhalb des Bereichs von SQL Server liegt. Standardmäßig ist die Option für verschachtelte Trigger in allen SQL Server-Instanzen aktiviert und wir können sie nach Bedarf deaktivieren.

Wir können überprüfen, ob die Option für verschachtelte Trigger auf Instanzebene in SSMS aktiviert ist, indem wir die folgenden Schritte ausführen:

Klicken Sie mit der rechten Maustaste auf Server -> Wählen Sie Eigenschaften -> Klicken Sie auf Erweitert

Um die Option für verschachtelte Trigger zu deaktivieren oder zu deaktivieren, klicken Sie auf das Dropdown-Menü und ändern Sie es in „False“ und klicken Sie auf OK .

Über T-SQL können wir überprüfen, ob die Option Nested Triggers aktiviert ist, indem wir die Spalte value_in_use in sys.configurations DMV auf den Konfigurationsnamen der Nested Triggers überprüfen.

Um diese Option zu deaktivieren, müssen wir die gespeicherte Systemprozedur sp_configure wie unten gezeigt verwenden:

EXEC sp_configure 'nested triggers', 0;  
GO  
RECONFIGURE;  
GO

Innerhalb aller DML- oder DDL-Trigger verfügt SQL Server zum Ermitteln der aktuellen Verschachtelungsebene über eine integrierte Funktion namens TRIGGER_NESTLEVEL, die die Anzahl der Trigger zurückgibt, die für die aktuelle Anweisung ausgeführt wurden, die den Trigger einschließlich sich selbst ausgelöst hat. Die Syntax der Funktion TRIGGER_NESTLEVEL wäre:

SELECT TRIGGER_NESTLEVEL ( object_id, <trigger_type> , <trigger_event_category> )

Dabei ist object_id die Objekt-ID des Triggers, trigger_type ist AFTER für AFTER trigger und IOT für INSTEAD OF trigger und trigger_event_category ist entweder DML oder DDL.

Wenn wir beispielsweise nur die Verschachtelungsebene bis 10 zulassen und nach 10 Ebenen einen Fehler auslösen müssen, können wir dies mit einem Testtrigger wie hier tun:

IF ((SELECT TRIGGER_NESTLEVEL(OBJECT_ID('test_trigger'), 'AFTER’, 'DML’)) > 10)  
   RAISERROR ('Trigger test_trigger nested more than 10 levels.',16, -1)

VERSCHLÜSSELUNG

Um die Trigger-Logik oder -Definition zu verschlüsseln, kann die Option WITH ENCRYPTION in der Trigger-Definition ähnlich wie bei allen anderen SQL Server-Objekten verwendet werden.

EXECUTE AS-Klausel

Um den Trigger mit einem bestimmten Sicherheitskontext auszuführen, kann die EXECUTE AS-Klausel in der Triggerdefinition verwendet werden.

NICHT ZUR REPLIKATION

Um anzugeben, dass der DML-Trigger nicht aufgerufen werden soll, während er über Replikationsänderungen ausgeführt wird, wird die Eigenschaft NOT FOR REPLICATION für alle Objekte in der Abonnentendatenbank festgelegt.

Schlussfolgerung

Vielen Dank, dass Sie den leistungsstarken Artikel über DDL-Trigger und Logon-Trigger gelesen haben, in dem wir den Zweck von DDL- und Logon-Triggern verstanden haben, wie Sie diese Trigger erstellen oder löschen, deaktivieren oder aktivieren und wie Sie die EVENTDATA()-Funktion verwenden Verfolgen von DDL- oder Anmeldeaktivitäten. Darüber hinaus haben wir gelernt, wie man die Ausführungsreihenfolge mehrerer SQL DML- oder DDL-Trigger zusammen mit rekursiven und verschachtelten Triggern im Detail festlegt und wie man rekursive oder verschachtelte Trigger sorgfältig behandelt.