今天在的我的群里有人对Oracle 数据库
启动
startup和startup force进行了讨论
其实这种命令类型的问题也没什么可讨论的,只要自己执行下startup force的同时看下alert日志,就可以总结出来区别,而且很有说服力。
1. startup
就是正常启动数据库,没什么好说的。
2. startup force
是shutdown abort + startup的组合,即强制关闭数据库+ 正常启动数据库,想快速重启数据库时胆子大的人用的。
startup force测试
在一个窗口执行startup force 命令
同时监控后台数据库的alert日志
其实这种命令类型的问题也没什么可讨论的,只要自己执行下startup force的同时看下alert日志,就可以总结出来区别,而且很有说服力。
1. startup
就是正常启动数据库,没什么好说的。
2. startup force
是shutdown abort + startup的组合,即强制关闭数据库+ 正常启动数据库,想快速重启数据库时胆子大的人用的。
startup force测试
在一个窗口执行startup force 命令
点击(此处)折叠或打开
- [oracle@vm012odb018 ~]$ sqlplus "/as sysdba"
-
- SQL*Plus: Release 11.2.0.4.0 Production on Fri Dec 20 10:16:29 2013
-
- Copyright (c) 1982, 2013, Oracle. All rights reserved.
-
-
- Connected to:
- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
- With the Partitioning, Oracle Label Security, OLAP, Data Mining
- and Real Application Testing options
-
- SQL> startup force
- ORACLE instance started.
-
- Total System Global Area 3340451840 bytes
- Fixed Size 2257840 bytes
- Variable Size 1929382992 bytes
- Database Buffers 1392508928 bytes
- Redo Buffers 16302080 bytes
- Database mounted.
- Database opened.
- SQL>
点击(此处)折叠或打开
- [root@vm012odb018 ~]# su - oracle
- [oracle@vm012odb018 ~]$ cd app/diag/rdbms/ledb01/LEDB01/trace/
- [oracle@vm012odb018 trace]$ tailf alert_LEDB01.log
- Archived Log entry 344 added for thread 1 sequence 344 ID 0xc87c495a dest 1:
- Fri Dec 20 02:00:00 2013
- Closing scheduler window
- Closing Resource Manager plan via scheduler window
- Clearing Resource Manager plan via parameter
- Fri Dec 20 02:00:08 2013
- Thread 1 advanced to log sequence 346 (LGWR switch)
- Current log# 1 seq# 346 mem# 0: /home/oracle/app/oradata/LEDB01/redo01.log
- Fri Dec 20 02:00:09 2013
- Archived Log entry 345 added for thread 1 sequence 345 ID 0xc87c495a dest 1:
-
-
以下为startup force的日志 -
-
-
- Fri Dec 20 10:17:17 2013
-
- --数据库被shutdown abort
-
- Shutting down instance (abort)
- License high water mark = 9
- USER (ospid: 23328): terminating the instance
- Instance terminated by USER, pid = 23328
- Fri Dec 20 10:17:18 2013
- Instance shutdown complete
- Fri Dec 20 10:17:19 2013 --启动数据库startup
- Starting ORACLE instance (normal)
- LICENSE_MAX_SESSION = 0
- LICENSE_SESSIONS_WARNING = 0
- Initial number of CPU is 1
- CELL communication is configured to use 0 interface(s):
- CELL IP affinity details:
- NUMA status: non-NUMA system
- cellaffinity.ora status: N/A
- CELL communication will use 1 IP group(s):
- Grp 0:
- Picked latch-free SCN scheme 3
- Autotune of undo retention is turned on.
- IMODE=BR
- ILAT =51
- LICENSE_MAX_USERS = 0
- SYS auditing is disabled
- Starting up:
- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
- With the Partitioning, Oracle Label Security, OLAP, Data Mining
- and Real Application Testing options.
- ORACLE_HOME = /home/oracle/app/product/11.2.0.4/db_1
- System name: Linux
- Node name: vm012odb018
- Release: 2.6.18-238.el5
- Version: #1 SMP Thu Jan 13 15:51:15 EST 2011
- Machine: x86_64
- Using parameter settings in server-side spfile /home/oracle/app/product/11.2.0.4/db_1/dbs/spfileLEDB01.ora
- System parameters with non-default values:
- processes = 300
- sessions = 472
- event = ""
- nls_language = "AMERICAN"
- nls_territory = "AMERICA"
- memory_target = 3200M
- control_files = "/home/oracle/app/oradata/LEDB01/control01.ctl"
- control_files = "/home/oracle/app/flash_recovery_area/LEDB01/control02.ctl"
- db_block_size = 8192
- compatible = "11.2.0.0.0"
- log_archive_dest_1 = "location=/home/oracle/archivelog"
- db_recovery_file_dest = "/home/oracle/app/flash_recovery_area"
- db_recovery_file_dest_size= 3882M
- undo_tablespace = "UNDOTBS1"
- remote_login_passwordfile= "EXCLUSIVE"
- db_domain = ""
- dispatchers = "(PROTOCOL=TCP) (SERVICE=LEDB01XDB)"
- audit_file_dest = "/home/oracle/app/admin/LEDB01/adump"
- audit_trail = "DB"
- db_name = "LEDB01"
- open_cursors = 300
- deferred_segment_creation= FALSE
- diagnostic_dest = "/home/oracle/app"
- Fri Dec 20 10:17:21 2013
- PMON started with pid=2, OS id=23423
- Fri Dec 20 10:17:21 2013
- PSP0 started with pid=3, OS id=23427
- Fri Dec 20 10:17:22 2013
- VKTM started with pid=4, OS id=23431
- VKTM running at (100ms) precision
- Fri Dec 20 10:17:22 2013
- GEN0 started with pid=5, OS id=23437
- Fri Dec 20 10:17:22 2013
- DIAG started with pid=6, OS id=23441
- Fri Dec 20 10:17:22 2013
- DBRM started with pid=7, OS id=23445
- Fri Dec 20 10:17:22 2013
- DIA0 started with pid=8, OS id=23449
- Fri Dec 20 10:17:22 2013
- MMAN started with pid=9, OS id=23453
- Fri Dec 20 10:17:22 2013
- DBW0 started with pid=10, OS id=23457
- Fri Dec 20 10:17:23 2013
- LGWR started with pid=11, OS id=23461
- Fri Dec 20 10:17:23 2013
- CKPT started with pid=12, OS id=23465
- Fri Dec 20 10:17:23 2013
- SMON started with pid=13, OS id=23469
- Fri Dec 20 10:17:23 2013
- RECO started with pid=14, OS id=23473
- Fri Dec 20 10:17:23 2013
- MMON started with pid=15, OS id=23477
- starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
- Fri Dec 20 10:17:23 2013
- MMNL started with pid=16, OS id=23481
- starting up 1 shared server(s) ...
- ORACLE_BASE from environment = /home/oracle/app
- Fri Dec 20 10:17:23 2013
- ALTER DATABASE MOUNT
- Successful mount of redo thread 1, with mount id 3372810867
- Database mounted in Exclusive Mode
- Lost write protection disabled
- Completed: ALTER DATABASE MOUNT
- Fri Dec 20 10:17:27 2013
- ALTER DATABASE OPEN
- Beginning crash recovery of 1 threads
- Started redo scan
- Completed redo scan
- read 129 KB redo, 50 data blocks need recovery
- Started redo application at
- Thread 1: logseq 346, block 45315
- Recovery of Online Redo Log: Thread 1 Group 1 Seq 346 Reading mem 0
- Mem# 0: /home/oracle/app/oradata/LEDB01/redo01.log
- Completed redo application of 0.03MB
- Completed crash recovery at
- Thread 1: logseq 346, block 45573, scn 10747900
- 50 data blocks read, 50 data blocks written, 129 redo k-bytes read
- LGWR: STARTING ARCH PROCESSES
- Fri Dec 20 10:17:28 2013
- ARC0 started with pid=20, OS id=23510
- ARC0: Archival started
- LGWR: STARTING ARCH PROCESSES COMPLETE
- ARC0: STARTING ARCH PROCESSES
- Fri Dec 20 10:17:29 2013
- ARC1 started with pid=21, OS id=23514
- Fri Dec 20 10:17:29 2013
- ARC2 started with pid=22, OS id=23518
- Thread 1 advanced to log sequence 347 (thread open)
- Thread 1 opened at log sequence 347
- Current log# 2 seq# 347 mem# 0: /home/oracle/app/oradata/LEDB01/redo02.log
- Successful open of redo thread 1
- MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
- SMON: enabling cache recovery
- ARC1: Archival started
- ARC2: Archival started
- ARC1: Becoming the 'no FAL' ARCH
- ARC1: Becoming the 'no SRL' ARCH
- ARC2: Becoming the heartbeat ARCH
- Fri Dec 20 10:17:29 2013
- ARC3 started with pid=23, OS id=23522
- Archived Log entry 346 added for thread 1 sequence 346 ID 0xc87c495a dest 1:
- [23506] Successfully onlined Undo Tablespace 2.
- Undo initialization finished serial:0 start:261251664 end:261251884 diff:220 (2 seconds)
- Verifying file header compatibility for 11g tablespace encryption..
- Verifying 11g file header compatibility for tablespace encryption completed
- SMON: enabling tx recovery
- ARC3: Archival started
- ARC0: STARTING ARCH PROCESSES COMPLETE
- Database Characterset is AL32UTF8
- No Resource Manager plan active
- replication_dependency_tracking turned off (no async multimaster replication found)
- Starting background process QMNC
- Fri Dec 20 10:17:32 2013
- QMNC started with pid=24, OS id=23530
- Completed: ALTER DATABASE OPEN
- Fri Dec 20 10:17:36 2013
- db_recovery_file_dest_size of 3882 MB is 0.00% used. This is a
- user-specified limit on the amount of space that will be used by this
- database for recovery-related files, and does not reflect the amount of
- space available in the underlying filesystem or ASM diskgroup.
- Fri Dec 20 10:17:36 2013
- Starting background process CJQ0
- Fri Dec 20 10:17:36 2013
- CJQ0 started with pid=25, OS id=23560
- Fri Dec 20 10:22:32 2013
- Starting background process SMCO
- Fri Dec 20 10:22:32 2013
- SMCO started with pid=28, OS id=23620
-
- oracle正常启动,startup force的全过程都在日志中体现。