Author: mac

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]     SQL> select file_id,file_name from dba_data_files where tablespace_name=’SYSAUX’; FILE_ID ———- FILE_NAME ——————————————————————————————————————————————– 2 /s01/oradata/FIXIT/datafile/o1_mf_sysaux_85wkhmrk_.dbf SQL> alter database datafile 2 offline; Database altered. 仮にここのdatafile 2、つまりSYSAUXのすべてのデータファイルもなくした。それにどんなバックアップもないから、バックアップでテーブルスペースをリカバリできない。 けどSYSAUXテーブルスペースはデータベースに必要としているシステムテーブルスペースだから、 AWRなど大切なデータと補助データを格納している   SQL> exec dbms_workload_repository.create_snapshot; BEGIN dbms_workload_repository.create_snapshot; END; * ERROR at line 1: ORA-13509: error encountered during updates to a AWR table ORA-00376:…

  プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]     ORA-01578エラはOracleによく現れる物理的なベッドブロックエラ(Corruption)で、10gから完全なバックアップとアーカイブログを持っている場合に、blockrecover/recoverコマンドでそのベッドブロックをオンラインでリカバリできる。その前提はデータブロックを含むトラックがまだ使用可能である。 以下の内容はバックアップなしにORA-01578エラを解決する例である。一部ベッドブロックのデータがなくす。：   SQL> exec  DBMS_STATS.GATHER_DATABASE_STATS; BEGIN DBMS_STATS.GATHER_DATABASE_STATS; END;   * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 4, block # 870212) ORA-01110: data file 4: ‘/s01/oradata/G10R25/datafile/o1_mf_users_7ch7d4nx_.dbf’ ORA-06512: at “SYS.DBMS_STATS”, line 15188 ORA-06512: at “SYS.DBMS_STATS”, line 15530 ORA-06512: at “SYS.DBMS_STATS”, line 15674…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   あるLinuxの10.2.0.4システムで、ログにORA-00600[6711]内部エラが何度も現れた:     Wed Sep  1 21:24:30 2010 Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_smon_5622.trc: ORA-00600: internal error code, arguments: [6711], [4256248], [1], [4256242], [0], [], [], [] Wed Sep  1 21:24:31 2010 Non-fatal internal error happenned while SMON was doing logging scn->time mapping.     MOSに6711内部エラ関するNoteがあったが、そのファイルが6711エラになった。原因を探ってみると、一部のクラスタのデータディクショナリーにエラがあるかも知れない。けど、そのNoteが未だにエラargumentバラメタの意味を教えてくれない。 corruptionに関するエラだから、obj#,file#,block#に関連している；4256248と4256242 二つの数値がData Block Addressに似ているから、dbaとして扱う。それで、1号データファイルの61938ブロックと61944データブロックに指定していると意味している。ではこれらのブロックがどこのオブジェクトに属しているか、探ってみよう：…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   ユーザーがLUNをASM DISKGROUPに追加するときに、あるASM Disk header KFBTYP_DISKHEADが削除されたことに気づき、そのDiskgroupがmountできなくなった。そしてDBAはkfed mergeなどの方法でKFBTYP_DISKHEAD blockをリカバリしたが、まだdiskgroup をmount出来ない。ALERT.logに以下のようなログが現れた：     NOTE: F1X0 found on disk 0 fcn 0.0 NOTE: cache opening disk 1 of grp 1: VOL2 label:VOL2 NOTE: cache opening disk 2 of grp 1: VOL3 label:VOL3 NOTE: cache opening disk 3 of grp 1: VOL4 label:VOL4…

  プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected] kccpb_sanity_check_2カーネル関数kernel functionがコントロールファイルの健康を確保する。そのORA-600[kccpb_sanity_check_2]が一般的にalter database mount段階で起こる； そのORA-600[kccpb_sanity_check_2]が起こる原因はコントロールファイル件controlfileブロックヘッダのseq#番号がコントロールファイルより大きいだから、その関数とコントロールファイルの間にロジックが一致していないと認定している。 そのkccpb_sanity_check_2関数は10gR2から導入された。つまり、9iにはこのようなコントロールファイル健康性検証など存在していない。lost writeとstale readを検出するために、その機能を導入した。     一般的にそのORA-600[kccpb_sanity_check_2]に二つのargumentコードを含んでいる: ARGUMENTS: Arg [a] seq# in control block header. Arg [b] seq# in the control file header. Arg [c] maclean     ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [53672], [53643], [0x000000000], [], [],…

  プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected] ORACLEデータベースを起動するときに、最初に起動するのはインスタンスで、つまり、nomount段階である。後でCONTROL_FILES バラメタで指定したコントロールファイル位置でデータベースMOUNT段階をロードする。次のステップはデータベースを起動する。このステップにはデータファイルとredoログを含んでいる。そして、前回のシャットダウンが乱暴しすぎた場合に、ロールフォワードしてください。実際には（apply redo）とロールバックするときに提出されていないトランザクションを完成する必要がある。 データベースの中止と起動にもいくつの階段に分けられる。まずはデータベースがクロスされて、データベースに変化しない。つまりデータファイルとredo logfileログファイルクロスされて、そしてdismount段階に入る。インスタンスがデータベースとのつながりがなくなる。データベースがunmountされたあとにOracleデータベースがコントロールファイルをクロスする。次のステップはSGAを削除して、バックグラウンドプロセスを中止する。これでインスタンスがクロスされた。 シャットダウンモードにもいろいろある。例えば、normal,immediate,transactionとabort.で、SHUTDOWN ABORTを除いて、データベースはSGAに必要としているデータをデータファイルとredo logfileに書き込む。もしSHUTDOWN ABORTあるいは意外中止が起こったが、SGAが必要としているデータをまだ抽出していない場合に、次データベースを起動するときに、crash recoveryしてください。これはOracleデータベースによって自主的に完成する。 Startup upgrade/migrateあるいは  _system_trig_enabled = FALSEを設定するのは起動する途中でトリガーを禁止する   Startup Slow / Hang   Startup can hang in any of the stages like nomount,mount or open stage. Following are some of the known issues reported so far:   Note 1367724.1 Startup…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   kdBlkCheckErrorはKernel Data Block Check Errorである。db_block_checking!=false が損害を見つけ出したらORA-600 [kddummy_blkchk] / ORA-600 [kdBlkCheckError] エラになる。そして中止される。 kdBlkCheckError/kddummy_blkchkに大量な検証コードを含んでいて、各検証コードにデータブロックもロジック分析に該当している。もしmismatchが存在しているならデータブロックにロジックトラブルが起きていると見なすべし。 例えば検証コード23001はWrong total extent countと意味している。。 もしORA-00600[kdBlkCheckError]が現れたら、一般的に、その原因はORACLEのBUG あるいはメモリーにエラがある。   ORA-00600[kdBlkCheckError]エラに関するは以下の通り：   NB Bug Fixed Description 17447078 12.1.0.2, 12.2.0.0 Diagnostic enhancement for ORA-600 [kdBlkCheckError] .. [18007] errors 14400110 11.2.0.4, 12.2.0.0 Bad redo / ORA-600 [kdBlkCheckError] .. [6135] for opcode 19.1…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   Diskgroupをmountするときに、以下のようなエラが現れた、以下の文を読んでください：   SQL> alter diskgroup DATA mount; alter diskgroup DATA mount * ERROR at line 1: ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk “17” is missing from group number “1” ORA-15042: ASM disk “16” is missing from group number “1” ORA-15042: ASM disk…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   ORA-08103エラの診断は8103エラのERROR STACK TRACEを作成する必要がある。TRACEで8103オブジェクトを引き起こした具体的なOBJとOBJDを記録する・これはcorruptionを含むかもしれないオブジェクトをより容易く探し出せる。けどフォアグラウンドプロセスがORA-08103になるから、バックグラウンドでTRACEファイルを作成しない、これは8103を設定し、ERRORSTACKのEVENTS引き起こす必要がある：   ALTER SYSTEM SET  EVENTS  ‘ 8103 TRACE NAME ERRORSTACK LEVEL 3’; 解決策は： 1. OBJDとDBAで具体的なテーブル名とブロック番号を探し出す できればそのテーブルをanalyze .. validate structureしてください 3. できればそのテーブルを含むtablespaceに対して dbms_space_admin.ASSM_TABLESPACE_VERIFYしてください 4. できればそのテーブルあるいは関するパーティションを移して、このトラブルを避けてみてください 5. できればそのテーブルあるいはパーティションをMSSMテーブルスペースに移して、このトラブルを避けられる execute dbms_space_admin.tablespace_verify(‘&tablespace_name’) oradebug setmypid oradebug tracefile_name   execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS) oradebug setmypid oradebug tracefile_name   [oracle@nas ~]$ oerr ora 8103…

プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   ORA-8103は我々Database Consultant がよく見られるトラブルである。 ORA-8103の 原因は主に二つがある: データブロックのタイプが無効的なものあるいはブロックタイプがOracleが予想したものと違っている。例えばOracleがデータタイプをdata(type=6)と見なしているが実際にはそうじゃない。 データブロックのdata_object_id とデータディクショナリーのdata_object_idがマッチしていない。   ORA-8103トラブルに対して、以下の処置を勧めている： ORA-08103トラブルの診断は8103エラのERROR STACK TRACEを作成して、TRACEで8103を引き起こしたOBJとOBJDを記録する。これはcorruptionがある相手を定義できる。 トラブルはフォアグラウンドプロセスがORA-08103エラになった場合に、バックグラウンドでTRACEファイルを作成しない。それで、人工的に8103を設定して、ERRORSTACKのEVENTSを引き起こす必要がある: ALTER SYSTEM SET EVENTS ‘8103 TRACE NAME ERRORSTACK LEVEL 3’; 解決策は以下の通り： 1. OBJDとDBAで具体的テーブル名とブロック名を探し出す 2. できればそのテーブルをanalyze .. validate structureしてください 3. できればそのテーブルを含むtablespaceに対して dbms_space_admin.ASSM_TABLESPACE_VERIFYしてください 4. できればそのテーブルを関するパーティションに移して、トラブルを避けてみてください 5. できれば。そのテーブルあるいはパーティションをMSSMテーブルスペースに移してトラブルを避けてください execute dbms_space_admin.tablespace_verify(‘&tablespace_name’) oradebug setmypid oradebug tracefile_name execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS) oradebug…