始创于2000年 股票代码:831685
咨询热线:0371-60135900 注册有礼 登录
  • 挂牌上市企业
  • 60秒人工响应
  • 99.99%连通率
  • 7*24h人工
  • 故障100倍补偿
您的位置: 网站首页 > 帮助中心>文章内容

ora-01190 ora-01110的解决方法

发布时间:  2012/9/5 17:06:25

SQLPLUS>ALTER DATABASE DATAFILE 2 ONLINE;
ALTER DATABASE DATAFILE 2 ONLINE
*
ERROR 位于第 1 行:
ORA-01190: 控制文件或数据文件2来自于最后一个 RESETLOGS 之前
ORA-01110: 数据文件 2: ‘E:\Oracle9I\ORA9I\UNDOTBS01.DBF’-
 

接下来由于V$DATAFILE中的CHECKPOINT_CHANGE#仍然大于V$RECOVER_FILE中的CHANGE#,决定用ADJUST_SCN来调整SCN.
首先需要设置_allow_resetlogs_corruption参数,否则不能成功(实验了)
SQLPLUS>ALTER SYSTEM SET “_allow_resetlogs_corruption”=TRUE SCOPE=SPFILE;
系统已更改。
SQLPLUS>SHUTDOWN IMMEDIATE
数据库已经关闭。
已经卸载数据库。
Oracle 例程已经关闭。
SQLPLUS>STARTUP MOUNT;
Oracle 例程已经启动。
Total System Global Area 135339940
bytes
Fixed Size 454564
bytes
Variable Size 109051904
bytes
Database Buffers 25165824
bytes
Redo Buffers 667648
bytes
数据库装载完毕。
SQLPLUS>ALTER DATABASE OPEN;
数据库已更改。
SQLPLUS>ALTER SESSION SET EVENTS ‘IMMEDIATE TRACE NAME ADJUST_SCN LEVEL 1′;
会话已更改。
SQLPLUS>SHUTDOWN IMMEDIATE
数据库已经关闭。
已经卸载数据库。
Oracle 例程已经关闭。
SQLPLUS>STARTUP MOUNT;
Oracle 例程已经启动。
Total System Global Area 135339940
bytes
Fixed Size 454564
bytes
Variable Size 109051904
bytes
Database Buffers 25165824
bytes
Redo Buffers 667648
bytes
数据库装载完毕。
SQLPLUS>SELECT TS#,FILE#,NAME,STATUS,CHECKPOINT_CHANGE# FROM V$DATAFILE;
TS# FILE# NAME STATUS CHECKPOINT_CHANGE#
—- —– —————————————- ——- ——————
0 1 E:\Oracle9I\ORA9I\SYSTEM01.DBF SYSTEM 1041478416
1 2 E:\Oracle9I\ORA9I\UNDOTBS01.DBF OFFLINE 0
3 3 E:\Oracle9I\ORA9I\DRSYS01.DBF OFFLINE 0
4 4 E:\Oracle9I\ORA9I\INDX01.DBF OFFLINE 0
5 5 E:\Oracle9I\ORA9I\TOOLS01.DBF OFFLINE 0
6 6 E:\Oracle9I\ORA9I\USERS01.DBF OFFLINE 0
7 7 E:\Oracle9I\ORA9I\XDB01.DBF OFFLINE 0
8 8 E:\Oracle9I\ORA9I\OEM_REPOSITORY.DBF OFFLINE 0
13 9 E:\Oracle9I\ORADATA\GAXZTEMP.DB OFFLINE 0
14 10 E:\Oracle9I\ORADATA\GAXZUSR.DB OFFLINE 0
15 11 E:\Oracle9I\ORADATA\GAXZRBS.DB OFFLINE 0
TS# FILE# NAME STATUS CHECKPOINT_CHANGE#
—- —– —————————————- ——- ——————
16 12 E:\Oracle9I\ORADATA\GAXZWEB.DB OFFLINE 0
已选择12行。
SQLPLUS>SELECT * FROM V$RECOVER_FILE;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
—– ——- ——- ——————– ————— ———-
2 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
3 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
4 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
5 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
6 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
7 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
8 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
9 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
10 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
11 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
12 OFFLINE OFFLINE WRONG FILE CREATE 37667 18-12月-04
已选择11行。
SQLPLUS>RECOVER UNTIL CANCEL;
完成介质恢复。
上面这一步很重要,虽然不做这个操作也能打开数据库,但是我们是要用RESETLOGS来打开数据库,否则仍然将其它数据文件联机的时候
仍然会报ORA-01189.
然后将数据文件状态联机。
SQLPLUS>ALTER DATABASE DATAFILE 2,3,4,5,6,7,8,9,10,11,12 ONLINE;
数据库已更改。
打开数据库。
SQLPLUS>ALTER DATABASE OPEN RESETLOGS;
数据库已更改。
查看V$DATAFILE,文件状态已经是ONLINE了。
TS# FILE# NAME STATUS CHECKPOINT_CHANGE#
— —– —————————————- ——- ——————
0 1 E:\Oracle9I\ORA9I\SYSTEM01.DBF SYSTEM 1041478418
1 2 E:\Oracle9I\ORA9I\UNDOTBS01.DBF ONLINE 1041478418
3 3 E:\Oracle9I\ORA9I\DRSYS01.DBF ONLINE 1041478418
4 4 E:\Oracle9I\ORA9I\INDX01.DBF ONLINE 1041478418
5 5 E:\Oracle9I\ORA9I\TOOLS01.DBF ONLINE 1041478418
6 6 E:\Oracle9I\ORA9I\USERS01.DBF ONLINE 1041478418
7 7 E:\Oracle9I\ORA9I\XDB01.DBF ONLINE 1041478418
8 8 E:\Oracle9I\ORA9I\OEM_REPOSITORY.DBF ONLINE 1041478418
13 9 E:\Oracle9I\ORADATA\GAXZTEMP.DB ONLINE 1041478418
14 10 E:\Oracle9I\ORADATA\GAXZUSR.DB ONLINE 1041478418
15 11 E:\Oracle9I\ORADATA\GAXZRBS.DB ONLINE 1041478418
TS# FILE# NAME STATUS CHECKPOINT_CHANGE#
— —– —————————————- ——- ——————
16 12 E:\Oracle9I\ORADATA\GAXZWEB.DB ONLINE 1041478418
至此,数据库已经恢复了,接下来的工作就简单了:
将临时表空间文件找回:
SQLPLUS>ALTER TABLESPACE TEMP ADD TEMPFILE ‘E:\Oracle9i\ORA9I\TEMP01.DBF’ REUSE;
表空间已更改。
将UNDO管理方式改成自动
SQLPLUS>ALTER SYSTEM SET UNDO_MANAGEMENT=AUTO SCOPE=SPFILE;
系统已更改。
SQLPLUS>ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS SCOPE=SPFILE;
系统已更改。
用EXP导出数据,重建数据库。
总结:刚解决完的时候,有点不敢相信竟然解决了。因为这种由SYSTEM表空间造成的ORA-01189这个错误,我一直以为只能通过DUL来解决了。
在网上也同样找不到真正解决的资料,一般都是解决ORA-01190的。这两个问题的区别在于,创建控制文件的时候如果不产生01189(用resetlogs选项)那么创建时不用将其它的数据文件去掉,而且打开数据库的时候只要设置_allow_resetlogs_corruption就可以了,另外也不用adjust_scn来修改change#。于是在自己的机器上又做了几次实验:
1关掉数据库;
2备份SYSTEM表空间;
3打开数据库;
4切换日志;
5关数据库;
6替换旧的SYSTEM表空间。
模拟出了同样的问题。然后用同样的方法解决了。


 


本文出自:亿恩科技【www.enkj.com】

服务器租用/服务器托管中国五强!虚拟主机域名注册顶级提供商!15年品质保障!--亿恩科技[ENKJ.COM]

  • 您可能在找
  • 亿恩北京公司:
  • 经营性ICP/ISP证:京B2-20150015
  • 亿恩郑州公司:
  • 经营性ICP/ISP/IDC证:豫B1.B2-20060070
  • 亿恩南昌公司:
  • 经营性ICP/ISP证:赣B2-20080012
  • 服务器/云主机 24小时售后服务电话:0371-60135900
  • 虚拟主机/智能建站 24小时售后服务电话:0371-60135900
  • 专注服务器托管17年
    扫扫关注-微信公众号
    0371-60135900
    Copyright© 1999-2019 ENKJ All Rights Reserved 亿恩科技 版权所有  地址:郑州市高新区翠竹街1号总部企业基地亿恩大厦  法律顾问:河南亚太人律师事务所郝建锋、杜慧月律师   京公网安备41019702002023号
      0
     
     
     
     

    0371-60135900
    7*24小时客服服务热线