真正该设的是 maxpiecesize，它作为公开参数直接限制每个 .bkp 文件大小；\_maxsetsize 是隐藏参数，仅影响 backup set 上限且不保证精确截断，易导致文件超限、配置不可验证等问题。
用 MAXPIECESIZE 控制单个 .bkp 文件大小
真正该设的是 MAXPIECESIZE，不是 _MAXSETSIZE。前者是公开参数，直接限制每个 backup piece（即你看到的 .bkp 文件）大小；后者是隐藏参数，只影响 backup set 上限，且不保证文件精确截断。
常见错误现象：_MAXSETSIZE=2G 后仍生成 3.2G 文件 → 因为那个数据文件太大，RMAN 不会拆分单个数据文件，只会在 backup set 边界处新建片。
- 必须在 RMAN 连接目标库后、执行备份前配置，例如：
CONFIGURE CHANNEL 1 DEVICE TYPE DISK MAXPIECESIZE 4G;
- 若使用并行备份，每个通道独立受
MAXPIECESIZE约束，比如PARALLELISM 4+MAXPIECESIZE 2G，最多同时写 4 个 ≈2G 的文件 - 设值要留余量：若云存储上传限制 ≤5GB，建议设
MAXPIECESIZE 4800M，避免跨块写入导致略微超限
MAXPIECESIZE 和 _MAXSETSIZE 同时存在时的行为
两者混用容易出问题。RMAN 会按更严格的阈值触发新片，但具体哪个生效不可预测 —— 尤其当 _MAXSETSIZE 小于 MAXPIECESIZE 时，可能干扰通道级控制逻辑。
实操建议：
- 彻底不用
_MAXSETSIZE：它不出现在SHOW ALL输出里，无法验证是否生效，也不被官方文档推荐用于控片大小 - 清除已有配置：
CONFIGURE MAXSETSIZE CLEAR;
避免残留影响 -
BACKUP AS COPY不受MAXPIECESIZE影响 —— 它是文件系统级拷贝，生成的是原始数据文件副本，不是 backup piece
为什么 SHOW ALL 看不到 _MAXSETSIZE
因为它是隐藏参数，SHOW ALL 只显示公开配置项。即使你用 ALTER SYSTEM SET "_maxsetsize"=2G SCOPE=BOTH; 手动设了，SHOW ALL 也不会列出，但 RMAN 在 backup set 场景下仍会参考它 —— 这正是容易误判的根源。
验证方式只有两种：
- 执行备份后检查生成的 .bkp 文件大小分布
- 在备份过程中开启调试：
SET COMMAND ID TO 'debug_size';
并配合 trace 日志观察片切换时机
真正需要盯住的，永远是最终落地的 .bkp 文件大小，而不是配置命令有没有“成功执行”。
