2013-02-19 40 views
0

如果我們使用Oracle Row Level Security(RLS)隱藏一些記錄 - 是否有任何性能影響 - 它會減慢我的SQL查詢嗎?爲此的Oracle包是:DBMS_RLS。使用(DBMS_RLS)Oracle行級別安全性(RLS)的性能影響?

我打算在一些表格中添加:IS_HISTORICAL = T/F。然後使用RLS隱藏具有IS_HISTORICAL = T值的記錄。

我們在應用程序中使用SQL查詢是相當複雜的,有內/外部連接,子查詢,相關子查詢等

200多桌,其中約50都會有這樣的RLS政策(隱藏記錄由IS_HISTORICAL = T)應用於它們。其餘的150個表是這50個表中的子表,因此RLS隱含在它們上面。

任何許可證含義?

謝謝。

+0

取決於您的上下文級別,但靜態上下文(例如)不會成爲性能問題的原因(VPD本身不會比執行select操作的應用程序更慢* ...其中is_historical ='N' ...)。 – tbone 2013-02-19 13:48:07

回答

2

「是否有任何性能影響 - 將它減慢我的SQL查詢 ?」

與有關性能的所有問題的答案是,「這取決於」。 RLS的工作原理是在適用的政策功能作爲一個WHERE子句的外部查詢包裹的控制查詢...

select /*+ rls query */ * from ( 
    select /*+ your query */ ... from t23 
    where whatever = 42) 
where rls_policy.function_t23 = 'true' 

所以對性能的影響完全依靠在功能上發生的事情。

做這些事的正常方法是使用上下文命名空間。這些是通過SYS_CONTEXT()函數訪問的會話內存的預定義區域。因此,從上下文中檢索存儲值的成本可以忽略不計。正如我們通常在每個會話中填充名稱空間一樣 - 比如通過登錄後觸發器或類似的連接鉤子 - 每個查詢的總體成本是微不足道的。有不同的方法可以刷新名稱空間,這可能會影響性能,但這些在事務的整體方案中也是微不足道的(see this other answer)。

所以性能影響取決於你的功能實際上做了什麼。這給我們帶來一個考慮您的實際政策:

「這RLS政策(來隱藏IS_HISTORICAL = T記錄)」

好消息是這樣的功能的執行被本身不太昂貴。壞消息是表現可能仍然是Teh Suck!無論如何,如果現場記錄與歷史記錄的比例是不利的。您可能最終將檢索所有記錄,然後過濾出歷史記錄。優化器可能會將RLS謂詞推入主查詢中,但我認爲這不太可能,因爲RLS的工作方式是:它避免將策略的標準暴露給普通注視(這使得調試RLS操作成爲一個真正的PITN)。

您的用戶將支付您糟糕的設計決定的價格。使用日誌或歷史表存儲舊記錄並僅保留實際表中的實時數據要好得多。將歷史記錄與現場記錄一起保存,很少成爲一個可擴展的解決方案。

「任何許可證含義?

DBMS_RLS需要企業版許可證。

+0

APC>非常豐富的答覆,謝謝。我們將根據IS_HISTORICAL列對錶格進行分區,以便將歷史記錄分離出來,並且oracle可以進一步對其進行優化。由於這個原因,沒有考慮單獨的歷史表格方法,並且還會創建和維護數百個歷史表格。 – Jasper 2013-02-19 09:57:30

+0

你有沒有基準測試方法?因爲我不知道分區修剪是否會在你希望的時候啓動。 – APC 2013-02-19 10:59:19