oracle 10 expdp lob,记录一次LOB损坏导致的EXPDP导出ORA-01555报错

同事在导出Oracle数据时遇到OR-01555错误,经排查发现是BLOB列可能损坏。通过创建临时表存储损坏行并避开它们,成功解决了问题。关键步骤包括检查LOB列、定位损坏行和调整导出查询。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

同事导出数据,结果遇到如下报错:

expdp user1/XXXXXXXX directory=szdata1 dumpfile=szhzinfo_20180319.dmp logfile=szhzinfo_20180319.log exclude=STATISTICS,INDEX tables=TKINFO QUERY=\"WHERE  voteproccesstime between 20180304000000 and 20180304235959 \"

Processing object type DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCACT_SCHEMA

ORA-31693: Table data object "USER1"."TKINFO" failed to load/unload and is being skipped due to error:

ORA-29913: error in executing ODCIEXTTABLEPOPULATE callout

ORA-01555: snapshot too old: rollback segment number with name "" too small

ORA-22924: snapshot too old

遇到ORA-01555报错最直接的反应就是undo表空间大小是否足够,undo_retention参数是否设置太小

经过验证,均不是以上问题造成的.

由于该表格有BLOB类型的列,经过搜索MOS怀疑是BLOB有损坏

IF: ORA-1555 Error During Export on LOB Data (文档 ID 1950937.1)

LOBs and ORA-01555 troubleshooting (文档 ID 846079.1)

开始排查是否有LOB字段的行存在损坏:

1.创建表存放lob损坏行的rowid

SQL> create table corrupted_lob_data (corrupt_rowid rowid, err_num number);

SQL> DESC LOBDATA

Name Null? Type

---------- --------- ------------

ID NOT NULL NUMBER

DOCUMENT BLOB

2.执行如下plsql块,找出存在损坏lob的行

declare

error_1578 exception;

error_1555 exception;

error_22922 exception;

pragma exception_init(error_1578,-1578);

pragma exception_init(error_1555,-1555);

pragma exception_init(error_22922,-22922);

n number;

begin

for cursor_lob in (select rowid r, &&lob_column from &table_owner..&table_with_lob) loop

begin

n := dbms_lob.instr (cursor_lob.&&lob_column, hextoraw ('889911')) ;

exception

when error_1578 then

insert into corrupted_lob_data values (cursor_lob.r, 1578);

commit;

when error_1555 then

insert into corrupted_lob_data values (cursor_lob.r, 1555);

commit;

when error_22922 then

insert into corrupted_lob_data values (cursor_lob.r, 22922);

commit;

end;

end loop;

end;

/

Enter value for lob_column: BYTE_IMAGE

Enter value for table_owner: USER1

Enter value for table_with_lob: TKINFO

old 10: for cursor_lob in (select rowid r, &&lob_column from &table_owner..&table_with_lob) loop

new 10: for cursor_lob in (select rowid r, BYTE_IMAGE from USER1.TKINFO) loop

old 12: num := dbms_lob.instr (cursor_lob.&&lob_column, hextoraw ('889911')) ;

new 12: num := dbms_lob.instr (cursor_lob.BYTE_IMAGE, hextoraw ('889911')) ;

3.查询结果发现rowid为AAAhS4AAUAAE3IRAAC的行 blob列有损坏

SQL> select * from corrupt_lobs;

CORRUPT_ROWID ERR_NUM

------------------ ----------

AAAhS4AAUAAE3IRAAC 1555

修改导出语句,跳过blob损坏的行,重新导出,成功导出

expdp user1/XXXXXXXX directory=szdata1 dumpfile=szhzinfo_20180319.dmp logfile=szhzinfo_20180319.log exclude=STATISTICS,INDEX tables=TKINFO QUERY=\"WHERE rowid NOT IN \(\'AAAhS4AAUAAE3IRAAC\'\) and voteproccesstime between 20180304000000 and 20180304235959 \"

### 解决 Oracle ORA-12514 报错 当遇到 `ORA-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor` 错误时,这通常意味着客户端尝试连接到的服务名称未被监听器识别。以下是几种可能的原因及解决方案: #### 验证服务名配置 确保在 tnsnames.ora 文件中的服务名和服务注册信息匹配。如果使用的是 Easy Connect 方法,则需确认主机名、端口以及服务名都正确无误。 ```bash # 检查tnsnames.ora文件路径下的内容 $ORACLE_HOME/network/admin/tnsnames.ora ``` #### 查看监听状态并验证已知服务 利用 lsnrctl 工具查看当前监听的状态及其知道哪些服务。这样可以帮助判断指定的服务是否已被监听器知晓。 ```bash lsnrctl status ``` 该命令会显示所有由监听进程管理的服务列表[^1]。 #### 修改 listener.ora 或者重新启动监听器 有时修改后的配置不会立即生效,因此建议重启监听器使更改生效: ```bash lsnrctl stop lsnrctl start ``` 另外,在某些情况下调整 `listener.ora` 中静态侦听设置也可能解决问题,特别是对于那些不自动向动态注册机制报告自己的实例来说更为重要[^3]。 #### 使用正确的连接字符串参数 确保应用程序使用的 JDBC URL 或其他形式的连接串里包含了适当的服务名而非 SID 。例如: ```java // 正确的方式应该是使用service name 而不是sid String url = "jdbc:oracle:thin:@hostname:port/service_name"; ``` #### 数据库实例状态检查 最后但同样重要的一步是要保证目标数据库实例正在运行并且能够接受新的连接请求。可以通过查询视图 V$INSTANCE 来获取有关实例的信息。 ```sql SELECT instance_name, status FROM v$instance; ``` 以上措施应该能有效处理大部分因服务命名错误而导致ORA-12514 问题[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值