① 什麼是oracle l是做什麼用的工具
經常有朋友在論壇上問到DUL工具，我在這里對這個工具作一個簡要介紹。
DUL是Data Unloader的縮寫，為Oracle公司工程師 Bernard van Duijnen 開發，以標准C寫成，可以直接從Oracle的數據文件中讀取數據，轉換為DMP或文本格式輸出，在非凡情況下可以用來進行數據恢復。
這些非凡情況主要指，資料庫沒有有效備份、或者系統表空間損壞，或者在非歸檔模式下的不可逆數據損失等等，一旦普通手段失去作用，DUL就可以作為最後一招來最大限度的拯救用戶數據。
然而DUL並非一個商業工具，這個工具僅在Oracle內部流通，但是逐漸的，DUL也開始流入民間，被一些資深Oracle工程師所使用。
隨著資料庫版本的變化，DUL工具也在逐漸升級之中，對應Oracle8 / Oracle8i / Oracle9i / Oracle10g都有其相應版本。
作為DBA們首先應該知道DBA第一守則：備份重於一切。首先應該把備份作為數據恢復的第一手段。
假如備份或其他恢復手段不可用，我們就應該知道，DUL是最後可以訴諸的手段。
國內的Oracle專家自行開發了類DUL工具，他稱之為 PRM-DUL，具有同樣類似的功能，是非常優秀的一款國產軟體。大家可以訪問 http://www.parnassusdata.com/ 獲得更多的信息。
② oracle哪個工具自動檢測系統瓶頸並給出建議
ADDM(Automatic DatabaseDiagnostic Monitor)是植入Oracle資料庫的一個自診斷引擎.ADDM 通過檢查和分析AWR獲取的數據來判斷Oracle資料庫中可能的問題.
在Oracle9i及之前，DBA們已經擁有了很多很好用的性能分析工具，比如，tkprof、sql_trace、statspack、setevent 10046&10053等等。這些工具能夠幫助DBA很快的定位性能問題。但這些工具都只給出一些統計數據，然後再由DBA們根據自己的經驗進行優化。
Oracle10g中推出了新的優化診斷工具：資料庫自動診斷監視工具（Automatic Database Diagnostic Monitor :ADDM）和SQL優化建議工具（SQL Tuning Advisor: STA）。這兩個工具的結合使用，能使DBA節省大量優化時間，也大大減少了系統宕機的危險。簡單點說，ADDM就是收集相關的統計數據到自動工作量知識庫(Automatic Workload Repository :AWR)中，而STA則根據這些數據，給出優化建議。
例如，一個系統資源緊張，出現了明顯的性能問題，由以往的辦法，做個一個statspack快照，等30分鍾，再做一次。查看報告，發現』 dbfile scattered read』事件在top 5 events裡面。根據經驗，這個事件一般可能是因為缺少索引、統計分析信息不夠新、熱表都放在一個數據文件上導致IO爭用等原因引起的。根據這些經驗，我們需要逐個來定位排除，比如查看語句的查詢計劃、查看user_tables的last_analysed子段，檢查熱塊等等步驟來最後定位出原因，並給出優化建議。但是，有了STA以後，它就可以根據ADDM採集到的數據直接給出優化建議，甚至給出優化後的語句。
ADDM能發現定位的問題包括：
•操作系統內存頁入頁出問題
•由於Oracle負載和非Oracle負載導致的CPU瓶頸問題
•導致不同資源負載的TopSQL語句和對象——CPU消耗、IO帶寬佔用、潛在IO問題、RAC內部通訊繁忙
•按照PLSQL和JAVA執行時間排的Top SQL語句.
•過多地連接 (login/logoff).
•過多硬解析問題——由於sharedpool過小、書寫問題、綁定大小不適應、解析失敗原因引起的。
•過多軟解析問題
•索引查詢過多導致資源爭用.
•由於用戶鎖導致的過多的等待時間(通過包dbms_lock加的鎖)
•由於DML鎖導致的過多等待時間(例如鎖住表了)
•由於管道輸出導致的過多等待時間(如通過包dbms_pipe.put進行管道輸出)
•由於並發更新同一個記錄導致的過多等待時間(行級鎖等待)
•由於ITL不夠導致的過多等待時間（大量的事務操作同一個數據塊）
•系統中過多的commit和rollback(logfilesync事件).
•由於磁碟帶寬太小和其他潛在問題（如由於logfile太小導致過多的checkpoint，MTTR設置問題，過多的undo操作等等）導致的IO性能問題I
•對於DBWR進程寫數據塊，磁碟IO吞吐量不足
•由於歸檔進程無法跟上redo日至產生的速度，導致系統變慢
•redo數據文件太小導致的問題
•由於擴展磁碟分配導致的爭用
•由於移動一個對象的高水位導致的爭用問題
•內存太小問題——SGATarget, PGA, Buffer Cache, Shared Pool
•在一個實例或者一個機群環境中存在頻繁讀寫爭用的熱塊
•在一個實例或者一個機群環境中存在頻繁讀寫爭用的熱對象
•RAC環境中內部通訊問題
•LMS進程無法跟上導致鎖請求阻塞
•在RAC環境中由於阻塞和爭用導致的實例傾斜
•RMAN導致的IO和CPU問題
•Streams和AQ問題
•資源管理等待事件
ADDM提供了一個整體的優化方案.基於一段時間內的AWRsnapshots(默認一小時一次)可以執行ADDM 分析,它可以幫我們診斷在這段期間內資料庫可能存在的瓶頸.
ADDM分析的目標是減小吞吐量的度量值, 在這里我們將它稱為"DB TIME".DB TIME是一個累積值(資料庫伺服器處理用戶請求所花費的時間).它包括了等待時間和CPU處理的時間(針對所有活躍的用戶進程而言),可以通過查詢下面兩個視圖來獲得它的值: V$SESS_TIME_MODEL,V$SYS_TIME_MODEL.
AWR收集的數據時放到內存中（sharepool），通過一個新的後台進程MMON定期寫到磁碟中。所以10g的sharepool要求比以前版本更大，一般推薦比以前大15-20%。
注意: ADDM不會將處理用戶響應時間作為調優的目標,你應該使用"TRACE"技術來監控它.
通過減小"DBTIME", 使用同樣多的系統資源,資料庫伺服器可以處理更多的用戶請求,也就是提高了吞吐量. 通過ADDM報告的問題是按照DBtime排序的.
③ Linux Oracle10g安裝好後，有什麼軟體類似於PLSQLdeveloper 的管理工具，用命令別人都看不懂，
oracle 自己的產品sqldeveloper