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