透過alert日誌看Oracle Startup的三個階段
alert日誌記錄oracle例項生命週期中發生的重要事件,例如資料庫啟動、關閉、日誌切換等,方便程式設計師和管理員發現問題。其中,資料庫啟動分為3個階段,即nomount,mount和open。那麼,在這三個階段alert日誌會記錄哪些資訊呢。下面我們就按照nomount,mount和open的順序逐步啟動資料庫。
接下來,檢視alert日誌的輸出內容如下:
由上可以看出,在nomount階段,Oracle首先尋找引數檔案(pfile/spfile),然後根據引數檔案中的設定(如記憶體分配等設定),建立例項(INSTANCE),分配記憶體,啟動後臺程式。Nomount的過程也就是啟動資料庫例項的過程。這個過程在後臺是啟動Oracle可執行程式的過程,Windows上是oracle.exe檔案的初始化,在Unix/Linux上是oracle可執行檔案的初始化。
檢視alert日誌的輸出內容如下:
mount資料庫的過程是讀引數檔案中描述的控制檔案,校驗控制檔案的正確性,將控制檔案的內容讀入到記憶體,mount是掛接的意思,是作業系統中的概念。一旦mount之後,就是將一個沒有意義的例項和一個資料庫發生了聯絡。
nomount
透過startup nomount命令將資料庫啟動到nomount狀態,此時,資料庫例項的狀態是STARTED。如下所示:點選(此處)摺疊或開啟
-
SQL>
-
SQL> startup nomount
-
ORACLE instance started.
-
-
Total System Global Area 941600768 bytes
-
Fixed Size 1348860 bytes
-
Variable Size 515902212 bytes
-
Database Buffers 419430400 bytes
-
Redo Buffers 4919296 bytes
-
SQL>
-
SQL> select status from v$instance;
-
-
STATUS
-
------------
-
STARTED
-
- SQL>
點選(此處)摺疊或開啟
-
Sat May 09 22:14:16 2015
-
Starting ORACLE instance (normal)
-
LICENSE_MAX_SESSION = 0
-
LICENSE_SESSIONS_WARNING = 0
-
Picked latch-free SCN scheme 2
-
Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
-
Autotune of undo retention is turned on.
-
IMODE=BR
-
ILAT =27
-
LICENSE_MAX_USERS = 0
-
SYS auditing is disabled
-
Starting up:
-
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
-
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
-
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
-
System name: Linux
-
Node name: enmoedu1.example.com
-
Release: 2.6.18-164.el5PAE
-
Version: #1 SMP Thu Sep 3 02:28:20 EDT 2009
-
Machine: i686
-
VM name: VMWare Version: 6
-
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileHOEGH.ora
-
System parameters with non-default values:
-
processes = 150
-
memory_target = 900M
-
memory_max_target = 900M
-
control_files = \"/u01/app/oracle/oradata/HOEGH/control01.ctl\"
-
control_files = \"/u01/app/oracle/oradata/HOEGH/control02.ctl\"
-
db_block_size = 8192
-
compatible = \"11.2.0.0.0\"
-
undo_tablespace = \"UNDOTBS1\"
-
remote_login_passwordfile= \"EXCLUSIVE\"
-
db_domain = \"\"
-
dispatchers = \"(PROTOCOL=TCP) (SERVICE=HOEGHXDB)\"
-
audit_file_dest = \"/u01/app/oracle/admin/HOEGH/adump\"
-
audit_trail = \"DB\"
-
db_name = \"HOEGH\"
-
open_cursors = 300
-
diagnostic_dest = \"/u01/app/oracle\"
-
Sat May 09 22:14:16 2015
-
PMON started with pid=2, OS id=5054
-
Sat May 09 22:14:16 2015
-
PSP0 started with pid=3, OS id=5056
-
Sat May 09 22:14:17 2015
-
VKTM started with pid=4, OS id=5063 at elevated priority
-
VKTM running at (1)millisec precision with DBRM quantum (100)ms
-
Sat May 09 22:14:17 2015
-
GEN0 started with pid=5, OS id=5067
-
Sat May 09 22:14:17 2015
-
DIAG started with pid=6, OS id=5069
-
Sat May 09 22:14:17 2015
-
DBRM started with pid=7, OS id=5071
-
Sat May 09 22:14:17 2015
-
DIA0 started with pid=8, OS id=5073
-
Sat May 09 22:14:17 2015
-
MMAN started with pid=9, OS id=5075
-
Sat May 09 22:14:17 2015
-
DBW0 started with pid=10, OS id=5077
-
Sat May 09 22:14:17 2015
-
LGWR started with pid=11, OS id=5079
-
Sat May 09 22:14:17 2015
-
CKPT started with pid=12, OS id=5081
-
Sat May 09 22:14:17 2015
-
SMON started with pid=13, OS id=5083
-
Sat May 09 22:14:17 2015
-
RECO started with pid=14, OS id=5085
-
Sat May 09 22:14:17 2015
-
MMON started with pid=15, OS id=5087
-
Sat May 09 22:14:17 2015
-
MMNL started with pid=16, OS id=5089
-
starting up 1 dispatcher(s) for network address \'(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))\'...
-
starting up 1 shared server(s) ...
- ORACLE_BASE from environment = /u01/app/oracle
mount
接下來,透過alter database mount;命令將資料庫啟動到mount狀態,此時,資料庫例項的狀態是MOUNTED。如下所示:點選(此處)摺疊或開啟
-
SQL>
-
SQL> alter database mount;
-
-
Database altered.
-
-
SQL>
-
SQL> select status from v$instance;
-
-
STATUS
-
------------
-
MOUNTED
-
- SQL>
點選(此處)摺疊或開啟
-
Sat May 09 22:15:30 2015
-
alter database mount
-
Sat May 09 22:15:34 2015
-
Successful mount of redo thread 1, with mount id 2100626370
-
Database mounted in Exclusive Mode
-
Lost write protection disabled
- Completed: alter database mount
open
透過alter database open;命令將資料庫啟動到open狀態,此時,資料庫例項的狀態是OPEN。如下所示:
檢視alert日誌的輸出內容如下:
點選(此處)摺疊或開啟
-
SQL>
-
SQL> alter database open;
-
-
Database altered.
-
-
SQL>
-
SQL> select status from v$instance;
-
-
STATUS
-
------------
-
OPEN
-
- SQL>
點選(此處)摺疊或開啟
-
Sat May 09 22:16:34 2015
-
alter database open
-
Beginning crash recovery of 1 threads
-
parallel recovery started with 2 processes
-
Started redo scan
-
Completed redo scan
-
read 12 KB redo, 9 data blocks need recovery
-
Started redo application at
-
Thread 1: logseq 7, block 118
-
Recovery of Online Redo Log: Thread 1 Group 1 Seq 7 Reading mem 0
-
Mem# 0: /u01/app/oracle/oradata/HOEGH/redo01.log
-
Completed redo application of 0.00MB
-
Completed crash recovery at
-
Thread 1: logseq 7, block 143, scn 918639
-
9 data blocks read, 9 data blocks written, 12 redo k-bytes read
-
Sat May 09 22:16:34 2015
-
Thread 1 advanced to log sequence 8 (thread open)
-
Thread 1 opened at log sequence 8
-
Current log# 2 seq# 8 mem# 0: /u01/app/oracle/oradata/HOEGH/redo02.log
-
Successful open of redo thread 1
-
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
-
Sat May 09 22:16:35 2015
-
SMON: enabling cache recovery
-
[5095] Successfully onlined Undo Tablespace 2.
-
Undo initialization finished serial:0 start:4294562150 end:4294562220 diff:70 (0 seconds)
-
Verifying file header compatibility for 11g tablespace encryption..
-
Verifying 11g file header compatibility for tablespace encryption completed
-
SMON: enabling tx recovery
-
Database Characterset is AL32UTF8
-
No Resource Manager plan active
-
replication_dependency_tracking turned off (no async multimaster replication found)
-
Starting background process QMNC
-
Sat May 09 22:16:35 2015
-
QMNC started with pid=22, OS id=5274
-
Completed: alter database open
-
Sat May 09 22:16:36 2015
-
Starting background process CJQ0
-
Sat May 09 22:16:36 2015
- CJQ0 started with pid=24, OS id=5296
這一階段資料庫讀取控制檔案中描述的資料檔案並驗證資料檔案的一致性,如果不一致,使用日誌檔案將資料庫檔案恢復到一致的狀態。資料庫open後,普通使用者才可以訪問資料庫。
~~~~~~~ the end~~~~~~~~~
~~~~~~~ the end~~~~~~~~~
hoegh2015.05.09
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30162081/viewspace-1631808/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 從Alert_Log看Oracle資料庫啟動三階段Oracle資料庫
- 透過alert日誌重建引數檔案
- oracle alert日誌Oracle
- ORACLE 告警日誌alert過大的處理Oracle
- 從alert日誌看Oracle 11g Datagurad日誌傳輸(上)Oracle
- 從alert日誌看Oracle 11g Datagurad日誌傳輸(下)Oracle
- 歸檔oracle alert日誌Oracle
- oracle 中 alert 報警日誌過大的處理方法Oracle
- oracle alert日誌每天截斷truncate_alert.shOracle
- oracle alert日誌亂碼處理Oracle
- 最佳實踐(保持、清理ORACLE alert日誌)Oracle
- oracle 11g檢視alert日誌方法Oracle
- 使用sql查alert日誌SQL
- Oracle 警告日誌 (alert log) 中包含哪些內容 ?Oracle
- Oracle的告警日誌之v$diag_alert_ext檢視Oracle
- .NET Core開發日誌——Startup
- 解決Windows上alert日誌和listener日誌不能超過4GB的問題Windows
- Oracle啟動三階段(一)Oracle
- Oracle啟動三階段(二)Oracle
- 透過三消看遊戲本質遊戲
- JS引擎執行緒的執行過程的三個階段JS執行緒
- alert日誌中出現ash size的警告
- 11g的alert日誌路徑
- 透過 Filebeat 收集 ubuntu 系統日誌Ubuntu
- 初學Java,這三個階段你經歷過嗎?Java
- 【alert】每週自動備份alert日誌檔案
- oracle-startup過程Oracle
- 警告日誌檔案alert_.log
- 熟練使用alert.log日誌
- 客服系統的三個發展階段
- 比特幣的三個經濟階段比特幣
- 透過java程式抽取日誌中的sql語句JavaSQL
- 用外部表實現Alert日誌的檢視
- alert日誌中的兩種ORA錯誤分析
- MariaDB伺服器查詢執行過程的三個階段概述伺服器
- MySQL事務提交的三個階段介紹MySql
- 初學Java的5個階段,你在哪個階段?Java
- alert日誌中的一條ora警告資訊的分析