ORACLE控制文件损坏处理办法

合集下载

(完整word版)Oracle数据库系统紧急故障处理方法

(完整word版)Oracle数据库系统紧急故障处理方法

Oracle数据库系统紧急故障处理方法Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障。

这些故障可能是由于硬件故障造成的,也可能是人为误操作而引起。

所以我们首先要判断问题的起因,如果是硬件故障则首先要解决硬件问题。

在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。

控制文件损坏:控制文件记录了关于oracle的重要配置信息,如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。

控制文件的损坏,会导致数据库异常关闭。

一旦缺少控制文件,数据库也无法启动,这是一种比较严重的错误。

损坏单个控制文件:1. 确保数据库已经关闭,如果没有用下面的命令来关闭数据库:svrmgrl>shutdown immediate;2. 查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。

3. 用操作系统命令将其它正确的控制文件覆盖错误的控制文件。

4. 用下面的命令重新启动数据库:svrmgrl>startup;5. 用适当的方法进行数据库全备份。

损坏所有的控制文件:1. 确保数据库已经关闭,如果没有用下面的命令来关闭数据库:svrmgrl>shutdown immediate;2. 从相应的备份结果集中恢复最近的控制文件。

对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录;对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。

3. 用下面的命令来创建产生数据库控制文件的脚本:svrmgrl>startup mount;svrmgrl>alter database backup controlfile to trace noresetlogs;4. 修改第三步产生的trace文件,将其中关于创建控制文件的一部分语句拷贝出来并做些修改,使得它能够体现最新的数据库结构。

ora-01113数据文件损坏的处理方法

ora-01113数据文件损坏的处理方法

ora-01113数据文件损坏的处理方法Ora-01113 ora-01110数据文件损坏的处理方法一、先将所有的oracle文件备份。

包括oracle目录和手工添加的数据文件目录。

二、在ms_dos下执行svrmgrl1.Svrmgrl> connect internal/oracle;提示连接成功转(2)2.Svrmgrl> shutdown abort ;关闭数据库,提示成功转(3)3.Svrmgrl> startup nomount ;提示无错误转(4),否则不是这个错误,查看控制文件错处理。

4.Svrmgrl> alter database mount ;提示无错误转(5),否则是其它错误,见其它文档5.Svrmgrl> select * from v$recover_file ;查看是哪个文件需要修复。

字段File#,结果是数值型的。

6.Svrmgrl> select * from v$datafile where file#=? ;具体查询损坏的数据文件位置。

7.Svrmgrl> recover database ;进行数据库修复,如果成功转(8),不成功转(9)8.Svrmgrl> alter database open ;如果成功则完成,可以备份数据库了。

如果不成功还是以前的错误代码转(9)9.Svrmgrl> alter database datafile ‘?.dbf’ offline drop ;将(5)查询的文件位置替换到?.dbf ,删除所有损坏的数据文件。

10.Svrmgrl> alter database open ;三、注意:以上处理内容只使用于ora-01110 ora-01113数据文件错误,并且所损坏的数据文件不能是以下文件:System01.dbf基本上如果这个文件损坏不好处理。

如果数据存储在这个文件中则完全没有希望。

Oracle数据库文件损坏修复(断电情况下)

Oracle数据库文件损坏修复(断电情况下)

现场情况:1、数据库没有作归档,2、数据都存放在system表空间3、没有备份状况:操作系统由于磁盘原因出现宕机,用户强行按电源关闭系统,数据库无法启动。

处理:Sql代码1.SQL> recover database;2.ORA-00283: recovery session canceled due to errors3.ORA-12801: error signaled in parallel query server P0024.ORA-10562: Error occurred while applying redo to data block (file# 1, block#4568)5.ORA-10564: tablespace SYSTEM6.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'7.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 5768.ORA-00600: internal error code, arguments: [6101]9.检查日志信息如下:Oracle代码1.Mon Nov 1915:38:5020072.ALTER DATABASE RECOVER database3.Mon Nov 1915:38:5020074.Media Recovery Start5. parallel recovery started with 3 processes6.Mon Nov 1915:38:5020077.Recovery of Online Redo Log: Thread 1 Group 3 Seq 16 Reading mem 08. Mem# 0 errs 0: /opt/oracle/oradata/orcl/redo03.log9.Mon Nov 1915:38:50200710.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:11.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []12.Mon Nov 1915:38:50200713.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:14.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []15.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)16.ORA-10564: tablespace UNDOTBS117.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'18.ORA-10560: block type 'KTU UNDO BLOCK'19.Mon Nov 1915:38:51200720.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:21.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []22.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)23.ORA-10564: tablespace UNDOTBS124.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'25.ORA-10560: block type 'KTU UNDO BLOCK'26.Mon Nov 1915:38:51200727.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:28.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 4568)29.ORA-10564: tablespace SYSTEM30.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'31.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 57632.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []33.Mon Nov 1915:38:54200734.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:35.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []36.Mon Nov 1915:38:54200737.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:38.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)39.ORA-10564: tablespace SYSTEM40.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'41.ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 23742.ORA-00607: Internal error occurred while making a change to a data block43.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []44.Mon Nov 1915:38:54200745.Media Recovery failed with error 1280146.ORA-283 signalled during: ALTER DATABASE RECOVER database ...从上面信息中抓取了一个信息:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)针对这个错误解决如下:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# string, block# string)2.Cause: See other errors on error stack.3.Action: Investigate why the error occurred and how important isthe data block. Media and standby database recovery usually ca n continue if user allows recovery to corrupt this data block。

Oracle控制文件管理和恢复

Oracle控制文件管理和恢复

1 查看控制文件信息SYS@ prod>select * from v$controlfile;目前三个控制文件(里面信息都一样)在同一个目录下,都在/dev/sda2磁盘上,很不安全,根据df显示的磁盘信息可以将控制文件放到test1目录下。

2 修改参数文件1)查看参数文件的位置,当前使用spfile启动2)SYS@ prod>alter system set control_files='/u01/oradata/prod/control01.ctl',2 '/u01/oradata/prod/control02.ctl','/u01/oradata/prod/control03.ctl' scope=spfile;System altered.3)修改参数文件使用vi打开initprod.ora 文件在contol_file 后面添加‘/test/contorl04.ctl’并保存退出。

4)关闭数据库SYS@ prod>shutdown immediate;5)复制控制文件[root@cuug ~]# cd /u01/oradata/prod[root@cuug prod]# cp ./control03.ctl /test1/control04.ctl6)验证控制文件7 )注意事项:a复制控制文件时应该是数据库关闭状态,否则在启库是容易造成数据库SCN号不一致导致数据库无法mountb 复制时最好使用oracle操作,如果使用root记得更改新文件夹的属组和属主。

(一)只有一个控制文件丢失1 删除一个控制文件[root@cuug prod]# rm /u01/oradata/prod/control01.ctlrm: remove regular file `/u01/oradata/prod/control01.ctl'? y[root@cuug prod]#2 关闭数据库SYS@ prod>shutdown immediate;注:没用控制文件在关闭数据库是容易造成数据库未完全关闭重启时会报ora-01012错误,解决方法是在操作系统层杀掉数据库相关进程,重启即可。

oracle 故障恢复案例

oracle 故障恢复案例

oracle 故障恢复案例Oracle故障恢复案例1. 数据库实例崩溃恢复某公司的Oracle数据库实例突然崩溃,导致所有业务无法正常运行。

经过专业技术人员的分析,发现是由于服务器硬件故障导致的。

为了恢复数据库,技术人员采取了备份恢复的方式,通过使用备份数据文件和重做日志文件,成功将数据库实例恢复到崩溃前的状态。

2. 数据文件损坏的恢复某公司的数据库中的一个数据文件损坏,导致部分数据无法正常访问。

为了解决这个问题,技术人员首先通过文件系统级别的工具检查数据文件的完整性,并确定了损坏的范围。

然后,他们使用备份数据文件和重做日志文件进行恢复,成功修复了损坏的数据文件,并使数据库恢复正常。

3. 表空间故障的恢复某公司的数据库中的一个表空间突然出现故障,导致表空间中的所有表无法访问。

为了解决这个问题,技术人员首先通过Oracle的故障自诊断工具诊断表空间故障的原因,并确定了故障的范围。

然后,他们使用备份的表空间文件和重做日志文件进行恢复,成功修复了故障的表空间,并使其正常运行。

4. 数据库日志文件损坏的恢复某公司的数据库日志文件突然损坏,导致数据库无法正常启动。

为了恢复数据库,技术人员首先检查了日志文件的完整性,并确定了损坏的范围。

然后,他们使用备份的日志文件进行恢复,成功修复了损坏的日志文件,并使数据库恢复正常。

5. 控制文件丢失的恢复某公司的数据库控制文件丢失,导致数据库无法正常启动。

为了解决这个问题,技术人员首先通过文件系统级别的工具检查控制文件的完整性,并确定了丢失的范围。

然后,他们使用备份的控制文件进行恢复,成功恢复了丢失的控制文件,并使数据库正常启动。

6. 数据库块损坏的恢复某公司的数据库中的一个数据块突然损坏,导致数据库无法正常读取该块的数据。

为了解决这个问题,技术人员首先通过Oracle的故障自诊断工具诊断数据块故障的原因,并确定了损坏的范围。

然后,他们使用备份的数据块进行恢复,成功修复了损坏的数据块,并使数据库恢复正常。

嘉为IT培训Oracle g控制文件的恢复

嘉为IT培训Oracle g控制文件的恢复

Oracle 10g控制文件的恢复李冠霖:Oracel数据库工程师Oracle数据库技术专家,Oracle认证开发专家,Oracle认证专家(OCP),专注于企业Oracle数据库系统的管理与开发、性能优化、商业智能等方面的技术培训与顾问咨询服务。

现为嘉为IT培训学院企业服务咨询顾问【前言】控制文件(Control File)是Oracle的重要物理文件之一,它记录了数据库的名字、数据文件的位置等信息。

控制文件的重要性在于,一旦控制文件损坏,数据库将会宕机,无论其是否进行多路复用,当其发生损坏后一旦数据库试图读写损坏的控制文件(这种操作是很频繁,例如日志切换)都会导致数据库挂起。

对此,当控制文件出现损坏,该如何进行恢复?【正文】操作环境:windows server 2003 oracle10g一损坏单个控制文件情况:损坏单个控制文件是比较容易恢复的,因为一般的数据库系统,控制文件不是一个,而且所有控制文件都互为镜像,只需拷贝一个好的控制文件替换损坏的控制文件就可以了。

具体以下操作:1.拷贝一个好的控制文件替换坏的控制文件;------如:D:\oracle\product\10.2.0\oradata\orcl目录下2.重新启动oracle数据库;------SQL>startup open;二损坏全部控制文件情况:一般情况下很难出现损坏全部控制文件,但出现这样的情况(如人为损坏),可以通过rman备份或者创建控制文件来进行恢复;具体以下操作:第一种方法:通过rman备份来恢复控制文件通常我们都会使用rman来备份每天的oracle数据,其中有个选项CONFIGURE CONTROLFILE AUTOBACKUP ON;-------开启控制文件自动备份CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '指定存放路径';--------控制文件备份的路径如果启动该项并执行rman备份,这时可以通过rman备份来恢复损坏的控制文件;(如果没开启控制文件自动备份,请看第二种方法):1.在命令行运行>rman target /2.RMAN>startup nomount;3.RMAN>set dbid=1332475275 ---目标数据库控制文件丢失, 需要记住dbid4.RMAN> restore controlfile from autobackup;或RMAN> restore controlfile from ‘控制文件备份文件路径’5. RMAN>alter database mount;6. RMAN> recover database;7. RMAN>alter database open resetlogs;8. RMAN>backup database;----resetlogs后进行一次全备!第二种方法:没有可用的备份控制文件,通过重建控制文件来恢复;注意事项:重建控制文件用于恢复全部数据文件的损坏,需要注意其书写的正确性,保证包含了所有的数据文件与联机日志,同时注意可在装载数据库的情况下执行:SQL> alter database backup controlfile to trace;获取控制文件脚本(D:\oracle\product\10.2.0\admin\orcl\udump):新建一个名为controlfile.sql文本,将以上黄色部分拷贝到文本上保存;1.启动数据库到nomount状态:SQL>startup nomount;2. 将controlfile.sql拷贝到oracle目录下:D:\oracle\product\10.2.0\db_1 并执行SQL> @?\controlfile3. SQL>alter database open resetlogs;控制文件恢复完成。

ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案一、概述ORACLE 数据库是一种关系型数据库管理系统,广泛应用于企业级应用中。

然而,在使用过程中,可能会遇到各种故障情况,例如数据库无法启动、数据丢失、性能下降等。

为了保证数据库的稳定运行,需要及时解决这些故障。

本文将介绍一些常见的 ORACLE 数据库故障解决方案。

二、数据库无法启动1. 检查数据库实例是否正常启动。

使用命令 `ps -ef | grep pmon` 查看数据库实例进程是否存在。

如果不存在,可能是由于数据库实例未正常启动导致的故障。

解决方案:使用 `sqlplus / as sysdba` 命令登录到数据库,执行 `startup` 命令启动数据库实例。

2. 检查数据库控制文件是否损坏。

控制文件是 ORACLE 数据库的重要组成部份,记录了数据库的结构信息。

如果控制文件损坏,数据库将无法启动。

解决方案:使用 `ls -l` 命令检查控制文件的状态。

如果控制文件状态为`MISSING` 或者 `OFFLINE`,则需要恢复控制文件。

可以使用备份的控制文件替换损坏的控制文件,并执行 `startup` 命令启动数据库。

三、数据丢失1. 检查数据库备份情况。

数据库备份是防止数据丢失的重要手段。

如果数据库备份完备,可以通过备份文件进行数据恢复。

解决方案:使用 `rman` 工具进行数据库恢复。

首先,使用 `list backup` 命令查看备份文件的信息。

然后,使用 `restore database` 命令恢复数据库。

2. 检查数据文件是否损坏。

数据文件是 ORACLE 数据库中存储数据的文件。

如果数据文件损坏,可能导致数据丢失。

解决方案:使用 `select file#, name, status from v$datafile;` 命令检查数据文件的状态。

如果数据文件状态为 `RECOVER`,则需要进行数据恢复。

可以使用备份的数据文件替换损坏的数据文件,并执行 `recover datafile <file#>` 命令进行数据恢复。

Oracle数据库基于用户管理的控制文件的备份与恢复

时间:2010.1.6 来源:网络编辑:联动北方技术论坛在Oracle数据库中,控制文件是非常重要的。

它用于记录和维护数据库。

当恢复数据库时,服务器进程和后台进程需要从控制文件中读取各种备份相关的信息。

如果控制文件损坏,则会导致这些备份信息的丢失。

尽管使用多元化控制文件可以防止控制文件损坏,但因为控制文件的重要性,应该定期备份控制文件。

当数据库配置发生改变时,一定要备份控制文件。

涉及到数据库配置改变的命令:1.alter database [add|drop] logfile2.3.alter database [add|drop] logfile member4.5.alter database [add|drop] logfile group6.7.alter database [noarchivelog|archivelog]8.9.alter database rename file10.11.create tablespace12.13.alter tablespace [add|rename] datafile14.15.alter tablespace [read write|read only]16.17.drop tablespace控制文件的备份,三种方式1)使用OS命令进行拷贝1)open状态下,使用alter database命令生成控制文件副本2)open状态下,使用alter database backup controlfile to trace命令将控制文件备份到跟踪文件控制文件的恢复,两种方式1)mount状态下,使用RECOVER DATABASE USING BACKUP CONTROLFILE2)mount状态下,生成跟踪文件并进行恢复2--2示例:1.[oracle@localhost ~]$ rlsqlplus / as sysdba2.3.SQL*Plus: Release 10.2.0.1.0 - Production on 星期一 8月 1 21:40:03 20114.5.Copyright (c) 1982, 2005, Oracle. All rights reserved.6.7.Connected to an idle instance.8.9.SQL> startup10.11.ORACLE instance started.12.13.Total System Global Area 528482304 bytes14.15.Fixed Size 1220360 bytes16.17.Variable Size 176161016 bytes18.19.Database Buffers 343932928 bytes20.21.Redo Buffers 7168000 bytes22.23.Database mounted.24.25.Database opened.--open状态下生成控制文件副本1.SQL> alter database backup controlfile to2.3. 2 '/oracle/10g/oracle/bakup/database/oralife.ctl';4.5.alter database backup controlfile to6.7.*8.9.ERROR at line 1:10.11.ORA-01580: error creating control backup file12.13./oracle/10g/oracle/bakup/database/oralife.ctl14.15.ORA-27038: created file already exists16.17.Additional information: 118.19.SQL> alter database backup controlfile to20.21. 2 '/oracle/10g/oracle/bakup/database/oralife.ctl' reuse; --reuse用于覆盖原有控制文件副本23.Database altered.--手动删除所有控制文件模拟文件丢失1.SQL> ho rm /oracle/10g/oracle/product/10.2.0/oradata/oralife/*.ctl;--使用evan登录,并添加数据1.SQL> conn evan/evan2.3.Connected.4.5.SQL> select * from t_evan;6.7.TEXT8.9.--------------------------------------------------------------------------------10.11.oracle12.13.java14.15.spring16.17.hibernate18.19.hibernate20.21.SQL> insert into t_evan values('added');22.23. 1 row created.24.25.SQL> commit;26.mit complete.28.29.SQL> conn / as sysdba30.31.Connected.32.33.SQL> shutdown immediate34.35.ORA-00210: cannot open the specified control file36.37.ORA-00202: control file: '/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'39.ORA-27041: unable to open file40.41.Linux Error: 2: No such file or directory42.43.Additional information: 344.45.SQL> shutdown abort46.47.ORACLE instance shut down.--alter_oralife.log出现这样的信息:1.Mon Aug 1 23:13:51 20112.3.ORA-00202: control file: '/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'4.5.ORA-27037: unable to obtain file status6.7.Linux Error: 2: No such file or directory8.9.Additional information: 3--拷贝控制文件到目标路径1.SQL>ho cp /oracle/10g/oracle/bakup/database/oralife.ctl /oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl2.3.SQL> alter system set control_files='/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'scope = spfile; --修改control_files参数,指定可用的控制文件4.5.System altered.6.7.SQL> startup force mount8.9.ORACLE instance started.10.11.Total System Global Area 528482304 bytes12.13.Fixed Size 1220360 bytes14.15.Variable Size 138412280 bytes16.17.Database Buffers 381681664 bytes18.19.Redo Buffers 7168000 bytes20.21.Database mounted.--生成trace文件1.SQL> alter database backup controlfile to trace noresetlogs;2.3.Database altered.4.5.SELECT c.VALUE || '/' || d.instance_name || '_ora_' || a.spid || '.trc' TRACE6.7.FROM v$process a, v$session b, v$parameter c, v$instance d8.9.WHERE a.addr = b.paddr10.11.AND b.audsid = USERENV ('sessionid')12.13.AND = 'user_dump_dest';14.15.TRACE16.17.--------------------------------------------------------------------------------18.19./oracle/10g/oracle/product/10.2.0/db_1/admin/oralife/udump/oralife_ora_4558.trc20.21.SQL> shutdown immediate22.23.ORA-01109: database not open24.25.Database dismounted.26.27.ORACLE instance shut down.--打开trace文件,去掉注释,在shutdown状态下执行脚本,创建控制文件--用evan登录验证数据1.SQL> conn evan/evan2.3.Connected.4.5.SQL> select * from t_evan;6.7.TEXT8.9.--------------------------------------------------------------------------------10.11.oracle12.13.java14.15.spring16.17.hibernate18.19.hibernate20.21.added22.23. 6 rows selected.可见数据没有丢失。

损坏控制文件的恢复方法

一般情况下是利用控制文件的副本,我们创建数据库的时候不是一般都建立3个控制文件吗,这是用于进行冗余保护的,如果只有一个控制文件是好的,那么我们只需要将已损坏的控制文件删除,然后将好的这个控制文件复制到已损坏的控制文件的目录下,重命名成已损坏的控制文件即可(注意一下复制的位置,如果目标文件夹所在的磁盘已经损坏的情况下,我们就得把控制文件复制到好的磁盘上,并且还要修改control_files参数重新定位控制文件的位置)。

还有一种情况就是所有控制文件都损坏了,那么就得利用控制文件的备份进行恢复。

所以,我们在数据库创建好后第一件事就是对控制文件进行备份,在数据库物理结构变化之后也得备份控制文件。

使用命令ALTER DATABASE BACKUP CONTROLFILE TO TRACE,会有一个转储文件会放在user_dump_dest参数定义的目录中,里面有重建控制文件的脚步,按照转储文件里面写的做就可以了。

一、损坏单个控制文件损坏单个控制文件是比较容易恢复的,因为一般的数据库系统,控制文件都不是一个,而且所有的控制文件都互为镜相,只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、控制文件损坏,最典型的就是启动数据库出错,不能mount数据库SQL>startupORA-00205: error in identifying controlfile, check alert log for more info查看报警日志文件,有如下信息alter database mountMon May 26 11:59:52 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。

控制文件损坏的恢复

一、损坏单个控制文件损坏单个控制文件是比较容易恢复的,因为一般的数据库系统,控制文件都不是一个,而且所有的控制文件都互为镜相,只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、控制文件损坏,最典型的就是启动数据库出错,不能mount数据库SQL>startupORA-00205: error in identifying controlfile, check alert logfor more info查看报警日志文件,有如下信息alter database mountMon May 26 11:59:52 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。

2、停止数据库SQL>shutdown immediate3、拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数,取消这个坏的控制文件。

4、重新启动数据SQL>startup说明:1、损失单个控制文件是比较简单的,因为数据库中所有的控制文件都是镜相的,只需要简单的拷贝一个好的就可以了2、建议镜相控制文件在不同的磁盘上3、建议多做控制文件的备份,长期保留一份由alter databasebackup control file to trace产生的控制文件的文本备份二、损坏全部控制文件损坏多个控制文件,或者人为的删除了所有的控制文件,通过控制文件的复制已经不能解决问题,这个时候需要重新建立控制文件。

同时注意,alter database backup control file to trace可以产生一个控制文件的文本备份。

以下是详细重新创建控制文件的步骤1、关闭数据库SQL>shutdown immediate;2、删除所有控制文件,模拟控制文件的丢失3、启动数据库,出现错误,并不能启动到mount下SQL>startupORA-00205: error in identifying controlfile, check alert logfor more info查看报警日志文件,有如下信息alter database mountMon May 26 11:53:15 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

ORACLE控制文件损坏处理办法
--关于ORACLE控制文件错误的处理
处理方法一.更改INIT.ORA中的参数,删除不能使用的controlFile ;
处理方法二.
先备份ORACLE安装目录和所有自定义创建的数据文件,再按照以下步骤进行试验处理。

进入MS-DOS窗口,适用SVRMGRL工具;
CONNECT INTERNAL/ORACLE ;
STARTUP NOMOUNT;
CREATE CONTROLFILE REUSE DA TABASE "ORCL" NORESETLOGS NOARCHIVELOG MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1815
LOGFILE
#此处根据实际情况处理
GROUP 1 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG' SIZE 1M,
GROUP 2 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG' SIZE 1M,
GROUP 3 'D:\ORACLE\ORADATA\ORCL\REDO01.LOG' SIZE 1M
DA TAFILE
#此处根据实际情况处理
'D:\ORACLE\ORADA TA\ORCL\SYSTEM01.DBF',
'D:\ORACLE\ORADA TA\ORCL\RBS01.DBF',
'D:\ORACLE\ORADA TA\ORCL\USERS01.DBF',
'D:\ORACLE\ORADA TA\ORCL\TEMP01.DBF',
'D:\ORACLE\ORADA TA\ORCL\TOOLS01.DBF',
'D:\ORACLE\ORADA TA\ORCL\INDX01.DBF',
'D:\ORACLE\ORADA TA\ORCL\DR01.DBF',
'D:\ORACLE\ORADA TA\ORCL\SDE.ORA',
'D:\ORACLE\ORADA TA\ORCL\GIS.ORA',
'D:\ORACLE\ORADA TA\ORCL\OEM_REPOSITORY.ORA'
CHARACTER SET ZHS16GBK
;
# Take files offline to match current control file.
# 可以不执行以下DROP
ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\USERS01.DBF'
OFFLINE DROP;
ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\TOOLS01.DBF'
OFFLINE DROP;
ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\INDX01.DBF' OFFLINE DROP;
ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\DR01.DBF' OFFLINE
DROP;
# Recovery is required if any of the datafiles are restored backups,
# or if the last shutdown was not normal or immediate.
# 可以直接使用RECOVER
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;
# No tempfile entries found to add.
# OK !!!!一切搞定
另外控制文件出现错误时ORACLE不提示控制文件错误,而是提示数据文件错误;比如:Ora-01122 ora-01110 ora-01207 ,可以在MOUNT状态下查询V$RECOVER_FILE,。

相关文档
最新文档