Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2017-4-13 14:45:03 | 查看: 1339| 回复: 0

数据库断电起不来了,原本很简单的为什么我的就不好使。。各种方法都试了。是不是要用bbed修改数据块?
以下是alertlog:
Thu Jul 30 22:23:31 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned off.
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.4.0.
System parameters with non-default values:
  processes                = 500
  __shared_pool_size       = 553648128
  __large_pool_size        = 16777216
  __java_pool_size         = 16777216
  __streams_pool_size      = 0
  sga_target               = 2801795072
  control_files            = /u01/app/oracle/oradata/orcl/control02.ctl
  db_block_size            = 16384
  __db_cache_size          = 2197815296
  db_writer_processes      = 2
  compatible               = 10.2.0.3.0
  log_archive_dest         = /opt/oracle/oradata/rundata/arc
  log_archive_format       = arch_%t_%s_%r.arc
  db_file_multiblock_read_count= 64
  db_recovery_file_dest    = /opt/oracle/oradata/rundata/flashback_dest
  db_recovery_file_dest_size= 4294967296
  _allow_resetlogs_corruption= TRUE
  _corrupted_rollback_segments= _SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$, _SYSSMU11$, _SYSSMU12$, _SYSSMU13$, _SYSSMU14$, _SYSSMU15$, _SYSSMU16$, _SYSSMU17$, _SYSSMU18$, _SYSSMU19$, _SYSSMU20$, _SYSSMU21$, _SYSSMU22$, _SYSSMU23$, _SYSSMU24$, _SYSSMU25$, _SYSSMU26$, _SYSSMU27$, _SYSSMU28$, _SYSSMU29$, _SYSSMU30$
  undo_management          = MANUAL
  undo_tablespace          =
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  global_names             = FALSE
  dispatchers              = (PROTOCOL=TCP) (SERVICE=orclXDB)
  session_cached_cursors   = 200
  utl_file_dir             = /home/oracle
  job_queue_processes      = 10
  cursor_sharing           = FORCE
  background_dump_dest     = /u01/app/oracle/admin/orcl/bdump
  user_dump_dest           = /u01/app/oracle/admin/orcl/udump
  core_dump_dest           = /u01/app/oracle/admin/orcl/cdump
  audit_file_dest          = /u01/app/oracle/admin/orcl/adump
  open_links               = 100
  db_name                  = orcl
  open_cursors             = 300
  pga_aggregate_target     = 404750336
PMON started with pid=2, OS id=25092
PSP0 started with pid=3, OS id=25094
MMAN started with pid=4, OS id=25096
DBW0 started with pid=5, OS id=25098
DBW1 started with pid=6, OS id=25100
LGWR started with pid=7, OS id=25102
CKPT started with pid=8, OS id=25104
SMON started with pid=9, OS id=25106
RECO started with pid=10, OS id=25108
CJQ0 started with pid=11, OS id=25110
MMON started with pid=12, OS id=25112
Thu Jul 30 22:23:32 2015
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=13, OS id=25114
Thu Jul 30 22:23:32 2015
starting up 1 shared server(s) ...
Thu Jul 30 22:23:32 2015
ALTER DATABASE   MOUNT
Thu Jul 30 22:23:36 2015
Setting recovery target incarnation to 3
Thu Jul 30 22:23:36 2015
Successful mount of redo thread 1, with mount id 1414263780
Thu Jul 30 22:23:36 2015
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Thu Jul 30 22:23:36 2015
ALTER DATABASE OPEN
Thu Jul 30 22:23:37 2015
Beginning crash recovery of 1 threads
parallel recovery started with 7 processes
Thu Jul 30 22:23:37 2015
Started redo scan
Thu Jul 30 22:23:37 2015
Completed redo scan
2 redo blocks read, 0 data blocks need recovery
Thu Jul 30 22:23:37 2015
Started redo application at
Thread 1: logseq 11, block 3
Thu Jul 30 22:23:37 2015
Recovery of Online Redo Log: Thread 1 Group 2 Seq 11 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/orcl/redo02.log
Thu Jul 30 22:23:37 2015
Completed redo application
Thu Jul 30 22:23:37 2015
Completed crash recovery at
Thread 1: logseq 11, block 5, scn 12288061293776
0 data blocks read, 0 data blocks written, 2 redo blocks read
Thu Jul 30 22:23:37 2015
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=24, OS id=25137
Thu Jul 30 22:23:37 2015
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=25, OS id=25139
Thu Jul 30 22:23:37 2015
Thread 1 advanced to log sequence 12 (thread open)
Thu Jul 30 22:23:37 2015
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Thu Jul 30 22:23:37 2015
ARC1: Becoming the heartbeat ARCH
Thu Jul 30 22:23:37 2015
Thread 1 opened at log sequence 12
  Current log# 3 seq# 12 mem# 0: /u01/app/oracle/oradata/orcl/redo03.log
Successful open of redo thread 1
Thu Jul 30 22:23:37 2015
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jul 30 22:23:37 2015
Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_arc0_25137.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 4294967296 bytes is 99.70% used, and has 13027328 remaining bytes available.
Thu Jul 30 22:23:37 2015
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
Thu Jul 30 22:23:37 2015
SMON: enabling cache recovery
Thu Jul 30 22:23:37 2015
Errors in file /u01/app/oracle/admin/orcl/udump/orcl_ora_25121.trc:
ORA-00600: internal error code, arguments: [4194], [62], [50], [], [], [], [], []
Thu Jul 30 22:23:39 2015
Doing block recovery for file 1 block 33722
Block recovery from logseq 12, block 3 to scn 12288061293784
Thu Jul 30 22:23:39 2015
Recovery of Online Redo Log: Thread 1 Group 3 Seq 12 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/orcl/redo03.log
Block recovery stopped at EOT rba 12.5.16
Block recovery completed at rba 12.5.16, scn 2861.159859926
Doing block recovery for file 1 block 5
Block recovery from logseq 12, block 3 to scn 12288061293781
Thu Jul 30 22:23:39 2015
Recovery of Online Redo Log: Thread 1 Group 3 Seq 12 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/orcl/redo03.log
Block recovery completed at rba 12.5.16, scn 2861.159859926
Thu Jul 30 22:23:39 2015
Errors in file /u01/app/oracle/admin/orcl/udump/orcl_ora_25121.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [62], [50], [], [], [], [], []
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Instance terminated by USER, pid = 25121
ORA-1092 signalled during: ALTER DATABASE OPEN...
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-20 14:52 , Processed in 0.046263 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569