小弟在window XP 上安装了 oracle 10g
成功安装并创建数据库之后发现实例经常会自动关闭
下面是贴出的一些log小弟是数据库方面的菜鸟
望各位老大多指正Dump file d:\oracle\product\10.1.0\admin\oracle\bdump\alert_oracle.log
Sat Mar 07 00:44:35 2009
ORACLE V10.1.0.2.0 - Production vsnsta=0
vsnsql=13 vsnxtr=3
Windows XP Version V5.1 Service Pack 3
CPU             : 2 - type 586, 2 Physical Cores
Process Affinity: 0x00000000
Memory (A/P)    : PH:1280M/2045M, PG:22233M/22887M, VA:1957M/2047M
Sat Mar 07 00:44:35 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
KCCDEBUG_LEVEL = 0
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
Dynamic strands is set to TRUE
Running with 2 shared and 18 private strand(s). Zero-copy redo is FALSE
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 10.1.0.2.0.
System parameters with non-default values:
  processes                = 150
  shared_pool_size         = 83886080
  large_pool_size          = 8388608
  java_pool_size           = 50331648
  control_files            = D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORACLE\CONTROL01.CTL, D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORACLE\CONTROL02.CTL, D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORACLE\CONTROL03.CTL
  db_block_size            = 8192
  db_cache_size            = 25165824
  compatible               = 10.1.0.2.0
  db_file_multiblock_read_count= 16
  db_recovery_file_dest    = D:\oracle\product\10.1.0\flash_recovery_area
  db_recovery_file_dest_size= 2147483648
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain                = 
  dispatchers              = (PROTOCOL=TCP) (SERVICE=oracleXDB)
  job_queue_processes      = 10
  background_dump_dest     = D:\ORACLE\PRODUCT\10.1.0\ADMIN\ORACLE\BDUMP
  user_dump_dest           = D:\ORACLE\PRODUCT\10.1.0\ADMIN\ORACLE\UDUMP
  core_dump_dest           = D:\ORACLE\PRODUCT\10.1.0\ADMIN\ORACLE\CDUMP
  sort_area_size           = 65536
  db_name                  = oracle
  open_cursors             = 300
  pga_aggregate_target     = 25165824
PMON started with pid=2, OS id=3452
MMAN started with pid=3, OS id=864
DBW0 started with pid=4, OS id=4084
LGWR started with pid=5, OS id=1952
CKPT started with pid=6, OS id=988
SMON started with pid=7, OS id=1108
RECO started with pid=8, OS id=1232
Sat Mar 07 00:44:35 2009
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
CJQ0 started with pid=9, OS id=668
Sat Mar 07 00:44:35 2009
starting up 1 shared server(s) ...
Sat Mar 07 00:44:35 2009
alter database mount exclusive
Sat Mar 07 00:44:35 2009
Controlfile identified with block size 16384
Sat Mar 07 00:44:40 2009
Setting recovery target incarnation to 2
Sat Mar 07 00:44:40 2009
Successful mount of redo thread 1, with mount id 1553929523
Sat Mar 07 00:44:40 2009
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Sat Mar 07 00:44:40 2009
alter database open
Sat Mar 07 00:44:41 2009
Maximum redo generation record size = 120832 bytes
Maximum redo generation change vector size = 116476 bytes
Private_strands 4 at log switch
Thread 1 opened at log sequence 10
  Current log# 3 seq# 10 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORACLE\REDO03.LOG
Successful open of redo thread 1
Sat Mar 07 00:44:41 2009
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Mar 07 00:44:41 2009
SMON: enabling cache recovery
Sat Mar 07 00:44:41 2009
Successfully onlined Undo Tablespace 1.
Sat Mar 07 00:44:41 2009
SMON: enabling tx recovery
Sat Mar 07 00:44:41 2009
Database Characterset is ZHS16GBK
Sat Mar 07 00:44:41 2009
Published database character set on system events channel
Sat Mar 07 00:44:41 2009
All processes have switched to database character set
Sat Mar 07 00:44:43 2009
Starting background process QMNC
QMNC started with pid=13, OS id=1600
Sat Mar 07 00:44:45 2009
replication_dependency_tracking turned off (no async multimaster replication found)
Sat Mar 07 00:44:46 2009
Starting background process MMON
Starting background process MMNL
MMON started with pid=14, OS id=1840
MMNL started with pid=15, OS id=3628
Sat Mar 07 00:44:48 2009
Completed: alter database open
Sat Mar 07 00:44:51 2009
db_recovery_file_dest_size of 2048 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.
Sat Mar 07 00:45:35 2009
Starting background process EMN0
EMN0 started with pid=18, OS id=3204
Sat Mar 07 00:45:35 2009
Shutting down instance: further logons disabled
Sat Mar 07 00:45:35 2009
Stopping background process QMNC
Sat Mar 07 00:45:35 2009
Stopping background process CJQ0
Sat Mar 07 00:45:37 2009
Stopping background process MMNL
Sat Mar 07 00:45:38 2009
Stopping background process MMON
Sat Mar 07 00:45:39 2009
Shutting down instance (immediate)
License high water  = 2
Sat Mar 07 00:45:39 2009
Stopping Job queue slave processes
Sat Mar 07 00:45:39 2009
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Sat Mar 07 00:45:45 2009
alter database close normal
Sat Mar 07 00:45:46 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Sat Mar 07 00:45:46 2009
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 10
Successful close of redo thread 1
Sat Mar 07 00:45:47 2009
Completed: alter database close normal
Sat Mar 07 00:45:47 2009
alter database dismount
Completed: alter database dismount
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active

解决方案 »

  1.   

    Sat Mar 07 00:45:35 2009 
    Starting background process [color=#0000FF]EMN0 

    EMN0 started with pid=18, OS id=3204 [/color]
    问题好像在这里.
      

  2.   

    Event Monitor – EMN0
    This process is also associated with Advanced Queuing. It is responsible for the asynchronous notification of subscribers that have registered a callback request for particular messages.和AQ有关,楼主之前在oem里面尝试过删除数据库么?
    confused
      

  3.   

    查了一下,发现EMN0这个是被关闭数据库的操作触发起来的进程,不是这个进程的原因导致关闭的,正常关闭的数据库也会有样的信息的
    This message occurs because there is a trigger which is installed with the JVM that fires at shutdown that 'wakes' up the EMN0 process. By itself, the message shouldn't be a concern.