共用方式為


關於 Notification Services 的常見問題集

Microsoft 已將 Microsoft Notification Services 使用者的常見問題彙編為下列清單。

問題和答覆

Notification Services 與 SQL Server Agent 之間的差異為何?

SQL Server Agent 的建立,是特別為了傳送訊息給 SQL Server 管理員,或依照伺服器或資料庫的條件來執行預定的工作。

相對地,Notification Services 可向任何來源收集資料、將事件對應至許多使用者所定義的訂閱,而且幾乎可使用任何通訊協定傳送已格式化的訊息到可接收訊息的任何裝置。

雖然您可以使用觸發程序自訂 SQL Server Agent,將訊息傳送給多位使用者,SQL Server Agent 並非針對數千或數百萬位使用者的規模而設計。Notification Services 的規模可大至數百萬位使用者,每天傳送數百萬份通知。

此外,Notification Services 作為開發平台,所提供的功能可縮短啟動、執行應用程式所需的時間。SQL Server Agent 不是開發平台,因此未提供類似的功能。

如需有關 Notification Services 的詳細資訊,請參閱<SQL Server Notification Services 簡介>。

是否可以在一部伺服器上執行多個通知應用程式?

是。請部署 Notification Services 的執行個體;每個執行個體都可以主控一或多個應用程式。您可以在一部伺服器上執行多個執行個體,也可以在一部伺服器執行多個版本的 Notification Services。

若要判定一部伺服器該執行多少個應用程式,必須查看每個應用程式可能會對伺服器造成多大的處理負荷。如果在一部伺服器上執行過多應用程式,效能會降低。

如需詳細資訊,請參閱<規劃 Notification Services 系統>。

由事件產生通知,要花多長的時間?

首先,並非所有的訂閱都屬於事件觸發類型。有些訂閱會指定通知的排程。在這個情況下,通知是依照定義的排程來傳送,而不是在事件到達的時候傳送。

若為事件觸發型的通知,從事件發生到傳遞通知之間的延遲,大部份視應用程式的設計而定。以下是通知延遲的原因:

  • 事件必須提交給 Notification Services。從事件發生到事件提供者以事件批次為單位提交事件之間所花的時間,是造成延遲的一個原因。
  • 產生器是按產生器 QuantumDuration 屬性值決定的排程來工作。如果配量持續時間是 60 秒,那麼使用事件批次來建立通知之前,可能會有 60 秒的延遲。
  • 產生器必須將事件對應至訂閱,以產生通知。對應是由一或多個 Transact-SQL 查詢來執行。這些查詢的效能決定產生通知的相關延遲。一般來說,一次評估的事件和訂閱愈多,這個處理序所花的時間就愈長。最佳化的規則和選擇適當的索引可縮短對應的延遲。
  • 散發者是按散發者 QuantumDuration 屬性值決定的排程來工作。如同產生器,如果配量持續時間是 60 秒,散發者處理通知批次之前,可能會有 60 秒的延遲。
  • 散發者必須將通知格式化和封裝,以傳遞通知。格式化是由內容格式器物件來執行。複雜的格式化會比簡易的格式化耗時,且將已格式化的通知傳送給傳遞服務也要花費一些時間。例如,將通知公佈到 HTTP 伺服器可能會耗時達 30 秒。

散發者傳送通知到傳遞服務 (如 Simple Mail Transfer Protocol (SMTP) 伺服器) 之後,Notification Services 便無法再控制傳送通知的延遲。

是否必須安裝 Microsoft Visual Studio 2005 才能開發 Notification Services 應用程式?

否,Microsoft Visual Studio 不是必要的,但它可簡化開發工作。

若要開發使用標準事件提供者和內容格式器的應用程式,可建立 XML 應用程式定義檔案 (ADF),再建立 XML 執行個體組態檔 (ICF) 來定義主控應用程式的執行個體,即可建立應用程式。您可以使用任何文字或 XML 編輯器來建立這些 XML 檔案。

若要使用 Notification Services Management Objects (NMO) 建置應用程式,或是要建置訂閱管理介面、自訂事件提供者和內容格式器,可以使用 Visual Studio 開發環境來建立這些物件。然而,不是一定要使用 Visual Studio。您可以使用任何文字編輯器來撰寫程式碼,此外必須安裝 Microsoft .NET Framework SDK 來編譯程式碼。

主控的事件提供者和非主控的事件提供者的相對優點為何?

實作主控的事件提供者通常需要的開發工作較少,原因是 Notification Services 執行個體可載入 Notification Services API 並維護用來啟動事件提供者的排程。主控的事件提供者和其他 Notification Services 元件和服務一樣,也可以啟用、停用。

如果您現有的基礎結構能夠提交事件 (如顧客關係管理應用程式或 Web 應用程式),可以使用非主控的事件提供者。非主控的事件提供者僅列入應用程式定義檔案 (ADF),以便訂閱類別參考。

我已擁有以未管理的程式碼所撰寫的訂閱管理應用程式。我可以從我的應用程式呼叫你們的 API 嗎?

Notification Services 支援簡單訂閱的 COM Interop。然而,因為 Microsoft.SqlServer.NotificationServices.Rules 命名空間中的類別不支援 COM Interop,無法使用 COM Interop 建立條件式訂閱。

如需詳細資訊,請參閱<COM Interop (含 Notification Services)>。

請參閱

工作

解析常見 Notification Services 問題
設定 Notification Services 事件記錄
使用事件訊息

說明及資訊

取得 SQL Server 2005 協助