求帮助,ORA-1578,ORA-01092错误,谢谢

杰克牌辣酱 2011-11-15 04:29:08
打开数据库的时候遇到ORA-01092: ORACLE instance terminated. Disconnection forced错误,查看alert日志内容如下:

Tue Nov 15 15:47:39 2011
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
cpu_count = 2
__shared_pool_size = 188743680
__large_pool_size = 4194304
__java_pool_size = 4194304
__streams_pool_size = 0
sga_target = 591396864
control_files = /u01/app/oracle/oradata/orcl/control02.ctl, /u01/app/oracle/oradata/orcl/control03.ctl
db_block_size = 8192
__db_cache_size = 385875968
compatible = 10.2.0.1.0
db_file_multiblock_read_count= 8
db_recovery_file_dest = /u01/app/oracle/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=orclXDB)
job_queue_processes = 10
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
db_name = orcl
open_cursors = 300
pga_aggregate_target = 196083712
PSP0 started with pid=3, OS id=2796
PMON started with pid=2, OS id=2794
MMAN started with pid=4, OS id=2798
DBW0 started with pid=5, OS id=2800
LGWR started with pid=6, OS id=2802
CKPT started with pid=7, OS id=2804
SMON started with pid=8, OS id=2806
RECO started with pid=9, OS id=2808
CJQ0 started with pid=10, OS id=2810
MMON started with pid=11, OS id=2812
Tue Nov 15 15:47:41 2011
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=2814
Tue Nov 15 15:47:41 2011
starting up 1 shared server(s) ...
Tue Nov 15 15:47:42 2011
ALTER DATABASE MOUNT
Tue Nov 15 15:47:46 2011
Setting recovery target incarnation to 2
Tue Nov 15 15:47:46 2011
Successful mount of redo thread 1, with mount id 1295059870
Tue Nov 15 15:47:46 2011
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Tue Nov 15 15:47:53 2011
alter database open
Tue Nov 15 15:47:53 2011
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes
Tue Nov 15 15:47:53 2011
Started redo scan
Tue Nov 15 15:47:54 2011
Completed redo scan
1 redo blocks read, 0 data blocks need recovery
Tue Nov 15 15:47:54 2011
Started redo application at
Thread 1: logseq 14, block 2, scn 735161
Tue Nov 15 15:47:54 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 14 Reading mem 0
Mem# 0 errs 0: /u01/app/oracle/oradata/orcl/redo01.log
Mem# 1 errs 0: /u01/app/oracle/oradata/orcl/redo01b.log
Tue Nov 15 15:47:54 2011
Completed redo application
Tue Nov 15 15:47:54 2011
Completed crash recovery at
Thread 1: logseq 14, block 3, scn 755163
0 data blocks read, 0 data blocks written, 1 redo blocks read
Tue Nov 15 15:47:55 2011
Thread 1 advanced to log sequence 15
Thread 1 opened at log sequence 15
Current log# 2 seq# 15 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log
Current log# 2 seq# 15 mem# 1: /u01/app/oracle/oradata/orcl/redo02b.log
Successful open of redo thread 1
Tue Nov 15 15:47:55 2011
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Nov 15 15:47:55 2011
SMON: enabling cache recovery
Tue Nov 15 15:47:56 2011
Errors in file /u01/app/oracle/admin/orcl/udump/orcl_ora_2820.trc:
ORA-01578: ORACLE data block corrupted (file # 2, block # 57)
ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'
Tue Nov 15 15:47:56 2011
Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_dbw0_2800.trc:
ORA-01578: ORACLE data block corrupted (file # , block # )
Instance terminated by USER, pid = 2820
ORA-1092 signalled during: alter database open
...

数据库运行在noarchivelog模式下,现在数据库只能mount,open的时候就出现错误:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced

谢谢啦
...全文
189 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 huangdh12 的回复:]

试着借助参数_allow_resetlogs_corruption 参数,进行不验证的打开。
[/Quote]

undo坏块,不能回滚,你加这个有什么用?????
huangdh12 2011-11-24
  • 打赏
  • 举报
回复
试着借助参数_allow_resetlogs_corruption 参数,进行不验证的打开。
  • 打赏
  • 举报
回复
如果联系我,请使用qq,csdn我不是经常上
杰克牌辣酱 2011-11-16
  • 打赏
  • 举报
回复
还是不行
杰克牌辣酱 2011-11-15
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 huangdh12 的回复:]

先讲数据库的undo_management设置成 manual
打开数据库后,重建undo表空间
然后 将undo_management 修改成auto 同时修改参数中的undo_tablespace的值
[/Quote] undo_management设置成MANUAL了,还是不能打开数据库,提示ORA-01092
我心飞翔 2011-11-15
  • 打赏
  • 举报
回复
查看警告日志,看看是否有如下类似的警告信息:
ORA-30012: undo tablespace ‘UNDO_TBS’ does not exist or of wrong type

如果有说明需要重建表空间,具体操作如下:
SQL> startup mount

SQL> select name from v$datafile;

SQL> show parameter undo;

SQL> select name from v$tablespace;

SQL> alter system set undo_tablespace=’undotbs1′ scope=spfile;

SQL> shutdown immediate;

SQL> startup;

huangdh12 2011-11-15
  • 打赏
  • 举报
回复
先讲数据库的undo_management设置成 manual
打开数据库后,重建undo表空间
然后 将undo_management 修改成auto 同时修改参数中的undo_tablespace的值
oO寒枫Oo 2011-11-15
  • 打赏
  • 举报
回复
startup mount
杰克牌辣酱 2011-11-15
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 benchim888 的回复:]

重建一个undo 数据文件。。
[/Quote]
现在打不开数据库,无法创建undo表空间
杰克牌辣酱 2011-11-15
  • 打赏
  • 举报
回复
额。。。现在数据库打不开,不能创建表空间
  • 打赏
  • 举报
回复
undo坏块,如果需要联系我,帮你解决
杰克牌辣酱 2011-11-15
  • 打赏
  • 举报
回复
[Quote=引用楼主 jscpb 的回复:]
打开数据库的时候遇到ORA-01092: ORACLE instance terminated. Disconnection forced错误,查看alert日志内容如下:

Tue Nov 15 15:47:39 2011
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING……
[/Quote]
我试试
BenChiM888 2011-11-15
  • 打赏
  • 举报
回复
重建一个undo 数据文件。。
内容概要:本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密,无法通过常规strings命令或IDA直接识别。作者通过分析发现,加密字符串存储在.rodata段,其解密所需信息(包括密文地址、长度和16位密钥)保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法,结合固定密钥KEY_TERM(由.data段24字节数据计算得出),实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本,并揭示了该保护机制的本质为代码混淆而非强加密,最终成功批量解密全部956条字符串,暴露程序真实行为,如shell命令模板、设备标识篡改、网络重置等操作。此外,文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群:具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标:①学习ELF二进制中字符串加密的典型实现方式与逆向突破口;②掌握从结构识别、函数追踪到算法还原的完整逆向流程;③理解“绑定二进制”的完整性校验设计及其局限性;④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议:此资源以实战案例驱动,不仅展示技术细节,更强调逆向思维与验证方法,建议读者结合IDA调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。

3,499

社区成员

发帖
与我相关
我的任务
社区描述
Oracle 高级技术相关讨论专区
社区管理员
  • 高级技术社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧