数据库宕机了-搞不好得打包滚蛋

项目背景:oracle11G,一个礼拜前做了数据库迁移
5月27号把虚拟机的oracle数据库rac，迁移到现有的物理机上面，运行了1个多礼拜没有问题；

客户让执行一个存储过程，我尼玛刚执行就报错了GG

ORA-01578: ORACLE 数据块损坏 (文件号 87, 块号 4189572)
ORA-01110: 数据文件 87: '+DATA/XXglrac/datafile/XX_data.319.1136376323'
ORA-26040: 数据块是使用 NOLOGGING 选项加载的
ORA-06512: 在 "XX.TEST1", line 46
ORA-06512: 在 "XX.TEST2", line 5
ORA-06512: 在 line 2

赶紧找DBA协助排除，我艹，DBA说 数据库有坏块，得用备份blockrecover了，关键是这个坏块可能很早之前就存在了，现在得数据库不一定能恢复处理;

只能从5月27号得老库拿数据，完蛋了1个多礼拜的数据可能丢失，搞不好要打包跑路了

什么配置都没有修改，重启一下oracle实例，oracle打开就崩，雪上加爽，这尼玛数据库蹦了…（ORA-07445）
全库还原3T，今天晚上怎么过？？？
oracle报错信息

Starting background process EMNC
EMNC started with pid=88, OS id=28326
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x28] [PC:0x7FC89503CAC8, java_util_HashMap__initHashSeedAsNeeded()+128] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/xxxrac/xxxrac1/trace/xxxrac1_ora_1103.trc  (incident=838370):
ORA-07445: exception encountered: core dump [java_util_HashMap__initHashSeedAsNeeded()+128] [SIGSEGV] [ADDR:0x28] [PC:0x7FC89503CAC8] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/xxxrac/xxxrac1/incident/incdir_838370/xxxrac1_ora_1103_i838370.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2023-06-06 21:20:45.687000 +08:00
Dumping diagnostic data in directory=[cdmp_20230606212045], requested by (instance=1, osid=1103), summary=[incident=838370].
PMON (ospid: 31124): terminating the instance due to error 397
System state dump requested by (instance=1, osid=31124 (PMON)), summary=[abnormal instance termination].

各种百度，总结后的数据库操作流程,最终是:无法启动是oralce补丁导致的，回退了就可以了

1）全库恢复到20230606 20:00，恢复完了还是无法开，打开就崩
2）尝试startup upgrade，数据库可以打开，结合告警推测可能是ojvm补丁的问题，回滚后重建java可以打开数据库
3）有坏块的表依然存在，truncate以后从旧库dump导入，全表扫描后可以查询所有数据
4）尝试backup validate相关datafile，V$DATABASE_BLOCK_CORRUPTION里面的数据没有刷新，依然显示有坏块，应该是block数据没有刷新的问题，我觉得可以忽略
5）在执行升级程序，目前没有报错

最后反馈给客户评估

1.数据库全库恢复到2023年06月06日 20:00，恢复后仍然出现无法打开数据库;根据报错判断是Oracle ovjm补丁bug导致，于是执行了回滚ojvm操作，之后可以打开数据库。
2.打开数据库后仍然提示有数据坏块，于是清空了坏块相关的8张表，并从旧库中导出了8张表的数据导入,之后数据库状态一切正常，
3.执行了数据库升级操作后，weblogic 启动正常，登入系统，访问正常，业务查询正常。
4.从旧系统导入的8张表
除了XXXX表，之外的7张表本来在此次数据库发布操作中按脚本执行也会清空操作，并重新生成。

XXXX表恢复使用的是5月27日的xxx数据库中的数据,恢复之后、操作完今天凌晨的数据库发布操作后，
我们看到表中数据最新时间戳也是6月7日凌晨4点多的数据。


5.不确定表XXXX表是否存在数据丢失，请评估。

百度和问CHATGPT给出的相关信息
https://blog.51cto.com/miracle/57178
我们执行的存储过程中有一个delete语句；

https://www.cnblogs.com/hmwh/p/12168390.html