透過alert日誌看Oracle Startup的三個階段

Hoegh發表於2015-05-09
        alert日誌記錄oracle例項生命週期中發生的重要事件,例如資料庫啟動、關閉、日誌切換等,方便程式設計師和管理員發現問題。其中,資料庫啟動分為3個階段,即nomount,mount和open。那麼,在這三個階段alert日誌會記錄哪些資訊呢。下面我們就按照nomount,mount和open的順序逐步啟動資料庫。

nomount

透過startup nomount命令將資料庫啟動到nomount狀態,此時,資料庫例項的狀態是STARTED。如下所示:

點選(此處)摺疊或開啟

  1. SQL>
  2. SQL> startup nomount
  3. ORACLE instance started.

  4. Total System Global Area 941600768 bytes
  5. Fixed Size 1348860 bytes
  6. Variable Size 515902212 bytes
  7. Database Buffers 419430400 bytes
  8. Redo Buffers 4919296 bytes
  9. SQL>
  10. SQL> select status from v$instance;

  11. STATUS
  12. ------------
  13. STARTED

  14. SQL>
接下來,檢視alert日誌的輸出內容如下:

點選(此處)摺疊或開啟

  1. Sat May 09 22:14:16 2015
  2. Starting ORACLE instance (normal)
  3. LICENSE_MAX_SESSION = 0
  4. LICENSE_SESSIONS_WARNING = 0
  5. Picked latch-free SCN scheme 2
  6. Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
  7. Autotune of undo retention is turned on.
  8. IMODE=BR
  9. ILAT =27
  10. LICENSE_MAX_USERS = 0
  11. SYS auditing is disabled
  12. Starting up:
  13. Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
  14. With the Partitioning, OLAP, Data Mining and Real Application Testing options.
  15. ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
  16. System name:    Linux
  17. Node name:    enmoedu1.example.com
  18. Release:    2.6.18-164.el5PAE
  19. Version:    #1 SMP Thu Sep 3 02:28:20 EDT 2009
  20. Machine:    i686
  21. VM name:    VMWare Version: 6
  22. Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileHOEGH.ora
  23. System parameters with non-default values:
  24.   processes = 150
  25.   memory_target = 900M
  26.   memory_max_target = 900M
  27.   control_files = \"/u01/app/oracle/oradata/HOEGH/control01.ctl\"
  28.   control_files = \"/u01/app/oracle/oradata/HOEGH/control02.ctl\"
  29.   db_block_size = 8192
  30.   compatible = \"11.2.0.0.0\"
  31.   undo_tablespace = \"UNDOTBS1\"
  32.   remote_login_passwordfile= \"EXCLUSIVE\"
  33.   db_domain = \"\"
  34.   dispatchers = \"(PROTOCOL=TCP) (SERVICE=HOEGHXDB)\"
  35.   audit_file_dest = \"/u01/app/oracle/admin/HOEGH/adump\"
  36.   audit_trail = \"DB\"
  37.   db_name = \"HOEGH\"
  38.   open_cursors = 300
  39.   diagnostic_dest = \"/u01/app/oracle\"
  40. Sat May 09 22:14:16 2015
  41. PMON started with pid=2, OS id=5054
  42. Sat May 09 22:14:16 2015
  43. PSP0 started with pid=3, OS id=5056
  44. Sat May 09 22:14:17 2015
  45. VKTM started with pid=4, OS id=5063 at elevated priority
  46. VKTM running at (1)millisec precision with DBRM quantum (100)ms
  47. Sat May 09 22:14:17 2015
  48. GEN0 started with pid=5, OS id=5067
  49. Sat May 09 22:14:17 2015
  50. DIAG started with pid=6, OS id=5069
  51. Sat May 09 22:14:17 2015
  52. DBRM started with pid=7, OS id=5071
  53. Sat May 09 22:14:17 2015
  54. DIA0 started with pid=8, OS id=5073
  55. Sat May 09 22:14:17 2015
  56. MMAN started with pid=9, OS id=5075
  57. Sat May 09 22:14:17 2015
  58. DBW0 started with pid=10, OS id=5077
  59. Sat May 09 22:14:17 2015
  60. LGWR started with pid=11, OS id=5079
  61. Sat May 09 22:14:17 2015
  62. CKPT started with pid=12, OS id=5081
  63. Sat May 09 22:14:17 2015
  64. SMON started with pid=13, OS id=5083
  65. Sat May 09 22:14:17 2015
  66. RECO started with pid=14, OS id=5085
  67. Sat May 09 22:14:17 2015
  68. MMON started with pid=15, OS id=5087
  69. Sat May 09 22:14:17 2015
  70. MMNL started with pid=16, OS id=5089
  71. starting up 1 dispatcher(s) for network address \'(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))\'...
  72. starting up 1 shared server(s) ...
  73. ORACLE_BASE from environment = /u01/app/oracle
由上可以看出,在nomount階段,Oracle首先尋找引數檔案(pfile/spfile),然後根據引數檔案中的設定(如記憶體分配等設定),建立例項(INSTANCE),分配記憶體,啟動後臺程式。Nomount的過程也就是啟動資料庫例項的過程。這個過程在後臺是啟動Oracle可執行程式的過程,Windows上是oracle.exe檔案的初始化,在Unix/Linux上是oracle可執行檔案的初始化。

mount

接下來,透過alter database mount;命令將資料庫啟動到mount狀態,此時,資料庫例項的狀態是MOUNTED如下所示:

點選(此處)摺疊或開啟

  1. SQL>
  2. SQL> alter database mount;

  3. Database altered.

  4. SQL>
  5. SQL> select status from v$instance;

  6. STATUS
  7. ------------
  8. MOUNTED

  9. SQL>
檢視alert日誌的輸出內容如下:

點選(此處)摺疊或開啟

  1. Sat May 09 22:15:30 2015
  2. alter database mount
  3. Sat May 09 22:15:34 2015
  4. Successful mount of redo thread 1, with mount id 2100626370
  5. Database mounted in Exclusive Mode
  6. Lost write protection disabled
  7. Completed: alter database mount
mount資料庫的過程是讀引數檔案中描述的控制檔案,校驗控制檔案的正確性,將控制檔案的內容讀入到記憶體,mount是掛接的意思,是作業系統中的概念。一旦mount之後,就是將一個沒有意義的例項和一個資料庫發生了聯絡。

open

透過alter database open;命令將資料庫啟動到open狀態,此時,資料庫例項的狀態是OPEN。如下所示:

點選(此處)摺疊或開啟

  1. SQL>
  2. SQL> alter database open;

  3. Database altered.

  4. SQL>
  5. SQL> select status from v$instance;

  6. STATUS
  7. ------------
  8. OPEN

  9. SQL>
檢視alert日誌的輸出內容如下:

點選(此處)摺疊或開啟

  1. Sat May 09 22:16:34 2015
  2. alter database open
  3. Beginning crash recovery of 1 threads
  4.  parallel recovery started with 2 processes
  5. Started redo scan
  6. Completed redo scan
  7.  read 12 KB redo, 9 data blocks need recovery
  8. Started redo application at
  9.  Thread 1: logseq 7, block 118
  10. Recovery of Online Redo Log: Thread 1 Group 1 Seq 7 Reading mem 0
  11.   Mem# 0: /u01/app/oracle/oradata/HOEGH/redo01.log
  12. Completed redo application of 0.00MB
  13. Completed crash recovery at
  14.  Thread 1: logseq 7, block 143, scn 918639
  15.  9 data blocks read, 9 data blocks written, 12 redo k-bytes read
  16. Sat May 09 22:16:34 2015
  17. Thread 1 advanced to log sequence 8 (thread open)
  18. Thread 1 opened at log sequence 8
  19.   Current log# 2 seq# 8 mem# 0: /u01/app/oracle/oradata/HOEGH/redo02.log
  20. Successful open of redo thread 1
  21. MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
  22. Sat May 09 22:16:35 2015
  23. SMON: enabling cache recovery
  24. [5095] Successfully onlined Undo Tablespace 2.
  25. Undo initialization finished serial:0 start:4294562150 end:4294562220 diff:70 (0 seconds)
  26. Verifying file header compatibility for 11g tablespace encryption..
  27. Verifying 11g file header compatibility for tablespace encryption completed
  28. SMON: enabling tx recovery
  29. Database Characterset is AL32UTF8
  30. No Resource Manager plan active
  31. replication_dependency_tracking turned off (no async multimaster replication found)
  32. Starting background process QMNC
  33. Sat May 09 22:16:35 2015
  34. QMNC started with pid=22, OS id=5274
  35. Completed: alter database open
  36. Sat May 09 22:16:36 2015
  37. Starting background process CJQ0
  38. Sat May 09 22:16:36 2015
  39. CJQ0 started with pid=24, OS id=5296
這一階段資料庫讀取控制檔案中描述的資料檔案驗證資料檔案的一致性,如果不一致,使用日誌檔案將資料庫檔案恢復到一致的狀態。資料庫open後,普通使用者才可以訪問資料庫。

~~~~~~~ the end~~~~~~~~~
hoegh
2015.05.09
      

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30162081/viewspace-1631808/,如需轉載,請註明出處,否則將追究法律責任。

相關文章