1、 不合理的大表全表掃描
詳見：點擊打開鏈接
v$session_longops視圖記錄了超過6秒的所有
SQL語句
這其中絕大部是全表掃描的語句！
2、 語句共享性不好
常出沒在OLTP，由于app沒有合理使用綁定變量，導致大量重復的語句Parse，浪費大量的shared pool，使CPU利用率居高不下
3、 過量的排序操作
有個原則：能不排序就不排序
特別是multi-pass，與事務設計、缺乏索引、優化器的選擇等均有關系
4、 大量遞歸SQL語句
由sys執行，以大量的空間管理sql語句為甚
常見于大數據處理
作為DBA，大數據處理前，主動進行存儲空間的分配
5、 優化器和統計信息
代碼有時候，在
測試環境能跑，到了生產環境就“萎”了
這是因為，生產環境沒有及時采集統計信息，導致
Oracle優化器不了解最新的數據和應用情況，而錯誤地選擇了非優化的執行路徑
所以，我們需及時采集統計信息，保證基于CBO的優化器能歡快運行
6、 不合理的參數設置
系統參數一定要調，還要合理地調
主要是些內存參數、進程參數等
7、 存儲部署不合理
由于存儲部署不合理導致I/O效率低下
處理方案：ASM、RAID10等
主要是C/S結構比較常見，幾乎絕跡于B/S了
9、 Redo Log 設計不合理
Redo log文件設計太小，頻繁觸發checkpoint事件，導致內存緊張和I/O繁忙
Redo log文件文件組太少，則可能使歸檔無法趕上redo entries產生的速度