甲骨文SYS.AUD $/dba_audit_session監控 - 優化SQL性能

Question

我有以下查詢，監視是否有人試圖與數據庫技術的用戶登錄：

SELECT COUNT (OS_USERNAME) 
FROM DBA_AUDIT_SESSION 
WHERE USERNAME IN ('USER1','USER2','USER3') 
AND TIMESTAMP>=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 

不幸的是這SQL的性能是相當的差因爲它在sys.aud $上執行TABLE ACCESS FULL。我試圖縮小它：

SELECT COUNT (sessionid) 
FROM sys.aud$ 
WHERE userid   IN ('USER1','USER2','USER3') 
AND ntimestamp# >=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 
and action# between 100 and 102; 

而且更糟。是否有可能通過強制oracle在這裏使用索引來優化該查詢？我將不勝感激任何幫助&提示。

Answer 1

SYS.AUD $沒有任何默認索引，但可以在ntimestamp#上創建一個。

但請謹慎行事。支持文件「影響的創建索引的表SYS.AUD $（文檔ID 1329731.1）」包括這樣的警告：

創建於SYS對象的其他指標，包括表AUD $不支持。

通常情況下，這將是談話的結束，你會想嘗試另一種方法。但在這種情況下，有幾個原因值得一試：

1. 該文件繼續說，索引可能會有所幫助，並首先進行測試。
2. 這只是一個索引。 SYS模式很特殊，但我們仍然只是在討論表上的索引。它可能會減慢速度，或者可能會導致空間錯誤，就像任何索引一樣。但我懷疑它有可能做一些瘋狂的事情，比如導致錯誤的結果錯誤。
3. 更改審計跟蹤的表空間有點常見，所以表不是神聖的。
4. 我以前見過它的索引。我管理的400個數據庫中有2個在列SESSIONID,SES$TID上有索引（儘管我不知道爲什麼）。這些指標已經存在多年，已經通過升級和補丁，並且據我所知沒有造成問題。

如果您願意測試並接受少量風險，那麼創建一個「不受支持」的索引對您來說可能是一個不錯的選擇。

Answer 2

如果您編寫了適當的連接，Oracle 10g以上的優化器會爲您的查詢選擇最佳計劃。不確定您的DBA_AUDIT_SESSION中有多少個重新對象存在，但您始終可以使用PARALLEL提示來加快執行速度。

SELECT /*+Parallel*/ COUNT (OS_USERNAME) 
--select COUNT (OS_USERNAME) 
FROM DBA_AUDIT_SESSION 
WHERE USERNAME IN ('USER1','USER2','USER3') 
AND TIMESTAMP>=SYSDATE - 10/(24*60) 
AND RETURNCODE !='0' 

查詢成本降低到3以前。

Answer 3

NumRows：8080019

所以它是相當大的，由於公司的規定。不幸的是，在這裏使用/*+Parallel*/使其運行時間更長，因此性能仍然更差。

其他建議？