oracle 服务启动之后又停止了

我用的oracle 10g R2 装在xp上。
我在xp服务管理下面启动服务之后，服务可以启动。然后我运行developer，运行一条查询语句之后，我的oracle的服务就停止了。下面是整个从启动到停止的alert.log日志。DBA能帮我分析下原因，给个解决的办法吗？
  谢谢了先！
Dump file d:\oracle\product\10.2.0/admin/orcl1/bdump\alert_orcl1.log
Sun Mar 08 22:52:25 2009
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows XP Version V5.1 Service Pack 2
CPU                 : 1 - type 586
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:264M/702M, Ph+PgF:1082M/1719M, VA:1940M/2047M
Sun Mar 08 22:52:25 2009
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
  __shared_pool_size       = 113246208
  __large_pool_size        = 4194304
  __java_pool_size         = 8388608
  __streams_pool_size      = 0
  spfile                   = D:\ORACLE\PRODUCT\10.2.0\DB_1\DBS\SPFILEORCL1.ORA
  nls_language             = SIMPLIFIED CHINESE
  nls_territory            = CHINA
  sga_target               = 188743680
  control_files            = D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL1\CONTROL01.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL1\CONTROL02.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL1\CONTROL03.CTL
  db_block_size            = 8192
  __db_cache_size          = 58720256
  compatible               = 10.2.0.1.0
  db_file_multiblock_read_count= 16
  db_recovery_file_dest    = D:\oracle\product\10.2.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=orcl1XDB)
  job_queue_processes      = 10
  audit_file_dest          = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL1\ADUMP
  background_dump_dest     = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL1\BDUMP
  user_dump_dest           = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL1\UDUMP
  core_dump_dest           = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL1\CDUMP
  db_name                  = orcl1
  open_cursors             = 300
  pga_aggregate_target     = 62914560
PMON started with pid=2, OS id=3428
PSP0 started with pid=3, OS id=4076
MMAN started with pid=4, OS id=3932
DBW0 started with pid=5, OS id=2848
LGWR started with pid=6, OS id=2884
CKPT started with pid=7, OS id=3168
SMON started with pid=8, OS id=4024
RECO started with pid=9, OS id=3416
CJQ0 started with pid=10, OS id=232
MMON started with pid=11, OS id=1664
MMNL started with pid=12, OS id=3088
Sun Mar 08 22:52:25 2009
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
Sun Mar 08 22:52:25 2009
alter database mount exclusive
Sun Mar 08 22:52:29 2009
Setting recovery target incarnation to 2
Sun Mar 08 22:52:30 2009
Successful mount of redo thread 1, with mount id 1065471465
Sun Mar 08 22:52:30 2009
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Sun Mar 08 22:52:30 2009
alter database open
Sun Mar 08 22:52:30 2009
Thread 1 opened at log sequence 10
  Current log# 3 seq# 10 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL1\REDO03.LOG
Successful open of redo thread 1
Sun Mar 08 22:52:30 2009
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Mar 08 22:52:30 2009
SMON: enabling cache recovery
Sun Mar 08 22:52:32 2009
Successfully onlined Undo Tablespace 1.
Sun Mar 08 22:52:32 2009
SMON: enabling tx recovery
Sun Mar 08 22:52:33 2009
Database Characterset is AL32UTF8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=16, OS id=2032
Sun Mar 08 22:52:41 2009
Completed: alter database open
Sun Mar 08 22:52:42 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.
Sun Mar 08 22:53:15 2009
Memory Notification: Library Cache Object loaded into SGA
Heap size 2360K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw== 


Sun Mar 08 22:53:29 2009
Starting background process EMN0
EMN0 started with pid=22, OS id=3124
Sun Mar 08 22:53:29 2009
Shutting down instance: further logons disabled
Sun Mar 08 22:53:30 2009
Stopping background process QMNC
Sun Mar 08 22:53:30 2009
Stopping background process CJQ0
Sun Mar 08 22:53:32 2009
Stopping background process MMNL
Sun Mar 08 22:53:33 2009
Stopping background process MMON
Sun Mar 08 22:53:34 2009
Shutting down instance (immediate)
License high water mark = 4
Sun Mar 08 22:53:34 2009
Stopping Job queue slave processes
Sun Mar 08 22:53:34 2009
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Sun Mar 08 22:53:42 2009
alter database close normal
Sun Mar 08 22:53:42 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Sun Mar 08 22:53:43 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
Sun Mar 08 22:53:43 2009
Completed: alter database close normal
Sun Mar 08 22:53:43 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

16 个解决方案

#1

检查以下磁盘空间

#2

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. 

好像是当前用户被分配的磁盘空间限额不够

#3

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. 


1.
利用rman清除一下db_recovery_file_dest_size.
使用rman登录数据库进行crosscheck：



$ rman target /

Recovery Manager: Release 10.1.0.2.0 - 64bit Production

Copyright (c) 1995, 2004, Oracle.  All rights reserved.

connected to target database: EYGLE (DBID=1337390772)

RMAN>  crosscheck archivelog all;

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK
validation failed for archived log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_05_17/o1_mf_1_790_0bjq36ps_.arc recid=1 stamp=526401126
validation failed for archived log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_05_17/o1_mf_1_791_0bkbcy7x_.arc recid=2 stamp=526420862
validation failed for archived log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_05_17/o1_mf_1_792_0bkkds4d_.arc recid=3 stamp=526428057
.......
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_07_16/o1_mf_1_1014_0hh3zsrp_.arc recid=225 stamp=531678074
validation failed for archived log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_07_16/o1_mf_1_1015_0hh40qyp_.arc recid=226 stamp=531678104
validation failed for archived log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
archivelog/2004_07_16/o1_mf_1_1016_0hh41jqq_.arc recid=227 stamp=531678129
Crosschecked 227 objects


RMAN> delete expired archivelog all;

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
1       1    790     X 17-MAY-04 /opt/oracle/flash_recovery_area/EYGLE/
......

Do you really want to delete the above objects (enter YES or NO)? YES
......
deleted archive log
archive log filename=/opt/oracle/flash_recovery_area/EYGLE/
......
RMAN> exit
Recovery Manager complete.


2或者增加 db_recovery_file_dest_size值
alter system set db_recovery_file_dest_size=4g;

#4

引用 3 楼 zxf_feng 的回复:

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. 


1. 
利用rman清除一下db_recovery_file_dest_size. 
使用rman登录数据库进行crosscheck： 


$ rman target / 

Recove…

不行 啊

#5

从日志上看不出什么问题,和正常关闭数据库的提示操作基本上一样.
问楼主是不是每次都是这样,一执行查询数据库就关闭.

#6

引用 5 楼 zcs_1 的回复:

从日志上看不出什么问题,和正常关闭数据库的提示操作基本上一样. 
问楼主是不是每次都是这样,一执行查询数据库就关闭.

难道是数据库版本不完善的问题？

#7

引用 5 楼 zcs_1 的回复:

从日志上看不出什么问题,和正常关闭数据库的提示操作基本上一样. 
问楼主是不是每次都是这样,一执行查询数据库就关闭.

现在是服务启动。然后我运行sqlplus username/pas as sysdba;
然后连接正常。但是一会儿就提示通信信道结束。

#8

引用 6 楼 oraclelogan 的回复:

引用 5 楼 zcs_1 的回复:
从日志上看不出什么问题,和正常关闭数据库的提示操作基本上一样. 
问楼主是不是每次都是这样,一执行查询数据库就关闭. 
 

难道是数据库版本不完善的问题？ 

似乎有点不对啊！以前都还是好好的。只是前段日子我不小心删除了数据文件。后来我通过dbca删除了数据库，然后在新建了个。不知道什么时候就成这样了！记得dbca之后我没有做其他的操作！

#9

不好办啊,试试重建吧,不行就把Oracle全部卸载了重建.

#10

引用 9 楼 zcs_1 的回复:

不好办啊,试试重建吧,不行就把Oracle全部卸载了重建.

这个本来就是重建 之后的库！ 删除数据库？反正是学习。为什么不多学点呢！ 
期待问题的解决方案。。。。。。。。。。

#11

检查一下系统和杀毒，实在没办法，那只有重装

#12

引用 11 楼 fzzlz 的回复:

检查一下系统和杀毒，实在没办法，那只有重装

是装的有问题。重新装吧

#13

安装是没有问题的。应为数据库一直运行没有问题的。只是由此我不小心删除了数据库文件，和日志文件。后来在恢复的过程中出的问题。

#14

引用 7 楼 maqinqin 的回复:

引用 5 楼 zcs_1 的回复:
从日志上看不出什么问题,和正常关闭数据库的提示操作基本上一样. 
问楼主是不是每次都是这样,一执行查询数据库就关闭. 
 

现在是服务启动。然后我运行sqlplus username/pas as sysdba; 
然后连接正常。但是一会儿就提示通信信道结束。

提示错误是什么，详细一点，
错误的过程中的日志贴一下

#15

该回复于2009-03-19 09:09:51被版主删除

#16

Sun Mar 08 22:53:15 2009 
Memory Notification: Library Cache Object loaded into SGA 
Heap size 2360K exceeds notification threshold (2048K) 
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw== 

这段的日志好像不全，问题应该是处在这里。