在最近(2010年9月6日)的一次培训中,有位朋友问起上节案例,该如何证明和验证Oracle介于Cache-Low RBA和On-Disk RBA之间的恢复过程?我们可以通过如下的过程来做一些观察和证明。 首先执行一个建表的CTAS操作,这个操作是为了多生成一些脏块(Dirty Buffer),然后紧接着执行两次控制文件转储,两次转储是为了确认对比一下控制文件的检查点没有变化,然后紧接着执行强制关闭数据库(Abort方式),再启动数据库
在EXPDP执行数据导出时,其中一个过程要调用SYS_XMLGEN执行XML文件生成,这个过程可能会产生性能问题,所以需要关注相应时段的AWR报告相关信息。 在一个客户的性能诊断中,发现类似如下的SQL,手工在SQL*Plus中执行该类SQL可以评估其性能,如果其性能存在较大问题,则需要介入研究起原因。
客户的数据库使用了cursor_sharing=similar参数,经过测试,发现这一参数极大影响了expdp的性能。 其本质原因是SQL的执行计划发生了改变。 在正常情况下28分钟完成的EXPDP操作,在similar模式下用了整整1个小时
在使用Expdp进行导出时,Expdp需要计算导出数据大小容量,Oracle可以通过两种方式进行容量估算,一种是通过数据块数量、一种是通过统计信息中记录的内容估算。两者在不同版本中,可能有巨大的性能差异,尤其是在Oracle 10g的早期版本中,一些Bug严重影响了性能。
对于数据库不太大的用户,我强烈建议用户在主机上多配备几块硬盘,将备份存放到本地,一是获得性能,二可以加快恢复,保证恢复时间。 最后客户在一块移动硬盘上找到了一份临时分离出去的备份文件,最终靠这个偶然留存的备份挽救了数据库。 数据备份,再多一份也不为过!
最近帮助用户恢复了一个由于存储故障导致的数据库灾难,整个数据库容量4TB,浪潮的存储设备,控制器损坏导致数据库故障。
最近在帮助用户恢复数据库时遇到了一则罕见的归档日志损坏案例
上周在上海出差时,有用户找到我们,请求帮住恢复一个因为硬盘损坏导致的数据库故障,数据库是Oracle 10g的RAC集群,存储使用的是ASM管理。 主要问题是SYSTEM表空间存在大量的坏块,DBV检查,很多关键数据块出现问题,收录一下DBV的检测输出,看一看RAID硬盘损坏类故障会导致多少故障吧
一个数据库,不知怎样就陷入了ORA-600 2831 和kcfofl_01错误中,表空间无法删除,频繁出现如下错误
很多时候,在强制打开数据库之后,比如使用了_allow_resetlogs_corruption等隐含参数,可能会导致数据库丧失一致性,损坏部分数据,如果损失的是部分DML数据,则数据库可能仍然可以运行良好,但是如果损失的是元数据,则可能数据库会出现一些其他的异常,当时这些异常也仍然是可以修复的,只是成本或代价会比较高昂。 最近的一则案例中,恢复数据之后,用户动态创建的某些临时表出现问题,无法成功导出,这就是强制Resetlogs的后果之一。
我以前写过一个文章,如何获得DBID,这个问题今天仍然有人问题,其实不管控制文件的名称里是否包含了DBID,但是,只要有了控制文件,就可以从其中获得 DBID,可以直接用二进制工具打开,读取固定的位,也可以恢复出了控制文件,通过其Mount数据库,再来查询V$视图。
客户原系统使用的是ASM存储管理,两块硬盘组成的大约2T的存储设备,这样在恢复时,我们必须通过两块硬盘来进行数据重组,ASM缺省的AU大小是 1M,在两块磁盘之间进行均衡(Balance),存储均衡是Oracle的一项性能提升技术,然而在故障时,你会发现这一技术让人倍感折磨,通常使用文件系统,一个文件会在单个系统上存储,而ASM是分散的,这就导致哪怕是最早创建的SYSTEM表空间,也必然在两个磁盘之间跨越交替存储。
学会如何规避风险往往比解决问题更重要,因为数据库的风险太多且无处不在。
近日,有朋友遇到了ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr]错误,具体的错误信息类似:Incident 63078 created, dump file: /u01/diag/rdbms/orcl/orcl/incident/incdir_63078/orcl_ora_1916_i63078.trcORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [3313], [2328320], [2334233], [], [], [], [],...
客户的一个数据库因为断电遇到了ORA-600 kcratr1_lostwrt错误,数据库无法启动。 错误信息类似: ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], [] Current SQL statement for this session: alter database open 这个错误不难解决,但是其具体成因有点意思
近期,在为一个客户的数据库制定紧急预案,这个数据库数据量大约在1.4T左右。由于客户没有额外的存储资源用于备份,所以数据库目前存在了很大的安全风险。 虽然存储级别有一定的安全防范,但是如果遇到数据损失、坏块、文件损坏等问题,将无法应对。
kcbgtcr 是Oracle数据库最重要的函数之一,其含义为:Kernal Cache Buffer GeT Cosistents Read,也就是数据库的一致性读操作,后面的代码有很多种,代表在不同的层面上出现问题。 Metalink 的Note 415773.1 - Diagnostics and Solutions for kcbgtcr() Related Internal Errors记录了与此相关的很多问题。
出现这个错误后,恢复中断,无法继续,3020错误在Metalink上的解释,主要原因是在恢复时发现Redo里面记录的信息和被恢复的数据块信息不一致,导致恢复无法继续。比如Update Some record from 3 to 2,结果发现该记录根本不是3,恢复无法继续。