掉电引起的ORA-1172错误解决过程(三)

由于UPS故障,导致机房连续多次掉电,问题解决后,发现一台本地测试数据库打开时报错,ORA-1172、ORA-1151错误。

掉电引起的ORA-1172错误解决过程(一):http://yangtingkun.itpub.net/post/468/465223

掉电引起的ORA-1172错误解决过程(二):http://yangtingkun.itpub.net/post/468/465868

打开数据库后的处理:

 

 

在前一篇文章中已经成功打开数据库,其实这时从目标上已经基本完成了,只需通过EXP或者EXPDP工具将数据库中的用户导出,重建数据库,然后导入数据即可。

不过对于恢复来说,还有很多可以做的,检查数据库的回滚段状态:

SQL> SELECT SEGMENT_NAME, OWNER, TABLESPACE_NAME, STATUS
  2  FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME    OWNER  TABLESPACE_NAME      STATUS
--------------- ------ -------------------- ----------------
SYSTEM          SYS    SYSTEM               ONLINE
_SYSSMU1$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU2$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU3$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU4$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU5$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU6$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU7$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU8$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU9$       PUBLIC UNDOTBS1             OFFLINE
_SYSSMU10$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU11$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU12$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU13$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU14$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU15$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU16$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU17$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU18$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU19$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU20$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU21$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU22$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU23$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU24$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU25$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU26$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU27$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU28$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU29$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU30$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU31$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU32$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU33$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU34$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU35$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU36$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU37$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU38$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU39$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU40$      PUBLIC UNDOTBS1             OFFLINE
_SYSSMU41$      PUBLIC UNDOTBS1             OFFLINE

42 rows selected.

可以发现除了SYSTEM回滚段,其他回滚段均为OFFLINE状态,这时所有的DML操作均回报错:

SQL> DELETE TEST.T;
DELETE TEST.T
            *
ERROR at line 1:
ORA-01552: cannot use system rollback segment for non-system tablespace 'GPO'

下面创建一个新的UNDO表空间,使得ORACLE有可用的UNDO表空间:

SQL> CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE '/data/oradata/test08/undotbs21.dbf'           
  2  SIZE 4096M;

Tablespace created.

下面修改初始化参数文件,改变UNDO表空间为UNDOTBS2,并将UNDO管理设置为AUTO模式,注释掉隐含参数_corrupted_rollback_segments:

*.undo_management=’AUTO’
*.undo_tablespace=’UNDOTBS2’

在关闭数据库时出现了异常:

SQL> SHUTDOWN IMMEDIATE

等待了几个小时,SHUTDOWN IMMEDIATE方式仍然无法关闭数据库,检查alert文件发现信息如下:

Tue Jun 10 17:02:41 2008
Starting background process EMN0
EMN0 started with pid=16, OS id=15734
Tue Jun 10 17:02:41 2008
Shutting down instance: further logons disabled
Tue Jun 10 17:02:41 2008
Stopping background process CJQ0
Tue Jun 10 17:02:41 2008
Stopping background process MMNL
Tue Jun 10 17:02:42 2008
Stopping background process MMON
Tue Jun 10 17:02:43 2008
Shutting down instance (immediate)
License high water mark = 44
Tue Jun 10 17:02:43 2008
Stopping Job queue slave processes
Tue Jun 10 17:02:43 2008
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Tue Jun 10 17:02:50 2008
Process OS id : 15693 alive after kill
Errors in file /opt/ora10g/admin/test08/udump/test08_ora_15629.trc

在另外的会话以SYSDBA登陆,利用SHUTDOWN ABORT关闭数据库,SHUTDOWN IMMEDIATE的会话信息如下:

ORA-03113: end-of-file on communication channel
SQL> STARTUP PFILE=/home/oracle/inittest08.ora
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist
SQL> CONN / AS SYSDBA
Connected to an idle instance.
SQL> STARTUP PFILE=/home/oracle/inittest08.ora
ORACLE instance started.

Total System Global Area 2483027968 bytes
Fixed Size                  2074760 bytes
Variable Size            1090520952 bytes
Database Buffers         1375731712 bytes
Redo Buffers               14700544 bytes
Database mounted.
Database opened.

数据库可以正常启动。下面删除UNDOTBS1表空间即可:

SQL> DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

SQL> DELETE TEST.T;

4051072 rows deleted.

SQL> COMMIT;

Commit complete.

不过由于数据库本身已经处于异常状态,后台仍然可以经常发现大量坏块:

Errors in file /opt/ora10g/admin/test08/bdump/test08_smon_19485.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 32529)
ORA-01110: data file 1: '/data/oradata/test08/system01.dbf'
Wed Jun 11 08:58:29 2008
WARNING: inbound connection timed out (ORA-3136)
Wed Jun 11 09:02:29 2008
Hex dump of (file 3, block 37871) in trace file /opt/ora10g/admin/test08/bdump/test08_m000_19556.trc
Corrupt block relative dba: 0x00c093ef (file 3, block 37871)
Fractured block found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x00c093ef
 last change scn: 0x0001.81e5b9f5 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xb56b0601
 check value in block header: 0x9fc
 computed block checksum: 0xdd4
Reread of rdba: 0x00c093ef (file 3, block 37871) found same corrupted data
Hex dump of (file 3, block 35683) in trace file /opt/ora10g/admin/test08/bdump/test08_m000_19556.trc
Corrupt block relative dba: 0x00c08b63 (file 3, block 35683)
Fractured block found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x00c08b63
 last change scn: 0x0001.856e48fc seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x7ead0601
 check value in block header: 0x1214
 computed block checksum: 0x3404
Reread of rdba: 0x00c08b63 (file 3, block 35683) found same corrupted data
Hex dump of (file 3, block 40608) in trace file /opt/ora10g/admin/test08/bdump/test08_m000_19556.trc
Corrupt block relative dba: 0x00c09ea0 (file 3, block 40608)
Fractured block found during buffer read
Data in bad block:
 type: 6 format: 2 rdba: 0x00c09ea0
 last change scn: 0x0001.856e48fc seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x65c20601
 check value in block header: 0x9ef1
 computed block checksum: 0x7a6b
Reread of rdba: 0x00c09ea0 (file 3, block 40608) found same corrupted data
Wed Jun 11 09:02:30 2008
Corrupt Block Found
         TSN = 2, TSNAME = SYSAUX
         RFN = 3, BLK = 37871, RDBA = 12620783
         BJN = 8933, BJD = 8933, BJECT = WRH$_SQLTEXT, SUBOBJECT =
         SEGMENT WNER = SYS, SEGMENT TYPE = Table Segment
Corrupt Block Found
         TSN = 2, TSNAME = SYSAUX
         RFN = 3, BLK = 35683, RDBA = 12618595
         BJN = 8943, BJD = 8943, BJECT = WRH$_SQL_BIND_METADATA, SUBOBJECT =
         SEGMENT WNER = SYS, SEGMENT TYPE = Table Segment
Wed Jun 11 09:07:30 2008
Errors in file /opt/ora10g/admin/test08/bdump/test08_smon_19485.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 32529)
ORA-01110: data file 1: '/data/oradata/test08/system01.dbf'
Wed Jun 11 09:07:32 2008
Corrupt Block Found
         TSN = 2, TSNAME = SYSAUX
         RFN = 3, BLK = 40608, RDBA = 12623520
         BJN = 8939, BJD = 8939, BJECT = WRH$_SQL_PLAN, SUBOBJECT =
         SEGMENT WNER = SYS, SEGMENT TYPE = Table Segment

因此,虽然数据库已经可以使用,但是为了防止数据库的进一步损坏,还是通过导出、重建、导入的方式比较稳妥。

 

 

时间: 2024-10-04 19:29:33

掉电引起的ORA-1172错误解决过程(三)的相关文章

掉电导致mysql innodb #145 错误解决解决

断电,导致innodb部分表坏了,phpmyadmin中看到该表显示为使用中,并报了,#145 - Table './shbc/user_order_logs' is marked as crashed and should be repaired. 以前也解决过一次myisam表损坏,请参考:Incorrect key file for table mysql表损坏的修复方法 解决办法如下: mysql> select * from user_order_logs;  ERROR 145 (H

掉电引起的ORA-1172错误解决过程(二)

由于UPS故障,导致机房连续多次掉电,问题解决后,发现一台本地测试数据库打开时报错,ORA-1172.ORA-1151错误. 掉电引起的ORA-1172错误解决过程(一):http://yangtingkun.itpub.net/post/468/465223 尝试打开数据库.     上一篇介绍了问题的产生和现象,下面尝试用EVENTS方式打开数据库,不过由于出现ORA-600 2662错误的机制与上面一篇文章不同,因此这里不需要设置隐含参数_allow_resetlogs_corruptio

ORA-00600 [2662]错误解决过程

错误|过程|解决 ORA-00600 [2662]错误解决过程 数据库版本:7.3.2   背景: 客户那边数据库突然出现一个current日志文件坏了,导致数据库crash了,然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数,做了不完全恢复后强行将数据库打开.可是打开数据库后发现只能用internal用户连接进去,别的用户连接都报错,错误信息如下: ORA-00600: internal error code, arguments: [2662

ORA-38760: This database instance failed to turn on flashback database 错误解决过程

ORA-38760: This database instance failed to turn on flashback database  错误解决过程   问题现象:           一大早起床把数据库打开,本来想做个测试,结果不料弹出ORA-38760: This database instance failed to turn on flashback database的错误,这个错误很显然是由于flashback导致的错误. 错误分析:     首先从错误现象来看,是由于flas

掉电引起的ORA-1172错误解决过程(一)

由于UPS故障,导致机房连续多次掉电,问题解决后,发现一台本地测试数据库打开时报错,ORA-1172.ORA-1151错误.     同事告诉我一台数据库无法打开,只能启动到MOUNT状态,于是连接数据库尝试打开,报错如下: SQL> alter database open;alter database open*ERROR at line 1:ORA-01172: recovery of thread 1 stuck at block 1669 of file 2ORA-01151: use

plsql连接oracle数据库报ora 12154错误解决方法_oracle

plsql连接oracle数据库报ora 12154错误 今天遇到一个问题,使用sqlplus能够连接到远程的数据库,但是使用plsql却连接不上,报错"ORA-12154: TNS: 无法解析指定的连接标识符" 解决方法如下: 1.先检查服务器端的监听服务是否打开,如果没有打开请启动其监听 客户端:tnsping <tns_name> 服务器Linux下: #>lsnrctl status 查看监听状态 #>lsnrctl start 启动监听 2.通过Sql

Oracle数据库ORA 54013错误的解决办法_oracle

ORA-54013: 不允许对虚拟列执行 INSERT 操作 这是Oracle 11 的新特性 -- 虚拟列. 在以前的Oracle 版本,当我们需要使用表达式或者一些计算公式时,我们会创建数据库视图,如果我们需要在这个视图上使用索引,我们会创建基于函数的索引.现在Oracle 11允许我们直接在表上使用虚拟列来存储表达式.虚拟列的值是不存储在磁盘的,它们是在查询时根据定义的表达式临时计算的.我们不能往虚拟列中插入数据,我们也不能隐式的添加数据到虚拟列,我们只能使用物理列来插入数据.然后可以查询

oracle数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr

Oracle RAC数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr