Oracle實用技巧.doc

Oracle實用技巧1.找出無用索引:DML 性能低下，其中最嚴(yán)重的原因之一是無用索引的存在。所有SQL的插入，更新和刪除操作在它們需要在每一行數(shù)據(jù)被改變時修改大量索引的時候會變得更慢。許多Oracle 管理人員只要看見在一個SQL 查詢的WHERE語句出現(xiàn)了一列的話就會為它分配索引。雖然這個方法能夠讓SQL運行得更快速，但是基于功能的Oracle 索引使得數(shù)據(jù)庫管理人員有可能在數(shù)據(jù)表的行上過度分配索引。過度分配索引會嚴(yán)重影響關(guān)鍵Oracle 數(shù)據(jù)表的性能。在Oracle9i出現(xiàn)以前，沒有辦法確定SQL查詢沒有使用的索引。Oracle9i有一個工具能夠讓你使用ALTER INDEX命令監(jiān)視索引的使用。然后你可以查找這些沒有使用的索引并從數(shù)據(jù)庫里刪除它們。下面是一段腳本，它能夠打開一個系統(tǒng)中所有索引的監(jiān)視功能:spool run_monitor.sqlselect alter index |owner|.|index_name| monitoring usage;from dba_indexeswhere owner not in (SYS,SYSTEM);spool off;run_monitor你需要等待一段時間直到在數(shù)據(jù)庫上運行了足夠多的SQL語句以后，然后你就可以查詢新的V$OBJECT_USAGE視圖。select index_name,table_name,mon,usedfrom v$object_usage;在下面，我們可以看見V$OBJECT_USAGE有一列被稱作USED，它的值是YES或者NO。它不會告訴你Oracle使用了這個索引多少次，但是這個工具對于找出沒有使用的索引還是很有用的。SQL select * from v$object_usage where rownum create table a(bm char(4),mc varchar2(20);Table createdSQL insert into a values(1111,aaaa);SQL insert into a values(1112,aaaa);SQL insert into a values(1113,aaaa);SQL insert into a values(1114,aaaa);SQL insert into a select * from a;4 rows insertedSQL commit;Commit completeSQL select rowid,bm,mc from a;ROWID BM MC- - -AAAIRIAAQAAAAJqAAA 1111 aaaaAAAIRIAAQAAAAJqAAB 1112 aaaaAAAIRIAAQAAAAJqAAC 1113 aaaaAAAIRIAAQAAAAJqAAD 1114 aaaaAAAIRIAAQAAAAJqAAE 1111 aaaaAAAIRIAAQAAAAJqAAF 1112 aaaaAAAIRIAAQAAAAJqAAG 1113 aaaaAAAIRIAAQAAAAJqAAH 1114 aaaa8 rows selected查出重復(fù)記錄SQL select rowid,bm,mc from a where a.rowid!=(select max(rowid) from a b where a.bm=b.bm and a.mc=b.mc);ROWID BM MC- - -AAAIRIAAQAAAAJqAAA 1111 aaaaAAAIRIAAQAAAAJqAAB 1112 aaaaAAAIRIAAQAAAAJqAAC 1113 aaaaAAAIRIAAQAAAAJqAAD 1114 aaaa刪除重復(fù)記錄SQL delete from a a where a.rowid!=(select max(rowid) from a b where a.bm=b.bm and a.mc=b.mc);刪除4個記錄.SQL select rowid,bm,mc from a;ROWID BM MC- - -AAAIRIAAQAAAAJqAAE 1111 aaaaAAAIRIAAQAAAAJqAAF 1112 aaaaAAAIRIAAQAAAAJqAAG 1113 aaaaAAAIRIAAQAAAAJqAAH 1114 aaaa5.控制文件損壞時的恢復(fù)根據(jù)如下錯誤信息，我們發(fā)現(xiàn)數(shù)據(jù)庫只能啟動實例，讀控制文件時發(fā)生錯誤。在數(shù)據(jù)庫設(shè)計的過程中，從安全的角度考慮，系統(tǒng)使用了三個鏡像的控制文件，現(xiàn)在三個控制文件version號不一致。SVRMGRLstartuporacle instance startedtotal system global area 222323980 bytesfixed size 70924 bytesvariable size 78667776 bytesdatabase buffers 143507456 bytesredo buffers 77824 bytesORA-00214: controlfile d:oracleoradataorclcontrol01.ctl version 57460 inconsistent with file d:oracleoradataorclcontrol02.ctl version 57452.根據(jù)以上分析，我們試著修改參數(shù)文件。將參數(shù)文件中的control_file參數(shù)修改為一個控制文件，分別使用control01、control02、control03。但數(shù)據(jù)庫都無法啟動，說明三個控制文件都已損壞。由于沒有控制文件的備份，我們只能采取重建控制文件的做法。D:svrmgrlOracle Server Manager Release 3.1.6.0.0 - Production版權(quán)所有 (c) 1997，1999，Oracle Corporation。保留所有權(quán)利。Oracle8i Enterprise Edition Release 8.1.6.0.0 - ProductionWith the Partitioning optionJServer Release 8.1.6.0.0 - ProductionSVRMGR connect internal連接成功。SVRMGR shutdowm abort已關(guān)閉 ORACLE 實例。SVRMGR startup nomount已啟動 ORACLE 實例。系統(tǒng)全局區(qū)域合計有 108475660個字節(jié)Fixed Size 70924個字節(jié)Variable Size 46116864個字節(jié)Database Buffers 62210048個字節(jié)Redo Buffers 77824個字節(jié)SVRMGRcreate controlfile reuse database orcl noresetlogs archivelogLogfile group 1 d:oracleoradataorclredo01.log,group 2 d:oracleoradataorclredo02.log,group 3 d:oracleoradataorclredo03.logdatafile d:oracleoradataorclsystem01.dbf,d:oracleoradataorclusers01.dbf,d:oracleoradataorcltemp01.dbf,d:oracleoradataorcltools01.dbf,d:oracleoradataorclindx01.dbf,d:oracleoradataorcldr01.dbf,d:oracleoradataorclrbs01.dbf;語句已處理。成功地重建控制文件后，我們嘗試著打開數(shù)據(jù)庫，但系統(tǒng)報錯，提示需要進行介質(zhì)恢復(fù)。SVRMGRrecover datafile d:oracleoradataorclsystem01.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorclusers0101.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorcltemp01.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorcltools01.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorclindx01.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorcldr01.dbf;介質(zhì)已恢復(fù)。SVRMGR recover datafile d:oracleoradataorclrbs01.dbf;介質(zhì)已恢復(fù)。介