为什么仍有对齐警告？

你的磁盘物理扇区 4096B，对齐单位实际是 2048s（1MiB，1024×1024 字节 = 2048×512B），而非仅 8s。手动指定的 1813334784s 虽能被 8 整除，但未被 2048 整除（1813334784÷2048=885417.478…），因此触发警告。

正确操作：让 parted 自动对齐（无需手动算扇区）

1. 切换单位为 MiB（自动满足 2048s 对齐）

(parted) unit MiB  # 1MiB=2048s，天然对齐4096B物理扇区

2. 计算分区起止位置（基于分区 3 的精确结束 MiB）
   先查看分区 3 的结束位置（MiB 单位）：

(parted) print  # 分区3的End会显示为 XX.MiB（例如：922999.0MiB）

假设分区 3 结束于 922999.0MiB，5GB=5000MiB（1GB=1000MiB），依次创建：

mkpart OCR01 880649MiB 885769MiB
mkpart OCR02 885769MiB 890889MiB
mkpart OCR02 890889MiB 896009MiB

3. 验证结果

(parted) print  # 3个分区Size均为5000MiB（即5GB），无对齐警告
(parted) unit GB; print  # 显示为5.00GB，大小精确

关键原理

unit MiB 模式下，parted 会自动将分区起止点对齐到 1MiB（2048s）边界，完全满足磁盘最佳性能要求。
无需手动计算扇区，既避免误差，又确保 5GB 精确大小（5000MiB=5×1000×1024×1024 字节 = 5GB）。

创建ASM磁盘

很常见的情况——纯 LUN（未创建分区表的裸设备）能直接创建 ASM 磁盘，但被分区表管理的物理磁盘（如 /dev/sdb）不行，核心差异在于设备是否有 “分区表标识”。

以下是原因解释和适配方案：

一、核心原因：ASM 对 “裸设备” 的识别逻辑

Oracle ASM 支持两种类型的设备作为 ASM 磁盘：

1. 纯裸设备（无分区表）：直接映射的 LUN（如存储分配的未格式化 LUN），无 MBR/GPT 分区表，设备本身就是 “干净的块设备”，ASM 可直接识别并使用。
2. 分区设备（有分区表）：若物理磁盘（如 /dev/sdb）创建了 MBR/GPT 分区表（哪怕没分任何分区），ASM 会判定它是 “分区表管理的磁盘”，要求必须使用其下的 “分区”（如 /dev/sdb1）而非整个磁盘。

你当前的 /dev/sdb 大概率已存在隐藏的分区表（或之前被初始化过分区表），所以 ASM 拒绝直接使用，需按以下方案处理。

二、解决方案：两种方式适配 ASM 创建

方案 1：清除分区表，让 /dev/sdb 变回 “纯裸设备”（推荐，贴合你说的 LUN 直接使用场景）

如果 /dev/sdb 无需分区，直接清理分区表即可恢复 “裸设备” 属性：

# 1. 清除/dev/sdb的分区表（MBR+GPT都清理，彻底裸设备化）
dd if=/dev/zero of=/dev/sdb bs=512 count=1  # 清除MBR分区表
sgdisk --zap-all /dev/sdb  # 清除GPT分区表（避免残留）

# 2. 验证：确认无分区表（无输出则成功）
parted /dev/sdb print  # 应显示"No partition table"或"unrecognized disk label"

# 3. 重新创建ASM磁盘（此时/dev/sdb是纯裸设备，可直接使用）
oracleasm createdisk DATA01 /dev/sdb

# 4. 验证结果
oracleasm listdisks  # 显示DATA01则成功

方案 2：保留分区表，用分区创建 ASM 磁盘（兼容现有磁盘结构）

若 /dev/sdb 需保留分区表，按之前的方法创建单个分区即可：

# 1. 进入parted创建分区（已确认无分区表则先创建GPT）
parted /dev/sdb
(parted) mklabel gpt  # 若已有分区表可跳过
(parted) mkpart DATA01 0% 100%  # 整个磁盘创建一个分区（/dev/sdb1）
(parted) quit

# 2. 清理分区残留
dd if=/dev/zero of=/dev/sdb1 bs=1M count=1

# 3. 创建ASM磁盘
oracleasm createdisk DATA01 /dev/sdb1

三、验证：确认设备类型

执行以下命令判断 /dev/sdb 是否为 “纯裸设备”：

# 若输出"disk label type: unknown"，说明是纯裸设备
blkid /dev/sdb  # 无输出
fdisk -l /dev/sdb  # 显示"Disk /dev/sdb: 1.8 TiB, ..., type: unknown"

按方案 1 操作后，/dev/sdb 就和你说的 “存储 LUN” 一样，可直接创建 ASM 磁盘，无需分区。

JBOD（Just a Bunch Of Disks，简单磁盘捆绑）

在使用 JBOD（Just a Bunch Of Disks，简单磁盘捆绑）配置的磁盘时，无法创建 Oracle ASM（Automatic Storage Management）磁盘，通常与以下原因相关：

1. JBOD 缺乏底层设备的一致性与可靠性支持

Oracle ASM 对底层存储设备有特定要求，需要设备具备稳定的标识（如持久化的设备名，避免重启后变化）和基本的可靠性保证（如避免单盘故障直接导致数据丢失）。

• JBOD 本质是多个独立磁盘的松散组合，没有统一的设备管理层，磁盘通常以物理盘（如/dev/sdb、/dev/sdc）形式直接暴露，设备名可能因系统重启、硬件重新枚举而变化，导致 ASM 无法稳定识别设备。
• 若未通过其他方式（如 udev 规则绑定持久化设备名）解决标识问题，ASM 会因设备路径不稳定而无法创建磁盘。

2. 未满足 ASM 对设备的 “原始设备” 要求

Oracle ASM 需要使用未格式化的原始设备（raw device）或通过分区工具（如fdisk、parted）创建的 “裸分区”（无文件系统），且设备需满足：

• 未被挂载（无文件系统）。
• 权限正确（通常需属主为grid用户，属组为asmadmin）。
• 未被其他进程占用（如 LVM、MDADM 等卷管理工具）。

若 JBOD 中的磁盘已被格式化、挂载，或被其他工具管理，ASM 会拒绝将其识别为可用磁盘。

3. 未正确配置 ASM 扫描路径

Oracle ASM 通过扫描特定路径（默认如/dev/oracleasm/disks/或/dev/sd*）发现候选设备，若 JBOD 磁盘的设备路径未包含在 ASM 的扫描范围内，会导致无法识别。

• 需通过asm_diskstring参数配置正确的设备路径（如/dev/sd*或/dev/disk/by-id/*），确保 JBOD 磁盘被纳入扫描。

4. 硬件或驱动层的兼容性问题

• 部分 JBOD 控制器可能缺乏对 Oracle 认证的驱动支持，导致磁盘 I/O 性能不稳定或设备识别异常，ASM 会因兼容性检测失败而拒绝使用。
• 需确认 JBOD 控制器及磁盘是否在 Oracle 官方的硬件兼容性列表（HCL） 中。

5. 未禁用磁盘的 “写缓存” 或其他冲突设置

部分 JBOD 磁盘可能默认启用了硬件写缓存，而 ASM 依赖底层设备的缓存一致性保证（尤其是在冗余配置中），若未禁用写缓存，可能导致 ASM 初始化失败。

• 可通过hdparm等工具检查并禁用磁盘写缓存（如hdparm -W 0 /dev/sdb）。

解决建议：

1. 确保磁盘为原始设备：删除磁盘上的所有分区和文件系统（如fdisk /dev/sdb删除分区，wipefs -a /dev/sdb清除文件系统签名）。
2. 配置持久化设备名：通过 udev 规则将 JBOD 磁盘绑定到固定名称（如/dev/asm-disk1），避免设备名变化。
3. 检查权限：设置设备权限为grid:asmadmin（如chown grid:asmadmin /dev/asm-disk1）。
4. 调整 ASM 扫描路径：在asm_initparam.ora中设置asm_diskstring='/dev/asm-disk*'，确保包含目标设备。
5. 验证兼容性：确认 JBOD 控制器和磁盘在 Oracle HCL 中，或替换为认证的存储配置（如 ASM 推荐的冗余存储，如 RAID 或 Oracle Exadata）。

若以上步骤仍无法解决，建议检查 ASM 相关日志（如alert_+ASM.log），通过错误信息定位具体原因（如设备权限、扫描路径或兼容性问题）。

核心原则：ASM 依赖 “无分区表、无文件系统、标识稳定” 的设备，配置时需优先满足这些条件。

磁盘组可以空间大小

在 Oracle ASM 中，当磁盘组采用 NORMAL 冗余模式 时，其空间使用特性如下：

1. 磁盘组总容量显示

磁盘组的 “总大小”（Total Size）会显示为所有成员磁盘的空间总和（例如，2 块 100GB 磁盘，总容量显示为 200GB）。这是因为 ASM 会将所有磁盘的物理空间计入总容量。

实际可用空间

NORMAL 冗余模式下，ASM 会对数据进行 双副本存储（镜像），以提供容错能力（允许单块磁盘故障）。因此，实际可用空间约为总容量的一半（例如，总容量 200GB 时，可用空间约 100GB）。

1. 这是因为每一份数据都会被写入两个不同的故障组（Failure Group），相当于消耗了两倍的物理空间。
2. 总结
   • 磁盘组 “总大小” = 所有磁盘空间总和（物理空间总量）。
   • 实际可用空间 ≈ 总大小的 50%（因镜像机制，需预留一半空间用于冗余）。

这种设计是 NORMAL 冗余模式为保证数据可靠性所必需的，与 HIGH 冗余模式（三副本，可用空间约 1/3）和 EXTERNAL 冗余模式（无副本，可用空间 = 总大小）形成区别。

在 Oracle ASM 中，HIGH 冗余模式的空间特性如下：

1. 总容量显示

磁盘组的 “总大小”（Total Size）仍为所有成员磁盘的物理空间总和（例如，3 块 100GB 磁盘，总容量显示为 300GB）。

实际可用空间

1. HIGH 冗余模式为了提供更高的容错能力（允许同时发生两块磁盘或两个故障组的故障），会对数据进行 三副本存储（每份数据在三个不同的故障组中各存一份）。因此：
   • 实际可用于存储用户数据的空间约为总容量的 1/3（例如，总容量 300GB 时，可用空间约 100GB）。
   • 剩余 2/3 的空间用于存储两份镜像副本，以保证冗余。
2. 与其他模式的对比
   • EXTERNAL 冗余：无副本，可用空间 ≈ 总容量（依赖外部存储的冗余，如 RAID）。
   • NORMAL 冗余：双副本，可用空间 ≈ 总容量的 1/2（允许单磁盘 / 故障组故障）。
   • HIGH 冗余：三副本，可用空间 ≈ 总容量的 1/3（允许双磁盘 / 故障组故障）。

因此，HIGH 冗余模式下，由于三副本机制，实际可用空间确实约为所有磁盘空间总和的三分之一，这是为了换取更高的数据可靠性。