咨询微信: dbservice1234 7 x 24 在线支持!

    你在这里

    • You are here:
    • 首页 > 24*7 紧急救援 服务热线:13764045638

24*7 紧急救援 服务热线:13764045638

 

下载DBRECOVER for Oracle 数据库恢复软件

微信: dbservice1234  QQ号:47079569     

 

 

ORACLE技术专家服务邮箱: service@parnassusdata.com

 

 


服务范围

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硬件产品故障

 

当你遇到如下恢复需求时,都可以找我们恢复:

意外DROP了表:请第一时间关闭应用和数据库实例,并对所有数据文件做一个备份。

  1. 意外DROP了column字段
  2. 意外truncate了表:与drop表类似
  3. 意外drop tablespace: 不管是drop tablespace带了including contents 还是including datafiles,都有机会恢复
  4. 丢失了system表空间数据文件:可以基于用户数据表空间尽可能恢复数据
  5. 只剩下部分数据文件: 与丢失了system表空间类似,只要你要的数据在对应数据文件里,我们就能挖掘出来
  6. Oracle数据字典或启动自举对象bootstrap objects存在问题
  7. 数据库只剩下部分备份文件,而且这些备份文件可能丢失归档日志archivelog、丢失增量备份,所以这些备份也是不一致的。
  8. ASM diskgroup disk header/metadata存在损坏,导致ASM diskgroup 无法成功mount

 

 

 

 


紧急服务策略

 

已购买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,几乎经历过所有用户可能遇到的问题。

 

我们乐于在第一时间响应对用户来说棘手的数据库崩溃,数据库调优,应用报错等问题。

 

 

Oracle的损坏/坏块 主要分以下几种:

 

ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
Consistent Read
Dictionary
File/RDBA/BL

 

 

 
Error   Description Corruption related to:
ORA-1578 ORA-1578一般为Oracle检测到存在物理坏块问题,包括其检测数据块中的checksum不正确,或者tail_chk信息不正确等。 ORA-1578 is reported when a block is thought to be corrupt on read.

Block

数据块

    OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note  
    OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”  
   
Fractured Block explanation
 
    Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g  
    Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table  
ORA-1410

ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。

该错误可能因为数据表与其索引存在不一致,也可能是分区的数据表本身存在问题。

This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.

Row

数据行

    Understanding The ORA-1410  
    Summary Of Bugs Containing ORA 1410  
    OERR: ORA 1410 “invalid ROWID”  
ORA-8103

该ORA-8103可能由多个BUG引起,例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header,导致出现ORA-8103错误。

诊断该问题可以从数据表的segment header和data_object_id入手。

The object has been deleted by another user since the operation began.
If the error is reproducible, following may be the reasons:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).

Block

数据块

    ORA-8103 Troubleshooting, Diagnostic and Solution  
    OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution  
ORA-8102 ORA-8102常见于索引键值与表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.

Index

索引

    OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)  
ORA-1499 对表和索引做交叉验证时发现问题 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.

Index

索引

    ORA-1499. Table/Index row count mismatch  
    OERR: ORA-1499 table/Index Cross Reference Failure – see trace file  
ORA-1498   Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE;
Block
    OERR: ORA 1498 “block check failure – see trace file”  
ORA-26040 由于采用过nologging/unrecoverable选项的redo生成机制,且做过对应的recover,导致数据块中被填满了0XFF,导致报错ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578

Block

数据块

    OERR ORA-26040 Data block was loaded using the NOLOGGING option  
    ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution  
    ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors  
    ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled  
    ORA-1578 ORA-26040 On Awr Table  
    Errors ORA-01578, ORA-26040 On Standby Database  
    Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option  
    ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option  
ORA-600[12700]

从索引获得的ROWID,对应到数据表时发现不存在数据行错误。

一把是一致性度consistent read问题

Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported due to a consistent read (CR) problem.

Consistent Read

一致性读

    Resolving an ORA-600 [12700] error in Oracle 8 and above.  
    ORA-600 [12700] “Index entry Points to Missing ROWID”  
ORA-600[3020] 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered.
Redo
    ORA-600 [3020] “Stuck Recovery”  
    Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)  
ORA-600[4194] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails.
Undo
    ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”  
    Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter  
ORA-600[4193] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails.
Undo
    ORA-600 [4193] “seq# mismatch while adding undo record”  
    Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter  
    Ora-600 [4193] When Opening Or Shutting Down A Database  
    ORA-600 [4193] When Trying To Open The Database  
ORA-600[4137] transaction id不匹配,问题可能存在与回滚段中或者对象本身存在讹误 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment.
Undo/Redo
    ORA-600 [4137] “XID in Undo and Redo Does Not Match”  
ORA-600[6101]   Not enough free space was found when inserting a row into an index leaf block during the application of undo. Index
    ORA-600 [6101] “insert into leaf block (undo)”  
ORA-600[2103]   Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged.
Control File
    ORA-600 [2130] “Attempt to access non-existant controlfile entry”  
ORA-600[4512]   Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption.
Block
    ORA-600 [4512] “Lock count mismatch”  
ORA-600[2662] 主要是发现一个数据块的SCN甚至超过了当前SCN,常规解决途径有调整SCN等,但11.2以后Oracle公司使较多调整SCN的方法失效了 A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error.
Block
    ORA-600 [2662] “Block SCN is ahead of Current SCN”  
    ORA 600 [2662] DURING STARTUP  
ORA-600[4097] 访问一个回滚段头以便确认事务是否已提交时,发现XID有问题 We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem.
Undo
    ORA-600 [4097] “Corruption”  
ORA-600[4000]   It means that Oracle has tried to find an undo segment number in the dictionary cache and failed. Undo
    ORA-600 [4000] “trying to get dba of undo segment header block from usn”  
ORA-600[6006]   Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.
ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk.
Index
    ORA-600 [6006]  
ORA-600[4552]   This assertion is raised because we are trying to unlock the rows in a block, but receive an incorrect block type.
The second argument is the block type received.
Block
    ORA-600 [4555]  
ORA-600[6856]   Oracle is checking that the row slot we are about to free is not already on the free list.
This internal error is raised when this check fails.
Row
    ORA-600 [6856] “Corrupt Block When Freeing a Row Slot  
ORA-600[13011]   During a delete operation we are deleting from a view via an instead-of trigger or an Index organized table and have exceeded a 5000 pass count when we raise this exception. Row
    ORA-600 [13011] “Problem occurred when trying to delete a row”  
ORA-600[13013]   During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause. Row
    ORA-600 [13013] “Unable to get a Stable set of Records”  
    How to resolve ORA-00600 [13013], [5001]  
ORA-600[13030]      
    ORA-600 [13030]  
ORA-600[25012]   We are trying to generate the absolute file number given a tablespace number and relative file number and cannot find a matching file number or the file number is zero. afn/rdba/tsn
    ORA-600 [25012] “Relative to Absolute File Number Conversion Error”  
ORA-600[25026]   Looking up/checking a tablespace
invalid tablespace ID and/or rdba found
afn/rdba/tsn
    ORA-600 [25026]  
ORA-600[25027]   Invalid tsn and/or rfn found afn/rdba/tsn
    ORA-600 [25027]  
ORA-600[kcbz_check_objd_typ] 内存中的block buffer检测发现存在错误的object id  An object block buffer in memory is checked and is found to have the wrong object id. This is most likely due to corruption. Buffer Cache
    ORA-600 [kcbz_check_objd_typ_3]  
    ORA-600 [kcbz_check_objd_typ]  
ORA-600[kddummy_blkchkORA-600[kdblkcheckerror] 一种逻辑检测发现问题的情况 ORA-600[kddummy_blkchk] is for 10.1/10.2 and ORA-600[kdblkcheckerror] for 11 onwards. Block
    ORA-600 [kddummy_blkchk]  
    How to Resolve ORA-00600[kddummy_blkchk]  
    ORA-600 [kdblkcheckerror]  
   
QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Listing (Full) [This section is not visible to customers.]
 
   
QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Definition && Return Values[This section is not visible to customers.]
 
ORA-600[ktadrprc-1]    

Dictionary

字典

    ORA-600 [ktadrprc-1]  
ORA-600[ktsircinfo_num1] SYS.SEG$字典表导致row cache字典缓存中存在意外 This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$. In most cases there is no information in sys.seg$.

Dictionary

字典

    ORA-600 [ktsircinfo_num1]  
ORA-600[qertbfetchbyrowid]     Row
    ORA-600 [qertbfetchbyrowid]  
ORA-600[ktbdchk1-bad dscn]   This exception is raised when we are performing a sanity check on the dependent SCN and fail.
The dependent scn is greater than the current scn.
Dictionary
    ORA-600 [ktbdchk1: bad dscn]