oracle-startup過程

1.NOMOUNT --------------------------- 這一步只和引數檔案有關，如果在這一步就出現問題，那麼通常可能是系統配置(如核心引數等)存在問題，需要檢查是否分配了足夠的系統資源。 --------------------------------------------------------------------------------------------------------------------------- 2.MOUNT -------------------------- 這一步需要從引數檔案中獲得控制檔案位置，讀取其中內容，校驗資料檔案的存在性。 除此之外還會去校驗口令檔案。Oracle預設查詢orapw檔案，如果該檔案找不到，則繼續查詢orapw檔案，如果兩者都不存在，資料庫將出現錯誤。但資料為仍可以開啟。從Oracle10g開始，當口令檔案丟失後，Oracle將不再提示錯誤，只是和口令檔案相關的部分功能將無法使用。 ---------------------------------------------------------------------------------------------------------------------------- lk檔案及作用 --------------------------------------- 該檔案在資料庫啟動時建立，用於作業系統對資料庫的鎖定。當資料庫啟動時獲得鎖定，資料庫關閉時釋放。在系統出現異常時，可能資料庫已經關閉，但鎖定並未釋放，或者因為後臺程式未正常停止等原因，會導致下次資料庫無法啟動。解決辦法就是重啟伺服器，或者手工釋放共享記憶體段。 ----------------------------------------------------------------------------------------------------------------------- 3.OPEN -------------------- 這一步將進行檢查點和完整性的檢查。如果檢查全部透過，則開啟資料庫，否則給出錯誤警告，停止開啟資料庫。 -------------------------------------------------------------------------------------------------------------------------- 資料庫的啟動驗證: ------------------------ 1. 第一次檢查資料檔案頭中的Checkpoint CNT是否與對應控制檔案中的Checkpoint CNT一致。此步驟檢查用以確認資料檔案是否來自同一版本，而不是從備份中恢復而來 （在熱備份模式下，資料檔案檢查點被凍結，但檢查點計數不會被凍結，會一直修改） 在Oracle10g中用8級轉儲獲得控制檔案資訊。 SQL> alter session set events 'immediate trace name controlf level 8'; 在Oracle9i中用10級轉儲。 ---------------------------------------------------------------------------------------------------------------------------- 2. 第二次檢查資料檔案頭的開始SCN和控制檔案中記錄的該檔案的的結束SCN是否一致。如果一致，則不需要對那個檔案進行恢復。 部分控制檔案轉儲內容： 222 DATA FILE RECORDS 223 *************************************************************************** 224 (size = 428, compat size = 428, section max = 100, section in-use = 5, 225 last-recid= 8, old-recno = 0, last-recno = 0) 226 (extent = 1, blkno = 11, numrecs = 100) 227 DATA FILE #1: 228 (name #7) /u01/app/oracle/oradata/orcl/system01.dbf 229 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1 230 tablespace 0, index=1 krfil=1 prev_file=0 231 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 232 Checkpoint cnt:52 scn: 0x0000.0007ba16 02/18/2011 16:30:22 233 Stop scn: 0xffff.ffffffff 02/16/2011 11:07:26 234 Creation Checkpointed at scn: 0x0000.00000009 06/30/2005 19:10:11 235 thread:0 rba:(0x0.0.0) 236 enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 ---------------------------------------------------------------------------------------------------------------------------- 在資料庫出現問題時，提示中給出的可能是不完整的資訊，而告警日誌中則記錄了完整的錯誤過程和錯誤號。 說明: 控制檔案中記錄的SCN指最後一次成功完成的檢查點SCN； 資料檔案頭中的記錄的SCN指資料檔案最後一次成功完成的檢查點SCN； 此外，在控制檔案和資料檔案頭都記錄一個檢查點計數(chkpt cnt)，而且資料檔案頭還記錄了一個 控制檔案檢查點計數(ctl cnt)。但這個ctl cnt要比控制檔案中的ctl cnt小1。這是因為，當檢查 點更新控制檔案和資料檔案頭上的chkpt cnt資訊時，在更新控制檔案之前，可以獲得當前的ctl cnt ,這個資訊被記入了資料檔案。之所以這麼做，是因為不能保證更新控制檔案上的chkpt cnt一定 會成功，記錄之前的ctl cnt可以確保上一次的chkpt cnt是成功完成的。[@more@]