本文主要是介绍Oracle集群ORA-03113:end-of-file on communication channel，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、问题场景描述
今天Oracle集群要更新各数据库的数据，折腾的启动不了了：
--》数据量比较大，数据泵方式导出的dmp文件 准备导入集群
--》由于之前的生产数据库数据比较少，需要增大表空间。
--》于是在sqlplus命令窗口，写了一个增加表空间的语句，但后来太慢 整个都卡了，取消了
--》有点心急，同时准备删除原用户重新建一个空用户进行导入
--》drop用户时提示有连接无法删除，v$session 查看连接太多，懒得kill了
--》😅想着数据库没其他的，重启一下也不要紧。结果shutdown immediate 写成shutdown
--》手一抖，回车 结果太慢，取消 再次shutdown immediate 不行了，改为shutdown abort
--》关是关了：startup 完了，报错了，启动到mounted 就提示报错了，如下：
用startup force 也不管用
😱 反复尝试，shutdown abort ;startup 都不管用~~~~
（注意：startup force 是shutdown abort+startup的组合，强制关闭数据库+正确启动，强制关闭可能会有数据丢失）
二、网上的资料：
前两种尝试了，失败告终。第三种 需要看日志，而且机器没有开rman,着急就忽略了。
反正机器上没什么重要的数据库，于是😅出现如下mount：甚至recover都不行。
启动到mount,再open 也不行。（注意：除非还原操作，resetlogs 要谨慎）
再次强调：open resetlog 操作比较危险的 容易丢数
三、解决办法--同事沟通、师傅指导
思路：找最新的alert日志，查找问题根源。
（1）查看日志
A.准备看一下日志的路径参数，结果报错。
sqlplus 进去 show parameter dump ,结果报错：
B.切换oracle用户，cd $ORACLE_BASE，一层层进目录，看结果。
su - oracle
cd $ORACLE_BASE
$ORACLE_BASE/diag/rdbms/orcl/orcl1/trace
trace下面 alert_x.日志：
终于看到结果了，归档日志空间不足。
C.看是否有进程在,查看数据库状态
ps -ef|grep ASM
ps -ef|grep smon
sqlplus "/as sysdba"
select instance_name,status from gv$instance;
ora_smon_orcl1 哪里来的？
查看集群数据库状态：
sqlplus "/as sysdba"
select instance_name,status from gv$instance;
结果：
echo $ORACLE_SID
疑问：
ps -ef|grep LOCAL=NO|wc -l
ps -ef|grep LOCAL=NO
tail -f al*
shutdown abort
startup
查看最新日志
D.进入集群，查看数据
查看共享存储的大小：
su - grid
asmcmd
lsdg
结果： free_MB 太小了，512G的共享存储基本满了
archive log list
无法查看：
F.处理
pwd
cd data
du
ls
cd archivelog
rm -rf 2022*
然后，再执行shutdown immediate ->>startup ,ok 成功启动
(2)备选方案(以上已ok，以下没有尝试)
如果执行上面仍不可以，则执行以下：
select instance_name,status from gv$instance;
---recover database until cancel；
四、总结 及后续探讨
总结：
show parameter dump
$ORACLE_BASE/diag/rdbms/orcl/orcl1/trace
su - grid
asmcmd lsdg
cd data/archivelog/2024_04_05
rm -rf 2022*
shutdown immediate
startup
后续探讨的问题：如何快速删除原用户的所有元数据，表、过程、包、视图、索引？
如何导入时把过程、视图、包，直接覆盖？
如果有实际使用过的，好的解决办法：欢迎探讨。
这篇关于Oracle集群ORA-03113:end-of-file on communication channel的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
