expdp报ora-21780。规避措施:expdp在运行时,请不要改变参数值,比如parallel参数值,filesize参数值等等。

当使用expdp进行数据导出时,切勿在导出过程中更改参数,如parallel参数和filesize参数,以避免出现ORA-21780错误。文章详细描述了此错误的原因,并提供了解决方案和工作规避方法。

expdp在运行时,请不要改变参数,比如parallel参数值,filesize参数值,

否则可能会导致ora-21780错误。

Data Pump Export (expdp) or Data Pump Import (impdp) reports ORA-21780 at the end of export completion. (Doc ID 1357811.1)


在该文章中,对触发ora-21780的动作做了一个描述:

Changes

Changed number of parallel processes while Data Pump Export or Import was running.

Export> parallel=1
Export> exit

Solution

FIX

  • 11.2.0.4
  • 12.1

WORKAROUND

Don't change the number of parallel processes while Data Pump Export is running.

References

BUG:10198387 - DATA PUMP EXPORT REPORTS ORA-21780 WHEN PARALLELISM (PARALLEL=N) IS MODIFIED

<think>嗯,用户遇到了一个经典的Oracle问题:expdp全库导出,由于包含BLOB字段的大表导致ORA-01555快照过旧错误。这个问题在数据库运维中很典型,用户应该是个DBA或者系统管理员,正在尝试数据迁移或备份操作。 从用户描述看,ta已经意识到问题与BLOB字段相关,说明对Oracle有一定了解。但可能对undo机制和expdp工作原理还不够深入,需要系统性的解决方案。用户情绪可能比较着急,毕竟数据导出失败会影响后续工作。 参考引用内容,有几个关键点值得注意: 1. 引用[1][2]都提到BLOB字段损坏可能导致ORA-01555,这提示我们需要检查数据完整性 2. 引用[4]提到了undo表空间检查,这是常规解决路径 3. 引用[3]的自动化作业思路对预防性维护有启发 深层需求可能是用户不仅想解决当前导出问题,更希望建立预防机制。所以除了应急方案,还需要给出长期优化建议。 技术层面要分三步走: 首先解决当务之急的导出失败问题,重点在undo配置优化和导出参数调整。对于BLOB大表,需要特殊处理策略,比如分区导出或使用compress选项减少undo压力。 其次要诊断根本原因,特别是检查BLOB字段是否损坏。这步很关键,否则即使导出成功,数据也可能不可用。 最后是系统级优化,包括undo表空间设计、retention策略、监控脚本等。引用[3]提到的自动化检查很实用,可以借鉴。 特别注意要提醒用户操作风险:修改undo表空间可能影响生产环境,检查BLOB字段需要停业务等。这些都要在方案中明确标注。</think>以下针对expdp全库导出因BLOB大表导致ORA-01555快照过旧问题的完整解决方案,结合Oracle机制和实际案例: ### 一、核心原因分析 1. **BLOB字段特性**:大对象字段需长间读取,导致导出期间依赖的undo数据被覆盖 2. **undo表空间不足**:事务量过大,undo空间回收速度 > 保留间(`undo_retention`) 3. **快照过旧机制**:导出过程中查询一致性需要undo信息,若被覆盖则错[^1][^2] ### 二、紧急解决方案 #### 1. 调整undo配置(立即生效) ```sql -- 检查当前undo状态 SELECT tablespace_name, status, SUM(bytes)/1024/1024 "Size(MB)" FROM dba_undo_extents GROUP BY tablespace_name, status; -- 增大undo表空间(至少扩展50%) ALTER DATABASE DATAFILE '/u01/oradata/undotbs01.dbf' RESIZE 50G; -- 设置retention保障(关键!) ALTER TABLESPACE undotbs1 RETENTION GUARANTEE; ALTER SYSTEM SET undo_retention=10800 SCOPE=BOTH; -- 建议3小以上 ``` #### 2. 优化expdp参数 ```bash expdp system/password FULL=Y DIRECTORY=exp_dir DUMPFILE=full.dmp FLASHBACK_TIME="SYSTIMESTAMP" -- 使用闪回代替一致性读 PARALLEL=4 -- 降低并行度减轻undo压力 CLUSTER=N -- 禁用RAC集群模式 COMPRESSION=ALL -- 减少BLOB传输量 ``` #### 3. 分阶段导出BLOB大表 ```bash # 先导出非BLOB表 expdp system/password TABLES_EXCLUDE=TABLE_WITH_BLOB DIRECTORY=exp_dir DUMPFILE=noblob.dmp # 单独导出BLOB大表(减少事务间) expdp system/password TABLES=TABLE_WITH_BLOB DIRECTORY=exp_dir DUMPFILE=blob_tables.dmp DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS -- 忽略约束错误 ``` ### 三、根治性措施 #### 1. 表级修复(针对损坏BLOB) ```sql -- 检查BLOB损坏(需在业务低峰期执行) ALTER TABLE table_with_blob MOVE LOB(blob_column) STORE AS (TABLESPACE users); SELECT owner, table_name FROM dba_lobs WHERE segment_name IN (SELECT segment_name FROM dba_segments WHERE tablespace_name='UNDO'); ``` #### 2. 系统级优化 ```sql -- 创建专用大文件undo表空间 CREATE BIGFILE UNDO TABLESPACE undotbs2 DATAFILE '/u01/oradata/undotbs2.dbf' SIZE 100G AUTOEXTEND ON NEXT 1G RETENTION GUARANTEE; -- 启用自动undo管理 ALTER SYSTEM SET undo_management=AUTO; ALTER SYSTEM SET undo_tablespace=undotbs2; ``` #### 3. 监控脚本(预防复发) ```sql --监控undo使用率 SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI') snap_time, ROUND((1-(SUM(undoblks)/(SUM(expiredblks)+SUM(unexpiredblks)+1)))*100,2) pct_used FROM v$undostat; ``` ### 四、替代方案 1. **RMAN全库备份**:`RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;` 2. **物理复制**:使用Active Data Guard或存储级快照 3. **增量导出**:仅导出变化数据(需配合`FLASHBACK_SCN`) > **关键提醒**:操作前务必停止监听服务防止新连接[^4] > ```bash > lsnrctl stop # 停止监听 > expdp ... # 执行导出 > lsnrctl start # 重启监听 > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值