这个案例告诉我们,将Oracle数据库直接开放在公网上是极其危险的,尤其是陈旧的数据库版本中可能存在很多已知的安全漏洞,可能被轻易的攻击渗透。常规的做法是将数据库隐藏在应用服务器的后端,同时要确保及时修正Oracle严重警告的安全漏洞,另外及时的备份是确保数据留存的最后手段。
最近在客户的一个案例中,遇到Latch : Library Cache的竞争,其竞争位于kglic函数调用。
在某些异常情况下,查询数据库的dba_extents字典表时,可能遇到ORA-600 kcfrbd_3错误,这个错误是由于文件大小和控制文件不符合导致的,触发原因可能是数据库写异常,通常可以通过重建控制文件来消除错误。 但是,如果是数据文件头部的信息记录错误,和数据文件本身不符合,则需要修改数据文件头部的文件大小信息,才能够解决该问题。
昨天朋友遇到一则数据库故障案例: 11.2.0.3 数据库因asm磁盘头块损坏宕机,出现错误ORA-15196。 更详细的错误如下:ORA-15196: invalid ASM block header [kfc.c:26076] [endian_kfbh] [256] [0 != 1] 进一步的检查发现DataGuard同样损坏.这让大家陷入不解,为何主库和备库会同时损坏?
在Oracle 10.2.0.5之前,ASM磁盘的头块并没有自己的备份,因此一旦头块损坏,如果没有以前kfed read备份出来的信息,恢复ASM磁盘头块的操作就会非常麻烦。但是从Oracle 10.2.0.5之后,ASM磁盘的头块会自动备份在另外一个块中,这实际上是Oracle 11g出现的功能,在Oracle 10.2.0.5版本中,这个备份也是存在的。
在使用dbv进行坏块检测时,会抛出文件号、块号等信息,这个信息来自于文件头的信息记录。
在很多朋友的数据库中,聚簇对象 C_OBJ#_INTCOL# 占用了大量空间,有时候希望通过TRUNCATE清理这个对象,注意,当然最好不要这么做,风险太高。
当数据库系统的时间被调整,回到历史状态时,数据库可能出现ORA-600 2252错误。 这个错误指,数据库的SCN被认为是错误和不合理的,Oracle内部控制每秒产生的SCN数量小于 16K 个,然后以1988年1月1日,0点0分0秒开始,可以计算出一个SCN可能的合理最大值。
最近客户在恢复数据库时遇到了ORA-600 kclchkblk_4错误,这个错误在MOS上有官方的解释和解决方案。
在2012年第一季度的CPU补丁中,包含了一个关于SCN修正的重要变更,这个补丁提示,在异常情况下,Oracle的SCN可能出现异常增长,使得数据库的一切事务停止,由于SCN不能后退,所以数据库必须重建,才能够重用。
这则案例警示我们:尽量少用OEM等图形工具进行数据库重要的管理和维护操作,如果你不清楚前台的一个操作在后台会如何执行,那么一定要谨慎使用这样的工具。 对于这样的案例,如果用户能够及时的保护现场,通过存储级别的恢复是可以找回数据文件的。
这个错误号,在MOS上没有解释,在Google上也找不到,但是从错误号上,我们可以大致猜出这个错误的原因: KTSP - Kernel Transaction SPace Transaction ReadExtents - Read segments Extents info Range - Extents Range
最近在客户的数据库恢复中再次遇到了ORA-00600 kccpb_sanity_check_2错误,这个错误是因为控制文件不一致导致的。 出现这个错误时,数据库将无法Mount挂载,影响数据库服务。 这个错误,多数是因为存储故障,丢失了数据写。
在2012第一季度,Oracle发布的CPU补丁中,包含了两个BUG修正,其中一个与SCN有关。 这个BUG的BUG号是:13489660 - DB-10.2.0.5-MOLECULE-020-CPUJAN2012 该BUG修正了SCN的问题,我们先从文件影响上来看看,大量内核相关的文件被更新
错误现实,在执行SYS.DBMS_HA_ALERTS_PRVT包的内部任务时出现问题。 而ORA-00600 6002 错误和索引相关,具体内容是指: 当Oracle试图去插入一个索引键值时,首先需要找到合适的位置,并且去进行相关校验,校验内容包括索引列数量、数据大小等,一旦发现不一致,则将出现ORA-600 的6002错误。
在之前遇到的ORA-00600 Kcbz_check_objd_typ_3错误时,发现了一个相关的隐含参数:_db_block_check_objtyp 该参数定义是否执行对象号和对象类型检测:
首先 kcbz_check_objd_typ_3 这个错误的含义是: 当Oracle在检查内存中的数据块时,发现数据块上的对象号是错误的,随之抛出kcbz_check_objd_typ_3 这个异常。 通常这个错误意味着存在着数据损坏。
最近,在帮助用户进行数据恢复之后遇到了一个ORA-00600 6749问题,这个错误实际上有多种可能,在这个客户系统中,也并不是因为恢复问题导致的,只是这个问题以前并没有被注意到。 多年以前,在ITPUB上就曾经探讨过这个问题, Oracle有一个BUG,在某行记录上,会将ROWID指向自身,这样当读取到这条记录时就可能产生死循环,无法跳出这条记录。