事件通知
事件通知會傳送事件的相關資訊給 Service Broker 服務。 事件通知會藉由將這些事件的相關資訊傳送至 Service Broker 服務，以回應各種 Transact-SQL 資料定義語言 (DDL) 語句和 SQL 追蹤事件。
事件通知可用來執行下列工作：
記錄和檢閱發生在資料庫的變更或活動。
執行動作以非同步而不是同步的方式來回應事件。
事件通知可提供程式設計替代方案給 DDL 觸發程序和 SQL 追蹤。
事件通知優點
事件通知會以非同步方式在交易範圍以外執行。 因此，與 DDL 觸發程序不同的是，事件通知可在資料庫應用程式中使用，以便回應未使用立即交易所定義之資源的事件。
和 SQL 追蹤不同，事件通知可用來在 SQL Server 執行個體內執行動作，以回應 SQL 追蹤事件。
與 SQL Server 一起執行的應用程式可使用事件資料來追蹤進度並進行決策。 例如，下列事件通知會在每次在 AdventureWorks2012範例資料庫中發出語句時 ALTER TABLE ，傳送通知給特定服務。
USE AdventureWorks2012;
GO
CREATE EVENT NOTIFICATION NotifyALTER_T1
ON DATABASE
FOR ALTER_TABLE
TO SERVICE '//Adventure-Works.com/ArchiveService' ,
'8140a771-3c4b-4479-8ac0-81008ab17984';
事件通知概念
建立事件通知時，系統會在 SQL Server 執行個體與您所指定的目標服務之間開啟一個或多個 Service Broker 對話。 交談通常會維持開啟狀態，只要事件通知是以伺服器執行個體上的物件存在即可。 在某些錯誤的例子中，可以在卸除事件通知之間先關閉交談。 這些交談永遠不會在事件通知之間共用。 每個事件通知都有自己獨佔的交談。 明確地結束交談可防止目標服務再收到訊息，而且在下次事件通知引發之前都不會再重新開啟交談。
事件資訊會以類型的 xml 變數的形式傳遞至 Service Broker 服務，提供事件發生時間、有關受影響的資料庫物件、涉及 Transact-SQL 批次語句和其他資訊的相關資訊。 如需事件通知所產生的 XML 架構詳細資訊，請參閱 EVENTDATA (Transact-SQL) 。
事件通知與 觸發程序
下表比較觸發程序和事件通知的異同。
| 觸發程序 | 事件通知 |
|---|---|
| DML 觸發程序回應資料管理語言 (DML) 事件。 DDL 觸發程序回應資料定義語言 (DDL) 事件。 | 事件通知可回應 DDL 事件和 SQL 追蹤事件的子集。 |
| 觸發程序可以執行 Transact-SQL 或 Common Language Runtime (CLR) Managed 程式碼。 | 事件通知不會執行程式碼。 相反地，它們會將訊息傳送 xml 至 Service Broker 服務。 |
| 觸發程序會在引發它們的交易範圍內同步處理觸發程序。 | 事件通知可以非同步處理，而且不會在引發它們的交易範圍中執行。 |
| 觸發程序的取用者與引發它的事件緊密繫結在一起。 | 事件通知的取用者與引發它的事件分離。 |
| 觸發程序必須在本機伺服器上處理。 | 事件通知可以在遠端伺服器上處理。 |
| 觸發程序是可以回復的。 | 事件通知是無法回復的。 |
| DML 觸發程序名稱是由結構描述限定範圍。 DML 觸發程序名稱是以資料庫或伺服器限定範圍。 | 事件通知名稱是以伺服器或資料庫限定範圍。 在 QUEUE_ACTIVATION 事件上的事件通知是限定成特定的佇列。 |
| DML 觸發程序是由套用觸發程序的資料表之相同擁有者所擁有。 | 佇列上的事件通知擁有者，有可能與套用事件通知的物件具有不同的擁有者。 |
| 觸發程序支援 EXECUTE AS 子句。 | 事件通知不支援 EXECUTE AS 子句。 |
您可以使用 EVENTDATA 函式來擷取 DDL 觸發程式事件資訊，此函式會 xml 傳回資料類型。 |
事件通知會將事件資訊傳送 xml 至 Service Broker 服務。 資訊將格式化成與 EVENTDATA 函數相同的結構描述。 |
| 與觸發程序相關的中繼資料可在 sys.triggers 與 sys.server_triggers 目錄檢視中找到。 | 與事件通知相關的中繼資料可在 sys.event_notifications 與 sys.server_event_notifications 目錄檢視中找到。 |
事件通知與 SQL 追蹤
下表比較使用事件通知和 SQL 追蹤來監督伺服器事件的異同。
| SQL 追蹤 | 事件通知 |
|---|---|
| SQL 追蹤不會產生與交易關聯的效能負擔。 資料的封裝很有效率。 | 建立 XML 格式事件資料與傳送事件通知有相關聯的效能負擔。 |
| SQL 追蹤可以監督任何追蹤事件類別。 | 事件通知可以監督追蹤事件類別的子集，以及所有資料定義語言 (DDL) 事件。 |
| 您可以自訂在追蹤事件中要產生哪些資料行。 | 會修復事件通知所傳回的 XML 格式事件資料之結構描述。 |
| 不論 DDL 陳述式是否已回復，永遠都會產生 DDL 所產生的追蹤事件。 | 如果在對應 DDL 陳述式中的事件已回復，就不會引發事件通知。 |
| 管理追蹤事件資料的中繼流程，將需要擴展和管理追蹤檔案或追蹤資料表。 | 事件通知資料的中繼管理是透過 Service Broker 佇列自動完成。 |
| 每次重新啟動伺服器時都必須重新啟動追蹤。 | 在註冊後，事件通知會持續存在於伺服器週期中並已交易。 |
| 在初始化後，就無法控制追蹤的引發。 停止時間和篩選時間可用來指定初始化它們的時間。 是透過輪詢對應追蹤檔案來存取追蹤。 | 可以針對收到事件通知所產生的訊息之佇列，使用 WAITFOR 陳述式來控制事件通知。 可以透過輪詢佇列來存取它們。 |
| ALTER TRACE 是建立追蹤所需的基本權限。 在對應電腦上建立追蹤檔案的權限也是必要的。 | 基本權限是視建立事件通知的類型而定。 在對應佇列上也需要 RECEIVE 權限。 |
| 可以遠端接收追蹤。 | 可以遠端接收事件通知。 |
| 追蹤事件是使用系統預存程序來實作。 | 事件通知是使用 Database Engine 和 Service BrokerTransact-SQL 語句的組合來實作。 |
| 透過查詢對應追蹤資料表、剖析追蹤檔案，或使用 SQL Server 管理物件 (SMO) 的 TraceReader Class，就可使用程式設計的方式來存取追蹤事件資料。 | 透過針對 XML 格式的事件資料發出 XQuery，或使用 SMO Event 類別，以程式設計方式來存取事件資料。 |
事件通知工作
| Task | 主題 |
|---|---|
| 描述如何建立及實作事件通知。 | 實作事件通知 |
| 描述如何針對可傳送訊息到遠端伺服器上 Service Broker 的事件通知，設定 Service Broker 對話安全性。 | 設定事件通知的對話安全性 |
| 描述如何傳回有關事件通知的詳細資訊。 | 取得事件通知詳細資訊 |