① Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障，簡單地講就是資料庫實例不能響應客戶端發起的請求，客戶端提交一個SQL後，就一直處於等待資料庫實例返回結果的狀態。更嚴重的現象是客戶端根本不能連接到資料庫，發起一個連接請求後，一直處於等待狀態。Oracle資料庫無響應故障怎麼處理呢?下面跟我一起來學習Oracle資料庫無響應故障的處理方法吧!
無響應的故障現象一般有以下幾種：
1.Oracle的進程在等待某個資源或事件
這種現象一般可以從V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等動態視圖中檢查進程正在等待的資源或事件，而被等待的資源或事件，一直都不能被獲取，甚至是很長時間都不可獲得。如果這個正在等待的進程持有了其他的資源，則會引起其他的進程等待，這樣就很可能引起實例中大范圍的會話發生等待。由於進程在等待資源或事件時，通常都處於SLEEP狀態，消耗的CPU資源非常少(在等待latch時要稍微多消耗一些CPU資源)，所以從OS來看，CPU的消耗並不高，甚至是非常低。
這種因為等待而引起的個別進程Hang，相對比較容易處理。
2. OracleProcess Spins
所謂Spin，就是指Oracle進程中的代碼在執行某個過程時，陷入了循環。在V$SESSION視圖中，往往可以看到Hang住的會話，一直處於“ACTIVE”狀態。對於這樣的會話，用“alter system kill session ‘sid,serial#’”命令也不能完全斷開會話，會話只能被標記為“killed”，會話會繼續消耗大量的CPU。進程Spins由於是在做循環，CPU的消耗非常大，從OS上明顯可以看到這樣的進程，通常會消耗整個CPU的資源。
而對於這樣的Hang住的會話，處理起來相對比較復雜，並且為了從根本上解決問題，需要超過DBA日常維護所需要的技能。
從故障范圍來看，無響應故障可以分為以下幾種情況：
1. 單個或部分會話(進程)Hang住
這種情況屬於小范圍的故障，業務影響相對較小，一般來說只會影響業務系統的個別模塊。在一個多應用系統的資料庫上面，如果Hang住的會話比較多，則影響的可能是其中的一個應用系統。這里有一個例外，如果Hang住的進程是系統後台進程，如pmon、smon等，則影響的范圍就非常大了，最終甚至會影響整個資料庫及所有應用系統。還有值得注意的是，即使是少部分會話Hang住，也要及時處理，否則極有可能會擴散到整個系統。
2. 單個資料庫實例Hang住
這種情況造成的影響非常大。在這個實例上的所有應用系統均受到嚴重影響，並且在找到根源並最終解決問題之前，資料庫實例往往須要重啟。
3. OPS或RAC中的多個實例或所有實例都Hang住
在這種情況下，即使是OPS或RAC，都已經沒辦法提供高可用特性了。使用這個資料庫的所有應用系統將不能繼續提供服務，這種情況往往須要重啟。
無響應故障成因分析
Oracle資料庫無響應，一般主要由以下幾種原因引起：
1. 資料庫主機負載過高，嚴重超過主機承受能力
比如應用設計不當，資料庫性能低下，活動會話數的大量增加，導致資料庫主機的負載迅速增加，資料庫不能正常操作，並最終Hang住;主機物理內存嚴重不足，引起大量的換頁，特別是在SGA中的內存被大量換出到虛擬內存時，資料庫實例往往就會Hang住。
2. 日常維護不當、不正確的操作引起資料庫Hang住
比如歸檔日誌的存儲空間滿，導致資料庫不能歸檔，引起資料庫Hang住;在一個大並發的繁忙的系
統上，對DML操作比較多的大表進行move、增加外鍵約束等操作也可能使系統在短時間內負載大幅升高，並引起資料庫系統Hang住;不正確的資源計劃(Resource Plan)配置，使進程得不到足夠的CPU等。
3. Oracle資料庫的Bug
幾乎每個版本都存在著會導致資料庫系統Hang住的Bug，這些Bug會在一些特定的條件下觸發，特別是在RAC資料庫中，引起資料庫Hang住的Bug比較多。
4. 其他方面的一些原因
比如在RAC資料庫中，如果一個節點退出或加入到RAC的過程中，當進行Resource Reconfiguration時，會使系統凍結一段時間，也有可能使系統Hang住。
以上所描述的幾種常見的會導致Oracle資料庫實例Hang住的原因中，大部分的情況是可以避免的，只要維護得當，一般不會出現這種故障。對於Oracle資料庫Bug所導致的資料庫無響應故障，由於是在特定的情況下才會觸發，所以如果能夠盡量對資料庫打上最新版本的補丁，並且熟悉當前版本中會導致系統Hang住的Bug以及觸發條件，就能夠最大限度地避免這種故障的發生，提高系統的可用性。
那麼，在資料庫Hang住的情況下，如何去分析並發現導致問題的根源?一方面，由於系統Hang住會導致業務系統不可用，為了能夠盡快地恢復業務，須快速地判斷問題所在，然後Kill掉引起故障的會話和進程，或者資料庫實例不得不重啟以迅速恢復業務;但另一方面，如果只是重啟資料庫或Kill會話和進程來解決問題，在很多情況下是治標不治本的辦法，在以後故障隨時可能會出現。如何在二者之間進行抉擇呢?對於資料庫Hang故障的處理，首先是盡可能地收集到系統Hang住時的狀態數據，然後盡快地恢復業務，恢復業務後分析收集到的數據，找到資料庫系統Hang住的真正原因，然後再進行相應的處理。下一節將詳細描述資料庫系統Hang住後的處理流程。
無響應故障處理流程
對於Oracle無響應故障的處理，我們可以按下圖所示的流程進行。
值得注意的是，上圖並不是一個完整的Oracle資料庫故障處理流程圖，只是處理Oralce資料庫無響應這一類特定的故障的流程，只列出了針對這一特定類型故障處理時的關鍵處理點。不過既然是故障，所以這類故障的處理流程與其他故障的處理流程，有著非常相似的地方。
下面是整個流程的詳細說明：
1. 在出現資料庫無響應故障後，首先確認系統的影響范圍，如上節所描述的'，是部分業務系統或模塊還是所有的業務系統都受影響，是不是整個實例或多個實例都無響應。同時應詢問系統維護和開發人員，受影響的系統在出現故障前是否有過變動，包括主機硬體、操作系統、網路、資料庫以及應用等。有時一個細小的變動就可能導致出現資料庫Hang住這樣嚴重的故障。曾經遇到一個庫，應用只是修改了一個SELECT語句就導致了資料庫Hang住。
2. 為了避免由於網路、資料庫監聽或客戶端因素影響分析，建議都登錄到主機上進行操作。
3. 如果主機不能登錄(為了避免干擾流程主線，這里不討論如網路問題這樣也會導致不能連接的故障)，嘗試關閉出現問題的業務系統，甚至是所有的業務系統。如果關閉了所有的業務系統之後，仍然不能連接，則只有考慮重新啟動資料庫主機。在資料庫主機重新啟動後，使用操作系統工具或OSW等長期監控操作系統的資源使用，同時監控Oracle資料庫的性能和等待等。
4. 登錄上主機後，先用top、topas等命令簡單觀察一下系統。看看系統的CPU使用、物理內存和虛擬內存的使用、IO使用等情況。
5. 使用SQLPLUS連接資料庫，如果不能連接，則只能從操作系統上觀察系統中是否有異常的現象，比如佔用CPU過高的進程。使用gdb、dbx等debugger工具對資料庫進行system state mp;使用strace、truss等工具檢查異常進程的系統調用;使用pstack、procstack等工具察看異常進程的call stack等。
6. 使用SQLPLUS連接上資料庫後，進行hanganalyze、system state mp等操作;或檢查等待事件、異常會話等正在執行的SQL等待。
7. 找到故障產生的原因，如果暫時找不到原因，盡量收集數據。
8.確良如果應用急須恢復，可通過Kill會話、重啟資料庫實例等方式，先恢復應用。
9. 根據最終診斷結果，對資料庫升級打補丁，或者修改應用等方式從根本上解決問題。
怎樣避免資料庫出現無響應故障
作為Oracle資料庫DBA，除了處理故障之外，更重要的是如何預防故障的發生。根據前面對資料庫無響應故障的成因分析，在日常的維護工作中，須做到以下幾點：
1. 進行正確的維護操作
很多的資料庫無響應故障都是由於不正確的維護操作引起的。應避免在業務高峰期做大的維護操作，比如像move、加主外鍵約束等會長時間鎖表的操作。如果的確需要，盡量使用正確的操作方法。比如用ONLINE方式重建索引;建主鍵、唯一鍵約束時先建索引，然後在建約束時指定新建的索引，等等。也就是保證系統的並發性、可伸縮性，避免系統串列操作的出現。
2. 優化應用設計，優化資料庫性能
為避免性能問題導致在業務高峰期資料庫不能及時有效處理來自業務的請求，甚至於完全Hang住。對於資料庫中存在串列訪問的部分進行優化，比如latch、enqueue，還包括不合理的sequence設計等。特別是在RAC資料庫中，嚴重串列訪問等待往往更容易引起嚴重的性能問題。優化應用設計，使資料庫具有更好的可伸縮性和並行處理能力，能夠有效地避免性能問題引起的資料庫Hang住。
3. 利用監控系統隨時監控系統負載
遇到系統負載過高，內存不足，OS中虛擬內存換頁很頻繁等情況時，及時採取措施;監控Oracle資料庫的核心進程，如pmon、smon等，看是否有異常，如過高的CPU消耗。出現異常應立即處理;監控歸檔空間和日誌切換;監控資料庫中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 為資料庫打上補丁
很多的無響應故障是由於Oracle的Bug引起的，資料庫DBA應關注當前版本中有哪些Bug會導致資料庫Hang住，盡量為資料庫打上解決這些Bug的補丁。
;② Oracle 資料庫錯誤1053程序無響應
簡單說明一下：因為在建服務時我沒有沒有配置啟動參數。所以，服務啟動時在無參數的情況下，會進入「後台控制」類型的代碼。後台控制代碼會要求與桌面交互的，而默認服務是不能與桌面進行交互，肯定會出問題的。（沒看懂，也不要緊，畢竟您不必對此感興趣）。
只需要知道一點：是因為細節處理上的一個大意，急於部署服務，而忽略了此，導致花了大半天天的時間來找問題。很不值，所以，做事放慢節奏是很重要的。WIndows XP的服務中，有一個服務需要以NT AUTHORITY\NetworkService用戶啟動，使用本地系統帳戶啟動沒有任何問題，但如果以NetworkService即報此錯誤代碼。
如果你的系統分區是NTFS分區，應屬帳戶的許可權問題。
解決辦法：將NT AUTHORITY\NetworkService用戶添加到Administrator組中。
我的電腦-->右鍵-->管理-->本地用戶和組；
選擇「組」-->雙擊Administrators-->單擊「添加」-->單擊「高級」-->單擊「立即查找」-->在下面的列表中選擇Network Service用戶-->兩次單擊「確定」-->加入。
有可能是listener出錯或者微軟補丁包沖突有可能監聽器出錯…… 我也經常碰到oracle各式各樣的問題，以下是我的經驗，希望對你有用：引起ora-1053錯誤的原因有很多，一般oracle出現問題後，我會依次測試，比如啟動服務、在SQL Plus里嘗試登錄、在Windows命令行嘗試啟動服務和登錄資料庫、測試監聽器是否正常。以我碰到的問題為例，打開Net8 Configuration Assistant-本地網路服務名配置-測試，選擇想要測試的網路服務名，發現測試沒有通過，這代表對應資料庫常式監聽器出現問題了。解決方案： 1.在Net8 Configuration Assistant中，選擇監聽程序配置-刪除，刪除以前的監聽程序（listener，原因可能是電腦IP變動了等等）。 2.控制面板-管理-服務，如果oracle listener還是啟動或已啟動狀態，那麼將這個服務關閉。 3.在Net8 Configuration Assistant
③ oracle 資料庫變慢怎麼分析
1、、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4、4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。
實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。
ORACLE資料庫性能優化工具
常用的資料庫性能優化工具有：
1、1、ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。
2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。
3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。
4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。
5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。
ORACLE資料庫的系統性能評估
信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。
1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數：
l l 資料庫回滾段是否足夠？
l l 是否需要建立ORACLE資料庫索引、聚集、散列？
l l 系統全局區（SGA）大小是否足夠？
l l SQL語句是否高效？
2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數：
l l 是否採用B*-索引或者bitmap索引？
l l 是否採用並行SQL查詢以提高查詢效率？
l l 是否採用PL/SQL函數編寫存儲過程？
l l 有必要的話，需要建立並行資料庫提高資料庫的查詢效率
SQL語句的調整原則
SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：
1、1、盡量使用索引。試比較下面兩條SQL語句：
語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN
(SELECT deptno FROM emp);
語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。
2、2、選擇聯合查詢的聯合次序。考慮下面的例子：
SELECT stuff FROM taba a, tabb b, tabc c
WHERE a.acol between :alow and :ahigh
AND b.bcol between :blow and :bhigh
AND c.ccol between :clow and :chigh
AND a.key1 = b.key1
AMD a.key2 = c.key2;
這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。
3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。
4、4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。
5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。
6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。
CPU參數的調整
CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。
使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar –u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。
資料庫管理員可以通過查看v$sysstat數據字典中「CPU used by this session」統計項得知ORACLE資料庫使用的CPU時間，查看「OS User level CPU time」統計項得知操作系統用戶態下的CPU時間，查看「OS System call CPU time」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。
資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。
出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。
1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況：
SELECT * FROM V$SYSSTAT
WHERE NAME IN
('parse time cpu', 'parse time elapsed', 'parse count (hard)');
這里parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間
waite time = parse time elapsed – parse time cpu
由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA
ORDER BY PARSE_CALLS;
來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。
2、資料庫管理員還可以通過下述語句：
SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;
查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。
3、3、資料庫管理員可以通過v$system_event數據字典中的「latch free」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latch free查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。
內存參數的調整
內存參數的調整主要是指ORACLE資料庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。
1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句：
select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache;
來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：
select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache;
查看數據字典緩沖區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。
2、 2、 數據緩沖區。資料庫管理員可以通過下述語句：
SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。
這個命中率應該在90％以上，否則需要增加數據緩沖區的大小。
3、 3、 日誌緩沖區。資料庫管理員可以通過執行下述語句：
select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率：
申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。
④ ORACLE資料庫性能優化概述
實際上 為了保證ORACLE資料庫運行在最佳的性能狀態下 在信息系統開發之前就應該考慮資料庫的優化策略 優化策略一般包括伺服器操作系統參數調整 ORACLE資料庫參數調整 網路性能調整 應用程序SQL語句分析及設計等幾個方面 其中應用程序的分析與設計是在信息系統開發之前完成的
分析評價ORACLE資料庫性能主要有資料庫吞吐量 資料庫用戶響應時間兩項指標 資料庫吞吐量是指單位時間內資料庫完成的SQL語句數目 資料庫用戶響應時間是指用戶從提交SQL語句開始到獲得結果的那一段時間 資料庫用戶響應時間又可以分為系統服務時間和用戶等待時間兩項 即
資料庫用戶響應時間＝系統服務時間 ＋ 用戶等待時間
上述公式告訴我們 獲得滿意的用戶響應時間有兩個途徑 一是減少系統服務時間 即提高資料庫的吞吐量 二是減少用戶等待時間 即減少用戶訪問同一資料庫資源的沖突率
性能優化包括如下幾個部分
ORACLE資料庫性能優化之一 調整數據結構的設計
這一部分在開發信息系統之前完成 程序員需要考慮是否使用ORACLE資料庫的分區功能 對於經常訪問的資料庫表是否需要建立索引等
ORACLE資料庫性能優化之二 調整應用程序結構設計
這一部分也是在開發信息系統之前完成 程序員在這一步需要考慮應用程序使用什麼樣的體系結構 是使用傳統的Client/Server兩層體系結構 還是使用Browser/Web/Database的三層體系結構 不同的應用程序體系結構要求的資料庫資源是不同的
ORACLE資料庫性能優化之三 調整資料庫SQL語句
應用程序的執行最終將歸結為資料庫中的SQL語句執行 因此SQL語句的執行效率最終決定了ORACLE資料庫的性能 ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row level manager）來調整優化SQL語句
ORACLE資料庫性能優化之四 調整伺服器內存分配
內存分配是在信息系統運行過程中優化配置的 資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區 日誌緩沖區和共享池的大小 還可以調整程序全局區（PGA區）的大小 需要注意的是 SGA區不是越大越好 SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換 這樣反而會降低系統
ORACLE資料庫性能優化之五 調整硬碟I/O 這一步是在信息系統開發之前完成的
資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上 做到硬碟之間I/O負載均衡
ORACLE資料庫性能優化之六 調整操作系統參數
例如 運行在UNIX操作系統上的ORACLE資料庫 可以調整UNIX數據緩沖池的大小 每個進程所能使用的內存大小等參數
lishixin/Article/program/Oracle/201311/17687
⑤ oracle資料庫響應時間是多少合適
我們發現，有時一個簡單合理的優化配置就可以極大地減少資料庫的響應時間，提高資料庫的吞吐量。另外，我們還需要關注系統的狀態（比如CPU、內存、磁碟的利用率）、操作系統是否存在問題、Oracle Server性能問題的成因以及應用程序的SQL質量是否合理等等。但是這些問題的合理解決需要對資料庫底層原理有深入的理解、經驗和判斷力