oracle 11g扩容卡在2tb是因底层mbr分区表限制，fdisk报错“dos partition table format cannot be used”即表明磁盘超2tb但仍是mbr；须用gdisk无损转gpt，再用parted扩展分区，最后针对ext4执行resize2fs或xfs重新mkfs，否则df -h仍显示旧容量。
oracle 11g 本身不识别磁盘分区格式，它依赖操作系统暴露的块设备路径（如 /dev/sdb1）和文件系统挂载点。真正卡住扩容的，是底层 linux 对 /dev/sdb 的分区表解析——如果仍是 mbr，parted 或 fdisk 就压根看不到超过 2tb 的空间，oracle 自然也读不到。
为什么 fdisk 报错“DOS partition table format cannot be used”
这是最典型的信号：内核已识别到磁盘物理容量 >2TB（比如 3.2TB），但当前分区表仍是 MBR（msdos）。fdisk 基于传统 BIOS/MBR 协议设计，遇到超限磁盘会直接拒绝操作，并抛出那条 WARNING。它不是 Oracle 的错，而是工具链在拒绝配合。
-
fdisk完全不支持 GPT 操作，强行使用只会破坏分区结构 - 即使你用
fdisk创建了“看似成功”的分区，lsblk或df -h也只会显示约 2TB，剩余空间处于“未分配但不可见”状态 - Oracle 数据文件若建在该分区上，
CREATE TABLESPACE时指定大小超过 2TB 会失败，报 ORA-01119 或 ORA-27041
用 parted 转 GPT 时必须跳过的三个坑
很多人执行 mklabel gpt 后发现数据没了——不是 parted 有问题，是操作顺序错了。关键点在于：GPT 转换本身不擦数据，但后续分区重建会。
- 先运行
sudo parted /dev/sdb print确认当前是Partition Table: msdos，且已有分区（比如/dev/sdb1）存在 - 不要直接
mklabel gpt——这会清空整个磁盘的分区表，原/dev/sdb1设备节点立即失效 - 正确做法是用
gdisk：安装后运行sudo gdisk /dev/sdb，输入r→g→w，它会在保留原有分区结构的前提下转换标签（即无损转换） - 转换完仍需用
parted重新对齐并扩展分区：进入sudo parted /dev/sdb，执行rm 1（删旧分区）、mkpart primary 1MiB 100%（新建对齐分区）、quit
Oracle 数据文件所在分区挂载后仍显示只有 2TB？检查 mkfs 和 resize2fs
即使分区已扩到 13TB，如果格式化时没指定完整空间，或文件系统未重置大小，df -h 依然卡在旧值。XFS 和 ext4 处理方式不同：
- XFS 不支持在线 resize，格式化必须一步到位：
sudo mkfs.xfs -f /dev/sdb1（无需额外 resize） - ext4 需两步：先
sudo mkfs.ext4 /dev/sdb1，再挂载后运行sudo resize2fs /dev/sdb1（否则仍只认初始格式化大小） - 挂载前确认
/etc/fstab中 UUID 正确：用sudo blkid /dev/sdb1获取新 UUID，替换 fstab 里旧的，避免重启后挂载失败 - Oracle 用户需确保
oracle用户对挂载点有读写权限：sudo chown oracle:oinstall /opt/oradata
最易被忽略的是：GPT 分区后若未重新格式化，旧文件系统元数据仍停留在 2TB 边界，df 显示的就是那个旧快照。别信 parted print 显示的 Size，要看 df -h 和 sudo xfs_info /dev/sdb1（XFS）或 sudo dumpe2fs -h /dev/sdb1 | grep "Block count"（ext4）输出的实际块数。
