【轉載】AIX LVM LVCB 和 Oracle 4k Offset的思考

​

AIX LVM LVCB 和 Oracle 4k Offset的思考

引言

     前段時間看了​​piner​​，Fenng和老農關于AIX LVCB對于oracle影響的讨論，感覺有收獲，是以總結了大家的看法和自己的心得。​

       歡迎大家的讨論。

    一般情況下，AIX的每一個邏輯卷前512位元組被稱為logical-volume control block (LVCB)，包含了LV的一些資訊。在 Oracle 9iR2 之前，為了避免和LVCB的沖突，Oracle 軟體會跳過前4k位元組不用。LVCB的和Oracle跳過4K的特點帶來的問題：

    如果一個VG中包含多個PV，PV做了條帶化（stripe），建立的LV跨在不同的PV上，這樣會導緻下面的問題，例如：如果stripe是32K，db_block是8K，如果沒有offset，則4個db_block就全在一個stripe裡了，不會跨PV。而有了4K的offset，則肯定第四個db_block就跨stripe了，也就成了一個Oracle DB block跨在多個LUN/PV上了，如下圖（例子來自于老農的文章）：

     當系統崩潰的時候，很有可能造成大量的 IO 不完整（如果OS寫了一個PV上的半block之後，來不及寫下一個PV上的半個block，如果是在同一個PV則可以保證一個block同時被更新），啟動 Oracle 的時候将會看到 ORA-01578：“ORACLE data block corrupted (file # %s, block # %s)”錯誤，大量的corrupted block對于資料可能是緻命的。

AIX解決方法

      AIX在Oracle 9iR2以後，引進了一種新的LV類型，也就是“Z”類型LV，這種類型的LV通過lslv lv_name或者lslv -L lv_name可以看到它的類型為：DS_LV。例如：

    # lslv -L lv_test_2g_001

    DEVICESUBTYPE :DS_LVZ

      或者，Oracle的dbfsize也可以檢查

    $ dbfsize /dev/rlv_test_2g_001

    Database file: /dev/rlv_test_2g_001

    Database file type: raw devicewithout 4K starting offset

    Database file size: 261248 8192 byte blocks

      如以上的結果，則顯示這個LV是沒有4k頭部的”Z”類型的LV，如果是普通類型的lv，LV類型是DS_LV，這種類型的LV，在lslv的指令中沒有任何SUBTYPE類型說明。這樣的LV需要特定的VG才能支援，因為它沒有LVCB了（其實LVCB的資訊都儲存到了VGDA中），那麼，LV肯定就要靠VGDA來管理了。

      Big VG的一個bug，就是使用-T O，建立成功的DS_LVZ類型的LV，在經過chlv或者是其它lvm指令，如varyoff/varyon之後，這個标志會消失。這個情況是比較可怕的，如你采用新建立的lv建立了資料檔案，但是，後來，因為HA切換或者其它原因varyoff/varyon了這個VG，甚至exportvg/importvg了這個VG，新的LV在資料庫看來，不是DS_LVZ類型的LV，資料庫将試圖跳過4k的偏移，但是偏移其實是不存在的。具體解決方案就是，請使用scalable類型的VG或者是打以上的更新檔：

Problem is caused by defect IY94343 in AIX Operating System.​

      影響的使用者：

Users of BIG volume groups with the bos.rte.lvm fileset at the 5.3.0.53 or 5.3.0.54 level.

     在AIX作業系統環境下Veritas VM 相容AIX Logical Volume Manager (LVM), Oracle同樣跳過4k。Veritas VM同樣使用一種新的LV類型（devsubtype：DS_VMZ）。

Oracle相關支援的資訊：

      Oracle is enhancing both 9iR2 and 10g to recognize this new type of Volume Manager volume. A patch from Oracle will be available soon that needs to be applied to 9.2.0.5 and 10.1. The reference bug number for this Oracle patch is 3712203.

AIX OS相關支援的資訊

    This ODM patch recognizes DS_VMZ type RAW Volume Manager volumes. Without this patch, when ODM is enabled, the Oracle instance will fail with error "ORA-01251: Unknown File Header Version read".​

      AIX 5.3 VG的類型包括：普通的VG，Big VG，Scalable VG。

     mkvg建立普通的VG，預設最大32 PV/1016個PP；

     mkvg –B建立Big VG，預設128PV/1016 PP；

     可以使用mkvg -t選擇其它PP數目，對于Big VG，mkvg -t 2表示支援64PV/2032PP，具體見下圖：

     通過mkvg -S可以建立Scalable-type VG。預設1024PV/256LV/32768PP。

      對于普通的VG，建立的都是普通的DS_LV類型的LV

      對于Big VG，是唯一允許同時存在這兩種LV類型(DS_LVZ類型沒有4k頭部的LV, 普通DS_LV類型的lv)的VG，如果指定-T O，則建立DS_LVZ類型的LV，否則，建立普通類型的LV，例如：#mklv -y’lv_test’ -t’raw’ -T O testvg 8 hdisk3

      對于Scalable-type VG類型的VG，建立的都是擴充的DS_LVZ類型的LV

1．出問題的前提：用了AIX裸裝置做datafile，且做了stripe，且LV不是DS_LVZ類型。

2．建議使用Scalable VG（Scalable VG在5.2沒有）

3．如果Oracle軟體寫資料的偏移大小是oracle block大小的倍數，就不會出現上面的問題（例如：偏移4k,oracle block size 4k就沒有問題；如果偏移可以設定例如8k, Oracle bock size 8k/4k，也不會有問題）

4．另一個問題：如果一個LV跨越在多個PV上，不論是否做了stripe，就可能有類似的問題，因為PP的大小肯定也是一個整數，如128M，那麼(128M-4k)/8K還是除不盡的（來自piner的文章）。我個人認為：這個是需要考慮的問題，但是遠沒有stripe帶來的影響大。Stripe的情況下會出現大量的DB Block位于不同的PV， 這樣系統崩潰會出現大量block corrupted。 如果僅僅是因為某個LV 跨越在多個PV上的問題，這樣的影響就小多了，前提是：系統crash的時候正在寫LV最後的那個block，而且僅僅一個block的損壞，對oracle資料庫還不一定是緻命的。

LVCB包含的一些LV資訊，例如：lvid，lvname，lvname，machine id，擷取LVCB資訊的指令

# getlvcb -TA datalv

         AIX LVCB

         intrapolicy = m

         copies = 1

         interpolicy = m

         lvid = 000ce0e40000d6000000010f0b787726.3

         lvname = datalv

         label = /data

         machine id = CE0E4D600

         number lps = 1600

         relocatable = y

         strict = y

         stripe width = 0

         stripe size in exponent = 0

         type = jfs2

         upperbound = 32

         fs = vfs=jfs2:log=/dev/loglv00:options=rw:account=false

         time created  = Fri Nov 24 14:17:35 2006

         time modified = Fri Nov 24 14:18:15 2006