A. 請問Oracle如何優化緩沖區
（1）獲取緩沖區活動情況
為了Oracle優化緩沖區，首先應了解緩沖區的活動情況。這可以通過查詢動態性能表（需有SELECT ANY TABLE特權)V$SYSSTAT來獲得。
1.SVRMGR select name ,value from v$sysstat
2.2 where name in('db block gets','consistent gets','physical reads');
3.NAME VALUE
4.db blockgets 3437
5.consistent gets 30500
6.physica reads 1963
7.3 rows selected.
其中，「db block gets」和「consistent gets」的值是請求數據緩沖區中讀的總次數。「physical reads」為請求數據時引起從盤中讀文件的次數。
（2）緩沖區命中率
從緩沖區讀的可能性的高低稱為緩沖區命中率。它可用如下公式計算：Hot Ratio＝1-(physical reads／(db block gets＋consistent gets)
緩沖區命中率越高，其速度就越快。如果命中率低於60％或70％時。則應增加緩沖區(即DB_BLOCK_BUFFERS)，以改進性能。根據公式可以計算出本例中的Hot Ratio=1-(1963/(3437+30500)=92％。如果緩沖區的命中率很高，希望在保持良好性能下適當減少緩沖區，這時可減少DB_BLOCK_BUFFERS的值，其最小值為4。
當一個文件上的輸入/輸出(I/O)請求干擾了第二個文件的輸入/輸出請求時，那麼這兩個文件就會發生爭用。所以兩個隨機存取的文件只有在無可能同時存取它們時，才可以存放在同一設備中。由此可以分為兩種類型的I/O爭用：並行I/O爭用和干擾爭用。並行I/O爭用多發生在同一時間對同一設備請求多種存取時，這種類型的爭用可以通過分離與表相聯系的索引的辦法來消除。干擾爭用發生在對一個順序文件進行寫操作而同時進行讀命令時中斷而引起。
I/O優化的目的是解決I/O瓶頸問題，I/O的優化必須在內存優化之後進行，可以通過減少磁碟爭用、有效分配數據塊空間和避免動態空間管理三個方面來優化I/O。
減少磁碟爭用
V$FILESTAT視圖提供有關物理讀寫的信息。物理I/O針對磁碟，邏輯I/O針對內存。如果有多個進程同時訪問同-磁碟，就產個磁碟爭用。
監控Oracle的磁碟活動
要解決磁碟爭用，首先應該知道磁碟的活動情況，確定是否發生爭用。這可以通過查詢動態性能表(需有SELECT ANY TABLE特權)V$FILESTAT和V$DATAFILE來確定。例如：
1.SQLSELECT Name，phyrds，phywrts
2.FROM V$DATAFILE df，V$FILESTAT fs
3.WHERE df.file#＝fs.file#；其中：◆ phyrds：記錄從盤上讀每個資料庫文件的次數。
◆ phywrts：記錄往盤上寫資料庫文件的次數。
一個盤上總的I/O次數是該盤上所有資料庫文件的phyrds和phywrts之和。必須把物理讀寫的總量控制在用戶硬體和操作系統的最優限制內。
B. 究竟怎麼理解Oracle中的物理讀，邏輯讀，即時讀，一致讀和讀一致性
1. 物理讀
這個很容易理解，cpu需要的數據在內存中找不到，那麼此時必須去物理磁碟上獲取，必然產生物理i/o。
反應在oracle中，就是會話需要某條數據時，在內存的buffer cache中中沒有，此時就要去磁碟上的dbf文件中讀取。就產生物理讀。
2. 邏輯讀
這個概念是最清晰，但同時又是最模糊的。
按照計算機原理來講，邏輯讀，表示cpu需要的數據在內存中被找到，數據被直接從內存中傳入cpu執行。
3. 即時讀（又叫當前讀）
按照tom大師的描述：
當前讀（Current read）：得到塊來實際更新所要修改的行時，所完成的獲取就是當前讀。
這么話怎麼理解？
A：讀塊的時候要加鎖。如果讀塊的目的是為了定位行、然後修改，這時加的鎖和純讀的鎖並不一樣，雖然它們兩個都是讀操作。
因為加的鎖不同，就有了當前讀和一致讀。
4. 一致讀
按照tom大師的描述：
一致讀（Consistent read）：「發現」要修改的行時，所完成的獲取就是一致讀。
這么話怎麼理解？
A：一致讀和當前讀放在一起時，一致讀指的純讀。
5. 讀一致性
這個概念，無庸置疑。
讀一致性：Oracle在需要時會使用undo數據來構造CR塊，從而提供非阻塞的查詢。
C. oracle怎麼優化
1.去掉不必要的大型表的全表掃描
2.緩存小型表的全表掃描
3.檢驗優化索引的使用
4.檢驗優化的連接技術
5.盡可能減少執行計劃的Cost
在含有子查詢的SQL語句中,要特別注意減少對表的查詢.例子：
SELECT EMP_NO FROM EMP WHERE (GROUP,NAME) = ( SELECT
COLUMN1,COLUMN2 FROM TEST WHERE TEST_ID = 604)
最高效的刪除重復記錄方法 ( 因為使用了ROWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
sql語句用大寫的；因為oracle總是先解析sql語句，把小寫的字母轉換成大寫的再執行
在java代碼中用到preparedStatement的時候盡量少用連接符「＋」連接字元串！
D. oracle 伺服器訪問速度慢 硬碟讀寫100% 怎麼辦
具體診斷oracle性能 查看AWR報告，抓出高物理讀的SQL 針對性優化
E. 怎樣優化Oracle資料庫
對於經常操作的表建視圖，對數據量較大的建索引。
F. oracle的sql 優化了邏輯讀是否就能降低耗時
邏輯讀就是從內存中(db buffer cache)讀。
SQL執行過程中，如果發生物理讀，將dbf的數據載入到內存，這一步顯然是非常耗時的。
所以上面的說法是錯誤的。
我們總是希望邏輯讀越多越好，畢竟從內存讀的速度要遠遠大大於從硬碟讀
G. oracle IO 讀寫高，怎麼優化
兩個辦法：一、優化硬體（CPU、內存和硬碟等），優化I/O子系統，增強IO讀寫能力；第二、優化SQL語句。第一種辦法治標不治本，建議用第二種辦法，你的截圖里邊那幾個幾百秒的SQL語句是有問題的，要進一步優化。查看一下執行這些語句是在哪些頁面，查詢了什麼數據，數據量多大，判斷一下業務邏輯，然後再去優化。
（如有幫助，請採納，謝謝）
H. oracle表如何優化
原則一：注意WHERE子句中的連接順序：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾.
尤其是「主鍵ID=？」這樣的條件。
原則二： SELECT子句中避免使用 『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間 。
簡單地講，語句執行的時間越短越好（尤其對於系統的終端用戶來說）。而對於查詢語句，由於全表掃描讀取的數據多，尤其是對於大型表不僅查詢速度慢，而且對磁碟IO造成大的壓力，通常都要避免，而避免的方式通常是使用索引Index。
使用索引的優勢與代價。
優勢：
1）索引是表的一個概念部 分,用來提高檢索數據的效率，ORACLE使用了一個復雜的自平衡B-tree結構. 通常,通過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引. 同樣在聯結多個表時使用索引也可以提高效率.
2） 另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗證.。那些LONG或LONG RAW數據類型, 你可以索引幾乎所有的列. 通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小表時,使用索引同樣能提高效率.
代價： 雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價. 索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁碟I/O . 因為索引需要額外的存儲空間和處理,那些不必要的索引反而會 使查詢反應時間變慢.。而且表越大，影響越嚴重。
使用索引需要注意的地方：
1、避免在索引列上使用NOT ，
我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE」遇到」NOT,他就會停止使用索引轉而執行全表掃描.
2、避免在索引列上使用計算．
WHERE子句中，如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描． 舉例:
低效:SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:SELECT … FROM DEPT WHERE SAL > 25000/12;
3、避免在索引列上使用IS NULL和IS NOT NULL
避 免在索引中使用任何可以為空的列，ORACLE性能上將無法使用該索引．對於單列索引，如果列包含空值，索引中將不存在此記錄. 對於復合索引，如果每個列都為空，索引中同樣不存在此記錄.如果至少有一個列不為空，則記錄存在於索引中．舉例: 如果唯一性索引建立在表的A列和B列上, 並且表中存在一條記錄的A,B值為(123,null) , ORACLE將不接受下一條具有相同A,B值（123,null）的記錄(插入). 然而如果所有的索引列都為空，ORACLE將認為整個鍵值為空而空不等於空. 因此你可以插入1000 條具有相同鍵值的記錄,當然它們都是空! 因為空值不存在於索引列中,所以WHERE子句中對索引列進行空值比較將使ORACLE停用該索引.
低效:(索引失效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效:(索引有效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;
4、注意通配符%的影響
使用通配符的情況下Oracle可能會停用該索引。如 :
SELECT…FROM DEPARTMENT WHERE DEPT_CODE like 『%123456%'（無效）。
SELECT…FROM DEPARTMENT WHERE DEPT_CODE = 『123456'（有效）
5、避免改變索引列的類型.:
當比較不同數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.
假 設 EMPNO是一個數值類型的索引列. SELECT … FROM EMP WHERE EMPNO = 『123' 實際上,經過ORACLE類型轉換, 語句轉化為: SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(『123') 幸運的是,類型轉換沒有發生在索引列上,索引的用途沒有被改變. 現在,假設EMP_TYPE是一個字元類型的索引列. SELECT … FROM EMP WHERE EMP_TYPE = 123 這個語句被ORACLE轉換為: SELECT … FROM EMP WHERETO_NUMBER(EMP_TYPE)=123 因為內部發生的類型轉換, 這個索引將不會被用到! 為了避免ORACLE對你的SQL進行隱式的類型轉換, 最好把類型轉換用顯式表現出來. 注意當字元和數值比較時, ORACLE會優先轉換數值類型到字元類型
6、索引的一些「脾氣」
a. 如果檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提高.
b. 在特定情況下, 使用索引也許會比全表掃描慢, 但這是同一個數量級上的區別. 而通常情況下,使用索引比全表掃描要塊幾倍乃至幾千倍!
除了使用索引，我們還有其他能減少資源消耗的方法：
1、用EXISTS替換DISTINCT：
當提交一個包含一對多表信息(比如部門表和雇員表)的查詢時,避免在SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換, EXISTS 使查詢更為迅速,因為RDBMS核心模塊將在子查詢的條件一旦滿足後,立刻返回結果.
例子:
(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
WHERE D.DEPT_NO = E.DEPT_NO
And E.sex =man
(高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT D
WHERE EXISTS
( SELECT 『X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO
And E.sex =man
);
2、用(UNION)UNION ALL替換OR (適用於索引列)
通常情況下, 用UNION替換WHERE子句中的OR將會起到較好的效果. 對索引列使用OR將造成全表掃描.
注意, 以上規則只針對多個索引列有效. 如果有column沒有被索引, 查詢效率可能會因為你沒有選擇OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引.
如果你堅持要用OR, 那就需要返回記錄最少的索引列寫在最前面.
高效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION ALL
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = 「MELBOURNE」
低效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = 「MELBOURNE」
3、用UNION-ALL 替換UNION ( 如果有可能的話)：
當 SQL語句需要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合並, 然後在輸出最終結果前進行排序. 如果用UNION ALL替代UNION, 這樣排序就不是必要了. 效率就會因此得到提高. 需要注意的是，UNION ALL 將重復輸出兩個結果集合中相同記錄. 因此各位還是要從業務需求分析使用UNION ALL的可行性. UNION 將對結果集合排序,這個操作會使用到SORT_AREA_SIZE這塊內存. 對於這塊內存的優化也是相當重要的.
4、Order By語句加在索引列，最好是主鍵PK上。
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE（低效）
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_CODE （高效）
5、避免使用耗費資源的操作:
帶 有DISTINCT,UNION,MINUS,INTERSECT的SQL語句會啟動SQL引擎 執行耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫. 如果你的資料庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強
6、使用Where替代Having（如果可以的話）
優化GROUP BY:
提高GROUP BY 語句的效率, 可以通過將不需要的記錄在GROUP BY 之前過濾掉.下面兩個查詢返回相同結果但第二個明顯就快了許多.
低效:
SELECT JOB , AVG(SAL)
FROM EMP GROUP JOB HAVING JOB = 『PRESIDENT'AND AVG(SAL)>XXX
高效:
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = 『PRESIDENT'
OR JOB = 『MANAGER' GROUP JOB Having AND AVG(SAL)>XXX
7、通常來說，如果語句能夠避免子查詢的 使用，就盡量不用子查詢。因為子查詢的開銷是相當昂貴的。具體的例子在後面的案例「一條SQL的優化過程」中。
I. 如何優化 物理讀的sql
物理讀和預讀都是IO操作，都是需要從磁碟中讀取數據到內存，只是讀取的時間有所不同。
1.預讀是在生成執行的同時去做的，通過這種方式可以提高IO的性能。
2.物理讀是當執行計劃生成好後去緩存讀取數據發現缺少數據之後才到磁碟讀取。當所有數據都從緩存中可以讀取就變成邏輯讀。