Maclean’s Oracle Database Tech Blog Archives

  • 【Oracle ASMデータリカバリ】ORA-15066 & too many offline disks in PST (grp 1)

    プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected] ある10.2.0.5 ASMシステムで、ストレージトラブルでnormal redundancy diskgroupに四つのfailgroupの中で、二つのfailgroupのASM DISKがアクセス出来ない。もし10gの環境でASM diskをアクセス出来ないであれば、disk dropをdiskgroupから出す。   エラは以下の通り:   Sat Nov 15 17:05:36 CST 2013WARNING: PST-initiated drop disk 1(739802527).1(3915943320) WARNING: PST-initiated drop disk 1(739802527).3(3915943321) Sat Nov 15 17:05:36 CST 2013NOTE: PST update: grp = 1Sat Nov 15 17:05:36 CST 2013ERROR: too many offline disks in PST (grp 1)Sat…

  • [Oracleのデータ復旧] ORA-00600【6856】一つのケース

    プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   あるユーザーデータベーステーブルスペースtablespaceがOFFLINEしたら、またONLINE出来なくなったトラブルになった。alter tablespace ABC  onlineを操作したら、エラになる:   alter tablespace abc online; error at line 1: ORA-00600: internal error code, arguments : [6856],[0],[163] 600のargument 1 によって、そのエラはそのテーブルスペースのデータとundoデータの間に整合性がないからである。 Ora-600 Base Functionality Description 6000 ram/data ram/analyze ram/index data, analyze command and index related activity   ここのundoデータは Deferred Undo Segmentと意味する; あるDEFERRED ROLLBACKもSAVE Undo segmentsと呼ばれている。以下のメリットがある: それは突然OFFLINEされたテーブルスペースのトランザクションをUNDO/Rollbackに格納して、データをロールバックする。 Segment_nameデータセグメントの名前はFILE#ファイル番号.Block#ブロック番号 そのSEGMENT_TYPEはDEFERRED ROLLBACKである SYSTEMシステムテーブルに自動的に作成する。 SYSユーザーに属している…

  • Oracle ORA-01122 ORA-01200 エラ解析

    プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   ORA-01122: database file 9 failed verification check ORA-01110: data file 9: ‘/mac01.dbf’ ORA-01200: actual file size of 64000 is smaller than correct size of 65600 [oracle@oel8 ~]$ oerr ora 1122 01122, 00000, “database file %s failed verification check” // *Cause: The information in this file is inconsistent with…

  • Oracle ORA-600 [kcbnew_3] トラブル診断

    ORA-00600[kcbnew_3] [a] [b] [c]はOracle 9i 9.2の後に導入された新たなブロックテストである。あるデータブロックを格納したcache bufferが再び利用される途中で、bufferの状態はstateで、データはtempあるいはundo。 Oracle一致性テストはbuffer headerのblock classと使用者へ伝えるblock classを比べて、相違なところを見つけた。 プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   ORA-00600[kcbnew_3]に三つのバラメタはバーションによって、説明も変わる: oracle 11.1とそのあと: [a] メモリーループ内存循环計数器、実は初期のブロックの数 [b]コードインスタンスにそのcacheのobject idをアクセスする [c] flagでそのbufferの特徴を定義する oracle 10.1 和 10.2中: [a] メモリーループ内存循环計数器、実は初期のブロックの数 [b] buffer class [c] コードインスタンスにそのcacheのobject idをアクセスする Oracle 9.2で: [a] buffer class ORA-600 [kcbnew_3]は コアメモリーbuffer管理に属している。影響は以下の通り:プロセスが失敗するあるいはSQLを実行できなくなるが二度のデータ損害を及ばない。 NB Bug Fixed Description 12391183 11.2.0.3, 12.1.0.0 ORA-600…

  • Oracle ORA-00201 ORA-00202 ORA-00206 ORA-00210コントロールファイルエラ解析

    プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   [oracle@mlab2 ~]$ oerr ora 201 00201, 00000, “control file version %s incompatible with ORACLE version %s” // *Cause: The control file was created by incompatible software. // *Action: Either restart with a compatible software release or use // CREATE CONTROLFILE to create a new control file that is…

  • Oracle ASM no read quorum in group: required 1, found 0 disks & ORA-15063 ORA-15017 ORA-15032

    プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:[email protected]   ASMを使うときにASM Diskgroupが現れて、MOUNTできなくなった上に、ASMインスタンスのalert.logに以下のようなエラが現れた: ERROR: no read quorum in group: required 1, found 0 disks ORA-15032: not all alterations performed ORA-15017: diskgroup “TESTDG04” cannot be mounted ORA-15063: ASM discovered an insufficient number of disks for diskgroup “TESTDG04” ERROR: /* ASMCMD */ALTER DISKGROUP testdg04 MOUNT これはASM Diskgroup上の部分、Metadataメータデータにロジック損害/一致していない事情が現れたと意味している。この場合にはkfed repairでリカバリしてください (10.2.0.5バーション後) kfed repairでうまくいかない場合には、ASM底の構造に詳しいプロ技術員が人工的にロジック損害を修復するという方法しかない。…

  • more about _allow_error_simulation

    自分でうまくいかないときに詩檀ソフトORACLEデータベースリカバリチームに助けを求めてください。 携帯番号: +86 13764045638    メール:[email protected]   _allow_error_simulationは10gのあとにadjust_scnトランザクションと付き添って、SCNがora-00600 [2662] askmac.cnに対する効果をより高める。 このバラメタはそれだけじゃない。隠しバラメタとしても、オプションのスイッチとしても、いろんな役目を果たしている。ディフォルトはfalseで,例えば10015 trace name adjust_scnこのようなトランザクションは実際に効かない。askmac.cn 552438.1 How To Adjust the SCN using parameter _MINIMUM_GIGA_SCN @ Formerly this note mentioned adjust_scn of event 10015 but no longer. An event is sometimes not helpful because some types or issues do not allow Oracle to reach the point of…

  • DROP TABLESPACEのOracle特別なリカバリ

    ORACLEデータベースを正常にオープンできない場合やマウントできない場合、データベースが損傷した場合等にオラクルデータベースファイル(~.dbf)を直接読み込むことによって、ファイルから有効なデータを抽出するツールです。 Oracleデータベース救済-リカバリ-運用とメンテナンス-オプティマイザサビースは詩檀ソフトに訪ねてください。 自分でうまくいかないときに詩檀ソフトORACLEデータベースリカバリチームに助けを求めてください。 携帯番号: +86 13764045638    メール:[email protected] ある企業に一番大事な業務は誤操作で、複数の業務テーブルスペースがDROPされた。これらの業務テーブルスペースには300あまりのテーブルを格納している。それにどんなバックアップもない。 詩檀ソフトエンジニアが現場に赴いて、トラブルについての詳しい情報を理解する: データベースはアーカイブモードだが、有効なバックアップがない。 複数のテーブルスペースがDROPされたが、DROP TABLESPACEがinlucding datafilesを指定していないから、関連するデータファイルがまだ削除されていない。 flashback queryでOBJ$、TAB$などのテーブルを検索して、DROP TABLESPACEに削除されたディクショナリー情報を獲得するときに、ORA-01555エラが現れる。これはUNDOデータも期限切りと意味している。flashback queryで、DROP TABLESPACEについてのディクショナリーデータをリカバリできない。 bbedでdbfのディクショナリーテーブルを観察して、OBJ$、TAB$などのディクショナリーテーブルが削除されたわずかのデータしか残っていない。特別なリカバリで削除されたデータ行をリカバリするという方法でディクショナリーデータをリカバリできない。 以上のシーン情報で、DROP TABLESPACEしたあとでflashback queryあるいはbbedなどの手段で該当するデータディクショナリーをリカバリできないから、データディクショナリーをリカバリすることでdrop tablespace操作をロールバックするには不可能である。 この場合に対して、有効な物理あるいはロジックバックアップもない場合に、ORACLE PRM-DULを使わないとリカバリできない。   注意:このような有効なバックアップがない場合に対して、100%にデータをリカバリできることを保障できない。データをリカバリする比率はデータスペースがOracleに回収された後に再び使われるかあるいは上書きされるかということで決める。DROP TABLESPACE操作自身には一連の再帰操作を含んでいるから。つまり、そのテーブルスペースにあるすべてのデータテーブルを再帰的にDROPして、すべてのデータテーブルを完全にDROPしたこそホントのDROP TABLESPACEが始められる。持続期間’で回収したスペースが再び利用され、上書きされる。   ディクショナリーデータは既になくしたから、ORACLE PRM-DULに非ディクショナリーモード(NON-SYSTEM TABLESPACE)で作業を進行する。つまり、DROP TABLESPACEされたデータファイルのSEGMENT HEADERあるいはSEGMENT EXTENTSデータを直にスキャンする。これらのデータにはテーブルの行データを含んでいるが、TABLE_NAMEあるいはCOLUMN_NAMEなどのメータデータを含んでいない。非ディクショナリーモードで抽出したテーブルのテーブルの名前はOBJ+で、そのDATA_OBJECT_ID形式は、例えばOBJ9999、そのテーブルがDATA_OBJECT_ID=9999のデータテーブルと意味している。故に、非ディクショナリーモードでUNLOADされたテーブルはそのデータはどこのテーブルに属しているかを人工的に識別する必要がある。   PRM-DUL非ディクショナリーモードで、二つのスキャン方法がある:SEGMENT HEADERあるいはEXTENTモード。テーブルスペースが何のデータファイルもなくしていない上にテーブルヘッダもなくしていない場合に、SEGMENT HEADERモードを使ってください。PRM-DULはテーブルヘッダモードでDATABASEとTABLES;をSCANして、190を超えたテーブルを見つけ出した。一部の業務テーブルをリカバリできたが、SEGMENT HEADERモードで五つ肝心な業務テーブルを見つけ出せない。   これは五つのテーブルのSEGMENT HEADERがもうDROP TABLESPACEされてこわれたと意味している。これはDROP TABLESPACEプロセスで一部の回収スペースが上書きされたと意味する。SEGMENT HEADERモードで必要なテーブルを見つけ出せないから、後はEXTENTモードで実行する。   EXTENTモードはデータファイルにあるすべての行のデータブロックを見つけ出すから、SEGMENT HEADERを必要としていない。故に、EXTENTモードで大量なデータを獲得できる。スキャンした範囲がより広くなるので、リカバリする必要としていないデータテーブルもより多く現れるから、前の方法よりずっと時間をかかる。

  • Oracle ASM kfed repairで何をできるか?

    オフィシャルな説明によると、kfed repairコマンドについての説明は極めて簡略である: Recover the disk header from the redundant copy of it maintained on an unused portion of the disk. 主にdisk headerのヘッダ4096 bytesのKFBTYP_DISKHEAD構造に使われる。 このリカバリは10.2.0.5後のDisk Header自動バックアップ機能に基づいている。 PSTでつまりAU=1の最後の二つのデータブロックで自動的にバックアップされた(Read from PST(AU 1)’s penultimate Block) KFBTYP_DISKHEAD。 例えば: [oracle@mlab2 oracleasm]$ kfed read asm-disk04 aun=1 blkn=254|less kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD…

  • DROP TABLESPACE的Oracle特殊恢复

    某企业核心业务数据库由于误操作导致多个业务表空间被意外DROP,这些业务表空间存放了300多张表,且无任何形式的有效物理、逻辑备份。 诗檀软件工程师赴用户现场。 具体了解了本问题的细节信息: 数据库采用归档模式,但当时未找到有效的物理或逻辑备份。 多个表空间被DROP ,但因为DROP TABLESPACE没有指定inlucding datafiles,故相关数据文件仍保留在文件系统中未被删除。 尝试使用flashback query闪回查询OBJ$、TAB$等表以便获取被DROP TABLESPACE所删除的字典信息时出现ORA-01555错误,说明相关UNDO数据已过期,无法通过闪回查询挽救DROP TABLESPACE相关的字典数据。 尝试使用bbed观察dbf上的字典表,发现OBJ$、TAB$等字典表仅仅残存少量已删除数据,无法通过特殊恢复已删除数据行的手段来恢复字典数据 以上场景信息,由于DROP TABLESPACE后已无法通过闪回查询或bbed特殊手段来恢复对应的数据字典信息,故恢复数据字典来回退drop tablespace操作已不可能。 针对此种场景,在无有效物理或逻辑备份的情况下,使用ORACLE PRM-DUL工具是唯一有效的恢复途径。   注意:针对此类无有效物理备份的场景采用DUL特殊恢复的,并无法保证100%恢复数据。其恢复数据的比例主要取决于数据空间在被ORACLE回收后是否有被重用或覆盖。DROP TABLESPACE操作本身包含一系列的递归操作,即包括递归地DROP该表空间上的所有数据表,在完全DROP该表空间上的所有数据表后才能真正意义上DROP TABLESPACE,则此DROP TABLESPACE持续的时间内其回收的空间可能被重用或覆盖。   由于字典数据已丢失且不可挽回,故在使用ORACLE PRM-DUL时需采用非字典模式(NON-SYSTEM TABLESPACE),即直接扫描已被DROP TABLESPACE的数据文件,扫描这些数据文件的SEGMENT HEADER或 SEGMENT EXTENTS数据。这些原始数据中虽然包含着实际表上的行数据,但并不包含例如表的名字TABLE_NAME或COLUMN_NAME字段名字或字段类型等元数据。故非字典模式下UNLOAD抽取出来的表的表名为OBJ+其DATA_OBJECT_ID的形式 例如OBJ9999,代表此表为DATA_OBJECT_ID=9999的数据表。故非字典模式下的UNLOAD出来的表,需要人工识别其数据具体属于哪个表,或通过其他手段来识别。   采用PRM-DUL的非字典模式 存在2种扫描方式,基于SEGMENT HEADER 表头或 EXTENT 盘区模式。 对于一个表空间无任何数据文件丢失的且确认表头未丢失的场景优先采用SEGMENT HEADER 表头模式。 PRM-DUL在表头模式下正常 SCAN DATABASE ; SCAN TABLES; 操作后扫描发现了超过190张表,通过业务人员识别和之前获取的表对应关系,优先恢复了部分业务表,但在SEGMENT HEADER 表头模式下未找到5张业务核心表。   通过SEGMENT HEADER 表头模式下未找到五张表,说明了这五张表的SEGMENT…