2010-04-19 63 views
2

我正在使用Oracle數據庫的兩個實例,將它們分別稱爲onetwotwo運行在比one更好的硬件(硬盤,內存,CPU)上,並且two是根據Oracle版本(均爲11g)在one之後的一個次要版本。兩者都有完全相同的表table_name,其索引完全相同。我在兩個實例上加載了500,000個相同的行到table_name。我再運行,在這兩種情況下:兩個Oracle數據庫實例之間的主要性能差異

delete from table_name; 

這個命令需要30秒才能完成對one 40分鐘才能完成的two。對兩個表執行INSERT和UPDATE具有類似的性能差異。有沒有人有什麼建議可以對兩個數據庫之間的性能產生如此嚴重的影響?

+1

任何活動對於未來的讀者,它看起來像這個問題是關係到Oracle的審計記錄。有關日誌記錄進程和正在使用的磁盤在其中一個實例上未正確配置。 – jrdioko 2010-04-27 21:52:48

回答

2

如果你可以監視訴WAIT_CLASS和事件列$ session的刪除會話你會得到一個關於延遲原因的線索。一般來說,我希望一個完整的表DELETE被磁盤綁定(一個等待類指示I/O或可能的配置)。它必須從表中讀取數據(因此它知道要刪除的內容),更新數據塊和索引塊以刪除爲UNDO表空間和重做日誌生成大量條目的條目。

在生產環境中,底層文件可能分佈在多個磁盤(甚至是SSD)上。開發/測試環境可能讓它們全都卡在一個設備上,並且磁盤上的大量磁頭移動會減慢速度。我可以看到跳過一個SQL可能是十倍。你的情況比這還糟糕。

如果在表[併發的wait_class]上有併發活動(例如其他會話插入),您可能會獲得鎖定爭用或會話都試圖敲擊索引。

3

我首先比較V $ PARAMETER ORDER BY NAME中的實例配置 - SELECT NAME,VALUE,並將結果假脫機爲兩個實例的文本文件,並使用一些文件比較工具來突出區別。應該調查由於數據庫名稱和文件位置而產生的差異以外的任何內容。極端情況可能是一個數據庫沒有歸檔日誌記錄,另一個數據庫定義了5個歸檔目的地。

如果您沒有訪問數據庫主機上的文件系統的權限,請查找某人並讓他們從您開始會話時獲取跟蹤文件和tkprof結果,ALTER SESSION SET sql_trace = true,然後執行您的操作刪除。這將會使任何遞歸SQL由於在桌子上的觸發器(可能是你自己),審計等

1

請注意:我不是一個DBA ...

我有以下幾點寫在我辦公窗口:

在緊急情況下,要求隨叫隨到DBA到:

  1. 檢測計劃
  2. 運行統計
  3. 沖洗共享緩衝池

號碼2和/或3正常修復查詢其工作在一個數據庫中而不是其他或工作昨天而不是今天....

相關問題