ORA-01578_Oracle_data_block_corrupted
ORA-00119 invalid specification for
一、ERROR:ORA-01034: ORACLE not availableORA-27101: shared memory realm does not exis1、报的oracle错ORA-01092: ORACLE instance terminated. Disconnection forced 2ORA-00604: error occurred at recursive SQL level 1ORA-01578: ORACLE data block corrupted (file # 1, block # 2112)ORA-01110: data file 1:'C:\APP\ADMINISTRATOR\ORADATA\NXDCZDOA\SYSTEM01.DBF' 二、sqlplus /nologSQL> conn / as sysdbaConnected to an idle instance.SQL> startup nomountORACLE instance started.Total System Global Area 890853260 bytesFixed Size 456588 bytesVariable Size 301989888 bytesDatabase Buffers 587202560 bytesRedo Buffers 1204224 bytesSQL> alter database mount;Database altered.SQL> alter database open;alter database open三、修改日志SQL> CREATE CONTROLFILE set Database ocp Resetlogs2 MAXLOGFILES 163 MAXLOGMEMBERS 34 MAXDATAFILES 1005 MAXINSTANCES 86 MAXLOGHISTORY 2927 LOGFILE9 GROUP 2 'D:\oracle\product\10.2.0\oradata\ocp\RED002.LOG'SIZE 50M,10 GROUP 3 'D:\oracle\product\10.2.0\oradata\ocp\RED003.LOG'SIZE 50M11 DATAFILE12 'D:\oracle\product\10.2.0\oradata\ocp\SYSTEM01.DBF',13 'D:\oracle\product\10.2.0\oradata\ocp\UNDOTBS01.DBF',14 'D:\oracle\product\10.2.0\oradata\ocp\SYSAUX01.DBF',15 'D:\oracle\product\10.2.0\oradata\ocp\USERS01.DBF'16 CHARACTER SET ZHS16GBK17 ;控制文件已创建。
les_07_Dealing with Database Corruption
处理数据库损坏目标•课程目标:–确定数据库损坏原因:•硬件•软件–要发现数据库损坏，可通过:•ANALYZE•DBVERIFY•DB_BLOCK_CHECKING•DBMS_REPAIR–用RMAN处理损坏什么是块损坏?•每当有块被读或被写时, 执行一次检查.–块版本–比较在cache和block buffer中的DBA (data block address)值–Block-checksum块校验, 如果启动的话•损坏块被确定为下列其中一个:–介质损坏–逻辑(或软件) 损坏块损坏症状: ORA-01578•错误ORA-01578: "ORACLE data block corrupted (file # %s, block # %s)":–当一个损坏数据库块被发现时已经产生–总是返回绝对的文件号码和块号码–当发现损坏时，返回发表执行查询的会话–出现在alert.log文件•检查警告日志和操作系统日志文件.•用可用的诊断工具找出损坏类型.•坚持通过多次运行检查，判断是否错误.•如果必须的话，就从损坏对象中恢复数据.•解决所有硬件问题:–内存–磁盘控制器–磁盘•如果必须的话，就从损坏对象中恢复或重建数据.损坏的相关特征TRUENoneBlock media recoveryTRUE Logical Flashback TRUE Logical DBMS_REPAIR FALSE Logical DB_BLOCK_CHECKING Physical Physical Logical Physical 发现损坏FALSE DB_BLOCK_CHECKSUM FALSE exp FALSE ANALYZEFALSE DBVERIFY 修理损坏特征DBVERIFY 应用程序•只对数据文件起作用; 重做日志文件不能被检查•检查块一致性•当数据库被打开的时候能够被使用•实用程序的名称: dbv$ dbv file=/u01/oradata/users01.dbf \blocksize=8192了解DBVERIFY 输出•一个记录就是一个块.•如果首部和尾部不匹配，DBVERIFY重读这个块，如果它们匹配，一个influx块被报告，否则，发出一个损坏信号.Total Pages Examined : 12800Total Pages Processed (Data) : 4408Total Pages Failing (Data) : 0Total Pages Processed (Index): 1264...Total Pages Marked Corrupt : 4Total Pages Influx : 0Highest block SCN : 654836 (0.654836)ANALYZE命令•执行一个逻辑块检查•当是软件损坏的时候，不对块做标记，仅仅报告它们•验证索引和表的条目SQL> ANALYZE TABLE table_name VALIDATE2 STRUCTURE CASCADE;SQL> ANALYZE INDEX index_name VALIDATE2 STRUCTURE;•DB_BLOCK_CHECKING初始化参数:–当处理每个块时，控制自我联结执行–能够防止内存和数据损坏–可通过ALTER SESSION或ALTER SYSTEM DEFERRED命令对它进行设置•DB_BLOCK_CHECKSUM初始化参数:–决定每个块的校验器是否维持且校验–预防潜在I/O系统引起的损坏a14f使用EXP发现损坏•常规的export能够被用来发现损坏.$ exp hr/hr tables=departmentsAbout to export specified tables via Conventional Path.... . exporting table DEPARTMENTSEXP-00056: ORACLE error 1578 encounteredORA-01578: ORACLE data block corrupted (file # 5, block #51)ORA-01110: data file 5:'/u01/app/oracle/oradata/orcl/example01.dbf'对逻辑损坏使用闪回DBAUSERUndo SQL或闪回表发现坏数据闪回版本查询闪回事务查询DBMS_REPAIR包•可用的程序–CHECK_OBJECT–FIX_CORRUPT_BLOCKS–DUMP_ORPHAN_KEYS–REBUILD_FREELISTS–SEGMENT_FIX_STATUS–SKIP_CORRUPT_BLOCKS–ADMIN_TABLES1.发现并报告损坏.2.评估DBMS_REPAIR 的代价和好处.SET SERVEROUTPUT ONDECLARE num_corrupt INT;BEGINnum_corrupt := 0;DBMS_REPAIR.CHECK_OBJECT (schema_name => ‘HR',object_name => 'DEPARTMENTS',repair_table_name => 'REPAIR_TABLE',corrupt_count => num_corrupt);END;3.使对象可用.SET SERVEROUTPUT ONDECLARE num_fix INT;BEGINnum_fix := 0;DBMS_REPAIR.FIX_CORRUPT_BLOCKS (schema_name => 'HR',object_name => 'DEPARTMENTS',object_type => DBMS_REPAIR.TABLE_OBJECT, repair_table_name => 'REPAIR_TABLE',fix_count => num_fix);END;4.修理损坏和重建丢失的数据.SET SERVEROUTPUT ONDECLARE num_orphans INT;BEGINnum_orphans := 0;DBMS_REPAIR.DUMP_ORPHAN_KEYS (schema_name => 'SCOTT',object_name => 'PK_DEPT',object_type => DBMS_REPAIR.INDEX_OBJECT,repair_table_name => 'REPAIR_TABLE',orphan_table_name => 'ORPHAN_KEY_TABLE',key_count => num_orphans);DBMS_OUTPUT.PUT_LINE('orphan key count: ' ||TO_CHAR(num_orphans));END;Block Media Recovery (BMR)•Block media recovery:–降低平均恢复时间(MTTR)–增加介质恢复期间的适用性•在恢复时数据文件保持在线.•仅仅对块进行恢复是达不到的.–用RMAN调用BLOCKRECOVER命令•从可用备份文件中还原个别块•调整服务器来恢复BLOCKRECOVER命令•RMAN BLOCKRECOVER命令:–确定这个备份包含恢复时需要的块–读取备份，并积聚被请求的块到内存中的缓冲器中–如果必须的话，通过从备份中读取归档日志来管理block media recovery 会话–不能用于不完全恢复RMAN> BLOCKRECOVER DATAFILE 6 BLOCK 3;使用BLOCKRECOVER 的例子•恢复一组损坏的块•用还原类型限制block media recovery•用恢复标签限制block media recovery•用时间、SCN、日志限制block media recoveryRMAN BMR 界面•动态性能视图显示当前状态的损坏.–V$DATABASE_BLOCK_CORRUPTION视图显示数据库当前损坏块的清单.RMAN> BLOCKRECOVER CORRUPTION LIST2> RESTORE UNTIL TIME 'sysdate –10';–V$BACKUP_CORRUPTION视图显示数据文件备份中的损坏块的清单.–V$COPY_CORRUPTION 视图显示镜像文件拷贝中的损坏块的清单.可选择性操作•表: 损坏块中的数据丢失了.–删除并重建表格，并且用输出文件导入数据.–用SQL或者PL/SQL把数据输入一个新建的表中.•索引: 丢弃和重建索引.总结•本节课中, 你学会如何:–识别数据库损坏的原因:•硬件•软件–用以下工具诊断数据库:•ANALYZE•dbverify•DB_BLOCK_CHECKING•DBMS_REPAIR–用RMAN修复损坏练习: 执行块介质恢复•This practice covers the following topics:–Discovering corruption–Identifying the location of the corruption–Recovering from the corruption by using block media recovery。
LIMS系统应急方案
有色金属研究总院测试中心实验室信息管理系统应急方案北京XX天地科技有限公司20XX年11月第 1 页共29 页文档说明本文档是有色金属研究总院测试中心LIMS项目应急预案。
文档控制文档作者：XX创建日期：20XX年11月确认日期：控制编码：GRINM-RM-01当前版本：1.0更改记录：文件归档:目录目录 (3)1.1.目的 (4)1.2.前提条件 (4)2.紧急情况的发现与应急方案的启动 (4)2.1.紧急情况的发现 (4)2.2.应急方案的启动 (5)2.2.1.启动的条件 (5)2.2.2.应急启动的发布 (5)2.3.各类实验室负责人 (5)3.应急措施 (5)3.1.生产服务器发生故障 (5)3.2.实验室同步故障 (6)3.3.网络故障 (6)3.4.数据库故障 (6)4.操作系统相关维护 (8)4.1.数据库安装与配置 (9)4.2.数据库日志检查 (21)4.3.性能优化与配置 (22)4.4.数据库备份与恢复 (24)5.数据库备份与恢复方案 (25)5.1.备份方案 (25)5.2.恢复方案 (28)总体介绍1.1.目的有色院STARLIMS系统作为实验室信息方面的企业级管理系统，一旦因各种原因意外中断，对有色院其他的信息系统影响重大。
本文档的目的在说明如何应对系统的意外中断以及如何在系统恢复后保证数据的完整性。
另外讲明了STARLIMS系统的基本维护方式方法。
本文主要涉及的问题如下：⏹一旦发现不能进行系统的正常操作，最终用户首先应该如何操作？⏹根据业务处理的连续性要求，在有色院实验室信息管理系统中断的情况下，如何处理业务？⏹在有色院实验室信息管理系统恢复运行以后，最终用户应该如何操作以保证系统中数据的准确和完整？⏹数据库应该如何进行日常维护与备份数据采用哪种策略？1.2.前提条件本文档所述应急方案针对有色院实验室信息管理系统因意外原因不能被最终用户正常使用的情况，即有色院实验室信息管理系统服务器系统停机/中断或网络中断的情况，并且该情况持续超过业务连续性所允许的范围，如超过1个工作日，或者有色院实验室信息管理系统不能顺利地支持实验室管理业务，如不能完成实验室审核、同步等业务。
Oracle数据库日常维护
1、查看监听器状态[bpm@www ~]$ lsnrctlLSNRCTL> statusLSNRCTL> exit2、启动监听器[bpm@www ~]$ lsnrctl start3、停止监听器[bpm@www ~]$ lsnrctl stopOracle数据库日常维护一、检查数据库文件的状态DBA要及时查看数据库中数据文件的状态（如被误删除），根据实际情况决定如何进行处理，检查数据文件的状态的SQL如下：select file_name,status from dba_data_files;如果数据文件的STATUS列不是AVAILABLE，那么就要采取相应的措施，如对该数据文件进行恢复操作，或重建该数据文件所在的表空间。
二、检查数据库定时作业的完成情况如果数据库使用了Oracle的JOB来完成一些定时作业，要对这些JOB的运行情况进行检查：select job,log_user,last_date,failures from dba_jobs;如果FAILURES列是一个大于0的数的话，说明JOB运行失败，要进一步的检查。
三、数据库坏块的处理当Oracle数据库出现坏块时，Oracle会在警告日志文件（alert_SID.log）中记录坏块的信息：ORA-01578: ORACLE data block corrupted (file # 7, block # <BLOCK>) ORA-01110: data file <AFN>: '/oracle1/oradata/V920/oradata/V816/users01.dbf'其中，＜AFN＞代表坏块所在数据文件的绝对文件号，<BLOCK>代表坏块是数据文件上的第几个数据块出现这种情况时，应该首先检查是否是硬件及操作系统上的故障导致Oracle数据库出现坏块。
在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。
oracle坏块原因分析与修复方法
Oracle 坏块总结收藏Oracle数据库出现坏块现象是指：在Oracle数据库的一个或多个数据块（一个数据块的容量在创建数据库时由db_block_size参数指定，缺省为8K）内出现内容混乱的现象。
由于正常的数据块都有固定的合法内容格式，坏块的出现，导致数据库进程无法正常解析数据块的内容，进而使数据库进程报错乃至挂起，并级联导致整个数据库实例出现异常。
一．坏块的产生原因坏块产生的原因大致有以下几种：1.1 硬件问题Oracle进程在处理一个数据块时，首先将其读入物理内存空间，在处理完成后，再由特定进程将其写回磁盘；如果在这个过程中，出现内存故障，CPU计算失误，都会导致内存数据块的内容混乱，最后反映到写回磁盘的数据块内容有误。
同样，如果存储子系统出现异常，数据块损坏也就随之出现了。
1.2 操作系统BUG由于Oracle进程对数据块的读写，都是以操作系统内核调用（system call）的方式完成的，如果操作系统在内核调用存在问题，必然导致Oracle进程写入非法的内容。
1.3 操作系统的I/O错误或缓冲问题1.4 内存或paging问题Oracle软件BUGOracle软件特定版本上，可能出现导致数据块的内容出现异常BUG。
1.5 非Oracle进程扰乱Oracle共享内存区域如上文所述，在当数据块的内容被读入主机的物理内存时，如果其他非Oracle进程，对Oracle 使用的共享内存区域形成了扰乱，最终导致写回磁盘的数据块内容混乱。
1.6 异常关机，掉电，终止服务异常关机，掉电，终止服务使进程异常终止，而破坏数据块的完整性，导致坏块产生。
注：这也是为什么突然断电会导致数据库无法启动由上可见，坏块的形成原因复杂。
当出现坏块时，为了找到确切的原因，需要大量的分析时间和排查操作，甚至需要多次重现才能找出根本原因。
但当故障发生在生产系统上，我们为了减少停机时间，会尽快实施应急权变措施以保证系统的可用性，这样就破坏了故障现场，对根本原因的分析因而也更加困难了。
DBVERIFY工具的使用
DBVERIFY工具的使用--**********************-- DBVERIFY 工具的使用--**********************Oracle 数据库运行过程中由于硬件故障或操作系统故障导致导致Oracle无法以Oracle格式来识别或所包含的内容即为出现数据块损坏故障，这个坏块可以分为介质损坏以及逻辑损坏。
下面给出了块的检查，以及使用DBVERIFY 工具实施块检查。
一、块检查1.何时检查块当一个数据块被读或写的时候，将对块的进行一致性检查，检查的内容包括块的版本比较块在cache与block buffer中的数据块地址根据要求进行校验(checksum)2.损坏的数据块的错误提示可以从告警日志文件中找到该错误提示，以及在会话中发现损坏的数据块时也会给出类似的提示ORA-01578: ORACLE data block corrupted (file # 6, block # 11)ORA-01110: data file6: '/u01/app/oracle/oradata/orcl/tbs01.dbf'3.与块损坏的相关特性(几种检查工具)------------------------------------------------------------------------------------------------特性 坏块侦测类型 能否修复损坏块------------------------------------------------------------------------------------------------DBVERIFY 物理 否ANALYZE逻辑 否DB_BLOCK_CHECKING 逻辑 否DB_BLOCK_CHECKSUM 物理 否exp 物理 否FlashBack逻辑 是DBMS_REPAIR 逻辑 是Block media recovery 未知 是二、DBVERIFY工具介绍特性是一个运行于操作系统提示符下的外部程序，用于验证数据文件，检查块的一致性错误仅仅针对数据文件，能够校验open阶段的数据文件以及shutdown状态下的数据文件可以验证复制的数据文件，也可以验证备份的镜像副本不支持联机日志文件，控制文件，归档日志，RMAN备份集验证被验证的文件可以位于文件系统，ASM磁盘或原始设备在Unix系统中位于:$ORACLE_HOME/bin/dbv在Windows系统中位于:%ORACLE_HOME%/bin/dbv.exe对于DBVERIFY工具，高版本可以自动识别低版本数据库，比如11g的dbv访问9i的数据库，但是低版本的dbv访问高版本会报错三、DBVERIFY工具用法1.获取dbv的帮助信息，直接在提示符下输入dbv即可 或者输入dbv help=y[oracle@oradb orcl]$ dbvDBVERIFY: Release 10.2.0.4.0 - Production on Tue Oct 2618:21:092010Copyright (c) 1982, 2007, Oracle. All rights reserved.Keyword Description (Default)----------------------------------------------------FILE File to Verify (NONE)START Start Block (First Block of File)END End Block (Last Block of File)BLOCKSIZE Logical Block Size (8192)--指定数据文件的尺寸,缺省值为8192,对于非8192块将收到DBV-00103错误LOGFILE Output Log (NONE) --用于显示验证进度FEEDBACK Display Progress (0)PARFILE Parameter File (NONE) --可以指定参数文件USERID Username/Password (NONE) --校验段、ASM文件需要使用SEGMENT_ID Segment ID (tsn.relfile.block) (NONE) --校验段,需要表空间ID,数据文件ID,段的头部IDHIGH_SCN Highest Block SCN To Verify (NONE)(scn_wrap.scn_base OR scn)2.校验online，offline数据文件，使用下面的方法dbv file=<dir>[oracle@oradb orcl]$ dbv file=$ORACLE_BASE/oradata/orcl/tbs01.dbfDBVERIFY: Release 10.2.0.4.0 - Production on Tue Oct 2618:29:392010Copyright (c) 1982, 2007, Oracle. All rights reserved.DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/orcl/tbs01.dbfDBVERIFY - Verification completeTotal Pages Examined : 128--校验的总页面数，一个页面即是一个数据块Total Pages Processed (Data) : 96--已处理的数据页面数Total Pages Failing (Data) : 0--已处理数据页面的失败数Total Pages Processed (Index): 1--已处理的索引页面数Total Pages Failing (Index): 0--已处理索引页面失败数Total Pages Processed (Other): 31--已处理的其它页面数Total Pages Processed (Seg) : 0Total Pages Failing (Seg) : 0Total Pages Empty : 0Total Pages Marked Corrupt : 0Total Pages Influx : 0Highest block SCN : 1152518 (0.1152518)注意：如果Total Pages Influx的值大于零，且未存在坏块的情况下，是由于针对open状态的文件运行dbv程序遇到了一个当前正在被DBWn进程写入的数据块[oracle@oradb orcl]$ dbv file=$ORACLE_BASE/oradata/orcl/tbs01.dbf feedback=1000上面这句在执行时每验证1000个块将显示一个"."号--下面的校验发现了I/O错误[oracle@oradb orcl]$ dbv file=/u01/app/oracle/oradata/orcl/tbs01.dbfDBVERIFY: Release 10.2.0.4.0 - Production on Tue Oct 2618:26:212010Copyright (c) 1982, 2007, Oracle. All rights reserved.DBV-00102: File I/O error on FILE (/u01/app/oracle/oradata/orcl/tbs01.dbf)during end read operation (-1)3.验证指定段该方法需要获得段所在表空间的ID，段所在数据文件的ID，段的头部ID如下面的查询表空间的ID为7，文件ID为6，段的头部ID为35sys@ORCL> select tablespace_id,tablespace_name,header_file,header_block2from sys_dba_segs3where segment_name='TB3';TABLESPACE_ID TABLESPACE_NAME HEADER_FILE HEADER_BLOCK------------- --------------- ----------- ------------7 TBS1 635注意：sys用户的段可以查询sys_user_segs，而普通用户的段信息，需要查询sys_dba_segs[oracle@oradb orcl]$ dbv userid=scott/tiger segment_id=7.6.35DBVERIFY: Release 10.2.0.4.0 - Production on Tue Oct 2618:50:012010Copyright (c) 1982, 2007, Oracle. All rights reserved.DBVERIFY - Verification starting : SEGMENT_ID = 7.6.35DBVERIFY - Verification completeTotal Pages Examined : 8Total Pages Processed (Data) : 5Total Pages Failing (Data) : 0Total Pages Processed (Index): 0Total Pages Failing (Index): 0Total Pages Processed (Other): 2Total Pages Processed (Seg) : 1Total Pages Failing (Seg) : 0Total Pages Empty : 0Total Pages Marked Corrupt : 0Total Pages Influx : 0Highest block SCN : 1152518 (0.1152518)4.验证复制的数据文件或验证备份的镜像副本RMAN> backup as copy datafile6--使用RMAN备份镜像副本2> format='/u01/app/oracle/bk/rmbk/cp_dfile6'3> tag='Copy_datafile6';[oracle@oradb orcl]$ dbv file=/u01/app/oracle/bk/rmbk/cp_dfile6DBVERIFY: Release 10.2.0.4.0 - Production on Tue Oct 2618:59:172010Copyright (c) 1982, 2007, Oracle. All rights reserved.DBVERIFY - Verification starting : FILE = /u01/app/oracle/bk/rmbk/cp_dfile6DBVERIFY - Verification completeTotal Pages Examined : 128Total Pages Processed (Data) : 96Total Pages Failing (Data) : 0Total Pages Processed (Index): 1Total Pages Failing (Index): 0Total Pages Processed (Other): 31Total Pages Processed (Seg) : 0Total Pages Failing (Seg) : 0Total Pages Empty : 0Total Pages Marked Corrupt : 0Total Pages Influx : 0Highest block SCN : 1152518 (0.1152518)RMAN命令中的BACKUP VALIDATE DATABASE命令通常用于检查全库，该命令不产生任何备份集，可以通过 Validate命令来检查是否能备份，如数据文件是否存在，是否存在坏块不能被备份，查询视图v$database_block_corruption，此视图将检查过程中存在的坏块如使用下面的查询RMAN> backup validate database;RMAN> backup validate database archivelog all;sys@ORCL> select * from v$database_block_corruption;no rows selected视图v$database_block_corruption将列出损坏的坏块所在的文件位置，损坏块的起始位置，损坏快的大 小以及损坏类型如果上述视图中发现了坏块，则可以通过SQL查询获得坏块所影响的范围，以及确定坏块 所影响的是索引段还是UNDO段select owner,segment_name,segment_type from dba_extents where file_id=<F> and <B>between block_id and block_id+blocks-1;(<F>和<B>分别是ORA-01578报出的坏块出现的文件号和块号)下面使用rman 来修复受损的数据块RMAN> run{。
NOLOGGING 介绍
以下操作可以启用nologging1.创建索引或重建索引。
2.通过/*+APPEND*/提示，使用直接路径(Direct Path)批量INSERT操作3.SQL*Loader直接路径加载数据。
4.CTAS方式创建数据表。
5.大对象(LOB)的操作。
6.一些ALTER TABLE操作，如MOVE SPLIT等数据文件的unrecoverable在Oracle的备份恢复过程中，需要注意数据文件的unrecoverable，不适当的操作很容易造成恢复后有大量的坏块。
在视图v$datafile中，UNRECOVERABLE_CHANGE#和UNRECOVERABLE_TIME分别表示数据文件最后一个unrecoverable操作的change#和时间。
unrecoverable通常就是指不记录日志的操作（nologging），这样当用一个旧的数据文件还原后，用日志进行恢复时，由于日志文件没有记录unrecoverable的操作时的日志，导致那些操作的数据块为逻辑坏块（实际上在日志文件中为这样的操作产生了一些重做日志项，在恢复时，根据这些重做日志项，直接将相应的数据块标记为坏块）。
常见的以下几种情况：1. 非归档模式下的create table as 操作和直接路径插入（如加了append hint的insert 语句和直接路径装载）2. 归档模式下的create table xxx nologging（即创建表时为表指定了nologging）和nologging表的直接路径插入。
在数据库（或表空间）为force logging时，任何操作都会记录日志。
不会有unrecoverable操作。
对于数据库备份后的恢复，需要注意查询v$datafile视图中关于unrecoverable操作时间，如果unrecoverable操作时间在数据文件备份之后（更精确的比较是通过change#，比较文件的checkpoint_change#和unrecoverable_change#），则恢复会产生坏块。
ORACLE坏块(ORA-01578)模拟与处理方法
ORACLE坏块(ORA-01578)模拟与处理方法一。
.什么是数据库的坏块首先我们来大概看一下数据库块的格式和结构——数据库的数据块有固定的格式和结构，分三层cache layer，transaction layer，data layer。
在我们对数据块进行读取写入操作的时候，数据库会对要读写的数据块做一致性的检查，其中包括数据块的类型、数据块的地址信息、数据块的SCN号以及数据块的头部和尾部。
如果发现其中有不一致的信息，那数据库就会标记这个数据块为坏块了。
数据库的坏块分为两种，逻辑坏块和物理坏块。
二．模拟坏块SQL> conn systemSQL> create tablespace corrupt datafile 'C:\corrupt.dbf' size 200k;SQL> create table corrupt_tab tablespace corrupt as select * from all_users;SQL> alter table corrupt_tab modify(user_id primary key);SQL> select extent_id,file_id,block_id,blocks from dba_extents2 where owner='SYSTEM' and segment_name='CORRUPT_TAB';EXTENT_ID FILE_ID BLOCK_ID BLOCKS---------- ---------- ---------- ----------0 8 17 8上述查询说明，这个表具有一个区间EXTNET_ID 0，位于8号文件，从块号17开始，大小为8个块。
SQL> conn / as sysdbaSQL> shutdown immediate;用UE编辑器模拟出物理或逻辑坏块。
使用
使用 exp来检查坏块，以及如何修复坏块如何使用exp来检查坏块，以及如何修复坏块CREATE TABLESPACE test DATAFILE '/u01/test_data.dbf' size 5M;在表空间创建一张表create table scott.test (id number,name varchar2(20)) TABLESPACE test ;插入大量数据declarebeginfor n_row in 1..100000 loopinsert into scott.test values(n_row,to_char(n_row));end loop;commit;end;使用UE编辑器修改二进制文件模拟损坏导出test表exp scott/oracle tables=test file=test.dmpEXP-00056: ORACLE error 1578 encounteredORA-01578: ORACLE data block corrupted (file # 6, block # 178)ORA-01110: data file 6: '/u01/test_data.dbf'Export terminated successfully with warnings.使用exp/imp恢复在这种情况下肯定会造成数据的丢失，在这种情况下应采取将数据导出然后重建表再进行导入的方法，来尽量恢复损坏数据块中的数据，但是在有坏块的情况下是不允许导出的，如下命令：Exp test/test file=t.dmp tables=t;导出命令在执行中会报ORA-01578错误，在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏，如：ORA—01578：ORACLE数据块损坏（文件号4，块号35）针对以上的提示首先查询那些对象被损坏：Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=6 and 178 between block_id and block_id+blocks-1;如果被损坏的块是索引，通常可以通过索引重建来解决，如果损坏的是数据（segment_type为table），那么通过设置如下内部事件使得Exp操作跳过坏块。
oracle rac的日常维护及注意事项
oracle rac的日常维护及注意事项2009-03-13 23:26oracle rac的日常维护及注意事项在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。
一、Oracle警告日志文件监控Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况：l 数据库的启动、关闭，启动时的非缺省参数；l 数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因；l 对数据库进行的某些操作，如创建或删除表空间、增加数据文件；问题处理启动参数不对检查初始化参数文件因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况，可以考虑增加重做日志文件组；想办法提高检查点或归档操作的效率；有人未经授权删除了表空间检查数据库的安全问题，是否密码太简单；如有必要，撤消某些用户的系统权限出现坏块检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建表空间不够增加数据文件到相应的表空间出现ORA-600根据日志文件的内容查看相应的TRC文件，如果是Oracle的bug，要及时打上相应的补丁二、数据库表空间使用情况监控（字典管理表空间）数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。
select tablespace_name, count(*) chunks , max(bytes/1024/1024) max_chunk from dba_free_space group by tablespace_name;上面的SQL列出了数据库中每个表空间的空闲块情况,如下所示：TABLESPACE_NAME CHUNKS MAX_CHUNK-------------------- ---------- ----------INDX 1 57.9921875RBS 3 490.992188RMAN_TS 1 16.515625SYSTEM 1 207.296875TEMP 20 70.8046875TOOLS 1 11.8359375USERS 67 71.3671875其中，CHUNKS列表示表空间中有多少可用的空闲块(每个空闲块是由一些连续的Oracle数据块组成)，如果这样的空闲块过多，比如平均到每个数据文件上超过了100个，那么该表空间的碎片状况就比较严重了，可以尝试用以下的SQL命令进行表空间相邻碎片的接合：alter tablespace 表空间名coalesce;然后再执行查看表空间碎片的SQL语句，看表空间的碎片有没有减少。
数据库坏块(ORA-01578)的解决方法
数据库坏块(ORA-01578)的解决方法
乐兵
【期刊名称】《铁路计算机应用》
【年(卷),期】2004(013)009
【摘要】针对当前Oracle数据库经常出现的数据库坏块错误(ORA-01578),分析问题的起因及影响,并根据实际经验提出两套具体的解决方法:错误陷阱设置法和ROWID检测法.给出具体命令以及提示信息,对于数据库管理员的日常检测和故障处理可以起一定的参考作用.
【总页数】3页(P49-51)
【作者】乐兵
【作者单位】郑州铁路分局,信息技术分处,郑州,450052
【正文语种】中文
【中图分类】TP338
【相关文献】
1.如何处理Oracle数据库中的坏块问题 [J], 陈宇
2.解决"军卫一号"系统数据库坏块的方法 [J], 何其才;曹婷
3.ORACLE8I数据库中数据坏块的解决方法 [J], 徐正雄;王玲;王洪强
4.基于Unix的Oracle数据库坏块分析与研究 [J], 张引琼
5.中型三甲医院Oracle数据库坏块恢复方法探讨 [J], 康季槐; 陈敏; 梁毅; 李文超因版权原因，仅展示原文概要，查看原文内容请购买。
Oracle坏块故障葵花宝典
Oracle坏块故障总结最近处理了两次典型的ora-01578,ora-01115,ora-01110故障，一次是平湖索引块坏，一次是黄山数据文件坏、blob数据块坏。
平湖的警告日志文件中有以下信息：ORA-12012: error on auto execute of job 21ORA-01578: ORACLE data block corrupted (file # 10, block # 2558610) ORA-01110: data file 10: 'D:\ORACLE\ORADATA\BS\USERS04.DBF'ORA-12012: error on auto execute of job 1ORA-01578: ORACLE data block corrupted (file # 16, block # 2624066) ORA-01110: data file 16: 'D:\ORACLE\ORADATA\BS\USERS10.DBF'应用软件可以正常使用，偶尔会报错ora-01578。
排错过程登录数据库检查：select count(*) from ep_table t where ptime<trunc(sysdate)-30 andalarmtype=0784163select count(*) from ep_table t4281062看来全表扫描正常select from ep_table t where ptime<trunc(sysdate)-31 and ptime>trunc(sysdate)-33 and alarmtype=0 and rownum<10001索引扫描报错了，推断为索引上有坏块！继续查：select owner,file_id,segment_name, segment_type, block_id, blocks from dba_extentswhere file_id=16 and block_id<=2624066 and (block_id + blocks- 1) >= 2624066;运气真好重建相关索引后数据库就恢复了。
RAC异常分析报告
数据库检查分析报告问题分析Errors in file /oracle/app/oracle/admin/p5dbc/bdump/p5dbc1_lms3_716894.trc:ORA-07445: exception encountered: core dump [] [] [] [] [] []Wed Apr 13 10:35:22 2016Errors in file /oracle/app/oracle/admin/p5dbc/udump/p5dbc1_ora_1061118.trc:ORA-07445: exception encountered: core dump [] [] [] [] [] []Wed Apr 13 10:35:22 2016Errors in file /oracle/app/oracle/admin/p5dbc/udump/p5dbc1_ora_12787768.trc:ORA-00600: internal error code, arguments: [kclfadd_1], [], [], [], [], [], [], []......ORA-00484: LMS* process terminated with error......Instance terminated by PMON, pid = 684112...在4.13日10:35分数据库发生ORA-07445及ORA-00600错误,随后数据库陆续触发大量ORA-00600，ORA-07445，ORA-00484，最终数据库crash。
分析：对ORA-00600，ORA-00484，ORA-07445相应的trc文件进行排查，未发现与之特征匹配的可导致数据库crash的bug；对于ORA-00600 [kclfadd_1]错误，发现其特征与已知bug5071492相似并可导致rac实例crash，但随后检查数据库patch发现已经安装了该bug对应的补丁。
综合网管日常检查说明文档(联通现场)
综合网管及EOMS作业计划操作手册2010-021.网管服务器相关检查（UNIX主机）1.1.可用状态通过TELNET是否能登录主机。
如不能登录或登录异常，请判断是否网络问题或主机异常导致无法登录。
网络问题判断方法：ping主机IP是否能通？ping网关是否能通？网络问题请通知网络管理员处理。
主机异常导致无法登录请联系项目经理处理。
1.2.CPU使用率检查运行TOP指令，查看IDLE列的avg值，观察3-5分钟，avg的值不能长期为0。
如果IDLE的值长期（超过30分钟）为0，请联系项目经理处理。
1.3.内存使用率检查运行TOP指令，查看Memory的free值，观察3-5分钟，free的值不能低于100M。
如果free的值长期（超过20分钟）低于100M，请联系项目经理处理。
1.4.磁盘空间检查运行bdf指令，查看每个目录的空间大小，每个目录的used值不能大于85%，如果超过该值，请联系项目经理处理。
1.5.系统重要日志检查1.5.1.dmesg运行dmesg命令检查主机错误缓冲区（需要root用户）。
正常情况下，该缓冲区只应该包含自检信息，如果出现了warning、error或者是一些不熟悉的信息，应该仔细检查或通知HP服务人员。
1.5.2.Syslog日志“/var/adm/syslog/syslog.log”，该日志文件中包含一些重要的维护信息（需要root用户）。
系统管理员应该定期用more或者vi命令，检查该文件。
系统管理员如果发现warning、error、failure以及一些不熟悉的信息，应该提高警惕。
1.5.3.Mail系统在发现问题时，往往会把一些信息发给root用户。
系统管理员应该定期检查root的mail信息，检查最近一周内的 mail，mail 中是否有warning、error、fail、panic 等异常提示，以确认系统中不存在异常。
1.5.4.Shutdownlog日志“/etc/shutdownlog”，该日志文件中记录机器的重起记录，察看最后一次机器重起时间，判断机器在最近时间是否有异常重起。
oracl 遇到的问题及解决方法
ORA-0131:Insufficient privileges.Note:Debugging requires the DEBUG CONNECT SESSION systemprivileges.后经查找，是缺失 DEBUG CONNECT SESSION 系统权限所致。
解决办法：以SYS用户登录数据库，执行赋权操作：1 SQL> grant DEBUG CONNECT SESSION to user_name;本文总结了一些Oracle数据库操作中常见错误及其解决方案，供参考。
包括ORA-01650、ORA-01652、ORA-01578、ORA-01628、ORA-00600、ORA-03113、ORA-00942、ORA-1636、ORA-01688以下将详细列出这些ora错误引起的原因及应对办法：第一个：ORA-01650:unable to extend rollback segment NAME by NUM intablespace NAME 产生原因：上述ORACLE错误为回滚段表空间不足引起的，这也是ORACLE数据管理员最常见的ORACLE错误信息。
当用户在做一个非常庞大的数据操作导致现有回滚段的不足，使可分配用的回滚段表空间已满，无法再进行分配，就会出现上述的错误。
解决方式：使用"ALTER TABLESPACE tablespace_name ADD DATAFILE filename SIZE size_of_file"命令向指定的数据增加表空间，根据具体的情况可以增加一个或多个表空间。
当然这与还与你主机上的裸盘设备有关，如果你主机的裸盘设备已经没有多余的使用空间，建议你不要轻意的增加回滚段表空间的大小，可使用下列的语句先查询一下剩余的tablespace空间有多少：Select user_name,sql_text from V$open_cursor where user_name='<user_name>';如果多余的空间比较多，就可以适当追加一个大的回滚段给表空间使用，从而避免上述的错误。
Oracle错误代码详解及解决方式
Oracle错误代码详解及解决方式ORA-00001: 违反唯一约束条件 (.)错误说明：当在唯一索引所对应的列上键入重复值时，会触发此异常。
ORA-00017: 请求会话以设置跟踪事件ORA-00018: 超出最大会话数ORA-00019: 超出最大会话许可数ORA-00020: 超出最大进程数 ()ORA-00021: 会话附属于其它某些进程；无法转换会话ORA-00022: 无效的会话 ID；访问被拒绝ORA-00023: 会话引用进程私用内存；无法分离会话ORA-00024: 单一进程模式下不允许从多个进程注册ORA-00025: 无法分配ORA-00026: 丢失或无效的会话 IDORA-00027: 无法删去当前会话ORA-00028: 您的会话己被删去ORA-00029: 会话不是用户会话ORA-00030: 用户会话 ID 不存在。
ORA-00031: 标记要删去的会话ORA-00032: 无效的会话移植口令ORA-00033: 当前的会话具有空的移植口令ORA-00034: 无法在当前 PL/SQL 会话中ORA-00035: LICENSE_MAX_USERS 不能小于当前用户数ORA-00036: 超过递归 SQL () 级的最大值ORA-00037: 无法转换到属于不同服务器组的会话ORA-00038: 无法创建会话: 服务器组属于其它用户ORA-00050: 获取入队时操作系统出错ORA-00051: 等待资源超时说明：如果Oracle在等待资源时出现超时错误，会触发此异常。
ORA-00052: 超出最大入队资源数 ()ORA-00053: 超出最大入队数ORA-00054: 资源正忙，要求指定 NOWAIT英文解析：resource busy and acquire with NOWAIT specified 错误解析：表被锁住了，要不等待表解锁，要不就去kill了它。
oracle数据库掉电损坏的一些处理经验
当oracle数据库非正常关闭时，可能面临无法启动或无法登陆的问题，其中部分原因是数据库文件损坏所致，如果数据库没有使用备份机制或运行于非归档模式下时，系统数据文件的损坏往往难以完全恢复，本文就经常遇到数据库数据文件损坏，总结了此类问题处理的常用方法。
一、检查数据文件、控制文件、日志文件是否有损坏。
1.查看文件$ORACLE_BASE/admin/dbname/bdump/alert_orasid.log中是否有文件损坏信息，类似如下信息：ORA-01578: ORACLE data block corrupted (file # 7, block # <BLOCK>;)ORA-01110: data file <AFN>;: '/oracle1/oradata/V920/oradata/V816/users01.dbf'通过file#和<AFN>找到损坏数据文件和文件类型，然后通过损坏的文件类型确认采用的恢复策略。
2.可以使用dbv检查数据文件（不适用于日志文件），应注意使用dbv检查数据文件时应对损坏数据库文件进行备份，dbv会修改数据文件中部分内容。
被检查的数据文件应为脱机状态。
dbv命令含义：关键字描述(Default)----------------------------------------------------FILE 待检测文件名(NONE)START 起始文件块(First Block of File)END 终止文件块(Last Block of File)BLOCKSIZE 逻辑块大小(8192)LOGFILE 输出日志文件(NONE)FEEDBACK 显示进度(0)PARFILE 参数文件(NONE)USERID 用户名/密码(NONE)SEGMENT_ID Segment ID (tsn.relfile.block) (NONE)HIGH_SCN Highest Block SCN To Verify (NONE)(scn_wrap.scn_base OR scn)常用到的参数有：FILE、BLOCKSIZE。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ORA-01578: Oracle data block corrupted (file # f_num, block # b_num)
产生原因：当ORACLE访问一个数据块时，由于1、硬件的I/O错误；2、操作系统的
I/O错误或缓冲问题；3、内存或paging问题；4、ORACLE试图访问一个未被格式化的系统块失败；5、数据文件部分溢出等上述几种情况的一种引起了逻辑坏块或者物理坏块，这时就会报ORA-01578的错误。
解决方式：由于ORACLE只有在访问到有问题的数据文件时才会报错，所以报错的时间有可能会比实际出错的时间要晚，如果ORA-01578出错信息提示数据坏块指向的是用户自己的数据文件，则用以下方法来解决：
如果通过下面的SQL语句查出的坏块出现有索引上，则只需重建索引即可
SQL>Select owner, segment_name, segment_type from dba_extents where file_id=5 and block_id between 60474 -1 and 60474
如果坏块出现在表上，先用以下语句分析是否为永久性坏块（建议多执行一两次，有助于鉴别数据坏块是永久性的（硬盘上的物理坏块）还是随机性的（内存或硬件错误引起））：SQL>Analyze table validate structure cascade;
执行该命令后，可能会出现以下的结果：
ORA-01578：与原先错误信息有相同的参数，为永久性的物理或逻辑坏块；
如果与原先错误信息有不同的参数，可能与内存，page space和I/O设备有关。
如果用户有此表的最新备份，那么最好是用此备份来恢复此表，或者使用event 10231来取出坏块以外的数据：
<1>.先关闭数据库
<2>.编辑init.ora文件，加入：
event=”10231 trace name context forever,level 10”
<3>.startup restrict
<4>.创建一个临时表：SQL>create table errortemp as select * from error ;(error是坏表的表名)
<5>.把event从init.ora文件中删掉并重起数据库
<6>.rename坏表，把临时表rename成坏表的表名
<7>.创建表上的INDEX等
如果ORA-01578出错信息提示数据坏块指向的是数据字典或者是回滚段的话，你应该立即与ORACLE公司联系，共同商量一个好的解决办法。
这里所讲的解决方法只是比较常见的一种，一些更为具体的解决办法可以查看一下ORACLE的故障解决手册，那里面有浞及
使用ROWID方法来取出坏块以外的数据的方法，这里就不介绍了。
相应的英文如下：
Cause:The given data block was corrupted,probably due to program errors
Action:Try to restore the segment containing the given data block,This may involve dropping the segment
and recreating it,If there is a trace file,report the messages recorded in it to customer support.。