優化數據訪問層

我有一個Web服務（JAX-RS/Spring），它可以生成針對Oracle中臨時表運行的SQL查詢。然後將數據存檔到另一個表格（通過3個MERGE語句）。每個「作業」（查詢和合並）的執行都是通過JMS代理（ActiveMQ）在後臺完成的。每個作業的操作順序如下：優化數據訪問層

insert/update into table Q (select from table F) -- done between 4 and 20 times 
    merge into table P (select from table Q) -- twice 
    merge into table P (select from table F) 
    merge into table P (select from table F) 
    create a view V as select from table P

（表Q是一張臨時表）。

當我派遣兩個或三個這樣的工作時，每個工作執行需要大約6-7分鐘。但是當我同時派遣多達15人的時候，這段時間延長了。

這是因爲所有這些進程都試圖插入/更新到臨時表Q？從而爭取資源？我應該注意哪些技術來優化這一點？例如，我想過爲表Q創建5或6個重複項，並且「負載均衡」是針對它們的數據訪問對象查詢。

感謝

來源

2010-09-09 wsb3383

當我派兩級三個類似的職位的是，它需要6-7分鐘每個作業執行。但是當我調度多達15運行在相同的時間，持續時間延長方式更長。

有任何數量的資源您的進程可以爭奪，而不僅僅是臨時表。

對於初學者，您的數據庫有多少個處理器（CPU /內核）？有一個非常好的經驗法則，我們不應該在每個處理器上運行超過1.8個後臺作業。因此，如果您沒有足夠的處理器來支持高度的並行性，那麼擔心克隆臨時表是沒有意義的。

調整的關鍵是：不要猜測。與其他一些數據庫管理系統產品不同，甲骨文公司擁有大量的儀器，我們可以利用這些儀器準確找出時間。它被稱爲等待接口。這並不完美，但比盲目重新設計數據庫模式要好得多。 Find out more.

來源

2010-09-09 19:23:21 APC

+1不錯的答案，尤其是「不要猜」的建議 – DCookie 2010-09-09 20:58:28

如果Q實際上是一個臨時表（如在GLOBAL TEMPORARY TABLE中那樣），那麼每個會話將有一個單獨的物理對象，因此它們不會爭用鎖或在數據級別。

您更可能爭用永久表P或服務器資源（內存和磁盤）上。

來源

2010-09-09 23:36:50

優化數據訪問層

回答

相關問題