ORA-19599: block number 75960 is corrupt in archived log

数据库在执行RMAN备份时遇到错误,报错显示归档日志文件存在坏块。问题反复出现,涉及序列号为811710和890857的归档日志。解决方案包括删除损坏的归档日志并重新备份,以及检查并修改filesystemio_options参数。已确认文件系统为EXT4格式,可能与filesystemio_options设为SETALL有关。

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

今天有个环境报rman备份失败,处理完紧急事情后,登录查看,发现报错如下

input archived log thread=1 sequence=811710 RECID=796334 STAMP=1137265897
channel d1: starting piece 1 at 02-JUN-23
released channel: d1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on d1 channel at 06/02/2023 11:26:37
ORA-19599: block number 75960 is corrupt in archived log /fra/archivelog/1_811705_990835557.dbf

Recovery Manager complete.
orcl:/backup/orcl/log@db>

查看alert日志,发现报错

Fri Jun 02 15:39:01 2023
***
Corrupt block seq: 811705 blocknum=75960.
Bad header found during backing up archived log
Data in bad block - seq:0. bno:0. time:0
beg:0 cks:0
calculated check value: 0
Reread of seq=811705, blocknum=75960, file=/home/oracle/archivelog/1_811705_990835557.dbf, found same corrupt data
Reread of seq=811705, blocknum=75960, file=/home/oracle/archivelog/1_811705_990835557.dbf, found same corrupt data
Reread of seq=811705, blocknum=75960, file=/home/oracle/archivelog/1_811705_990835557.dbf, found same corrupt data
Reread of seq=811705, blocknum=75960, file=/home/oracle/archivelog/1_811705_990835557.dbf, found same corrupt data
Reread of seq=811705, blocknum=75960, file=/home/oracle/archivelog/1_811705_990835557.dbf, found same corrupt data
Fri Jun 02 15:40:38 2023

应该是归档日志文件坏块了,数据库每天有expdp全库导出的备份,这里就删除归档后重新做数据库完全备份

rman > delete force noprompt archivelog until time 'sysdate - 1/6';

20230805日更新

同样的问题又一次出现了,同样报错

Fri Aug 04 01:58:45 2023
***
Corrupt block seq: 890857 blocknum=312.
Bad header found during backing up archived log
Data in bad block - seq:0. bno:0. time:0
beg:0 cks:0
calculated check value: 0
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data

Fri Aug 04 11:28:15 2023
***
Corrupt block seq: 890857 blocknum=312.
Bad header found during backing up archived log
Data in bad block - seq:0. bno:0. time:0
beg:0 cks:0
calculated check value: 0
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data

Sat Aug 05 00:12:38 2023
***
Corrupt block seq: 890857 blocknum=312.
Bad header found during backing up archived log
Data in bad block - seq:0. bno:0. time:0
beg:0 cks:0
calculated check value: 0
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Sat Aug 05 00:32:21 2023


[root@newdb trace]# strings orcl_ora_2667.trc
Trace file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2667.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1
System name:    Linux
Node name:    newdb
Release:    4.1.12-61.1.28.el6uek.x86_64
Version:    #2 SMP Thu Feb 23 20:03:53 PST 2017
Machine:    x86_64
VM name:    VMWare Version: 6
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 58
Unix process pid: 2667, image: oracle@newdb (TNS V1-V3)
*** 2023-08-05 00:12:38.192
*** SESSION ID:(6430.22735) 2023-08-05 00:12:38.192
*** CLIENT ID:() 2023-08-05 00:12:38.192
*** SERVICE NAME:(SYS$USERS) 2023-08-05 00:12:38.192
*** MODULE NAME:(backup archivelog) 2023-08-05 00:12:38.192
*** ACTION NAME:(0000187 STARTED16) 2023-08-05 00:12:38.192
Corrupt block seq: 890857 blocknum=312.
Bad header found during backing up archived log
Data in bad block - seq:0. bno:0. time:0
beg:0 cks:0
calculated check value: 0
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
Reread of seq=890857, blocknum=312, file=/home/oracle/archivelog/1_890857_990835557.dbf, found same corrupt data
[root@newdb trace]#

mos文档:ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros when filesystemio_options=SETALL on ext4 file system using Linux (Doc ID 1487957.1)

处理办法

1、查询系统,发现文件系统确实ext4格式

2、查看参数,filesystemio_options配置成SETALL

3、修改filesystemio_options,重启数据库

sql > ALTER SYSTEM SET filesystemio_options='NONE' SCOPE=SPFILE;

### 解决方案分析 ORA-01722 错误表明在 SQL 查询中存在无法转换为数字的字符串。这种情况通常是由于参数类型不匹配或 SQL 语句本身存在问题所致。以下是对问题的具体分析和解决方案。 --- ### 可能的原因及解决办法 #### 原因一:参数类型不匹配 如果 `XinyongShensuRecordMapper.xml` 文件中的 SQL 语句期望接收一个数值类型的参数,但实际传入的是字符串类型,则会触发 ORA-01722 错误[^1]。 ##### 解决方法 确保传递给 `deleteById` 方法的参数类型与数据库字段类型一致。例如,如果数据库字段是 `NUMBER` 类型,则应在 Java 实体类中将其定义为 `Long` 或 `Integer` 类型。 ```java public class XinyongShensuRecord { private Long recordId; public Long getRecordId() { return recordId; } public void setRecordId(Long recordId) { this.recordId = recordId; } } ``` 同时,在调用 `deleteById` 方法时,确保传入的参数已正确转换为数值类型: ```java long idValue = Long.parseLong(xxxId); XinyongShensuRecordMapper.deleteById(idValue); ``` --- #### 原因二:SQL 语句中的隐式转换 即使参数类型正确,某些情况下,SQL 语句可能会尝试对非数值字段进行隐式转换,从而导致 ORA-01722 错误[^2]。 ##### 解决方法 检查 `XinyongShensuRecordMapper.xml` 文件中的 SQL 语句,确保不会对非数值字段执行任何算术运算或其他可能导致隐式转换的操作。例如,避免类似以下的写法: ```sql WHERE TO_NUMBER(RECORD_ID) = ? ``` 改为直接使用字段名: ```sql WHERE RECORD_ID = ? ``` --- #### 原因三:MyBatis 参数绑定问题 MyBatis 在绑定参数时可能出现类型推断错误,尤其是在未明确指定参数类型的情况下。这也会导致 ORA-01722 错误[^3]。 ##### 解决方法 在 `XinyongShensuRecordMapper.xml` 文件中显式声明参数类型。例如: ```xml <update id="deleteById" parameterType="java.lang.Long"> DELETE FROM WTC_RECEIPT_BACK_T WHERE RECORD_ID = #{recordId,jdbcType=NUMERIC} </update> ``` 通过这种方式可以确保 MyBatis 正确识别参数类型并生成合适的 SQL 语句。 --- #### 原因四:数据质量问题 有时,数据库中存在的脏数据也可能导致 ORA-01722 错误。例如,某条记录的 `RECORD_ID` 字段存储了非数值字符。 ##### 解决方法 运行以下查询以查找可能存在的问题数据: ```sql SELECT * FROM WTC_RECEIPT_BACK_T WHERE REGEXP_LIKE(RECORD_ID, '[^0-9]'); ``` 如果有返回结果,说明部分数据不符合预期格式,需要清理这些数据。 --- ### 综合建议 为了彻底解决 ORA-01722 错误,可以从以下几个方面入手: 1. 确保 Java 实体类中的字段类型与数据库字段类型完全一致。 2. 检查 SQL 语句是否存在可能导致隐式转换的操作。 3. 在 MyBatis 配置文件中显式声明参数类型。 4. 清理数据库中可能存在的一致性问题。 --- ### 示例代码 以下是经过优化后的代码示例: ```java // 调用方代码 try { long idValue = Long.parseLong(xxxId); // 将 String 转换为 Long XinyongShensuRecordMapper.deleteById(idValue); } catch (NumberFormatException e) { throw new IllegalArgumentException("Invalid identifier format", e); } // Mapper XML 文件配置 <update id="deleteById" parameterType="java.lang.Long"> DELETE FROM WTC_RECEIPT_BACK_T WHERE RECORD_ID = #{recordId,jdbcType=NUMERIC} </update> ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值