2011年4月8日金曜日

[memo] Oracle Linux 6 に Gridをインストールする... (その2) ...も玉砕

Oracle Linux 6に Oracle 11gR2を導入しようとしてハマった話の続き。
前回はこちら。


ASM環境を構築して create databaseしたところまでは出来たのですが、実際にデータをロードして selectしてみたら Corrupt Blockのエラーが多発してしまいました。
この状況はまだクリア出来ておらず、現在進行形です。
以下に状況をまとめていきます。

Oracle Linux 6 (x86_64)
Oracle Database 11.2.0.2

現象としては普通に selectすると alertlogに
  1. Hex dump of (file 5, block 1119186) in trace file  
  2. /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_p004_17683.trc  
  3. Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)  
  4. Bad header found during user buffer read  
  5. Data in bad block:  
  6.  type: 6 format: 2 rdba: 0x015d409a  
  7.  last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04  
  8.  spare1: 0x0 spare2: 0x0 spare3: 0x0  
  9.  consistency value in tail: 0x1bbd0602  
  10.  check value in block header: 0xd126  
  11.  computed block checksum: 0x0  
  12. Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at  
  13. rdba: 0x015113d2 (file 5, block 1119186)  
  14. Read datafile mirror 'DATA_0002' (file 5, block 1119186) found valid data  
のメッセージが延々と続きます。
Corrupt Blockがあったのでミラーから読んだよ、というものです。
ちなみに ASMの冗長性は normalです。

調査開始。

今回の環境では iSCSIで接続しているディスクたちを ASMディスクとして使用しています。
  1. [root@node00 ~]# iscsiadm -m session  
  2. iser: [13] 10.2.0.135:3260,1 iqn.1995-07.com.insight-tec.node15:storage.raid0  
  3. iser: [14] 10.2.0.134:3260,1 iqn.1995-07.com.insight-tec.node14:storage.raid0  
  4. iser: [15] 10.1.0.133:3260,1 iqn.1995-07.com.insight-tec.node13:storage.raid0  
  5. iser: [16] 10.1.0.131:3260,1 iqn.1995-07.com.insight-tec.node11:storage.raid0  
  6. iser: [17] 10.2.0.136:3260,1 iqn.1995-07.com.insight-tec.node16:storage.raid0  
  7. iser: [18] 10.1.0.132:3260,1 iqn.1995-07.com.insight-tec.node12:storage.raid0  
  8.   
  9. [root@node00 ~]# oracleasm listdisks  
  10. VOL1  
  11. VOL2  
  12. VOL3  
  13. VOL4  
  14. VOL5  
  15. VOL6  
※ ここで iscsiadmの結果の一番左に tcpではなく iserと表示されているに気づきました? iSER(iSCSI Extention for RDMA)は、iSCSIのデータ転送を TCPではなく RDMA(Remote DMA)を使うことで高速化する技術です。そのあたりの詳しいことは後日まとめるつもり。

そのディスクたちの状況を調べていきます。

  1. SQL> select GROUP_NUMBER, DISK_NUMBER, MOUNT_STATUS, HEADER_STATUS, STATE, REDUNDANCY, FAILGROUP, PATH from v$asm_disk;  
  2.   
  3. G D MOUNT_S HEADER_STATU STATE    REDUNDA FAILGROUP    PATH  
  4. - - ------- ------------ -------- ------- ------------ ---------------------------  
  5. 1 5 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0005    /dev/oracleasm/disks/VOL6  
  6. 1 4 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0004    /dev/oracleasm/disks/VOL5  
  7. 1 3 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0003    /dev/oracleasm/disks/VOL4  
  8. 1 2 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0002    /dev/oracleasm/disks/VOL3  
  9. 1 1 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0001    /dev/oracleasm/disks/VOL2  
  10. 1 0 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0000    /dev/oracleasm/disks/VOL1  
  11.   
  12. SQL> select DISK_NUMBER, HOT_USED_MB+COLD_USED_MB USED_MB, READS, WRITES, READ_ERRS, WRITE_ERRS from v$asm_disk;  
  13.   
  14. DISK_NUMBER    USED_MB      READS     WRITES  READ_ERRS WRITE_ERRS  
  15. ----------- ---------- ---------- ---------- ---------- ----------  
  16.           5      11035      18319      63000          0          0  
  17.           4      11035      16104      61260          0          0  
  18.           3      11038      15517      64942          0          0  
  19.           2      11038      15802      66461          0          0  
  20.           1      11034      12914      67519          0          0  
  21.           0      11040      16818      66523          0          0   
READ_ERRS, WRITE_ERRS共に 0なので、ASM的なエラーは検知していないよう。
エラー内容もレイヤーとしては ASMではなく datablockのエラーに見えます。

今回報告されたブロックのダンプを取ってみます。
  1. SQL> alter system dump datafile 5 block 1119186;  

それと、トレースに吐き出されているブロックダンプを比較する。

これがトレースに吐き出されていた情報
  1. Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)  
  2. 7F5048652000 0000A206 015D409A 000F1BBD 04020000  [.....@].........]  
  3. 7F5048652010 0000D126 00000001 000122E0 000F0AAF  [&........"......]  
  4. ....  
  5. 7F5048653FF0 74756F62 65687420 65747320 1BBD0602  [bout the ste....]  
  6. Bad header found during user buffer read  
  7. Data in bad block:  
  8.  type: 6 format: 2 rdba: 0x015d409a  
  9.  last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04  
  10.  spare1: 0x0 spare2: 0x0 spare3: 0x0  
  11.  consistency value in tail: 0x1bbd0602  
  12.  check value in block header: 0xd126  
  13.  computed block checksum: 0x0  
  14. Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at rdba: 0x015113d2 (file 5, block 1119186)  

これが自分でダンプした情報
  1. Start dump data blocks tsn: 6 file#:5 minblk 1119186 maxblk 1119186  
  2. Block dump from cache:  
  3. Dump of buffer cache at level 4 for tsn=6, rdba=22090706  
  4. Block dump from disk:  
  5. buffer tsn: 6 rdba: 0x015113d2 (5/1119186)  
  6. scn: 0x0000.000f19dd seq: 0x02 flg: 0x04 tail: 0x19dd0602  
  7. frmt: 0x02 chkval: 0x54c9 type: 0x06=trans data  
  8. Hex dump of block: st=0, typ_found=1  
  9. Dump of memory from 0x00007FF47C991A00 to 0x00007FF47C993A00  
  10. 7FF47C991A00 0000A206 015113D2 000F19DD 04020000  [......Q.........]  
  11. 7FF47C991A10 000054C9 00000001 000122E0 000F0AAE  [.T......."......]  
  12. ....  
  13. 7FF47C9939F0 73202E73 6E656C69 65722074 19DD0602  [s. silent re....]  

データの中身から Consistency value, checksum, 果てには SCNまでまるっきり異なります。当然ですが、エラーが出てからデータの更新はしていません。ミラーから読み込んだデータで上書きされたとしか考えられません。あるいは、コマンドの実行方法を間違えているのか?

今回問題のテーブルに select count(*) をかけるのですが、毎回 Corruptと報告されるブロックアドレスが異なります。ミラーデータから修復されているとしたら、そのうちエラーは出なくなりそうなものですが、何度実行しても同じくらいの数のブロックがエラーと報告されます。

dbverifyかけてみました。

  1. $ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100  
  2. ...  
  3. Total Pages Marked Corrupt   : 6  
  4. ...  
  5. $ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100  
  6. ...  
  7. Total Pages Marked Corrupt   : 13  
  8. ...  

何度やっても Corrupt Blockが消えないし、毎回異なるブロックが報告されるという状況は変わらず。読みながら、ブロックを修復しつつ、他のブロックを壊している ような感じです。

ここで、一応諦めました。

ASMは、OS Versionや Oracle Versionを、非常にセンシティブに選びます。
きっと 11gR2が Oracle Linux 6対応するときは、新しい必須パッチが出るのだと予想。

ここまでの収穫

ASM内部情報についてまとめたサイトを見つけました。
11gR1 から 11gR2で ASMの内部構造がかなり変更されているのがわかります。

ASM Metadata and Internals
投稿者 時刻:
ラベル: , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)