异常断电导致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,如需转载请自行联系原作者

相关文章
|
10月前
|
Oracle 关系型数据库 Linux
【YashanDB 知识库】通过 dblink 查询 Oracle 数据时报 YAS-07301 异常
客户在使用 YashanDB 通过 yasql 查询 Oracle 数据时,遇到 `YAS-07301 external module timeout` 异常,导致 dblink 功能无法正常使用,影响所有 YashanDB 版本。原因是操作系统资源紧张,无法 fork 新子进程。解决方法包括释放内存、停掉不必要的进程或增大进程数上限。分析发现异常源于 system() 函数调用失败,返回 -1,通常是因为 fork() 失败。未来 YashanDB 将优化日志信息以更好地诊断类似问题。
|
9月前
|
Oracle 关系型数据库 Linux
【YashanDB知识库】通过dblink查询Oracle数据时报YAS-07301异常
【YashanDB知识库】通过dblink查询Oracle数据时报YAS-07301异常
|
10月前
|
Oracle 关系型数据库 Linux
【YashanDB 知识库】通过 dblink 查询 Oracle 数据时报 YAS-07301 异常
某客户在使用 YashanDB 通过 yasql 查询 Oracle 数据时,遇到 `YAS-07301 external module timeout` 异常,导致 dblink 功能无法正常使用,影响所有版本。问题源于操作系统资源紧张,无法 fork 新子进程。解决方法包括释放内存、停掉不必要的进程或增大进程数上限。分析发现异常原因为系统调用 fork() 失败。经验总结:优化日志记录,提供更多异常信息。
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
286 1
【赵渝强老师】Oracle的控制文件与归档日志文件
|
SQL Oracle 关系型数据库
Oracle 从 DMP 文件中恢复指定表的步骤
Oracle 从 DMP 文件中恢复指定表的步骤
1092 7
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
271 1
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的数据文件
在Oracle数据库中,数据库由多个表空间组成,每个表空间包含多个数据文件。数据文件存储实际的数据库数据。查询时,如果内存中没有所需数据,Oracle会从数据文件中读取并加载到内存。可通过SQL语句查看和管理数据文件。附有视频讲解及示例。
139 0