【Oracle数据库恢复】ORA-00600: [16513], [1403], [20]一例

2014/09/18 by Leave a Comment

某国内数据库系统由于存储故障导致ASM diskgroup损坏，后续恢复过程中在open  database阶段遇到了ORA-00600: [16513], [1403], [20]：ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []

 


ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ssd_unwind_bp: unhandled instruction at 0x76add1 instr=f
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
ksfdmp()+63          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             006AE9A20 ? 000000003 ?
                                                   7FFF04273960 ? 7FFF042739C0 ?
                                                   7FFF04273900 ? 000000000 ?
kgesiv()+119         call     kgeriv()             006AE9A20 ? 00DAC5398 ?
                                                   000000000 ? 2B749C907FA0 ?
                                                   7FFF04273900 ? 000000000 ?
ksesic2()+215        call     kgesiv()             006AE9A20 ? 00DAC5398 ?
                                                   000004081 ? 000000002 ?
                                                   7FFF042748A0 ? 000000000 ?
kqdpts()+351         call     ksesic2()            006AE9A20 ? 000000000 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqrlfc()+314         call     kqdpts()             55DF9CE78 ? 000000000 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqlbplc()+153        call     kqrlfc()             55DF9CE78 ? 7FFF04274BC0 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
kqlblfc()+263        call     kqlbplc()            000000000 ? 7FFF04274BC0 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
adbdrv()+58009       call     kqlblfc()            000000000 ? 7FFF0427B450 ?
                                                   00000057B ? 000000000 ?
                                                   000000014 ? 000000000 ?
opiexe()+13745       call     adbdrv()             000000000 ? 7FFF0427B450 ?
                                                   536FEDDF8 ? 000000000 ?
                                                   000000014 ? 000000000 ?
opiosq0()+3398       call     opiexe()             000000004 ? 000000000 ?
                                                   7FFF0427C60C ? 000000001 ?
                                                   000000014 ? 000000000 ?
kpooprx()+318        call     opiosq0()            000000003 ? 00000000E ?
                                                   7FFF0427C938 ? 0000000A4 ?
                                                   000000000 ? 600000013 ?
kpoal8()+783         call     kpooprx()            7FFF0427FB1C ? 7FFF0427DB48 ?
                                                   000000013 ? 000000001 ?
                                                   000000000 ? 600000013 ?
opiodr()+1184        call     kpoal8()             00000005E ? 000000017 ?


ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0cdc.c2a516cc):

ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16513], [1403], [20], [], [], [], [], []
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704

该open database 失败时的ORA-00600: [16513]错误并不常见，根据其stack call看：kqrlfc=>kqdpts=>报错

kqrlfc =>KQR Kernel SQL Row cache management component Load Fixed Cache 代表加载基本row cache字典缓存
kqdpts => Kernel Query Dictionary Patch Time Stamps

可以看到该16513 属于 16500 dict/rowcache this layer provides support to load / cache Oracle’s dictionary in memory in the library cache; 即问题指向在加载字典缓存时oracle遇到了严重的问题。

该问题后续通过手动patch数据字典来绕过了。

 

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

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

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

 

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

PRM-DUL成功案例之一：恢复ORA-600[25027]错误的多张千万行级别的表

2014/09/15 by 1 Comment

ParnassusData成功使用PRM-DUL为某西南用户恢复了问题数据库中出现ORA-600[25027]错误的多张千万行级别的表，这是是PRM release之后第一个成功案例。

 

最新版PRM-DUL下载地址： http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122 

ORA-00600: internal error code, arguments: [25027], [11], [8459115], [], [], [], [], []

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

PRM-DUL成功案例：成功为中原某客户从断电损坏严重的数据库中恢复出十多万张表

2014/09/15 by Leave a Comment

PRM-DUL成功案例：成功为中原某客户从断电损坏严重的数据库中恢复出十多万张表

 

中原某政府机构存储断电导致存储异常，大量的数据块发生fracture，总数据量近1个TB。 通过rman validate检测发现仅SYSTEM表空间上就有10000多个坏块，配合PRM拯救数据，从损坏数据库中恢复了十万多张表的绝大部分数据。

 

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

PRM-DUL成功帮助某移动厂商恢复被DROP掉的业务核心表

2014/09/15 by Leave a Comment

PRM-DUL成功帮助某移动厂商恢复被DROP掉 且位于 SYSTEM表空间上的业务核心表，由于数据位于SYSTEM表空间上所以不存在使用回收站技术恢复的可能。

 

 

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

诗檀软件成功为某房地企业修复受损的ORACLE核心对象

2014/09/15 by Leave a Comment

诗檀软件成功为某房地企业修复受损的ORACLE核心对象，其受损的是ORACLE数据字典核心基础表OBJ$的I_OBJ5索引，该索引受损后直接导致用户数据无法正常访问和导出；由于该索引为关键的bootstrap索引，所以无法被简单rebuild，需要通过手工Patch方式来修复，诗檀工程师在最短时间内修复该索引成功，且保证无丢失任何数据。

 

 

 

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

诗檀软件官方网站parnassusdata.com已改版 欢迎访问

2014/09/11 by Leave a Comment

经过2个月时间的不断修改，诗檀软件官方网站parnassusdata.com已完成初次改版，欢迎大家访问！

主页上启用的JS动画，以动态形式来说明PRM-DUL的强大DataBridge功能，数据将在损坏数据库和新建数据库之间灵活传输，包括普通数据类型的LOB类型。

 

parnassusdata1

 

PRM产品页面，我们将PRM产品版本精简为2个，社区版和企业版。 社区版完全免费，且其ASM恢复功能也完全免费。 而企业版则没有任何限制。

 


 parnassusdata2

 

 

 

紧急服务页面 加强了图标和文字说明：

服务范围

ParnassusData紧急响应服务支援覆盖中国本土地区，提供7*24小时汉语技术支持，涵盖Oracle数据库产品：ORACLE RDBMS和MYSQL。

服务包括但不限于：

  1. 针对无法打开的ORACLE数据库，实施特殊的手工修复
  2. 基于ParnassusData Recovery Manager PRM专业ORACLE数据库恢复工具恢复问题数据库中的数据
  3. 修复数据库中的坏块
  4. 解决关键的ORA-00600(600错误)问题
  5. 实施ORACLE数据库的崩溃恢复/修复
  6. 解决关键的ORACLE数据库性能问题，解除性能瓶颈
  7. 针对ORACLE的致命BUG提供解决方案
  8. 实施ORACLE补丁安装
  9. 协助解决紧急的ORACLE硬件产品故障
紧急服务策略

 

已购买ParnassusData 紧急响应服务包的企业可以直接拨打13764045638后按2接入签约用户技术支持通道，将由ParnassusData服务交付经理负责分配工程师跟进解决技术问题。 如果是新客户可以拨打13764045638后按1接入购买紧急服务通道。  用户可以 24 * 7 通过13764045638获得技术服务。 ParnassusData当天的执勤工程师将通过电话支持和远程接入的方式解决用户的技术难题。 当用户的技术问题较为棘手，难以通过电话和远程支持解决的情况下，ParnassusData Emergency紧急任务现场工程师将赶赴用户现场修复问题。

 

数据库恢复服务

ParnassusData数据库修复团队对于Oracle数据库的恢复任务包括：数据库无法打开，丢失SYSTEM表空间，ASM Diskgroup无法mount等具有丰富的恢复经验。 我们是能将您的数据库快速修复并使之能最快ONLINE使用的紧急任务团队。 我们可以以最安全的方式连接到您的数据库服务器，或者通过电话远程协助恢复任务。尽可能快地恢复用户的业务并基于实际情况尽可能保证数据的一致性与完整性是我们的使命。

 

故障解决

当用户正经受数据库中神秘的阻塞/锁定，或影响甚广的HANG挂起问题，或特殊的报错故障时，ParnassusData Oracle数据库技术团队的专家顾问将协助用户快速并安全地解决故障。ParnassusData的Oracle专家都是身经百战的熟手DBA，几乎经历过所有用户可能遇到的问题。

parnassusdata3

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

Oracle PRM-DUL成功帮助安徽某政府机关恢复数据

2014/09/10 by 3 Comments

最近 安徽某政府机关数据库出现严重损坏问题，通过当地集成商联系到诗檀软件，通过ORCLE PRM-DUL工具成功从受损数据库中恢复出绝大多数数据。

 

具体问题为数据库shutdown 之后再次尝试OPEN时报错trc:ORA-00600: internal error code, arguments: [3619]，

 

ALTER DATABASE OPEN /* db agent *//*
ORA-00600: internal error code, arguments: [3619], [3], [0], [], [], [], [],
[], [], [], [], []
Incident details in:
orcl_ora.trc

 

该ORA-00600[3619]错误相关的存在一些bug :

 

Bug 9156272 : ESSC: ALTER DATABASE OPEN FAILS WITH ORA-1110 / ORA-372 FOR
READ ONLY FILE-> provided fix for Bug 9156272; bug fixed in 11.2.0.2
Bug 9587488 : ESSC: ORA-600 [3619] - DB WILL NOT OPEN AFTER SHUTDOWN
-> recommended to install the fix for Bug 9584943
ORA-600[KCRATR_SCAN_LOSTWRT] ON ALTER DATABASE OPEN; this bug is fixed in11.2.0.2

这个case 用户自行通过PRM-DUL Schmea级别数据抽取恢复了，这说明一般技术人员通过阅读PRM文档就可以掌握PRM的基本使用了。

对ORACLE PRM持续增强中！。

ORACLE PRM 白皮书地址： http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

prm-dul

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

PRM-DUL成功案例：为东北某企业恢复了10多T的Oracle数据

2014/08/19 by 1 Comment

PRM-DUL成功案例：为东北某企业恢复了10多T的Oracle数据，该数据库由于存储故障导致控制文件和SYSTEM表空间部分损坏，之后用户处代维尝试重建控制文件 但操作失误漏掉了部分数据文件，多次尝试使用”_allow_resetlogs_corruption”打开数据库均出现了不同程度的问题， 随之问题变得更为严峻。 本次恢复涉及到近200个数据文件，数据量达到10多个T。

 

建议在尝试”_allow_resetlogs_corruption”等特殊恢复手段前一定要想清楚，是否能面对即便加了这些隐藏参数仍无法打开数据库的状况下如何应当，以及尽可能备份当时的SYSTEM表空间数据文件

 

QQ截图20141016155150

 

QQ截图20141016154850

 

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

【Oracle ASM数据恢复】ORA-15066 & too many offline disks in PST (grp 1)

2014/08/18 by Leave a Comment

某10.2.0.5 ASM系统由于存储故障导致normal redundancy diskgroup中的4个failgroup中的2个failgroup的ASM DISK均无法访问，在10g中若ASM disk无法访问将直接将disk drop出diskgroup中。

 

报错如下：

 

Sat Nov 15 17:05:36 CST 2013
WARNING: PST-initiated drop disk 1(739802527).1(3915943320) 
WARNING: PST-initiated drop disk 1(739802527).3(3915943321) 
Sat Nov 15 17:05:36 CST 2013
NOTE: PST update: grp = 1
Sat Nov 15 17:05:36 CST 2013
ERROR: too many offline disks in PST (grp 1)
Sat Nov 15 17:05:36 CST 2013
ERROR: ORA-15066 signalled during reconfiguration of diskgroup DATADG
NOTE: requesting all-instance membership refresh for group=1
Sat Nov 15 17:05:36 CST 2013
NOTE: membership refresh pending for group 1/0x2c187d9f (DATADG)
WARNING: rejecting drop force of disk number 1
WARNING: rejecting drop force of disk number 3
SUCCESS: refreshed membership for 1/0x2c187d9f (DATADG)
Sat Nov 15 17:05:39 CST 2013
ERROR: PST-initiated disk drop failed
Sat Nov 15 17:05:39 CST 2013
ERROR: PST-initiated MANDATORY DISMOUNT of group DATADG
NOTE: cache dismounting group 1/0x2C187D9F (DATADG) 
Sat Nov 15 17:05:39 CST 2013
NOTE: halting all I/Os to diskgroup DATADG

由于是normal redundancy，所以只能丢失一个failgroup。ASM尝试drop 2个failgroup时会导致diskgroup被强制DISMOUNT，即PST-initiated MANDATORY DISMOUNT of group DATADG。

 

PST-initiated drop disk =》 PST初始化drop disk

ERROR: too many offline disks in PST (grp 1) ==> ASM认为若drop 这么多disk会导致丢失数据，所以是too many offline disk

 

WARNING: rejecting drop force of disk number 1
WARNING: rejecting drop force of disk number 3  ==> ASM拒绝drop这些disk

ERROR: PST-initiated disk drop failed==> PST初始化drop disk失败

ERROR: PST-initiated MANDATORY DISMOUNT of group ORADATA==》 强制dismount diskgroup

 

以上对于该asm diskgroup的维护将陷入死循环，即 mount diskgroup => 开始drop disk=> 由于drop disk过多 导致asm 强制dismount diskgroup => 人为再次手动mount diskgroup。 该ASM Diskgroup实际变得不可用了。

 

我们可以通过设置隐藏参数或者手动patch PST的方式来绕过该问题，具体需要了解ASM 底层数据结构的工程师现场根据实际情况实施，再次不再鏖述。

 

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

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

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

_  __

(_)/   \

<‘_, ____)~~~~~~~

^^   ^^

 

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

PRM-DUL for oracle恢复被truncate截断掉的表

2014/08/12 by Leave a Comment

PRM DUL for oracle恢复被truncate截断掉的表 Oracle DBA神器：PRM灾难恢复工具，Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据库数据恢复特性 ，PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具。PRM可以在无备份的情况下恢复被truncated/drop掉的表，也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具，同时具备很多Oracle DUL不具备的特性

 

 

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

沪ICP备14014813号-2

沪公网安备 31010802001379号