?DBA對現代硬件的了解總是不足夠的，雖然說有時候不了解這些東西，也不影響我們搞數據庫運維。不過多了解一些這方面的知識總是好的。7、8年前我們剛剛開始使用SSD的時候遇到過4K扇區的問題，SSD盤分區的時候沒有對齊性能會有影響。甚至弄得不好，存儲在SSD盤上的Oracle Redo Log還會給你弄出點性能問題。

在一個朋友提出了一個Oracle 問題之前，我一直沒有關注過目前普通機械盤是否也存在4K扇區的問題。直到前幾天，一個朋友發了一個補丁，問512e是個啥意思。

這是一個Oracle 19C的BUG，在運行于RHEL/CENTOS 8的19.3的Oracle上，如果使用了ASMLIB，并且ASM磁盤組的磁盤包含512e的磁盤，則查詢v$asm_disk的時候會出現CORE DUMP。而如果往這個磁盤組中添加磁盤的時候，甚至會導致整個磁盤組損壞。問題夠嚇人。

512e這個概念在數年前搞SSD盤的時候就大致了解過，學名叫512字節扇區仿真訪問模式。在一些不支持原生態4K扇區的場景下，通過512字節的邏輯扇區來訪問4K物理扇區的SSD設備也是以前經常用的方法。而這個BUG出現在HDD上，難道現在HDD也開始使用4K扇區了嗎？于是我馬上谷歌了一下，發現一種稱為Advanced Format Hard Disk的磁盤技術在十多年前就已經開始出現了，而2014年后，大部分的硬盤企業都推出了企業級的AF硬盤。

關于4K扇區磁盤的好處，我在這里簡單的講一下，首先磁盤越來越大，4K盤可以在使用相同的尋址空間上獲得更大的存儲空間，另外一點，因為元數據的減少，也提高了磁盤容量的實際使用率，從硬盤廠商發布的數據看，使用4K扇區后，磁盤空間可用量多了7%以上。而從他們發布的性能數據上看，對于順序讀，順序寫的性能，采用4K扇區后都是有所提升的，隨機讀的性能略高（不知道這種略高是不是磁盤技術帶來的，從轉速和讀取的性能上實際上是沒有什么提升的），隨機寫的性能略有下降，不過幾乎可以忽略。磁盤場廠商的數據告訴你，方向使用4K HDD吧，性能是沒問題的。我咨詢了一些國內的一些這方面的朋友，他們告訴我性能差異可以接受如果對齊邊界，看不出明顯的差別。不過不同的場景下，這些指標可能會有不同。只不過無論我們接受不接受，今后4K扇區的Advanced Format HDD肯定是標配了。

上面這個磁盤上面的紅框中的LOGO就是4KN磁盤的標識。如果我們仔細查看一下自己手頭的硬盤，應該可以發現存在這樣的標識：

我們可以看到上面有兩種LOGO，一種是512e的，另外一種是4Kn的，這是兩種新的磁盤扇區訪問的模式。AF是指本磁盤是4K一個扇區的，不過支持512邏輯扇區訪問模式，操作系統可以把我當成512字節扇區的磁盤來訪問。4Kn是指磁盤本身是4K扇區的，并且支持OS以4K本地訪問的模式來訪問這個磁盤。再加上原來的物理扇區就是512字節的磁盤，其訪問模式稱為512n，這三種磁盤訪問模式就是我們日常能夠遇到的HDD的訪問模式。

于是我們的HDD世界中存在兩種扇區規格，512和4K。為了向前兼容，4K扇區的磁盤也搞了一個512e的仿真訪問模式，使原來的應用可以不做修改就能夠訪問4K扇區的磁盤。于是磁盤訪問模式出現了3種：1）512n，其物理扇區和邏輯扇區都是512字節的，這是以前的傳統訪問模式；2）512e，其磁盤的物理扇區是4K的，不過為了兼容原有的系統，在分區的時候選擇了512邏輯扇區大小；3）4Kn，其物理扇區與邏輯扇區都是4K的，系統采用原生4K的方式去訪問這些磁盤。

Linux從RHEL/CENTOS 6開始支持原生的4Kn，之前都是通過512e的硬盤格式仿真訪問。如果你采用4Kn的硬盤格式，那么是不需要考慮任何分區對齊之類的問題的。而如果你使用512e的方式，那么就必須認真考慮對齊的問題了。因為如果分區不做4K對齊，那么原本一個IO可以搞定的問題，就可能因為邊界問題而要使用2個IO了，IO數量翻了一倍，對磁盤的壓力也大了，IO延時也會增加。這對于數據庫系統來說是十分不好的事情。

對于數據庫來說，理解這些差異也是有用的。MySQL、PostgreSQL等數據庫都是把數據放在文件系統上，IO也都是向Linux的文件系統發起，這些磁盤格式之間的差異被文件系統給屏蔽了，因此我們平時也不需要太關注這些。而如果你使用Oracle則有些不同了。

Oracle從11.2.0.3開始全面支持4K扇區磁盤，支持4Kn。Oracle的ASM是自己對IO進行優化的，為了達到極致，Oracle在Linux內核中增加了一個ASMLIB模塊，用于和裸設備打交道。在普通情況下，Oracle通過512e的發格式訪問磁盤扇區的數據，而在使用了ASMLIB的方式下，可以使用4Kn的模式訪問磁盤，從而獲得最佳的性能。

在創建磁盤組的時候，Oracle ASM的接口會自動獲得邏輯扇區/物理扇區的大小，如果發現某個磁盤組內有不同的邏輯磁盤/物理磁盤大小的時候，就會報錯。如果運氣不好，遇到了本文開頭提到的那個BUG，這時候還可能會引起DISKGROUP的故障（一般情況下不會，如果ASM實例設置了不理會邏輯扇區大小的參數_disk_sector_size_override，則大概率會出現此問題）。

在Oracle中使用4K扇區的磁盤，一定要注意幾個方面：1）表空間的BLOCKSIZE不要低于4K,否則會面臨性能問題，還好我們的絕大多數數據庫都是用默認的8K BLOCKSZIE，不過某些超高并發，存在嚴重熱塊爭用的系統往往會使用較小的BLOCKSIZE，也有一些客戶為了避免熱塊沖突，把索引存放在2K BLOCKSIZE的表空間中；2）REDO LOG盡可能使用4Kn的磁盤格式，并且將REDO BLOCK大小設置為4K，而不是使用默認的512；3）創建磁盤組或者向磁盤組中加入新盤的時候，一定要檢查物理扇區和邏輯扇區的大小，從而避免不兼容問題的出現。

最后要說的是，針對4Kn還是512e/512n模式，這是一個全鏈路問題。從磁盤到操作系統的任何一個環節上出現不一致的配置，或者不兼容的硬件，都會影響到我們最終獲得的設備的屬性。我在網上看到過一個案例。在同一臺存儲上分配的兩個LUN，在操作系統層面看到的山區格式不同。

這種情況會導致創建ASM DISKGROUP的時候報錯，在操作系統上檢查了很久也沒有發現問題，最終在存儲上找到了原因。

在創建LUN的時候，同一個管理員在兩個不同時間里創建的兩個LUN使用了不同的BLOCK SIZE。存儲管理員是不管這些的，他們也不知道這個參數還會引發Oracle的問題。

硬件發展雖然沒有我們想象的那么快，只不過DBA的硬件知識更新的太慢了。以至于現代硬件數年前就已經研究的很清楚的問題，我們今天才去關注。如果不是那個Oracle的BUG，我可能還停留在HDD 512扇區的慣性里。這種知識的學習，什么時候是個頭啊，選擇DBA這個職業，真的得保持一顆學習的心。