Oracle Linux 6に Oracle 11gR2を導入しようとしてハマった話の続き。
前回はこちら。
ASM環境を構築して create databaseしたところまでは出来たのですが、実際にデータをロードして selectしてみたら Corrupt Blockのエラーが多発してしまいました。
この状況はまだクリア出来ておらず、現在進行形です。
以下に状況をまとめていきます。
Oracle Linux 6 (x86_64)
Oracle Database 11.2.0.2
現象としては普通に selectすると alertlogに
Hex dump of (file 5, block 1119186) in trace file
/home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_p004_17683.trc
Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)
Bad header found during user buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x015d409a
last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x1bbd0602
check value in block header: 0xd126
computed block checksum: 0x0
Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at
rdba: 0x015113d2 (file 5, block 1119186)
Read datafile mirror 'DATA_0002' (file 5, block 1119186) found valid data
のメッセージが延々と続きます。
Corrupt Blockがあったのでミラーから読んだよ、というものです。
ちなみに ASMの冗長性は normalです。
調査開始。
今回の環境では iSCSIで接続しているディスクたちを ASMディスクとして使用しています。
[root@node00 ~]# iscsiadm -m session
iser: [13] 10.2.0.135:3260,1 iqn.1995-07.com.insight-tec.node15:storage.raid0
iser: [14] 10.2.0.134:3260,1 iqn.1995-07.com.insight-tec.node14:storage.raid0
iser: [15] 10.1.0.133:3260,1 iqn.1995-07.com.insight-tec.node13:storage.raid0
iser: [16] 10.1.0.131:3260,1 iqn.1995-07.com.insight-tec.node11:storage.raid0
iser: [17] 10.2.0.136:3260,1 iqn.1995-07.com.insight-tec.node16:storage.raid0
iser: [18] 10.1.0.132:3260,1 iqn.1995-07.com.insight-tec.node12:storage.raid0
[root@node00 ~]# oracleasm listdisks
VOL1
VOL2
VOL3
VOL4
VOL5
VOL6
※ ここで iscsiadmの結果の一番左に tcpではなく iserと表示されているに気づきました? iSER(iSCSI Extention for RDMA)は、iSCSIのデータ転送を TCPではなく RDMA(Remote DMA)を使うことで高速化する技術です。そのあたりの詳しいことは後日まとめるつもり。
そのディスクたちの状況を調べていきます。
SQL> select GROUP_NUMBER, DISK_NUMBER, MOUNT_STATUS, HEADER_STATUS, STATE, REDUNDANCY, FAILGROUP, PATH from v$asm_disk;
G D MOUNT_S HEADER_STATU STATE REDUNDA FAILGROUP PATH
- - ------- ------------ -------- ------- ------------ ---------------------------
1 5 CACHED MEMBER NORMAL UNKNOWN DATA_0005 /dev/oracleasm/disks/VOL6
1 4 CACHED MEMBER NORMAL UNKNOWN DATA_0004 /dev/oracleasm/disks/VOL5
1 3 CACHED MEMBER NORMAL UNKNOWN DATA_0003 /dev/oracleasm/disks/VOL4
1 2 CACHED MEMBER NORMAL UNKNOWN DATA_0002 /dev/oracleasm/disks/VOL3
1 1 CACHED MEMBER NORMAL UNKNOWN DATA_0001 /dev/oracleasm/disks/VOL2
1 0 CACHED MEMBER NORMAL UNKNOWN DATA_0000 /dev/oracleasm/disks/VOL1
SQL> select DISK_NUMBER, HOT_USED_MB+COLD_USED_MB USED_MB, READS, WRITES, READ_ERRS, WRITE_ERRS from v$asm_disk;
DISK_NUMBER USED_MB READS WRITES READ_ERRS WRITE_ERRS
----------- ---------- ---------- ---------- ---------- ----------
5 11035 18319 63000 0 0
4 11035 16104 61260 0 0
3 11038 15517 64942 0 0
2 11038 15802 66461 0 0
1 11034 12914 67519 0 0
0 11040 16818 66523 0 0 READ_ERRS, WRITE_ERRS共に 0なので、ASM的なエラーは検知していないよう。
エラー内容もレイヤーとしては ASMではなく datablockのエラーに見えます。
今回報告されたブロックのダンプを取ってみます。
SQL> alter system dump datafile 5 block 1119186;
それと、トレースに吐き出されているブロックダンプを比較する。
これがトレースに吐き出されていた情報
Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)
7F5048652000 0000A206 015D409A 000F1BBD 04020000 [.....@].........]
7F5048652010 0000D126 00000001 000122E0 000F0AAF [&........"......]
....
7F5048653FF0 74756F62 65687420 65747320 1BBD0602 [bout the ste....]
Bad header found during user buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x015d409a
last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x1bbd0602
check value in block header: 0xd126
computed block checksum: 0x0
Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at rdba: 0x015113d2 (file 5, block 1119186)
これが自分でダンプした情報
Start dump data blocks tsn: 6 file#:5 minblk 1119186 maxblk 1119186
Block dump from cache:
Dump of buffer cache at level 4 for tsn=6, rdba=22090706
Block dump from disk:
buffer tsn: 6 rdba: 0x015113d2 (5/1119186)
scn: 0x0000.000f19dd seq: 0x02 flg: 0x04 tail: 0x19dd0602
frmt: 0x02 chkval: 0x54c9 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FF47C991A00 to 0x00007FF47C993A00
7FF47C991A00 0000A206 015113D2 000F19DD 04020000 [......Q.........]
7FF47C991A10 000054C9 00000001 000122E0 000F0AAE [.T......."......]
....
7FF47C9939F0 73202E73 6E656C69 65722074 19DD0602 [s. silent re....]
データの中身から Consistency value, checksum, 果てには SCNまでまるっきり異なります。当然ですが、エラーが出てからデータの更新はしていません。ミラーから読み込んだデータで上書きされたとしか考えられません。あるいは、コマンドの実行方法を間違えているのか?
今回問題のテーブルに select count(*) をかけるのですが、毎回 Corruptと報告されるブロックアドレスが異なります。ミラーデータから修復されているとしたら、そのうちエラーは出なくなりそうなものですが、何度実行しても同じくらいの数のブロックがエラーと報告されます。
dbverifyかけてみました。
$ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100
...
Total Pages Marked Corrupt : 6
...
$ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100
...
Total Pages Marked Corrupt : 13
...
何度やっても Corrupt Blockが消えないし、毎回異なるブロックが報告されるという状況は変わらず。読みながら、ブロックを修復しつつ、他のブロックを壊している ような感じです。
ここで、一応諦めました。
ASMは、OS Versionや Oracle Versionを、非常にセンシティブに選びます。
きっと 11gR2が Oracle Linux 6対応するときは、新しい必須パッチが出るのだと予想。
ここまでの収穫
ASM内部情報についてまとめたサイトを見つけました。
11gR1 から 11gR2で ASMの内部構造がかなり変更されているのがわかります。
ASM Metadata and Internals
