OCI Oracle 19c超大PDB本地克隆进度监控及死锁问题咨询

有效监控克隆进度的方法 #

• 放弃使用select count(*) from dba_data_files;，克隆挂载阶段数据文件尚未批量创建，该查询无法反映真实进度。改用以下方式：
  • 在CDB根容器执行：SELECT OPNAME, SOFAR, TOTALWORK, ELAPSED_SECONDS, TIME_REMAINING FROM V$SESSION_LONGOPS WHERE OPNAME LIKE '%PDB CLONE%';，这个视图会跟踪克隆过程中数据文件复制的实时进度，包括已完成量、总工作量和剩余预估时间。
  • 通过ASMCMD或视图监控数据文件变化：用asmcmd ls -l +<磁盘组名>/<CDB名>/PDB_CLONE/DATAFILE/定期查看目标数据文件的大小增长；或执行SELECT DISK_NAME, READS, WRITES, BYTES_READ, BYTES_WRITTEN FROM V$ASM_DISK_IOSTAT WHERE GROUP_NUMBER = <磁盘组号>;，确认磁盘是否有持续的读写负载，判断复制是否在进行。
  • 仔细梳理CDB告警日志，查找Copying datafile <文件号> to <目标路径>这类条目，确认数据复制的具体执行情况。

死锁信息的判断与处理 #

• 克隆过程中出现的内部死锁（多涉及PDB元数据锁），Oracle通常会自动化解，只要克隆会话未终止、状态正常，无需手动干预。可在CDB根执行：SELECT SID, SERIAL#, STATUS, EVENT FROM V$SESSION WHERE ACTION LIKE '%CREATE PLUGGABLE DATABASE%';，若会话状态为ACTIVE，等待事件是db file sequential read、enq: TX - row lock contention这类正常的I/O或锁等待，说明操作仍在推进。
• 若会话状态变为INACTIVE且长时间无变化，或告警日志出现ORA-00060错误并终止操作，才需要中断克隆并排查根源。

12TB PDB克隆的耗时预期 #

• 12TB规模的本地克隆耗时受存储性能（ASM磁盘组的带宽、IOPS）、CPU资源、源PDB繁忙程度影响。按1GB/s的存储带宽计算，纯数据复制就需要约3.3小时，再加上元数据处理、一致性快照维护等环节，3小时仍在合理范围内。之前小PDB克隆速度快是因为数据量差异，不能直接类比。

是否需要继续等待？ #

• 先通过上述监控手段确认操作是否持续推进：
  • 若V$SESSION_LONGOPS显示进度持续增长、ASM数据文件大小不断增加、会话状态正常，建议继续等待，可根据存储性能额外预留2-3小时的缓冲时间。
  • 若监控发现进度停滞超过30分钟、会话状态异常，或出现新的错误日志，考虑中断操作并排查以下因素：
    • 源PDB是否存在长时间运行的事务？执行SELECT SID, START_TIME, STATUS FROM V$TRANSACTION t JOIN V$SESSION s ON t.SES_ADDR = s.SADDR WHERE s.CON_ID = <源PDB的CON_ID>;，活跃事务会延迟克隆的一致性快照生成。
    • ASM磁盘组空间是否充足？执行SELECT NAME, FREE_MB, TOTAL_MB FROM V$ASM_DISKGROUP;，确保目标磁盘组剩余空间至少比源PDB大10%。
    • 系统资源是否耗尽？用top、vmstat或iostat检查CPU、内存、磁盘I/O负载，磁盘I/O等待过高会大幅拖慢复制速度。
    • 源PDB是否启用本地UNDO？执行SELECT NAME, LOCAL_UNDO_ENABLED FROM CDB_PDBS WHERE NAME = 'PDB';，本地UNDO模式下克隆需要额外处理undo数据，耗时会更长。

后续克隆的优化建议 #

• 若ASM磁盘组兼容性设置≥12.1，下次克隆建议使用稀疏克隆：CREATE PLUGGABLE DATABASE PDB_clone FROM PDB identified by CLONE SNAPSHOT COPY;，利用ASM快照特性几乎瞬间完成克隆，后续按需复制修改的数据，大幅缩短初始耗时。
• 克隆前暂停源PDB的非必要业务，减少活跃事务，避免克隆过程中因快照等待拖慢进度。
• 若业务允许，可将源PDB切换为READ ONLY模式后再执行克隆，无需维护一致性快照，能显著提升速度。

内容的提问来源于stack exchange，提问作者dntz