在Oracle中使用BizTalk Server接收數據庫更改通知

Question

我已經在Oracle中使用BizTalk實現了數據庫更改通知概念，但是我沒有收到RowId，這是我發生任何更改時的主要字段。我得到的輸出如下，

怎樣才能行ID？

第二個問題是，只要任何變化都發生在我的數據庫中的通知是不是來之前，除非我運行下面的查詢在我的數據庫

grant change notification to UserName 

我怎樣才能使這些權限堅持？

Answer 1

選項3是您需要啓用的選項。

從Registration Properties與數據庫更改通知開發應用程序

註冊屬性

Oracle數據庫支持的對象註冊下列選項：

1. 清除在通知選項：註銷後首先更改通知。

2. 超時選項：指定時間間隔後的註冊過期。

3. ROWID s選項：ROWID更改的行是通知ROWID選項的一部分。

4. 可靠通知選項：默認情況下，通知在共享內存中生成。如果選擇此選項，則會在持久數據庫隊列中生成通知。通知以原子方式與改變註冊對象的事務排隊。由於通知在數據庫中是持久的，因此如果實例在生成通知後崩潰，則可以在後續重新啓動時或在運行RAC時由羣集的正常實例重新傳遞它們。 （注意：在通知性能和可靠性之間存在折衷，因爲在生成可靠通知時存在CPU和I/O成本，如果需要更好的通知性能，建議選擇默認的內存選項）。

5. 操作過濾器：能夠通知特定操作（例如，僅針對INSERT和UPDATE的通知）。

6. 交易滯後：指定連續通知之間的計數。

如果選擇了ROWID選項，則更改的行的ROWID將作爲通知的一部分發布。 ROWID以外部字符串格式發佈。從通知中的ROWID信息中，應用程序應該隨後能夠通過執行「SELECT * from table_name_from_notification where ROWID = rowid_from_notification」形式的查詢來檢索已更改行的內容。在常規堆表中，ROWID的長度爲18個字節。在索引組織表（IOT）的情況下，ROWID的長度取決於主鍵的大小，因此可能大於18個字節。

ROWID通知是分層次彙總的。如果在服務器端沒有足夠的內存來保存ROWID，那麼通知可能會被彙總爲FULL-TABLE-NOTIFICATION（通知描述符中的特殊標記保留用於此目的）。當收到這樣的通知時，應用程序必須保守地假定整個表（即所有行）可能已被修改。 ROWID不是這種通知的一部分。如果由於ROWID導致的總共享內存消耗太大（超過動態共享池大小的1％），或者如果在事務中的單個註冊對象中修改了太多的行（超過80個大約），則可能會滾動ROWID ）或者如果IOT的修改行的邏輯ROWID的總長度太大（大約超過1800字節）。