异常断电导致ORACLE控制文件等受到破坏的处理

简介:

故障现象:客户某台WINDOWS服务器掉电,ORACLE数据库STARTUP提示控制文件CONTROL01.CTLCONTROL02.CTL被破坏。

 

一、处理控制文件异常故障

方法:直接拷贝CONTROL03.CTLCONTROL01.CTL,保险起见可以拷贝一个备份放

二、尝试启动

1startup,碰到ORA-01172ORA-01151错误

SQL> startup;

ORACLE 例程已经启动。

Total System Global Area  612368384 bytes

Fixed Size                  1250428 bytes

Variable Size             146803588 bytes

Database Buffers          457179136 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-01172: 线程 1 的恢复停止在块 89 (在文件 2 )

ORA-01151: 如果需要请使用介质恢复以恢复块和还原备份

2、恢复介质后再次启动,碰到ORA-00607ORA-00600600问题一般是UNDO文件出问题

SQL> recover database;

完成介质恢复。

SQL> shutdown immediate;

ORA-01109: 数据库未打开

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup;

ORACLE 例程已经启动。

 

Total System Global Area  612368384 bytes

Fixed Size                  1250428 bytes

Variable Size             146803588 bytes

Database Buffers          457179136 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

ORA-00607: 当更改数据块时出现内部错误

ORA-00600: 内部错误代码参数: [4194], [58], [19], [], [], [], [], []

3、利用数据库OPEN的时机执行如下语句(因为很快数据库即自动关闭)

SQL> SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME

------------------------------

SYSTEM

_SYSSMU1$

_SYSSMU2$

_SYSSMU3$

_SYSSMU4$

_SYSSMU5$

_SYSSMU6$

_SYSSMU7$

_SYSSMU8$

_SYSSMU9$

_SYSSMU10$

 

SEGMENT_NAME

------------------------------

_SYSSMU11$

_SYSSMU12$

_SYSSMU13$

_SYSSMU14$

_SYSSMU15$

_SYSSMU16$

_SYSSMU17$

_SYSSMU18$

已选择19行。

SQL>

4、创建PFILE

SQL> CREATE PFILE='D:\oracle\product\10.2.0\oradata\zjport\BACKFILE\ORACLEADMINORCLPFILEINITORCL.ORA' FROM SPFILE;

文件已创建。

5、修改PFILE

添加下面的参数:

undo_management='MANUAL'

_corrupted_rollback_segments=

(_SYSSMU1&,_SYSSMU2&,_SYSSMU3&,_SYSSMU4&,_SYSSMU5&,_SYSSMU6&,_SYSSMU7&,_SYSSMU8&,_SYSSMU9&,_SYSSMU10&,_SYSSMU11&,_SYSSMU12&,_SYSSMU13&,_SYSSMU14&,_SYSSMU15&,_SYSSMU16&,_SYS

SMU17&,_SYSSMU18&)

6、下面尝试用PFILE方式打开数据库

C:\Documents and Settings\Administrator>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on 星期四 9 20 09:25:05 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> STARTUP PFILE=D:\oracle\product\10.2.0\oradata\zjport\BACKFILE\ORACLEADMINORCLPFILEINITORCL.ORA MOUNT

ORACLE 例程已经启动。

Total System Global Area  612368384 bytes

Fixed Size                  1250428 bytes

Variable Size             146803588 bytes

Database Buffers          457179136 bytes

Redo Buffers                7135232 bytes

数据库装载完毕。

7、介质恢复

SQL> RECOVER DATABASE;

完成介质恢复。

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

ORA-00279: 更改 5520735 ( 09/20/2012 09:20:58 生成对于线程 1 是必需的

ORA-00289: 建议:

D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ZJPORT\ARCHIVELOG\2012_09_20\O1_MF_1_145_%U_.ARC

ORA-00280: 更改 5520735 (用于线程 1) 在序列 #145 

指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

cancel

介质恢复已取消。

8RESETLOGS方式OPEN

SQL> ALTER DATABASE OPEN RESETLOGS;

数据库已更改。

SQL>

---------------------------------------------------

至此数据库恢复,后续执行数据备份并写入SPFILE

---------------------------------------------------

1、数据库备份

2、创建SPFILE

create spfile  from pfile='D:\oracle\product\10.2.0\oradata\zjport\BACKFILE\ORACLEADMINORCLPFILEINITORCL.ORA';

---------------------------------------------------------------------------

至此数据库完全恢复、数据也备份完成,后续修改不归档方式为为归档方式 

---------------------------------------------------------------------------

1、修改初试化参数,使能自动归档 

 

--归档路径

SQL> alter system set log_archive_dest_1='LOCATION=D:\oracle\product\10.2.0\oradata\zjport\archivelog';

--归档命名格式

SQL> alter system set log_archive_max_processes = 5;

SQL> alter system set log_archive_format = "archive_%t_%s_%r.arc" scope=spfile;

2、重启数据库

SQL> shutdown immediate

SQL> startup mount;

SQL> alter database archivelog;

SQL> alter database open;

3、确认

SQL> archive log list;



本文转自zylhsy 51CTO博客,原文链接:http://blog.51cto.com/yunlongzheng/999339,如需转载请自行联系原作者

相关文章
|
3月前
|
SQL Oracle 关系型数据库
Oracle 从 DMP 文件中恢复指定表的步骤
Oracle 从 DMP 文件中恢复指定表的步骤
167 7
|
3月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
3月前
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
108 1
|
3月前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
112 1
【赵渝强老师】Oracle的控制文件与归档日志文件
|
3月前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的数据文件
在Oracle数据库中,数据库由多个表空间组成,每个表空间包含多个数据文件。数据文件存储实际的数据库数据。查询时,如果内存中没有所需数据,Oracle会从数据文件中读取并加载到内存。可通过SQL语句查看和管理数据文件。附有视频讲解及示例。
|
4月前
|
Oracle 关系型数据库 数据库
oracle数据恢复—Oracle数据库文件损坏导致数据库打不开的数据恢复案例
打开oracle数据库时报错,报错信息:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。急需恢复zxfg用户下的数据。 出现上述报错的原因有:控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件,启动数据库依然有许多查询报错。export和data pump工具无法使用,查询告警日志并分析报错,确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于该文件损坏,从数据库层面无法修复数据库。由于system和用户表空间的数据文件是正常的,
|
5月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。
|
5月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
8月前
|
SQL Oracle 关系型数据库
实时计算 Flink版产品使用问题之同步oracle表时,数据量约800万,检查点异常,该如何排查
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
8月前
|
SQL Oracle 关系型数据库
mysql和oracle 命令行执行sql文件 数据库执行sql文件 执行sql语句
mysql和oracle 命令行执行sql文件 数据库执行sql文件 执行sql语句
101 0

推荐镜像

更多