现场故障 案例:控制文件损坏

本文出自 “深蓝的blog” 博客,若转载,请务必保留此出处:http://blog.csdn.net/huangyanlong

1、手工切归档时出错;

2、查看告警信息;

3、转储/disk2下的控制文件;

4、启库,切归档;

5、手工执行0级全备。


时间


目的


操作


09:50


正常巡检,开启告警日志,

检查数据库时间、状态


#tail -f /u01/app/oracle/admin/metro/bdump/alert_metro.log

SQL> SELECT sysdate from dual;

SYSDATE

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

21-05-14 09:50:24

SQL> select status from v$instance;

STATUS

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

OPEN


09:51


发现告警日志中

一条cannot提示信息


Wed May 21 09:47:15 2014

Thread 1 cannot allocate new log, sequence 104

Checkpoint not complete

Current log# 3 seq# 103 mem# 0: /u01/app/oracle/oradata/metro/redo03.log

Current log# 3 seq# 103 mem# 1: /disk1/metro/redofile/redo03a.log

Thread 1 advanced to log sequence 104

Current log# 1 seq# 104 mem# 0: /u01/app/oracle/oradata/metro/redo01.log

Current log# 1 seq# 104 mem# 1: /disk1/metro/redofile/redo01a.log


09:53


发现告警日志中

连续出现ORA-00202告警信息


Wed May 21 09:53:25 2014

Hex dump of (file 0, block 1) in trace file /u01/app/oracle/admin/metro/bdump/metro_arc0_385212.trc

Corrupt block relative dba: 0x00000001 (file 0, block 1)

Completely zero block found during control file header read

Wed May 21 09:53:25 2014

Errors in file /u01/app/oracle/admin/metro/bdump/metro_arc0_385212.trc:

ORA-00202: control file: ‘/disk2/metro/control_file/control03.ctl‘

Wed May 21 09:53:26 2014

Errors in file /u01/app/oracle/admin/metro/bdump/metro_arc0_385212.trc:

ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)

ORA-00202: control file: ‘/disk2/metro/control_file/control03.ctl‘


10:10


到数据库下进行手工归档,

报错并断开连接


SQL> alter system switch logfile;

alter system switch logfile

*

ERROR at line 1:

ORA-03135: connection lost contact


10:12


尝试启库,失败,报错


SQL> startup

ORACLE instance started.

Total System Global Area  612368384 bytes

Fixed Size                  2022800 bytes

Variable Size             226493040 bytes

Database Buffers          377487360 bytes

Redo Buffers                6365184 bytes

ORA-00205: error in identifying control file, check alert log for more info


10:13


根据启库时提示信息

及告警日志信息,

初判控制文件存在问题


启库时提示:

ORA-00205: error in identifying control file, check alert log for more info

告警日志中提示:

ORA-00202: control file: ‘/disk2/metro/control_file/control03.ctl‘


10:16


根据提示转储disk2下控制文件


[[email protected]]$cd /disk2/metro/control_file

[[email protected]]$ls

control03.ctl

[[email protected]]$mv control03.ctl control03.ctl.bak

[[email protected]]$cd /disk1/metro/control_file

[[email protected]]$ls

control02.ctl

[[email protected]]$cp control02.ctl /disk2/metro/control_file/control03.ctl


10:19


启库,成功


SQL> startup;

ORACLE instance started.

Total System Global Area  612368384 bytes

Fixed Size                  2022800 bytes

Variable Size             226493040 bytes

Database Buffers          377487360 bytes

Redo Buffers                6365184 bytes

Database mounted.

Database opened.


10:20


删除有问题的控制文件


[[email protected]]$ls

control03.ctl      control03.ctl.bak

[[email protected]]$rm control03.ctl.bak

[[email protected]]$ls

control03.ctl


10:22


0级全备


[[email protected]]$cd /home/oracle/

[[email protected]]$ls

ctl.sh            scripts           smit.log          smit.script       smit.transaction

[[email protected]]$cd scripts

[[email protected]]$ls

bin  log  tmp

[[email protected]]$cd bin

[[email protected]]$ls

rmanlevel0.sh      rmanlevel0.sh.bak  rmanlevel1.sh      rmanlevel1.sh.bak

[[email protected]]$sh rmanlevel0.sh


10:28


完成全备


10:29


切归档


SQL> alter system archive log current;

System altered.

原创作品,允许转载,转载时请务必注明出处(http://blog.csdn.net/huangyanlong)、作者信息和本声明 。关于涉及版权事宜,作者有权追究法律责任。

现场故障 案例:控制文件损坏

时间: 2024-10-09 00:29:32

现场故障 案例:控制文件损坏的相关文章

RAC环境下控制文件损坏重建过程

处理过程参考了: https://blogs.oracle.com/Database4CN/entry/%E5%A6%82%E4%BD%95%E9%87%8D%E5%BB%BArac%E7%9A%84%E6%8E%A7%E5%88%B6%E6%96%87%E4%BB%B6 问题现象: 现场有学校提报 登录PL/SQL连接数据库是报错“ORA-12541: TNS:无监听程序 ”:排查日志,发现 Tue Nov 25 14:46:58 2014 Thread 2 advanced to log s

控制文件损坏,丢失其中一个

控制文件丢了一个,损坏了一个,还剩余一个,无法启动 startup nomount alter system set control_files=('') scope=spfile;指定到仍然存在的控制文件 show parameter control 查看控制文件参数是否修改成功 shutdown immediate startup mount

Oracle 控制文件和日志文件

管理控制文件 在Oracle数据库中,控制文件是一个很小(大小一般在10MB范围内)的二进制文件,含有数据库的结构信息,包括数据文件和日志文件的信息.可以将控制文件理解为物理数据库的一个元数据存储库.控制文件在数据库创建时被自动创建,并在数据库发生物理变化时更新.控制文件被不断更新,并且在任何时候都要保证控制文件是可用的.只有Oracle进程才能够安全地更新控制文件的内容,所以,任何时候都不要试图手动编辑控制文件. 由于控制文件在数据库中的重要地位,所以保护控制文件的安全非常重要,为此Oracl

ORACLE之重建控制文件

这里上传图片一直失败,想要查看详细信息和截图的可以下载附件 首先看一下控制文件的理解: 控制文件是一个二进制文件,用于记录数据库的物理结构.一个控制文件只属于一个数据库.创建数据库时,创建控制文件.当数据库的物理结构改变的时候,Oracle会更新控制文件,不能手动修改内容. 控制文件内容有:数据库名.数据库创建的时间戳.数据文件的名字和位置.redo log (联机重做日志文件)的名字和位置.表空间信息.当前日志的序列号.checkpoint 信息.最新的 RMAN备份信息.归档日志信息 当这些

Oracle 11g在ASM磁盘组上添加控制文件

控制文件(Control File)是Oracle的物理文件之一,它记录了数据库的名字.数据文件的位置等信息.控制文件的重要性在于,一旦控制文件损坏,数据库将会宕机.如果没有数据库的备份和归档日志文件,数据库将无法恢复.因此,我们应该多路镜像控制文件(Multiplex Control Files),并把每个镜像的控制文件分布在不同的物理磁盘.根据经验,控制文件多路镜像以后,几个控制文件同时坏掉的可能性几乎为零.控制文件管理的重心是重在预防,而不是亡羊补牢! 今天做在测试环境为control f

oracle 控制文件多路复用

网上有很多关于控制文件的操作,我大概看了下.有很多都是炒来炒去转来转去.下面以自己理解和操作为例来对oracle的控制文件进行下介绍. 首先介绍下控制文件 在oralce数据库中,控制文件是一个很小的二进制文件,一般大小在10MB左右在数据库创建时被自动创建,并在数据库变化时更新.控制文件不断被更新,并且在任何时候都要保证控制文件可用.控制文件在oracle中扮演者很重要的角色,没有控制文件或者控制文件损坏数据库必然down掉.控制文件包含有数据库结构信息,数据文件和日志文件信息. 由于控制文件

服务器异常断电,导致oracle控制文件版本不一致,报错ora-00214解决记录

控制文件介绍: 每一个oracle都至少会生成一个控制文件,一个数据库可以拥有多个控制文件,但是一个控制文件只能属于一个数据库. 控制文件内部除了存放数据库名及其创建日期,数据文件,日志文件等相关信息,在系统运行的过程中还会存放系统更改号,检查点信息及归档的当前状态等信息. 出于安全考虑,数据库会自动创建2到3个控制文件,每个控制文件记录相同的信息,这个可以确保在数据库运行时,某个控制文件损坏,oracle会自动使用另一个控制文件,当所有控制文件损坏时,数据库将无法工作. 注:通过 v$cont

故障的具体步骤恢复控制文件

假定控制文件丢失或损坏,实例通常会中止. 然后,,您必须执行下列步骤: 1.关闭实例(假设它仍然是开放的). 2.通过复制现有控制文件来恢复丢失的控制文件. 3.启动实例. 实验: 1.查看当前控制文件的情况下 show parameter control_files 2.模拟控制文件丢失故障 !rm /home/oracle/control_bak/control03.ctl show parameter control_files  --被删除的控制文件仍然存在 3.触发检查点操作 alte

恢复控制文件故障详细步骤

如果控制文件丢失或损坏,则实例通常会中止.然后,您必须执行以下步骤: 1.关闭实例(如果它仍处于打开状态). 2.通过复制现有控制文件还原缺失的控制文件. 3.启动实例. 实验: 1.查看当前控制文件情况 show parameter control_files 2.模拟控制文件丢失故障 !rm /home/oracle/control_bak/control03.ctl show parameter control_files  --被删除的控制文件仍然存在 3.触发检查点操作 alter s