Dela via


Händelsemeddelanden

Gäller för:SQL Server

Händelsemeddelanden skickar information om händelser till en Service Broker-tjänst. Händelsemeddelanden körs som svar på en mängd olika Transact-SQL DDL-instruktioner (datadefinitionsspråk) och SQL Trace-händelser genom att skicka information om dessa händelser till en Service Broker-tjänst.

Händelsemeddelanden kan användas för att göra följande:

  • Logga och granska ändringar eller aktiviteter som inträffar i databasen.
  • Utför en åtgärd som svar på en händelse på ett asynkront sätt i stället för synkront sätt.

Händelsemeddelanden kan erbjuda ett programmeringsalternativ till DDL-utlösare och SQL Trace.

Fördelar med händelsemeddelanden

Händelsemeddelanden körs asynkront, utanför en transaktions omfång. Till skillnad från DDL-utlösare kan händelsemeddelanden därför användas i ett databasprogram för att svara på händelser utan att använda några resurser som definierats av den omedelbara transaktionen.

Till skillnad från SQL Trace kan händelsemeddelanden användas för att utföra en åtgärd i en instans av SQL Server som svar på en SQL Trace-händelse.

Händelsedata kan användas av program som körs tillsammans med SQL Server för att spåra förloppet och fatta beslut. Följande händelsemeddelande skickar till exempel ett meddelande till en viss tjänst varje gång en ALTER TABLE instruktion utfärdas i exempeldatabasen AdventureWorks2022 .

USE AdventureWorks2022;
GO

CREATE EVENT NOTIFICATION NotifyALTER_T1
    ON DATABASE
    FOR ALTER_TABLE
    TO SERVICE '//Adventure-Works.com/ArchiveService',
        '8140a771-3c4b-4479-8ac0-81008ab17984';

Begrepp för händelsemeddelanden

När ett händelsemeddelande skapas öppnas en eller flera Service Broker-konversationer mellan en instans av SQL Server och den måltjänst som du anger. Konversationerna förblir vanligtvis öppna så länge händelsemeddelandet finns som ett objekt på serverinstansen. I vissa felfall kan konversationerna stängas innan händelsemeddelandet tas bort. Dessa konversationer delas aldrig mellan händelseaviseringar. Varje händelsemeddelande har egna exklusiva konversationer. Om du avslutar en konversation hindrar du uttryckligen måltjänsten från att ta emot fler meddelanden och konversationen öppnas inte igen nästa gång händelsemeddelandet utlöses.

Händelseinformation levereras till Service Broker-tjänsten som en variabel av typen xml som ger information om när en händelse inträffar, om det berörda databasobjektet, den Transact-SQL batch-instruktionen som ingår och annan information. Mer information om XML-schemat som skapas av händelseaviseringar finns i EVENTDATA.

Händelsemeddelanden jämfört med utlösare

I följande tabell jämförs och kontrasterar utlösare och händelsemeddelanden.

Triggers Händelsemeddelanden
DML-utlösare svarar på DML-händelser (datamanipuleringsspråk). DDL-utlösare svarar på DDL-händelser (Data Definition Language). Händelsemeddelanden svarar på DDL-händelser och en delmängd av SQL-spårningshändelser.
Utlösare kan köra Transact-SQL eller clr-hanterad kod (Common Language Runtime). Händelsemeddelanden kör inte kod. I stället skickar de XML-meddelanden till en Service Broker-tjänst.
Utlösare bearbetas synkront inom omfånget för de transaktioner som gör att de utlöses. Händelsemeddelanden kan bearbetas asynkront och inte köras i omfånget för de transaktioner som orsakar att de utlöses.
Konsumenten av en utlösare är nära kopplad till den händelse som gör att den utlöses. Användaren av ett händelsemeddelande frikopplas från den händelse som gör att den utlöses.
Utlösare måste bearbetas på den lokala servern. Händelsemeddelanden kan bearbetas på en fjärrserver.
Utlösare kan återställas. Det går inte att återställa händelsemeddelanden.
DML-utlösarnamn är schemaomfattande. DDL-utlösarnamn är databasomfattande eller serveromfångsbegränsade. Namn på händelsemeddelanden begränsas av servern eller databasen. Händelsemeddelanden på en QUEUE_ACTIVATION händelse är begränsade till en specifik kö.
DML-utlösare ägs av samma ägare som de tabeller som de tillämpas på. Ägaren till ett händelsemeddelande i en kö kan ha en annan ägare än det objekt som den tillämpas på.
Utlösare stöder EXECUTE AS -satsen. Händelsemeddelanden stöder EXECUTE AS inte satsen.
Händelseinformation för DDL-utlösare kan samlas in med funktionen EVENTDATA, som returnerar en XML-datatyp . Händelsemeddelanden skickar xml-händelseinformation till en Service Broker-tjänst. Informationen formateras till samma schema som för funktionen EVENTDATA.
Metadata om utlösare finns i katalogvyerna sys.triggers och sys.server_triggers . Metadata om händelsemeddelanden finns i katalogvyerna sys.event_notifications och sys.server_event_notifications .

Händelsemeddelanden vs. SQL Spårning

Följande tabell jämför och kontrasterar med hjälp av händelsemeddelanden och SQL Trace för övervakning av serverhändelser.

SQL-spårning Händelsemeddelanden
SQL Trace genererar inga prestandakostnader som är associerade med transaktioner. Paketering av data är effektivt. Det finns prestandakostnader som är associerade med att skapa XML-formaterade händelsedata och skicka händelsemeddelandet.
SQL Trace kan övervaka alla spårningshändelseklasser. Händelsemeddelanden kan övervaka en delmängd av spårningshändelseklasser och även alla DDL-händelser (Data Definition Language).
Du kan anpassa vilka datakolumner som ska genereras i en spårningshändelse. Schemat för XML-formaterade händelsedata som returneras av händelsemeddelanden har åtgärdats.
Spårningshändelser som genereras av DDL genereras alltid, oavsett om DDL-instruktionen återställs. Händelsemeddelanden utlöses inte om händelsen i motsvarande DDL-instruktion återställs.
Att hantera det mellanliggande flödet av spårningshändelsedata innebär att fylla i och hantera spårningsfiler eller spårningstabeller. Mellanliggande hantering av händelsemeddelandedata utförs automatiskt via Service Broker-köer.
Spårningar måste startas om varje gång servern startas om. När händelsemeddelanden har registrerats bevaras de mellan servercyklerna och utförs.
Efter att ha initierats kan avfyrningen av spårningar inte kontrolleras. Stopptider och filtertider kan användas för att ange när de initieras. Spårningar nås genom att avsöka motsvarande spårningsfil. Händelsemeddelanden kan styras med hjälp av -instruktionen WAITFOR mot kön som tar emot meddelandet som genereras av händelsemeddelandet. De kan nås genom att avsöka kön.
ALTER TRACE är den minsta behörighet som krävs för att skapa en spårning. Behörighet krävs också för att skapa en spårningsfil på motsvarande dator. Minsta behörighet beror på vilken typ av händelseavisering som skapas. RECEIVE behörighet krävs också i motsvarande kö.
Spårningar kan tas emot via fjärranslutning. Händelsemeddelanden kan tas emot via fjärranslutning.
Spårningshändelser implementeras med hjälp av systemlagrade procedurer. Händelsemeddelanden implementeras med hjälp av en kombination av Database Engine och Service Broker Transact-SQL-instruktioner.
Spårningshändelsedata kan nås programmatiskt genom att fråga motsvarande spårningstabell, parsa spårningsfilen eller använda SQL Server Management Objects (SMO) TraceReader-klassen. Händelsedata används programmatiskt genom att utfärda XQuery mot XML-formaterade händelsedata eller med hjälp av SMO-händelseklasserna.

Aktiviteter för händelsemeddelanden

Task Article
Beskriver hur du skapar och implementerar händelsemeddelanden. Implementera händelsemeddelanden
Beskriver hur du konfigurerar dialogsäkerhet för Service Broker för händelsemeddelanden som skickar meddelanden till en tjänstkoordinator på en fjärrserver. Konfigurera dialogsäkerhet för händelsemeddelanden
Beskriver hur du returnerar information om händelsemeddelanden. Hämta information om händelsemeddelanden