ASM 翻譯系列第三十八彈：ASM資料清理

原作者：Bane Radulovic

譯者：    魏興華

稽核：    魏興華

DBGeeK社群聯合出品

原文連結：http://asmsupportguy.blogspot.sg/2015/12/asm-data-scrubbing.html 

根據維基百科， 資料清理（data scrubbing）的定義是“一種資料糾錯技術，利用後臺任務週期性的掃描記憶體或儲存的錯誤，在檢測到錯誤後利用資料的多餘副本來對資料進行糾正，資料清理可以減少資料錯誤不斷累計的可能性，進而降低由資料錯誤帶來的風險”。

資料清理（disk scrubbing）是Oracle 12C ASM出現的新功能， Oracle ASM 12C官方文件中寫道，“ASM的磁碟清理透過校驗不經常被讀取的資料，提高了可用性和可靠性，對於磁碟組是normal 和 high redundancy冗餘模式的，磁碟清理會檢查資料的邏輯錯誤，在發現後利用映象磁碟進行錯誤的自動修復，同時磁碟清理利用了磁碟組的衝平衡功能來降低IO資源的消耗。”

Setup

首先我們來構造一個實驗，我的環境中有一個normal冗餘的磁碟組DATA，有一點需要在這裡指出來，本環境中的磁碟管理是透過12.1.0.2的ASM filter driver (AFD)來做的。

譯者注：AFD，這是一個可以取代 ASMLIB 和 udev 設定的新功能，並且還增加了 I/O Filter 功能，該功能可以拒絕所有無效的 I/O 請求，最主要的作用是防止意外覆寫 ASM 磁碟的底層盤。

[grid@dbserver]$ sqlplus / as sysasm

SQL*Plus: Release 12.1.0.2.0 Production on Tue Dec 8 14:08:22 2015

...

SQL> select NAME, TYPE, STATE from v$asm_diskgroup_stat;

NAME         TYPE   STATE

------------ ------ -----------

DATA         NORMAL MOUNTED

SQL> select DISK_NUMBER, PATH from v$asm_disk_stat;

DISK_NUMBER PATH

----------- ----------------

        0 AFD:ASMDISK01

        2 AFD:ASMDISK03

        4 AFD:ASMDISK05

        1 AFD:ASMDISK02

        6 AFD:ASMDISK07

        5 AFD:ASMDISK06

        3 AFD:ASMDISK04

7 rows selected.

SQL>

我在這個磁碟組中建立了一些資料檔案：

[grid@dbserver]$ asmcmd ls +DATA/BR/DATAFILE

SYSTEM.261.887497785

USERS.262.8874978313

UNDOTBS1.269.887497831

SYSAUX.270.887497739

T1.305.897911209

T2.306.897911479

T3.307.897911659

Scrubbing a file

我們可以透過ASM的清理功能去對一個磁碟組、一個盤、一個檔案做清理，下面的例子裡，我們演示對一個ASM檔案做清理。

為了清理一個檔案，我們需要連線到ASM例項，然後執行ALTER DISKGROUP SCRUB FILE 命令：

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair power high wait;

...

上面命令中repair關鍵字是可選的，如果沒有輸入repair關鍵字，那麼檢測到資料的錯誤資訊後只會在相關日誌檔案中被報告，而不會被自動修復。

在ASM的alert日誌中，我們可以看到磁碟清理過程中的輸出資訊，一旦清理清理完成，ASM日誌中也會有相關資訊輸出：

Tue Dec 08 11:55:56 2015

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair power high wait

Tue Dec 08 11:55:56 2015

NOTE: Waiting for scrubbing to finish

Tue Dec 08 11:56:43 2015

NOTE: Scrubbing finished

Tue Dec 08 11:56:43 2015

SUCCESS: alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair power high wait

因為在我的環境中沒有資料毀壞，因此在ASM的alert檔案中，沒有任何錯誤被檢測到。

當ASM資料清理在執行過程中，可以看到有2個ASM程式在做實際的工作。

[grid@dbserver]$ ps -ef | grep asm_sc

grid     17902     1  0 11:27 ?        00:00:00 asm_scrb_+ASM

grid     24365     1  0 11:49 ?        00:00:01 asm_scc0_+ASM

...

• SCRB-ASM做磁碟清理的master程式，主要負責協調磁碟的清理操作

• SCCn-ASM做磁碟清理的slave程式，用來執行檢查操作，可能的程式有SCC0-SCC9。

• SCRn-ASM做磁碟清理的slave程式，主要用來對有錯誤的資料進行修復，可能的程式有SCR0-SCR9。

• SCVn-ASM做磁碟清理的slave程式，主要用來執行確認操作，可能的程式有SCV0-SCV9。

Corrupted block found

我們下面來舉一個具體的例子來，透過毀壞資料檔案的一個資料塊-假如是block 200，然後透過磁碟清理操作來觀察ASM資料清理的檢測、修復效果。首先透過指令碼find_block.pl來定位到block 200在ASM磁碟上的2個copy。

譯者注：find_block.pl指令碼的相關內容請參照ASM系列的Find block in ASM篇獲取詳細資訊

[grid@dbserver ]$ $ORACLE_HOME/perl/bin/perl find_block.pl +DATA/BR/DATAFILE/t3.307.897911659 200

dd if=/dev/sdo1 bs=8192 count=1 skip=1460552 of=block_200.dd

dd if=/dev/sdd1 bs=8192 count=1 skip=1462088 of=block_200.dd

然後我使用dd命令抽取這兩個block。

[root@dbserver]# dd if=/dev/sdo1 bs=8192 count=1 skip=1460552 of=block_200_primary.dd

[root@dbserver]# dd if=/dev/sdd1 bs=8192 count=1 skip=1462088 of=block_200_mirror.dd

將這兩個塊寫入到文字檔案後，使用作業系統的diff命令來校驗一下這兩個copy是否是一樣的。

[root@dbserver]# diff block_200_primary.dd block_200_mirror.dd

[root@dbserver]#

如預期，由於沒有資料毀壞，目前兩個塊的內容是完全一樣的。

現在我們把塊的一個副本毀壞，由於使用了ASM filter driver，在做毀壞操作的時候會有些麻煩，需要關閉ASM，解除安裝ASM filter driver，才能使用作業系統dd命令往ASM磁碟中寫入命令：

首先建立一個文字檔案，作為毀壞源：

[root@dbserver]# od -c block_200_mirror.dd > block_200_corrupt.txt

接著關閉資料庫和ASM例項，解除安裝掉ASM filter driver，否則dd操作將不能執行。

[root@dbserver]# modprobe -r oracleafd

[root@dbserver]# lsmod | grep oracle

oracleacfs           3308260  0

oracleadvm            508030  0

oracleoks             506741  2 oracleacfs,oracleadvm

然後毀壞掉block 200的映象copy。

[root@dbserver]# dd if=block_200_corrupt.txt of=/dev/sdd1 bs=8192 count=1 seek=1462088

1+0 records in

1+0 records out

8192 bytes (8.2 kB) copied, 0.00160027 s, 5.1 MB/s

讀取上面步驟中寫回的內容，透過作業系統diff命令確認兩個塊的內容是否有差異：

[root@dbserver]# dd if=/dev/sdd1 bs=8192 count=1 skip=1462088 of=block_200_corr.dd

1+0 records in

1+0 records out

8192 bytes (8.2 kB) copied, 0.00152298 s, 5.4 MB/s

 

[root@dbserver]# diff block_200_primary.dd  block_200_corr.dd

Binary files block_200_primary.dd and block_200_corr.dd differ

[root@dbserver]#

如上面的輸出，現在兩個塊的內容出現了不一樣。

Scrub a file

下面到了本節的重點內容，我們重新載入ASM filter driver模組。

[root@dbserver]# insmod /lib/modules/.../oracleafd.ko

重啟ASM例項，開始對上面測試用到的資料檔案進行清理：

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' wait;

...

觀察ASM的alert 日誌，資料清理過程中發現了毀壞的資料塊：

Tue Dec 08 13:25:48 2015

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' wait

Starting background process SCRB

Tue Dec 08 13:25:48 2015

SCRB started with pid=25, OS id=4585

Tue Dec 08 13:25:48 2015

NOTE: Waiting for scrubbing to finish

Tue Dec 08 13:25:49 2015

NOTE: Corrupted block 200 found in file +DATA/BR/DATAFILE/t3.307.897911659

Tue Dec 08 13:25:50 2015

NOTE: Corrupted block 200 found in file +DATA/BR/DATAFILE/t3.307.897911659

Tue Dec 08 13:26:39 2015

NOTE: Scrubbing finished

Tue Dec 08 13:26:39 2015

SUCCESS: alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' wait

後臺程式的dump檔案目錄中也發現新產生了一些trace檔案：

[grid@dbserver]$ ls -lrt | tail

-rw-r-----. 1 grid oinstall  36887 Dec  8 13:25 +ASM_scc0_4587.trc

-rw-r-----. 1 grid oinstall  36967 Dec  8 13:25 +ASM_scv0_4592.trc

-rw-r-----. 1 grid oinstall   5088 Dec  8 13:25 +ASM_gmon_16705.trc

-rw-r-----. 1 grid oinstall  36965 Dec  8 13:25 +ASM_scv1_4599.trc

-rw-r-----. 1 grid oinstall 551218 Dec  8 13:26 alert_+ASM.log

如果我們更進一步檢視SCC0程式的trace檔案，會看到清理操作輸出的詳細報告：

[grid@dbserver]$ more ./+ASM_scc0_4587.trc

Trace file /u01/app/grid/diag/asm/+asm/+ASM/trace/+ASM_scc0_4587.trc

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

...

HARD VIOLATION(S) DETECTED!

CORRUPTED BLOCK INFORMATION:

memory address: 0x7f13531fb000

block size: 8192

block number: 200 [0xc8]

block offset in this write request of 1 block(s): 0

file type: datafile (type value: 2)

...

HARD check failed at block 200

還可以透過grep相關關鍵字快速的獲取報告中重要關注的內容：

[grid@dbserver]$ egrep -i "corrupted|block number|failed" *sc*trc

+ASM_scc0_4587.trc:CORRUPTED BLOCK INFORMATION:

+ASM_scc0_4587.trc:  block number: 200 [0xc8]

+ASM_scc0_4587.trc:  Magic number  Block size  Block number  Checksum  Head-tail match

+ASM_scc0_4587.trc:FAILED CHECK(S):

+ASM_scc0_4587.trc:  MAGIC NUMBER CHECK FAILED

+ASM_scc0_4587.trc:  BLOCK SIZE CHECK FAILED

+ASM_scc0_4587.trc:  BLOCK NUMBER CHECK FAILED

+ASM_scc0_4587.trc:  HEAD-TAIL MATCH CHECK FAILED

+ASM_scc0_4587.trc:HARD check failed at block 200

+ASM_scv0_4592.trc:CORRUPTED BLOCK INFORMATION:

+ASM_scv0_4592.trc:  block number: 200 [0xc8]

+ASM_scv0_4592.trc:  Magic number  Block size  Block number  Checksum  Head-tail match

+ASM_scv0_4592.trc:FAILED CHECK(S):

+ASM_scv0_4592.trc:  MAGIC NUMBER CHECK FAILED

+ASM_scv0_4592.trc:  BLOCK SIZE CHECK FAILED

+ASM_scv0_4592.trc:  BLOCK NUMBER CHECK FAILED

+ASM_scv0_4592.trc:  HEAD-TAIL MATCH CHECK FAILED

+ASM_scv0_4592.trc:HARD check failed at block 200

+ASM_scv0_4592.trc:NOTE: Corrupted block 200 found in file +DATA/BR/DATAFILE/t3.307.897911659

+ASM_scv1_4599.trc:CORRUPTED BLOCK INFORMATION:

+ASM_scv1_4599.trc:  block number: 200 [0xc8]

+ASM_scv1_4599.trc:  Magic number  Block size  Block number  Checksum  Head-tail match

+ASM_scv1_4599.trc:FAILED CHECK(S):

+ASM_scv1_4599.trc:  MAGIC NUMBER CHECK FAILED

+ASM_scv1_4599.trc:  BLOCK SIZE CHECK FAILED

+ASM_scv1_4599.trc:  BLOCK NUMBER CHECK FAILED

+ASM_scv1_4599.trc:  HEAD-TAIL MATCH CHECK FAILED

+ASM_scv1_4599.trc:HARD check failed at block 200

+ASM_scv1_4599.trc:NOTE: Corrupted block 200 found in file +DATA/BR/DATAFILE/t3.307.897911659

[grid@dbserver]$

Fix the corruption

上面的操作沒有新增repair關鍵字，因此毀壞並沒有被自動修復，只是在相關跟蹤日誌中輸出了清理操作發現到的壞塊，這次我們在命令中增加repaire關鍵字，利用資料清理對檔案進行自動修復：

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair wait;

...

Tue Dec 08 13:35:02 2015

SQL> alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair wait

Tue Dec 08 13:35:02 2015

NOTE: Waiting for scrubbing to finish

Tue Dec 08 13:35:03 2015

NOTE: Corrupted block 200 found in file +DATA/BR/DATAFILE/t3.307.897911659

Tue Dec 08 13:35:04 2015

NOTE: Scrubbing block 200 in file 307.897911659 in slave

NOTE: Successfully scrubbed block 200 in file 307.897911659

Tue Dec 08 13:35:53 2015

NOTE: Scrubbing finished

Tue Dec 08 13:35:53 2015

SUCCESS: alter diskgroup DATA scrub file '+DATA/BR/DATAFILE/t3.307.897911659' repair wait

根據日誌輸出，清理操作順利的完成了，同樣我們再次透過對比兩個塊的內容來校驗是否資料得到了修復。

[root@dbserver ~]# dd if=/dev/sdd1 bs=8192 count=1 skip=1462088 of=block_200_after_scrub_repair.dd

1+0 records in

1+0 records out

8192 bytes (8.2 kB) copied, 0.000856456 s, 9.6 MB/s

[root@dbserver]# diff block_200_primary.dd block_200_after_scrub_repair.dd

[root@dbserver]#

完美！資料塊被成功的修復了。

Conclusion

ASM資料清理可以檢測和自動修復有介質或邏輯損壞的資料塊，它也可以糾正由於外部因素導致的壞塊,比如我們上面例子裡的，由非Oracle程式寫入導致的損壞。