DBA对现代硬件的理解总是不足的。虽然有时候我们不了解这些东西，但是并不影响我们的数据库运维。但多了解一下总是好的。7、8年前，我们刚开始使用SSD时，遇到了4K扇区的问题。SSD磁盘分区时不对齐会影响性能。即使做得不好，存储在SSD盘上的OracleRedoLog也会给你带来一些性能问题。之前有朋友提一个oracle的问题，我一直没关注过普通机械盘有没有4K扇区。直到前几天有朋友发补丁问512e是什么意思。这是Oracle19C的一个BUG。在RHEL/CENTOS8上运行的Oracle19.3，如果使用ASMLIB，ASM磁盘组中的磁盘包含512e磁盘，查询v$asm_disk时会出现COREDUMP。而如果在这个磁盘组中增加一个磁盘，甚至会导致整个磁盘组损坏。问题够吓人的。512e的概念在几年前做SSD盘的时候就已经大致了解过了。学名是512字节扇区仿真访问模式。在一些不支持原生4K扇区的场景下，通过512字节的逻辑扇区访问4K物理扇区的SSD设备也是一种常用的方法。而且这个BUG出现在HDD上，难道HDD现在也开始使用4K扇区了吗？于是马上google了一下，发现十几年前就开始出现一种叫做AdvancedFormatHardDisk的磁盘技术，而2014年以后，大部分硬盘公司都推出了企业级AF硬盘。关于4K扇区盘的好处，这里简单说一下。首先，磁盘越来越大。4K磁盘可以使用相同的寻址空间获得更大的存储空间。还有一点，因为元数据的减少，也提高了磁盘容量的实际利用率。根据硬盘厂商公布的数据，使用4K扇区后，可用磁盘空间增加7%以上。从他们公布的性能数据来看，使用4K扇区后，顺序读和顺序写的性能都有所提升，随机读的性能略高（不知道这种略高的性能是不是磁盘技术造成的。是的，速度和读取性能其实并没有什么提升），随机写入性能略有下降，但几乎可以忽略不计。diskfarm厂商的数据告诉你，方向应该用4KHDD，性能没问题。我咨询了国内的一些朋友，他们告诉我，边界对齐的话，性能差异是可以接受的，没有明显的差异。但是，在不同的场景下，这些指标可能会有所不同。只是不管我们接受与否，4K扇区的高级格式化硬盘在未来肯定是标配的。上盘上方红框内的LOGO是4KN盘的标识。如果我们仔细观察手头的硬盘，应该能发现这样一个标识：我们可以看到上面有两种LOGO，一种是512e，一种是4Kn，这是两块新盘sectors访问模式。AF表示磁盘为4K扇区，但支持512逻辑扇区访问方式，操作系统可以将其作为512字节扇区磁盘访问。4Kn表示磁盘本身有4K扇区，支持OS以4K本地访问方式访问磁盘。另外，原来的物理扇区是一个512字节的磁盘，其存取方式称为512n。这三种磁盘访问方式就是我们每天都会遇到的硬盘访问方式。所以在我们的HDD世界中有两个扇区规格，512和4K。为了向后兼容，4K扇区磁盘也实现了512e仿真访问方式，这样原应用程序就可以访问4K扇区磁盘而无需修改。于是就有了三种磁盘访问方式：1）512n，它的物理扇区和逻辑扇区都是512字节，这是以前传统的访问方式；2）512e，其磁盘物理扇区为4K，但为了兼容原系统，分区时选择了512的逻辑扇区大小；3）4Kn，它的物理扇区和逻辑扇区都是4K，系统使用原生4K的方式来访问这些磁盘。Linux从RHEL/CENTOS6开始支持原生4Kn，之前是通过512e硬盘格式模拟访问的。如果你使用的是4Kn格式的硬盘，就不需要考虑任何分区对齐的问题。而如果你使用512e方式，那么你就必须认真考虑对齐问题。因为如果分区不做4K对齐，那么一个IO可以解决的问题可能因为边界问题需要使用两个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模式访问磁盘，以获得最佳性能。创建磁盘组时，OracleASM的接口会自动获取逻辑扇区/物理扇区的大小。如果发现某个磁盘组中有不同的逻辑磁盘/物理磁盘大小，就会报错。如果运气不好，遇到本文开头提到的BUG，此时也可能导致DISKGROUP失败（一般不会，如果ASM实例设置忽略逻辑扇区大小参数_disk_sector_size_override，大概率会出现这种情况出现问题）。在Oracle中使用4K扇区的磁盘时，必须注意几个方面：1）表空间的BLOCKSIZE不能低于4K，否则会面临性能问题。好在我们的数据库大多使用默认的8KBLOCKSZIE，但是一些超高并发、热块争用严重的系统往往会使用较小的BLOCKSIZE，还有一些客户为了避免热块冲突将索引存储在2KBLOCKSIZE表空间；2）REDOLOG尽量使用4Kn磁盘格式，REDOBLOCK大小设置为4K，而不是默认的512；3）在创建磁盘组或向磁盘组中添加新磁盘时，一定要检查物理扇区和逻辑扇区的大小，以免出现不兼容问题。最后要说的是，无论是4Kn还是512e/512n模式，这都是全链路问题。从磁盘到操作系统的任何链接中的配置不一致或硬件不兼容都会影响我们最终获得的设备的属性。我在网上看到一个案例。分配在同一存储上的两个LUN在操作系统级别上具有不同的山区格式。这种情况会导致创建ASMDISKGROUP时报错。在操作系统上查了半天也没发现问题，最后在存储上找到了原因。创建LUN时，同一管理员在两个不同时间创建的两个LUN使用不同的BLOCKSIZE。存储管理员不关心这个，他们不知道这个参数会导致Oracle出问题。虽然硬件的发展并没有我们想象的那么快，只是DBA的硬件知识更新太慢了。结果，我们只关注现代硬件几年前研究清楚的问题。如果不是OracleBUG，我可能还会卡在HDD512扇区的惯性中。这种知识的学习什么时候才能出头？选择DBA这个职业，真的要保持一颗学习的心。
