来看看美国最大电信公司AT&T的Oracle数据库备份策略

2015/09/15 by Leave a Comment
​ 
AT&T公司是美国最大的固网电话服务供应商及第一大的行动电话服务供应商，此外还提供宽频及收费电视服务。合共1.5亿户提供服务，当中8,510万户为无线用户 。
AT&T是Oracle数据库的重度用户，从oracle的官方网站上可以了解到  AT&T 采用的产品不仅仅是Oracle Database ，还有Oracle EBS 、Peoplesoft和Siebel等等。
http://www.oracle.com/us/products/applications/att-170685.html
 ​
作为Oracle数据库的重度用户，且数据是十分重要的巨无霸级电信运营商而言数据库备份策略十分重要。
 ​
由于AT&T的维护人员运维着成百上千套Oracle数据库，    他们把数据库按照不同的可用性要求划分为三个可用性/恢复级别，分别为低、中、高。低是应用程序可以承受的在任何类型的介质失败后需要最长的平均恢复时间，高是应用程序有很少的停机时间或不允许停机。
下列是对上述三个级别的数据库备份的保存策略。推荐的保存周期取决于硬件的限制和用户描述的平均恢复时间。说明一些磁盘备份和恢复文件可能存储在FRA外面。FRA以外的磁盘存储空间应该通过OS 和RMAN命令手动管理
 ​

以下是AT&T的最优备份方法和策略

 

  • 使用闪回区作为归档日志的存放位置

 

使用闪回区作为归档位置，因为归档日志被数据库自动管理，因此归档空间不足的风险大大降低，要发挥闪回区（FRA）的最大优势，尽可能的依赖磁盘的可用性存储和管理许多不同的文件。

 

  • 多重归档日志记录

 

通过实现硬盘镜像（有归档日志区域的镜像）保存归档日志的多个副本，或者通过设置LOG_ARCHIVE_DEST_n初始化参数为一个FRA 以外的位置。

 

  • 在磁盘上保存归档的redo日志

一般来说，归档日志文件保存在磁盘至少48小时或者你可以取决于存储的可用性。这将保证在介质失败后更快恢复，因为日志不能存储在慢的磁带机上，在闪回区达到83%或93%时，信息将放到告警日志。不再被恢复所需要（或者备份到磁带机上）的日志将被自动删除。记住在闪回数据库操作时归档日志如果不在磁盘上，他们必须从磁带上转储来“倒回”数据库 。

  • 备份控制文件

在每一次关键备份时，获得数据库控制文件的二进制和文本类型的副本。这对数据库结构改变后尤其重要。

 

为了RMAN 在每次备份和数据库结构改变后可以自动备份控制文件和服务器参数文件，需要开启自动备份 AUTOBACKUP ON (默认为OFF)。自动备份特点使得RMAN 转储自动备份的控制文件，在你不能访问数据库，甚至控制文件丢失/破坏后恢复数据库。

  • 备份参数文件和密码文件

RMAN 工具不支持ORACLE_HOME, init.ora 和密码文件备份。然而，所有的这些文件必须使用系统命令备份或者第三方备份工具。如果你的实例使用spfile代替init.ora 文件，你可以用RMAN 自动备份spfile 或者使用BACKUP SPFLE 命令。

 

  • 增量备份的改变跟踪文件

这个特点是允许RMAN 只备份上次全备份以来改变的数据块，减少了执行备份所需的时间，只备份很少的数据块，

size of change tracking file = # of redo threads * (# of old backups + 2) * (size of db/250000)

 

  • 备份归档日志时不要指定DELETE ALL INPUT

DELETE ALL INPUT 会在目标备份然后删除归档日志和其副本，“delete  input”会在目标备份后删除已经备份的归档。下一次将从位置1备份来作为位置2的新日志备份，然后删除备份过的日志。这意味着你可以有自从上次磁盘上位置2 的可用备份（只要备份过一次）和上次备份之前的两个备份副本。查看说明443814.1-用RMAN管理多个归档日志目录的详细内容。

 

  • RAC 环境下备份所有的CRS资源

 

RAC 数据库需要OCR 的备份和Voting 磁盘文件。RMAN 不支持这个，因此使用系统命令定期执行备份。

阅读 Metalink 说明: 279793.1 How to Restore a Lost Voting Disk in 10g and Note: 268937.1 Repairing or Restoring an Inconsistent OCR in RAC regarding backup and restore a lost Voting/OCR.

 

  • 考虑使用增量更新备份

增量更新备份使用合并数据库镜像复制和增量备份，来提供快速且有效的数据库恢复。使用RMAN具有数据高可用性需求的特点，保证少的平均恢复时间并且能消除全库备份的需要。

 

  • 设置RMAN 恢复目录

使用恢复目录数据库作为备份和转储操作的仓库。恢复目录提供了与RMAN数据保存在每个目标数据库的控制文件中的以下几种另外的功能：

  • 在恢复目录里存储RMAN脚本
  • 一个节点的备份能转储到另一个节点
  • 没有控制文件的空间限制并且能储存更多关于备份的历史数据
  • 在恢复和维护操作期间提高性能
  • 备份物理备库需要恢复目录

 

备份过程

计划实现三个独立标准备份程序，这将适用于上述相应的可用性和恢复要求。

 

低MTTR的数据库备份过程

 

对于有高可用需求和低容忍恢复时停机的的数据库，保证在磁盘上的0级增量备份并且每天用1级增量备份增量更新这个副本，然后把所有其他的文件转移到DSU/磁带 。

FRA DISK QUOTA =  Size of 1 full copy of database
+ size of 1 day’s level 1 incremental backup
+ size of (Y+1) days of archived logs
+ size of flshback logs

Y是脚本里 BACKUP RECOVERY AREA执行的时间。

FRA 设置以下步骤用来执行备份

  • 备份控制文件
    • 文本复制用RMAN 命令 BACKUP CURRENT CONTROLFILE;
    • SQL： ‘alter database backup control file to trace’;
    • SET CONTROL FILE AUTOBACKUP ON.
  • 每天执行1级增量备份和用前一天的1级备份前滚0级备份
  • 把所有的闪回区文件备份到DSU/磁带上，这将备份所有不存在于磁带上的备份集，以及自上次备份以来所有已归档的重做日志。。
  • 删除DSU/磁带上过期的备份。
  • 如果是RAC 环境，通过OS 命令从CRS复制OCR和卷文件

 

中等MTTR的数据库备份过程

每周执行一次完全压缩的0级增量备份到FRA以外的磁盘，并且每天执行1级压缩增量备份到FRA。每天把闪回区备份到DSU/磁带，因此保证备份集和归档日志可以被删除，以满足更新需求的空间。

FRA DISK QUOTA =   size of X day’s level 1 incremental backup
+ size of (Y+1) days of archived redologs
+ size of  flashback logs x 2

X是你想要 保存在FRA中的增量备份的数量，Y是在备份脚本中执性BACKUP RECOVERY AREA所用的天数。

如果FRA和外部的磁盘存储区被配置, 用下列步骤完成备份

  • 一周一次
    • 备份控制文件
    • 备份上周的0级压缩备份到磁带并且用OS命令从磁盘中删除
    • 执行检查并从磁盘删除过期的0级备份
    • 每周执行0级增量备份到FRA以外的磁盘
    • 从磁带删除过期的备份
    • 备份闪回区
  • 每天执行1级增量备份到FRA
    • 备份所有的闪回区文件到DSU/磁带。这将备份所有磁带上没有的备份集以及上一次任何类型的备份以来所有的归档日志
    • 执行1级增量备份到FRA
  • 如果是RAC环境，通过OS命令从CRS 复制OCR和卷文件

 

高MTTR的数据库存储过程

 

对于能承受足够的时间来恢复和磁盘存储限制，使用FRA仅仅作为归档的目的地。磁盘配额规则将自动从FRA删除不再被恢复所需要的日志。

FRA DISK QUOTA =   size of 1 day’s level 1 incremental backup
+ size of (1 days of archived logs) * 2
+ size of  flashback logs x 2

按下列步骤设置FRA，用来执行备份

  • 归档日志文件在FRA里
  • 每周执行0级全增量备份到磁带作为压缩备份集。
    • 备份控制文件
    • 执行0级备份到磁带
    • 删除磁带上的过期备份
    • 备份恢复文件目的地到磁带
  • 一周内的其他天
    • 备份恢复文件目录到磁带
    • 执行1级增量备份到FRA
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

【转】Exadata存储服务器的紧急修复(rescue)经验分享

2015/08/23 by Leave a Comment

转自 https://blogs.oracle.com/ExadataCN/entry/exadata%E5%AD%98%E5%82%A8%E8%8A%82%E7%82%B9%E7%9A%84rescue

 
这篇文章主要从何时需要紧急修复、准备过程、实施阶段等几个方面来与大家分享Exadata 存储服务器Rescue方面的维护经验，有的地方提供了My Oracle Support网站的文章号。

了解storage server 和rescue方法

 


什么是Rescue呢？Rescue这个英文对应的中文含义是紧急修复，只在非常必要的情况下才需要进行，否则会造成无谓停机和软件版本的不一致。
首先，我们需要了解Exadata存储服务器(storage server)方面的知识，它主要提供智能的磁盘I/O给计算节点。关于磁盘的管理，可以通过阅读My Oracle Support文章Auto disk management feature in Exadata (Doc ID 1484274.1)来熟悉storage server上的自动磁盘管理特性。

以下关于何时需要紧急修复，准备阶段和实施阶段等方面进行分享。

 

何时需要Storage server（存储服务器）的rescue过程

 

当系统盘失效，操作系统有一个文件系统损坏了或者boot区域被破坏了的时候。一台节点机上的两个系统磁盘都同时失效了的话，就必须通过CELLBOOT USB flash盘上的Oracle Exadata Storage Server软件进行rescue了。

请仔细阅读产品文档中的 Maintaining Exadata Storage Servers of Oracle Exadata Racks章节：
Using the Oracle Exadata Storage Server Software Rescue Procedure

准备阶段

 

平时要查看CELLBOOT USB盘是否可用，如果丢失或者损坏了，通过如下过程来创建：
重新生成一个损毁的CELLBOOT USB闪存盘

如果CELLBOOT USB闪存盘丢失或者损毁，您可以使用如下过程来创建一个新的。
注意: 针对运行Oracle Exadata Storage Server Software release 12.1.2.1.0或更高版本的机器创建一个USB闪存盘，要求机器操作系统版本是Oracle Linux 6
To create a USB flash drive for a machine running Oracle Exadata Storage Server Software release 12.1.2.1.0 or later requires a machine running Oracle Linux 6.

以root用户身份登录到cell
接插上新的USB盘，它上面的容量得至少1GB，最大可以到8GB。
从系统上移除任何其它的USB闪存盘执行如下命令：

cd /opt/oracle.SupportTools
./make_cellboot_usb -verbose -force

一般来说，Cell上有大量的业务数据，需要注意保证相应磁盘组里有足够多的空闲空间，这样，ASM根据情况重新分布(该需要rescue的cell上面的)数据到磁盘组的剩余磁盘时，就不至于因为空余空间不足从而无法完成。

如果storage server上打过one-off patch，请记住打过的patch号，以便rescue之后可能需要重新打。

实施阶段

 


真正进行紧急修复时要注意什么呢？
用CELLBOOT USB进行rescue时，从GRUB里选择CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode引导条目。但如果CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode 这个选项条目显示不出来，请参照文章Unable to rescue the Exadata storage using CELLBOOT USB (Doc ID 1413637.1) 的步骤向下继续进行。
如果rescue过程完不成，这多半表明可能有硬件问题。这时如果您连接到iLOM 上执行：
show faulty
它会说明出了什么情况。如果机器确实有硬件问题，则必须先修正这个硬件故障，之后再进行后续工作。

如果启动Storage Cell后，根文件系统 “/” 被mount成 read only了，则恢复的过程需要用到USB相关的rescue模式，需要详细步骤请创建一个技术支持服务请求(SR)，由Oracle技术支持工程师协助解决。

Rescue完成后的注意事项

 

如果机器是X3-2 Eighth Rack，则需要参考文章Exadata Database Machine Eighth Rack reconfiguration required after restore/rescue (Doc ID 1538561.1)里所说的补充步骤来恢复为正确的配置。

如果Flash cache的mode (Writethrough及Write-Back)被从默认值修改过，在rescue之后，要手动单独重启一次cell server (restart cellsrv)。

检查IORMPLAN, THRESHOLDs, Cell notification settings这些配置是否与原来的一致，不一致的话进行调整。
如果系统改变过host_access_control，需要检查是否一致。但一般来说这一项大多数用户都不涉及。

其它参考

 

有可能的话请尝试熟悉文章：    Exadata Platinum Customer Outage Classifications and Restoration Action Plans (Doc ID 1483344.1) 所提及的与系统停止运行有关的维护要点。

 

参考链接

 

OTN:Oracle Exadata
Oracle Exadata Machine 官方主页
Exadata 官方文档

 

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

跨国企业级Oracle数据库备份策略

2015/08/23 by 1 Comment

跨国企业级Oracle数据库备份策略

 

下载地址：https://zcdn.askmac.cn/【诗檀软件-郭兆伟-技术报告】跨国企业级Oracle数据库备份策略.pdf

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle RMAN 10g中如何提高copy datafile的并发

2015/03/21 by Leave a Comment
Oracle RMAN 10g中如何提高copy datafile的并发
try something like this:
format后面修改为你复制的目标文件名
 run
 { allocate channel mac01  DEVICE TYPE DISK MAXOPENFILES=1 PARMS=’BLKSIZE=1048576′ ;
   allocate channel mac02  DEVICE TYPE DISK MAXOPENFILES=1 PARMS=’BLKSIZE=1048576′ ;
   allocate channel mac03  DEVICE TYPE DISK MAXOPENFILES=1 PARMS=’BLKSIZE=1048576′ ;
   allocate channel mac04  DEVICE TYPE DISK MAXOPENFILES=1 PARMS=’BLKSIZE=1048576′ ;
   backup as copy (datafile ‘+DATADG/MAC/DATAFILE/system.258.819691771′    format ‘/s01/backup/system.dbf’ channel mac01) 
   (datafile ‘+DATADG/MAC/DATAFILE/sysaux.257.819691725′    format ‘/s01/backup/sysaux.dbf’    channel mac02)
   (datafile ‘+DATADG/MAC/DATAFILE/undotbs1.260.819691817′  format ‘/s01/backup/undotbs1.dbf’  channel mac03);
 }
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

oracle中闪回数据库到还原点的操作

2015/03/19 by Leave a Comment

oracle中闪回数据库到还原点的操作

CREATE RESTORE POINT before_clean GUARANTEE FLASHBACK DATABASE;
 
==>必须保证闪回回复区flashback recovery area有足够的磁盘空间
 
在standby 上，  注意 操作之前要记得 关闭redo传输
 
alter database recover managed standby database finish force;
 
alter database open;
 
操作
 
shutdown immediate;
startup mount;
 
flashback database to RESTORE POINT before_clean;
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

oracle中以测试为目的人为制造物理坏块的方法

2015/03/19 by Leave a Comment

oracle中以测试为目的人为制造物理坏块的方法

SQL> create table maclean_corrupt tablespace users as select * from dba_tables;
 
表已创建。
 
SQL> select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid) from maclean_corrupt where rownum<10;
 
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID)
———————————— ————————————
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
                              382307                                    6
 
已选择 9 行。
 
 
 
SQL> alter system checkpoint;
 
系统已更改。
 
 
C:\Users\xiangbli>rman target /
 
恢复管理器: Release 12.1.0.1.0 – Production on 星期日 9月 22 09:23:50 2013
 
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
 
已连接到目标数据库: MACLEAN (DBID=1694338843)
 
RMAN> recover datafile 6 block 382307 clear;
 
启动 recover 于 22-9月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=254 设备类型=DISK
完成 recover 于 22-9月 -13
 
 
 
SQL> alter system flush buffer_cache;
 
系统已更改。
 
SQL> select count(*) from maclean_corrupt;
select count(*) from maclean_corrupt
       *
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 6, 块号 382307)
ORA-01110: 数据文件 6: ‘C:\APP\XIANGBLI\ORADATA\MACLEAN\USERS01.DBF’
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件成功帮助山西某公安系统恢复了超过3TB的数据库

2015/03/08 by 1 Comment

诗檀软件成功帮助山西某公安系统恢复了超过3TB的数据库

 

由于客户数据库使用裸设备，且数据量高达3T。这里仅对整个system表空间文件及部分数据文件头进行备份。
相应备份被放置在/oracle/backup目录下。

1) 备份spfile
create pfile='/home/oracle/pfile1' from spfile;

2) 备份system表空间文件及数据文件头
SQL> select bytes/1024/1024 from v$datafile where file#=1;  --  2040
$ mkdir /oracle/backup

$ dd if=/dev/rrac_system01 of=/oracle/backup/rrac_system01.bak bs=1024000

$ dbv file=rrac_system01.bak blocksize=8192

SQL> set echo off
SQL> set heading off
SQL> set linesize 300 pagesize 0
SQL> select 'dd if='||name||' of=/oracle/backup/header_'||file# || ' bs=1024000 count=10' from v$datafile;

3) 备份控制文件
$ dd if=/dev/rrac_ctrol01 of=/oracle/backup/rrac_ctrol01 bs=1024000

2. 现场报错及启库操作

在数据救援中发现以下报错
Errors in file
/oracle/product/admin/orcl/udump/orcl2.ora_160642.trc:
ORA-00600: internal error code, arguments: [2662], [4], [4186310893], [4], [4186345409], [58720264], [],…

Errors in file 
/oracle/product/admin/orcl/udump/orcl2_ora_136116.trc:
ORA-00600: internal error code, arguments: [2256],[0], [1073741824], [5],[3],[],[],[]

除了以上数据库SCN问题错误外，还存在online redo 日志讹误及Undo问题。诗檀软件工程师通过设置系统参数重新修正了SCN号，通过设置10513， 10231 event事件避免了相关检查报错，并使用恢复操作恢复了数据库。
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件成功帮助云南某旅游企业恢复断电受损的Oracle数据库

2015/02/16 by 1 Comment

诗檀软件在年前成功帮助云南某旅游企业恢复断电受损的数据库

用户网站后台数据库在部署HA之前意外断电后无法OPEN，诗檀软件工程师@Biot_Wang在2个小时内顺利打开数据库并修复了后续问题。

 

Screen Shot 2015-02-16 at 4.49.11 PM

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

解决ORA-00600[ktspgfb-1]一例

2015/02/14 by Leave a Comment

解决ORA-00600[ktspgfb-1]一例，该案例的trace信息如下：

 

Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production

ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
Current SQL statement for this session:

INSERT INTO XX 
---- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               102973B94 ?
ksfdmp+0018          bl       01FD34D8             
kgerinv+00e8         bl       _ptrgl               
kgeasnmierr+004c     bl       kgerinv              042888888 ? 022488888 ?
                                                   102A8F8D0 ? 000000000 ?
                                                   000000000 ?
ktspgfblk+0240       bl       kgeasnmierr          110006728 ? 1103FCB28 ?
                                                   102A8F9B0 ? 000000000 ?
                                                   000000180 ? 7000008730AC6E8 ?
                                                   000000307 ? 7000008230AD080 ?
ktspgfbs+01b0        bl       ktspgfblk            000000058 ? 000001FE8 ?
                                                   022046489 ? 7000008829255B4 ?
                                                   FFFFFFFFFFF7030 ? 000000002 ?
                                                   FFFFFFFFFFF6DF0 ?
                                                   4448224200000000 ?
ktspfsrch+00a4       bl       ktspgfbs             700000018BD8014 ? 000000000 ?
                                                   1101D65E0 ? FFFFFFFFFFF6FF8 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ktspscan_bmb+01e4    bl       ktspfsrch            100EC61D0 ? 000000000 ?
ktspgsp_cbk1+049c    bl       ktspscan_bmb         1009BA2C4 ?
ktspgsp_cbk+0098     bl       ktspgsp_cbk1         00000000F ? 1101FB1D0 ?
                                                   700000877E9C140 ? 000000000 ?
                                                   0000000F0 ? 000000000 ?
                                                   000000000 ? 0000000C0 ?
kdtgsp+04d4          bl       ktspgsp_cbk          FFFFFFFFFFF7470 ? 110216600 ?
                                                   FFFFFFFFFFF7440 ? 110061460 ?
                                                   000000008 ? 1103DB9F0 ?
                                                   000000000 ? 110405C30 ?
kdtgsph+01ec         bl       kdtgsp               000000001 ? 1103D04D0 ?
kdtFlushBuf+03f8     bl       kdtgsph              FFFFFFFFFFF7600 ? 110006728 ?
insflush+01e8        bl       kdtFlushBuf          70000088292C480 ?
insrow+01ec          bl       insflush             1103CEDF8 ? 000000000 ?
                                                   10009E1D4 ? FFFFFFFFFFF86F0 ?

 

 

 

ktspgfbs的含义为Get first level bitmap block for search

ktspgfblk的含义为KTSP Get first level bitmap block

发生该ORA-00600: internal error code, arguments: [ktspgfb-1]错误，基本可以认为是数据对象的基本信息一级位图块可能存在逻辑损坏/讹误。

针对该错误需要根据不同的数据对象类型制定不同的修复策略。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

该ORA-00600[ktspgfb-1]错误的bug信息如下：

 Bug# 7260057   See Note:7260057.8
      Instance crash after failed RESIZE on NFS
      Fixed: 10.2.0.5, 11.2
 
  Bug# 2424226   See Note:2424226.8
      OERI:[ktspgfb-1] possible after direct load of bitmap managed segment
      Fixed: 9.0.1.4, 9.2.0.1
 
  Bug# 2253389   See Note:2253389.8
      ORA-00600:[KTSPGFB-1] possible after direct load of bitmap managed table
      Fixed: 9.0.1.4, 9.2.0.1
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With:

解决ORA-00600:[kcbgcur_3]一例

2015/02/14 by Leave a Comment

解决ORA-00600:[kcbgcur_3]一例 ，kcbgcur_3这个函数出现ORA-00600错误一般是告诉我们，当一个状态为”CURRENT”的cache buffer中存放的是程序所预期的数据地址，即TABLESPACE号和相关DBA(RDBA)，但Oracle却发现这个block并不属于一个预期的OBJECT(实际是发现了不同的Data_object_id)。

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

这一般说明是数据出现了逻辑上的讹误，主要有几种原因造成这种问题：

  1. 严重的写丢失Lost Write造成逻辑上的不一致
  2. Oracle自身bug造成的逻辑上的不一致

在此例子中kcbgcur_3的相关argument为ORA-00600: internal error code, arguments: [kcbgcur_3], [91738], [1], [0], [0], [], [], []，而数据库版本为9.2.0.8， 参考附录的kcbgcur_3的argument信息详解，各argument的含义为

 

Arg [a] 91738 即对象的object_id

Arg [b] 1代表临时对象

通过91738这个object_id可以迅速定位到出错对象，根据不同的对象类型可以给与不同的修复手段。

 

此例子的stack call如下:

----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               102973B94 ?
ksfdmp+0018          bl       01FD34D8             
kgerinv+00e8         bl       _ptrgl               
kgeasnmierr+004c     bl       kgerinv              000000079 ? 000000000 ?
                                                   000000000 ? 70000086D814308 ?
                                                   000000079 ?
kcbassertsd4+010c    bl       kgeasnmierr          110006728 ? 1103FCB28 ?
                                                   10302D894 ? 400000004 ?
                                                   000000000 ? 00001665A ?
                                                   000000000 ? 000000001 ?
kcbgcur+0b90         bl       kcbassertsd4         FFFFFFFFFFE8150 ?
                                                   8448448400000000 ?
                                                   101083D80 ? 1101FB1D0 ?
                                                   FFFFFFFFFFFF0000 ?
                                                   000000000 ?
ktbgcur+0064         bl       kcbgcur              FFFFFFFFFFE8550 ? 11042B5B0 ?
                                                   FFFFFFFFFFE8260 ? 000000010 ?
kdislink+00ec        bl       ktbgcur              000000000 ? 000000000 ?
                                                   000000000 ? 110002E40 ?
kdisle+3e8c          bl       kdislink             000000020 ? 110405C30 ?
                                                   70000087CC49528 ?
                                                   70000087CC48830 ?
kdiins0+17a0         bl       kdisle               700000884D0E400 ?
                                                   FFFFFFFFFFE8C78 ?
                                                   FFFFFFFFFFE8D60 ?
                                                   100000000000001 ?
                                                   2000000000002 ? 11041A738 ?
                                                   FFFFFFFFFFFFFFFF ?
                                                   000000000 ?
kauxsin+2088         bl       kdiins0              700000884D0E400 ? 000000000 ?
                                                   000000B40 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 2000000000000 ?
insidx+08fc          bl       kauxsin              700000884D115B8 ?
                                                   FFFFFFFFFFF86DC ?
                                                   F2FFFFFFFF8530 ? 1103CEF18 ?
                                                   1103CEFA0 ? 1103CEFC8 ?
                                                   1103CEED8 ? 000000000 ?
insflush+0204        bl       insidx               700000884D1DEB0 ?
insrow+01ec          bl       insflush             1103CEDF0 ? 000000000 ?
                                                   10009E1D4 ? FFFFFFFFFFF90A0 ?
                                                   000000000 ?
insdrv+05f4          bl       insrow               1103CEDF0 ? FFFFFFFFFFF90A0 ?
                                                   000000000 ?
insexe+0648          bl       insdrv               1103CEDF0 ?
opiexe+1e44          bl       insexe               700000884DCD2D8 ?
                                                   700000884DCCE88 ?
opiodr+08cc          bl       _ptrgl               
ttcpip+0cc4          bl       _ptrgl               
opitsk+0d60          bl       ttcpip               11000D3B0 ? 000000000 ?

 

附录

 

关于kcbgcur_3 ORA-00600的详细信息，其报错argument的信息含义如下：

 

10gR2及以后是:

 

Arg [a] Object Id passed to the cache by the layer accessing the cache.

Arg [b] Class of the block.

Arg [c] Flags which define characteristics of buffer usage

Arg [d] 1 for a temporary object.

 

10gR1中的信息如下：

 

Arg [a] Object Id passed to the cache by the layer accessing the cache.

Arg [b] Class of the block.

Arg [c] 1 for a temporary object.

 

Oracle 9.X中的信息如下：

 

Arg [a] Object Id passed to the cache by the layer accessing the cache.

Arg [b] 1 for a temporary object.

 

Oracle 8.0.4到8.1.7中的信息如下：

 

Arg [a] Class of the block.

Arg [b] Tablespace number.

Arg [c] Relative DBA.

Arg [d] Object Id in the cache buffer at the time of the error.

Arg [e] Object Id passed to the cache by the layer accessing the cache. Indicates if this is a temporary or a permanent object.

Arg [f] In version 8.0.4 to 8.1.5, this is 1 for a permanent object. In version 8.1.6 and 8.1.7, this is 1 for a temporary object.

 

Oracle 8.0.3中的信息如下:

Arg [a] Class of the block.
Arg [b] Tablespace number.
Arg [c] Relative DBA.
Arg [d] Object Id in the cache buffer at the time of the error.
Arg [e] Object Id passed to the cache by the layer accessing the cache.

 

 kcbgcur_3的相关BUG列表如下

 


13467683
11902008
11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 12.1.0.0
Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368
12.1.0.0
SMON may crash with ORA-00600 [kcbgcur_3] or ORA- 600 [kcbnew_3] during Transaction recovery
7227645
11.1.0.7, 11.2.0.1
OERI[kcbgcur_3]/OERI[kcb_check_objd_typ] during INSERT on freelist-managed segment
6444339
10.2.0.5, 11.2.0.1
Truncate/purge does not clean AQ dependencies properly
6337376
11.1.0.7
OERI:kcbgcur_3 / ORA-8103 after truncating a partition table with LOBs
5909305
11.1.0.6
Change to DML (TM) lock modes for foreign key constraints
5303237
11.1.0.6
ORA-600 [kcbgtcr_5] during create queue table
8778379
10.2.0.5
Fix event 10227 in 10.2 ORA-600[kcbgcur_3] or ORA- 600[kcbgcur_9]
3963135
10.1.0.5, 10.2.0.1
OERI[kcbgcur_3] / OERI:25027 during bitmap index updates
2784201
9.2.0.5, 10.1.0.2
OERI:[ktspfupdst-1] on INSERT into LOB after TRUNCATE with ASSM
3693283
9.0.1.0
TRUNCATE can cause SMON to crash the instance with OERI:[KTSF_RSP2]
1148416
8.1.6.1, 8.1.7.0
Buffer cache corruption can occur using GLOBAL TEMPORARY TABLES
689973
8.0.4.4, 8.0.5.1, 8.0.6.0
OERI:KCBGCUR_3 during DROP/CREATE table with concurrent queries.
Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With:

沪ICP备14014813号-2

沪公网安备 31010802001379号