UNDO表空间数据文件和system表空间数据文件都是数据库的关键数据文件,如果损坏会导致sql执行失败,用户无法登录,甚至实例崩溃等.同样恢复UNDO表空间数据文件也必须在数据库mount状态下进行. 数据库在运行过程中发现UNDO表空间数据文件损坏,此时是无法正常关闭数据库的: SQL> shutdown immediate; ORA-01122: database file 3 failed verification check ORA-01110: data file 3: '/u

缩小Oracle目录下UNDOTBS01.DBF文件的大小 分类: Oracle 使用sys用户登录Oracle 方法一:重置表空间大小 执行ALTER DATABASE DATAFILE 'D:ORACLEORADATAUNDOTBS01.DBF' RESIZE 100M; 其中 'D:ORACLEORADATAUNDOTBS01.DBF' 为您系统中UNDOTBS01.DBF文件的存储路径;100M为重置后的大小,根据需要修改 如果方法一无法执行,可使用方法二 方法二:新建UNDO表空间,替

OS: Oracle Linux Server release 5.7 DB: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production 数据库打开模式,非归档模式,非当前日志损坏 SQL> archive log list;Database log mode No Archive ModeAutomatic archival DisabledArchive destination USE_DB_RE

上周三中午CQ数据库数据文件损坏,导致登录时一张关键的表无法查询报错从而cq无法登录,此次故障和上次的一样,不过恢复的非常曲折,导致停机两天,现简单的通报下恢复过程: 故障原因: oracle-902版本的一个BUG,数据文件大小逼近4G.8G临界点时无法自动扩展,该bug在903版本后得到修复,但是公司cq库迟迟未升级,14号数据文件上保存了大量的大对象数据以及大部分cq系统表,在执行修改操作段扩张时逼近4G大小临界点从而报错,导致数据文件头不一致,数据文件被offline...上次故障也是同

前段时间一朋友自己电脑上的开发测试用的数据库出了点问题,电脑操作系统是Win8,直接在Win8上安装了Oracle11g,后来系统自动升级到Win8.1,Oracle相关的服务全都不见了,想想把数据文件.参数据文件.控制文件.redo log备份一下,然后重装一下,但在复制控制文件的时候,总是无法复制,最终放弃了备份控制文件,打算装好后重建控制文件.一切还算顺利,因为数据文件和redo log都是完整的,所以重建控制文件也很顺利. 由此想到春节前有一台服务器因断电而导致控制文件和redo log

背景 业务起不来,读取数据库时报坏块,无法读取数据 数据库版本:11.2.0.3 数据库无备份,无归档 1. 识别坏块 执行以下命令后,rman 会把坏块信息统计到 v$database_block_corruption RMAN> backup validate check logical database; 此命令只是检查坏块,不会执行备份操作 如果执行失败的话,可以通过 'SKIP INACCESSIBLE' 来跳过失败 RMAN> configure device type disk

一, 故障模拟 控制文件损坏 发现关闭不了 强制关闭   故障恢复   发现已经执行到mont阶段,因为这个不依靠控制文件 进入整段日志 cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace/ 查看alert_orcl.log日志 vim alert_orcl.log 报错信息 ORA-: cannot open the specified control file ORA-: control file: '/oradata/orcl/control01.c

1.什么是块损坏: 所谓损坏的数据块,是指块没有採用可识别的 Oracle 格式,或者其内容在内部不一致. 通常情况下,损坏是由硬件故障或操作系统问题引起的.Oracle 数据库将损坏的块标识为"逻辑损坏"或"介质损坏". 假设是逻辑损坏,则是 Oracle 内部错误. Oracle 数据库检測到不一致之后,就将逻辑损坏的块标记为损坏.假设是介质损坏,则是块格式不对:从磁盘读取的块不包括有意义的信息. 通过恢复块,或者删除包括损坏块的数据库对象(或同一时候採用这两种

   如果损坏的是current redo log (select group#,sequence#,archived,status from v$log;) 有两种情况: A.   数据库是正常关闭的.当前日志组的损坏就可以直接用alter database clear unarchived logfile group n来重建. 启动数据库到mount状态 SQL> select group#,sequence#,archived,status from v$log; GROUP#  SEQ

Oracle 控制文件损坏解决方案 故障一:丢失(损坏)一个控制文件 前台报错:ORA-00205:error in identifying control file,check alert log for more info 解决方案:(干净或非干净方式关闭数据库) 使用完好的控制文件复制(替换)重命名丢失(损坏)的控制文件: 故障二:两个控制文件版本不一致 (1)一个控制文件正常,另一个控制文件来源于其他备份或其他数据库的控制文件: 前台报错:ORA-00214:control file '

04 bbed修复system文件头损坏 1 启动数据库,查看trace,在mount到open, SQL> startup mount; ORACLE instance started. Total System Global Area bytes Fixed Size bytes Variable Size bytes bytes Redo Buffers bytes Database mounted. SQL> alter session set events '10046 trace

己亥清爽系列说明:清爽系列是作为恢复系列的基础篇,基于FS(File System)文件系统的手工还原恢复,也叫基于用户管理的还原恢复.来自于博客园AskScuti 实验说明:在有完全备份基础下,物理删除关键系统数据文件 system01.dbf ,模拟介质损坏或丢失,并进行手工还原恢复操作. 基于版本:Oracle 11gR2 11.2.0.4 AskScuti 概念说明:请严格区分什么叫还原(Restore),什么叫恢复(Recover). 还原(Restore):如果是基于用户管理(手工)

一.概述 本文将给大家介绍oracle各类文件损坏的现象和应对策略,请注意所有的恢复都是基于有备份的情况,所以请开启数据库的日常备份.文章将从以下文件展开 a. 密码文件 b. 参数文件 c. 控制文件 d. 数据文件(分普通表空间数据文件,其它表空间数据文件如system.sysaux.undo) e. 日志文件(分current.active.inactive) 在正式实验之前,我先问一个问题,上面这些文件,哪个损坏最致命? 二.环境准备 本实验在oracle 11G归档模式下进行,实验前先

DBF 文件 ORACLE 数据库恢复 清·魏源<庸易通义>:"至道问学之有知无行,分温故为存心,知新为致知,而敦厚为存心,崇礼为致知,此皆百密一疏." 起因 在我们的生产活动中,意外总是在不经意间发生.那天一个安装有 oracle 数据库的盘符不小心被格式化了,好几个项目都炸了.不过还好有备份,不过只有 .DBF 文件和几个日志文件: //数据库系统相关 REDO01.LOG REDO02.LOG REDO03.LOG SYSTEM01.DBF UNDOTBS01.DBF

方法一:1.将数据文件的状态offline SQL> select file_name,tablespace_name from dba_data_files where file_name like '%user%'; FILE_NAME -------------------------------------------------------------------------------- TABLESPACE_NAME ------------------------------ /

DB:Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production OS:Oracle Linux 5.7 非归档模式:SQL> archive log list;Database log mode              No Archive ModeAutomatic archival             DisabledArchive destination            USE_DB

模拟手工删除UNDO表空间 在ORADATA 中把UNDOTBS01.DBF 删除 模拟启库 SQL> STARUP; * 第 1 行出现错误: ORA-01157: 无法标识/锁定数据文件 2 - 请参阅 DBWR 跟踪文件 ORA-01110: 数据文件 2: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF' 利用系统本身的默认手动管理 MANUAL UNDO 表空间 SYSTEM 启动库  SQL> CREATE PFILE='C

undo 故障诊断与恢复(二) 今天是2013-09-01,目前困扰我将近一周的问题,终于解决了,我非常感谢帮助我的朋友,也非常感谢管我要钱然后替我解决问题的朋友(我没采用).这更激发了我一定要解决这个问题的斗志. 我写这篇笔记,就是为了帮助那些遇到同样困难的朋友,我觉得‘闻道有先后,术业有专攻’,没有人是无法被取代的.如果有朋友搜到我这篇文章,希望我能给你带来问题的解决办法. 先描述一下,我模拟的这种问题的情景: 1)数据处于open状态,非归档,无备份 2)直接rm掉undo表空间的所有数据

在RMAN备份中,出现了一个问题,就是出现坏块了. ORA-: write error on file (blocksize=) ORA-: File I/O error Linux Error: : Bad file descriptor 解决方案: blockrecover datafile 1 block 为什么我知道坏块40321就会在datafile 1中呢?因为错误提示的是system01.dbf. 你可以从v$datafile文件中查得文件号和文件名. SQL> select fi

1:使用初始化参数 使用初始化参数db_block_checksum\db_block_checking能够设置数据库对块的物理一致性和逻辑一致性检查. Db_block_checksum:物理一致性检查.默认开启. 始终对system表空间数据进行检查.假设开启还会对日志进行检查,开启后会有1-2%的性能影响.建议开启. Db_block_checking:逻辑一致性检查,默认未开启.始终对system表空间进行检查,假设开启会有1-10%的性能影响.DML越频繁,性能影响越大.不建议开启.