早期用Linux的時候，看Oracle監(jiān)聽狀態(tài)和端口只是瀏覽一下，沒有認(rèn)真看過內(nèi)容也是英文提示，時隔數(shù)載重新?lián)炱餙racle,Windos下CMD查看監(jiān)聽狀態(tài)發(fā)現(xiàn)很多有意思的問題，Oracle實(shí)例和線程很多不懂之處請高手指點(diǎn)
網(wǎng)站設(shè)計(jì)制作過程拒絕使用模板建站；使用PHP+MYSQL原生開發(fā)可交付網(wǎng)站源代碼;符合網(wǎng)站優(yōu)化排名的后臺管理系統(tǒng)；成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站收費(fèi)合理；免費(fèi)進(jìn)行網(wǎng)站備案等企業(yè)網(wǎng)站建設(shè)一條龍服務(wù).我們是一家持續(xù)穩(wěn)定運(yùn)營了十載的創(chuàng)新互聯(lián)建站網(wǎng)站建設(shè)公司。
首先Oracle啟動階段nomount,mount,open（其余不作啰嗦）每一個階段都做了測試和總結(jié)
1、數(shù)據(jù)庫關(guān)閉階段（實(shí)例狀態(tài)）
服務(wù) "CLRExtProc" 包含 1 個實(shí)例。
實(shí)例 "CLRExtProc", 狀態(tài)UNKNOWN,包含此服務(wù)的1個處理程序.
已連接到空閑例程。
登錄之后已連接空閑進(jìn)程，而且狀態(tài)未知的，后期查閱資料才知道UNKNOWN狀態(tài)非自動注冊，通過搜索Listener.org里面內(nèi)容，匹配services之后才進(jìn)行的注冊，在這個文件中不需要配置SID，PMON會自動檢測，因?yàn)閿?shù)據(jù)庫沒有啟動，所以空閑進(jìn)程。
2、nomount階段
SQL> startup nomount;
ORACLE 例程已經(jīng)啟動。
Total System Global Area 1686925312 bytes
Fixed Size 2176368 bytes
Variable Size 1090521744 bytes
Database Buffers 587202560 bytes
Redo Buffers 7024640 bytes
可見數(shù)據(jù)庫大小，變量緩沖區(qū)等資源已經(jīng)啟動。我們測試查詢一下v$datafile,v$controlfile,v$database.
SQL> select file#,name from v$datafile;
select file#,name from v$datafile
*
第 1 行出現(xiàn)錯誤:ORA-01507: ??????
SQL> select name from v$controlfile;
未選定行
查詢看到nomount階段沒有加載數(shù)據(jù)文件，可以檢測SGA相關(guān)。
監(jiān)聽狀態(tài)查看（實(shí)例）
服務(wù)"soujiusubdb" 包含1 個實(shí)例。
實(shí)例"soujiusubdb", 狀態(tài)BLOCKED, 包含此服務(wù)的1 個處理程序...
引用：這時候?qū)嵗呀?jīng)啟動，BLOCKED阻塞的狀態(tài)，那么Oracle實(shí)例應(yīng)該是操作系統(tǒng)中線程運(yùn)行，OS阻塞用pritive調(diào)用原子操作，由于某事件無法運(yùn)行，受阻塞。但是nomount階段多數(shù)講解：只會創(chuàng)建實(shí)例，并不加載數(shù)據(jù)庫，Oracle僅為實(shí)例創(chuàng)建各種內(nèi)存結(jié)構(gòu)和服務(wù)進(jìn)程，不會打開任何數(shù)據(jù)文件。在NoMount模式下，只能訪問那些與SGA區(qū)相關(guān)的數(shù)據(jù)字典視圖，包括V$PARAMETER、V$SGA、V$PROCESS 和 V$SESSION等，這些視圖中的信息都是從SGA區(qū)中獲取的，與數(shù)據(jù)庫無關(guān)，系統(tǒng)分配內(nèi)存、開啟后臺進(jìn)程，同時更新alter日志文件。
那么在操作系統(tǒng)的層面是否能這樣理解，通過Oracle的nomount命令來創(chuàng)建實(shí)例，這時候操作系統(tǒng)會給分配進(jìn)程或線程去響應(yīng)請求，Oracle為實(shí)例創(chuàng)建內(nèi)存結(jié)構(gòu)和服務(wù)進(jìn)程，也就是實(shí)例具備了必要資源分配，那么此時的線程的狀態(tài)應(yīng)該為就緒狀態(tài)（除了得到CUP之外的資源，獲得處理機(jī)即可運(yùn)行），插入就緒隊(duì)列，但是監(jiān)聽狀態(tài)為阻塞，也就意味著nomount狀態(tài)下，實(shí)例線程在就緒隊(duì)列被掛起，不釋放CUP（實(shí)例當(dāng)前應(yīng)該沒有獲取CPU），調(diào)用suspend原子操作，靜止就緒（不接受調(diào)度）nomount是主動而非被動去阻塞。
3、mount階段
我們這時候去查看數(shù)據(jù)文件，日志文件，控制文件都是正常，查看監(jiān)聽實(shí)例，這時候?qū)嵗隣顟B(tài)變成了Ready(就緒狀態(tài))，也就是Oracle在執(zhí)行mount時候時候調(diào)用原語active來喚醒實(shí)例線程，變成活動就緒狀態(tài)。
服務(wù) "CLRExtProc" 包含 1 個實(shí)例。
實(shí)例 "CLRExtProc", 狀態(tài) UNKNOWN, 包含此服務(wù)的 1 個處理程序...
服務(wù) "soujiusubdb" 包含 1 個實(shí)例。
實(shí)例 "soujiusubdb", 狀態(tài) READY, 包含此服務(wù)的 1 個處理程序...
引用：這種啟動模式將為實(shí)例加載數(shù)據(jù)庫，但保持?jǐn)?shù)據(jù)庫為關(guān)閉狀態(tài)。因?yàn)榧虞d數(shù)據(jù)庫時需要打開數(shù)據(jù)庫控制文件，但數(shù)據(jù)文件和重做日志文件都都無法進(jìn)行讀寫，所以用戶還無法對數(shù)據(jù)庫進(jìn)行操作。 在Mount模式下，只能訪問那些與控制文件相關(guān)的數(shù)據(jù)字典視圖，包括V$THREAD、V$CONTROLFILE、V$DATABASE、V$DATAFILE 和 V$LOGFILE等，這些視圖都是從控制文件中獲取的。 啟動條件是需要有控制文件，如果控制文件丟失或者損壞，啟動將會報錯。此時系統(tǒng)會打開控制文件、檢查數(shù)據(jù)文件、日志文件的名稱和位置，但此時不檢查文件到底是否存在不存在。
4、open階段
引用：open階段，該階段主要是打開數(shù)據(jù)文件、日志文件，在打開的過程中對數(shù)據(jù)文件和日志文件進(jìn)行一致性檢查，如果不一致，則SMON進(jìn)程繼續(xù)實(shí)例恢復(fù)，如果文件丟失，打開失敗。
我本以為在此階段實(shí)例狀態(tài)會就緒變成執(zhí)行狀態(tài)，變更open階段之后，查看監(jiān)聽后發(fā)現(xiàn)多出一個服務(wù)，但是實(shí)例名一樣，狀態(tài)也一樣，仍然為就緒狀態(tài)，Oracle實(shí)例線程一直處于就緒狀態(tài)這一點(diǎn)還沒有搞清楚，希望老師們給予解答，解析迷惑。
服務(wù)摘要..
服務(wù) "CLRExtProc" 包含 1 個實(shí)例。
實(shí)例 "CLRExtProc", 狀態(tài) UNKNOWN, 包含此服務(wù)的 1 個處理程序...
服務(wù) "SOUJIUSUBDBXDB" 包含 1 個實(shí)例。
實(shí)例 "soujiusubdb", 狀態(tài) READY, 包含此服務(wù)的 1 個處理程序...
服務(wù) "soujiusubdb" 包含 1 個實(shí)例。
實(shí)例 "soujiusubdb", 狀態(tài) READY, 包含此服務(wù)的 1 個處理程序...
數(shù)據(jù)庫關(guān)閉，卸載實(shí)例，終止實(shí)例，幾種參數(shù)關(guān)閉方式需求不同，應(yīng)用場合不同，但是最后整體一個關(guān)閉過程大同小異，希望也能學(xué)習(xí)到關(guān)于關(guān)閉數(shù)據(jù)庫時候線程的動作。
重慶分公司
重慶分公司
