プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：service@parnassusdata.com

  ある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データブロックに指定していると意味している。ではこれらのブロックがどこのオブジェクトに属しているか、探ってみよう： SQL> set linesize 200; SQL> select segment_name, segment_type 2    from dba_extents 3   where relative_fno = 1 4     and (61938 between block_id and block_id + blocks or 5         61944 between block_id and block_id + blocks);   SEGMENT_NAME                                                                      SEGMENT_TYPE --------------------------------------------------------------------------------- ------------------ SMON_SCN_TO_TIME                                                                  CLUSTER 予想したとおり、clusterである。SMON_SCN_TO_TIMEはSMON_SCN_TIMEテーブルのクラスタで、SMON_SCN_TIMEテーブルはデータベースのscnに該当する時間ステップを記録するために存在している。データディクショナリーのsql.bsqファイルを作成するために、それを確認して、構造をより深刻に理解してください: cat $ORACLE_HOME/rdbms/admin/sql.bsq|grep -A 24 "create cluster smon_scn_to_time" create cluster smon_scn_to_time ( thread number                         /* thread, compatibility */ ) / create index smon_scn_to_time_idx on cluster smon_scn_to_time / create table smon_scn_time ( thread number,                         /* thread, compatibility */ time_mp number,                        /* time this recent scn represents */ time_dp date,                          /* time as date, compatibility */ scn_wrp number,                        /* scn.wrp, compatibility */ scn_bas number,                        /* scn.bas, compatibility */ num_mappings number, tim_scn_map raw(1200), scn number default 0,                  /* scn */ orig_thread number default 0           /* for downgrade */ ) cluster smon_scn_to_time (thread) /   create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp) /   create unique index smon_scn_time_scn_idx on smon_scn_time(scn) / 以上のスクリプトでこのクラスタに複数のインディクスが存在していることを確認できる。すべてのオブジェクトを検証してください: SQL> analyze table SMON_SCN_TIME validate structure; Table analyzed.   SQL>analyze table SMON_SCN_TIME validate structure cascade; Table analyzed.   SQL> analyze cluster SMON_SCN_TO_TIME validate structure; Cluster analyzed.   SQL> analyze cluster SMON_SCN_TO_TIME validate structure cascade; analyze cluster SMON_SCN_TO_TIME validate structure cascade * ERROR at line 1: ORA-01499: table/index cross reference failure - see trace file ここで、トラブルがはっきりとした。トラブルはSMON_SCN_TO_TIMEのインディクスsmon_scn_to_time_idxにある。ロジックエラの可能性が高い。幸いに、トラブルが起きたのはインディクスだけで、トラブルの原因をわかれば解決するには容易くなる: SQL> alter index smon_scn_to_time_idx rebuild ;   Index altered.   /* インディクスにトラブルが起きた場合に、ただ再構造するだけで何の役も立たない。再構造するときにアラームログにORA-00600[6711]エラになった !!! */   /* トラブルがあるインディクスを徹底的にdropして、再び構造する必要がある! */   SQL> drop index smon_scn_to_time_idx ;   Index dropped.   SQL> create index smon_scn_to_time_idx on cluster smon_scn_to_time;   Index created.   /* ここで、トラブルを解決した、アラームログにエラが報告していない! * /   /* That's great! * /