电脑突然断电后无法启动

ALLSTARS_ORACLE

数据库 oracle10.2.0.3

如图 12:16 开机 自动启动数据库后 其他文件都更新了 redo时间未更新 估计是这里出问题了？

alter_log里面的日志如下

Mon Apr 01 12:16:00 2013
ORACLE V10.2.0.3.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 16 - type 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:31357M/32756M, Ph+PgF:33463M/33847M, VA:3976M/4095M
Mon Apr 01 12:16:00 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 1000
LICENSE_SESSIONS_WARNING = 1000
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 =121
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.3.0.
System parameters with non-default values:
  processes                = 1000
  sessions                 = 1105
  license_max_sessions     = 1000
  license_sessions_warning = 1000
  __shared_pool_size       = 427819008
  __large_pool_size        = 8388608
  __java_pool_size         = 8388608
  __streams_pool_size      = 8388608
  sga_target               = 1258291200
  control_files            = Z:\ORACLE\PRODUCT\10.2.0\ORADATA\SWFACE\CONTROL01.CTL, Z:\ORACLE\PRODUCT\10.2.0\ORADATA\SWFACE\CONTROL02.CTL, Z:\ORACLE\PRODUCT\10.2.0\ORADATA\SWFACE\CONTROL03.CTL
  db_block_size            = 8192
  __db_cache_size          = 796917760
  compatible               = 10.2.0.3.0
  db_file_multiblock_read_count= 16
  db_recovery_file_dest    = Z:\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=SWFaceXDB)
  session_cached_cursors   = 1000
  job_queue_processes      = 10
  audit_file_dest          = Z:\ORACLE\PRODUCT\10.2.0\ADMIN\SWFACE\ADUMP
  background_dump_dest     = Z:\ORACLE\PRODUCT\10.2.0\ADMIN\SWFACE\BDUMP
  user_dump_dest           = Z:\ORACLE\PRODUCT\10.2.0\ADMIN\SWFACE\UDUMP
  core_dump_dest           = Z:\ORACLE\PRODUCT\10.2.0\ADMIN\SWFACE\CDUMP
  session_max_open_files   = 1000
  db_name                  = SWFace
  open_cursors             = 300
  pga_aggregate_target     = 418381824
PSP0 started with pid=4, OS id=2776
MMAN started with pid=6, OS id=2780
DBW0 started with pid=8, OS id=2808
DBW1 started with pid=10, OS id=2812
LGWR started with pid=12, OS id=2816
CKPT started with pid=14, OS id=2820
SMON started with pid=16, OS id=2824
RECO started with pid=18, OS id=2828
CJQ0 started with pid=20, OS id=2832
MMON started with pid=22, OS id=2836
Mon Apr 01 12:16:03 2013
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=24, OS id=2840
Mon Apr 01 12:16:03 2013
starting up 1 shared server(s) ...
Mon Apr 01 12:16:04 2013
alter database mount exclusive
PMON started with pid=2, OS id=2772
Setting recovery target incarnation to 2
Mon Apr 01 12:16:08 2013
Successful mount of redo thread 1, with mount id 2957411652
Mon Apr 01 12:16:08 2013
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Mon Apr 01 12:16:08 2013
alter database open
ORA-1113 signalled during: alter database open...
Mon Apr 01 12:29:52 2013
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.
Mon Apr 01 13:51:59 2013
WARNING: inbound connection timed out (ORA-3136)
Mon Apr 01 14:04:40 2013
WARNING: inbound connection timed out (ORA-3136)

数据库里面有大量图片 我初来乍到 不敢乱动了，求大神支援

ALLSTARS_ORACLE

redo002.log  最后修改日期 2013-3-25 12:02
redo003.log  最后修改日期 2013-3-28 10:11
redo001.log  最后修改日期 2013-3-28 14:30
control01.ctl 最后修改日期 2013-4-1 12:16
control02.ctl 最后修改日期 2013-4-1 12:16
control03.ctl 最后修改日期 2013-4-1 12:16

12:16重新开机 然后自动启动的数据库 控制文件的时间更新了 重做日志没更新



我重启数据库后 提示'xxx\xxx.dbf'需要恢复 我执行 recover datafile 后 出现一个选项<suggestion/filename/auto/cancel> 我输入前三个都提示出错 只能输入cancel 输入后提示recover 但是alter database open的时候还是提示需要修复 怎么办啊


我现在能startup mount 说明控制文件没坏，然后redolog 日期比较旧 是不是 执行：
recover database until cancel;
alter database open resetlogs;
就可以恢复到redolog的那个时间点啊 我对于新插入的数据没什么要求 丢就丢了 只能能让数据库启动起来就行。