重启服务器要先停MySQL吗_oracle服务器重启需先用命令关闭数据库吗?

本帖最后由 hbm1985 于 2012-5-19 22:56 编辑

以下是测试过程:

Sat May 19 22:28:48 2012

Completed: alter database open -----此处打开了数据库

22:30:29 重启了OS ,记录日志为test oracle (并没有手动关闭数据库),见图

Sat May 19 22:31:59 2012

Beginning crash recovery of 1 threads             ---此处实例恢复

在日志中,没有发现shutodwn database的信息.可以认为是crash掉了.

可见,不关闭数据库,就重启OS,是不安全的.

Sat May 19 22:28:48 2012

Completed: alter database open -----此处打开了数据库

Dump file c:\oracle\product\10.2.0/admin/orcl/bdump\alert_orcl.log

Sat May 19 22:31:51 2012

ORACLE V10.2.0.1.0 - Production vsnsta=0

vsnsql=14 vsnxtr=3

Windows Server 2003 Version V5.2 Service Pack 2

CPU                 : 2 - type 586, 1 Physical Cores

Process Affinity    : 0x00000000

Memory (Avail/Total): Ph:339M/511M, Ph+PgF:911M/1043M, VA:1938M/2047M

Sat May 19 22:31:51 2012

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 2

Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =18

LICENSE_MAX_USERS = 0

SYS auditing is disabled

ksdpec: called for event 13740 prior to event group initialization

Starting up ORACLE RDBMS Version: 10.2.0.1.0.

System parameters with non-default values:

processes                = 150

sga_max_size             = 159383552

__shared_pool_size       = 71303168

__large_pool_size        = 4194304

__java_pool_size         = 4194304

__streams_pool_size      = 4194304

spfile                   = C:\ORACLE\PRODUCT\10.2.0\DB_1\DBS\SPFILEORCL.ORA

nls_language             = SIMPLIFIED CHINESE

nls_territory            = CHINA

sga_target               = 159383552

control_files            = C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL, C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL,

C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL

db_block_size            = 8192

__db_cache_size          = 67108864

compatible               = 10.2.0.1.0

log_archive_dest_1       =

log_archive_format       = ARC%S_%R.%T

db_file_multiblock_read_count= 16

db_recovery_file_dest    = C:\oracle\product\10.2.0/flash_recovery_area

db_recovery_file_dest_size= 2147483648

undo_management          = AUTO

undo_tablespace          = UNDOTBS1

recyclebin               = OFF

remote_login_passwordfile= EXCLUSIVE

db_domain                =

dispatchers              = (PROTOCOL=TCP) (SERVICE=orclXDB)

job_queue_processes      = 10

audit_file_dest          = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\ADUMP

background_dump_dest     = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\BDUMP

user_dump_dest           = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP

core_dump_dest           = C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\CDUMP

db_name                  = orcl

open_cursors             = 300

pga_aggregate_target     = 124780544

PMON started with pid=2, OS id=1880

PSP0 started with pid=3, OS id=1896

MMAN started with pid=4, OS id=1900

DBW0 started with pid=5, OS id=1940

LGWR started with pid=6, OS id=1956

CKPT started with pid=7, OS id=1968

SMON started with pid=8, OS id=1988

RECO started with pid=9, OS id=2028

CJQ0 started with pid=10, OS id=2036

MMON started with pid=11, OS id=240

MMNL started with pid=12, OS id=544

Sat May 19 22:31:53 2012

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

Sat May 19 22:31:54 2012

alter database mount exclusive

Sat May 19 22:31:58 2012

Setting recovery target incarnation to 2

Sat May 19 22:31:59 2012

Successful mount of redo thread 1, with mount id 1311522394

Sat May 19 22:31:59 2012

Database mounted in Exclusive Mode

Completed: alter database mount exclusive

Sat May 19 22:31:59 2012

alter database open

Sat May 19 22:31:59 2012

Beginning crash recovery of 1 threads             ---此处实例恢复

parallel recovery started with 2 processes

Sat May 19 22:32:00 2012

Started redo scan

Sat May 19 22:32:01 2012

Completed redo scan

3272 redo blocks read, 298 data blocks need recovery

Sat May 19 22:32:02 2012

Started redo application at

Thread 1: logseq 95, block 3

Sat May 19 22:32:02 2012

Recovery of Online Redo Log: Thread 1 Group 1 Seq 95 Reading mem 0

Mem# 0 errs 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG

Sat May 19 22:32:02 2012

Completed redo application

Sat May 19 22:32:04 2012

Completed crash recovery at

Thread 1: logseq 95, block 3275, scn 1930015

298 data blocks read, 298 data blocks written, 3272 redo blocks read

Sat May 19 22:32:05 2012

LGWR: STARTING ARCH PROCESSES

ARC0 started with pid=18, OS id=1980

ARC1 started with pid=19, OS id=1992

Sat May 19 22:32:05 2012

ARC0: Archival started

ARC1: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

Thread 1 advanced to log sequence 96

Thread 1 opened at log sequence 96

Current log# 2 seq# 96 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Successful open of redo thread 1

Sat May 19 22:32:06 2012

ARC1: STARTING ARCH PROCESSES

Sat May 19 22:32:06 2012

ARC0: Becoming the 'no FAL' ARCH

ARC0: Becoming the 'no SRL' ARCH

Sat May 19 22:32:06 2012

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Sat May 19 22:32:06 2012

SMON: enabling cache recovery

ARC2 started with pid=20, OS id=512

Sat May 19 22:32:06 2012

ARC2: Archival started

ARC1: STARTING ARCH PROCESSES COMPLETE

ARC1: Becoming the heartbeat ARCH

db_recovery_file_dest_size of 2048 MB is 30.54% 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.

Sat May 19 22:32:08 2012

Successfully onlined Undo Tablespace 1.

Sat May 19 22:32:08 2012

SMON: enabling tx recovery

Sat May 19 22:32:08 2012

Database Characterset is AL32UTF8

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

QMNC started with pid=21, OS id=2052

Sat May 19 22:32:10 2012

Completed: alter database open

123.png

(12.77 KB, 下载次数: 18)

2012-5-19 22:41 上传