解决ORA-01555报错

当执行长时间运行的SQL查询或存储过程时,可能会遇到ORA-01555错误。该错误表明回滚段太小,无法保持数据一致性。错误可能由大事务、频繁提交、查询一致性读取引起。解决方案包括增加回滚段大小、设置更大的undo_retention时间、优化查询、减少不必要的事务提交、为大事务指定回滚段和优化游标使用。通过调整这些参数和策略,可以避免ORA-01555错误的发生。

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

OS环境:windows2008

数据库版本:oracle 11.2.0

 

今天同事需要执行一个拥有大批量运算的存储过程,当执行的时候报错,报错信息如下:

 

ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 18 with name
"_SYSSMU18_671080725$" too small
ORA-06512: at "TRANUSER.TRAN_ETL_LOAD_J2S_MAIN", line 22
ORA-06512: at "TRANUSER.TRAN_ETL_LOAD_JST_PRE", line 5
ORA-06512: at line 2

 

--精彩解释

不知道是从哪里转的了, 假设有张表,叫table1,里面有5000万行数据,假设预计全表扫描1次需要1个小时,我们从过程来看: 

1、在1点钟,有个用户A发出了select * from table1;此时不管将来table1怎么变化,正确的结果应该是用户A会看到在1点钟这个时刻的内容。这个是没有疑问的。 
2、在1点30分,有个用户B执行了update命令,更新了table1表中的第4000万行的这条记录,这时,用户A的全表扫描还没有到达第4000万条。毫无疑问,这个时候,第4000万行的这条记录是被写到了回滚段里去了的,我假设是回滚段RBS1,如果用户A的全表扫描到达了第4000万行,是应该会正确的从回滚段RBS1中读取出1点钟时刻的内容的。 
3、这时,用户B将他刚才做的操作commit了,但是这时,系统仍然可以给用户A提供正确的数据,因为那第4000万行记录的内容仍然还在回滚段RBS1里,系统可以根据SCN来到回滚段里找到正确的数据,但是大家注意到,这时记录在RBS1里的第4000万行记录已经发生了一点重大的改变:就是这个第4000万行的在回滚段RBS1里的数据有可能随时被覆盖掉,因为这条记录已经被提交了!!! 
4、由于用户A的查询时间漫长,而业务在一直不断的进行,RBS1回滚段在被多个不同的tracnsaction使用着,这个回滚段里的extent循环到了第4000万行数据所在的extent,由于这条记录已经被标记提交了,所以这个extent是可以被其他transaction覆盖掉的! 
5、到了1点40分,用户A的查询终于到了第4000万行,而这时已经出现了第4条说的情况,需要到回滚段RBS1去找数据,但是已经被覆盖掉了,于是01555就出现了。

--错误提示

数据库报错 ORA-01555 什么回滚段 '_SYSSMU168' is too small.很明显 是可用的回滚段太小了 满足不了那个大事物的需要 具体的sql我就不提供了

还有一种可能,一般伴随着ORA-22924出现就是LOB上的问题

### 解决 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、付费专栏及课程。

余额充值