Oracle错误——ORA-03113:在通信信道文件的末尾 解决方案

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

起源

 

今天跟往常一样,登陆PL/SQL,确登陆失败,出现一个错误“ORA-01034”和“ORA-27101”如图:


然后就就通过命令提示符去登陆Oracle,去查看怎么回事,然后问题进一步出现。错误“ORA-03113:通信通道的文件结尾进程 ID:6320 回话 ID :191 序列号:3”。


 

问题根源

 

Oracle出现错误。于是去错误日志里去找问题根源:在 e:\app\kang\diag\rdbms\oracle\oracle\trace\目录下找到oracle_ora_6320.trc文件。打开显示错误日志:

 

Trace filee:\app\kang\diag\rdbms\oracle\oracle\trace\oracle_ora_6320.trc
Oracle Database 11gEnterprise Edition Release 11.2.0.1.0 - 64bit Production
With thePartitioning, OLAP, Data Mining and Real Application Testing options
Windows NT VersionV6.1 Service Pack 1
CPU                 : 4 - type 8664, 2 PhysicalCores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total):Ph:2805M/6087M, Ph+PgF:6761M/12173M
Instance name: oracle
Redo thread mountedby this instance: 1
Oracle processnumber: 19
Windows thread id:6320, image: ORACLE.EXE (SHAD)
 
 
*** 2014-08-1608:18:55.461
*** SESSIONID:(191.3) 2014-08-16 08:18:55.461
*** CLIENT ID:()2014-08-16 08:18:55.461
*** SERVICE NAME:()2014-08-16 08:18:55.461
*** MODULENAME:(sqlplus.exe) 2014-08-16 08:18:55.461
*** ACTION NAME:()2014-08-16 08:18:55.461
 
ORA-19815: 警告:db_recovery_file_dest_size 字节 (共 4102029312 字节) 已使用 100.00%, 尚有 0 字节可用。
************************************************************************
You have followingchoices to free up space from recovery area:
1. Consider changingRMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOGDELETION POLICY.
2. Back up files totertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space andincrease db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessaryfiles using RMAN DELETE command. If an operating
   system command was used to delete files,then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ORA-19809:超出了恢复文件数的限制
ORA-19804: 无法回收33961984 字节磁盘空间 (从 4102029312 限制中)
*** 2014-08-1608:18:55.502 4132 krsh.c
ARCH: Error 19809Creating archive log file to'E:\APP\KANG\FLASH_RECOVERY_AREA\ORACLE\ARCHIVELOG\2014_08_16\O1_MF_1_159_%U_.ARC'
*** 2014-08-1608:18:55.502 2747 krsi.c
krsi_dst_fail: dest:1err:19809 force:0 blast:1
DDE: Problem Key 'ORA312' was flood controlled (0x1) (no incident)
ORA-00312: 联机日志 3 线程1: 'E:\APP\KANG\ORADATA\ORACLE\REDO03.LOG'
ORA-16038: 日志 3sequence# 159 无法归档
ORA-19809:超出了恢复文件数的限制
ORA-00312: 联机日志 3 线程1: 'E:\APP\KANG\ORADATA\ORACLE\REDO03.LOG'
 
*** 2014-08-1608:18:55.565
USER (ospid: 6320):terminating the instance due to error 16038


 

 

从这里我们发现了问题的根源:“

ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 4102029312 字节) 已使用100.00%, 尚有 0 字节可用。 db_recovery_file_dest_size也叫归档日志空间不足导致的。既然找到问题的根源,那解决起来也就easy了。

 

解决途径

 

空间小,那摆在我们面前办法就是,一个是将空间设置大点,还有一个就是将多余的文件删除掉就可以。那么我们就将这两个办法都使用一下。

 

通过命令窗体:

--------设置归档日志空间的大小

sqlplus / as sysdba
shutdown abort     ----关闭进程
startup mount       ---- 装载数据库
select * from v$recovery_file_dest; ---查询归档日志
db_recovery_file_dest_size=10737418240; --设置归档日志空间为10G
Exit ---到这里空间大小已经设置完毕


 

--------删除归档日志

rmantarget /   -----进入rman工具窗体
RMAN>crosscheckarchivelog all;  --执行这个命令能够把无效的expired的archivelog标出来。
RMAN>deletenoprompt archivelog until time "sysdate -3";  -- -即删除3天前的归档日志
 


到这里就彻底ok了。

接下来又一次打开数据库:正常使用

 

在删除归档文件里有一点要注意,通过命令窗体显示显示归档文件都在E:\app\kang\flash_recovery_area\oracle\ARCHIVELOG  下。可是我们不能手工在操作系统中直接把这些文件删除掉,这是由于在controlfile中记录着每个archivelog的相关信息,当我们在OS中删除这些文件后。我们的controlfile中仍然记录着这些archivelog的信息,因此在Oracle的OEM管理器中还会存在这些日志。

由于当我们手工清除archive文件夹下的文件后,这些记录并没有被我们从controlfile中清除掉。也就是oracle并不知道这些文件已经不存在了。

所以还是要通过命令窗体去运行删除这些文件的命令。

 

后记

 

归档日志事实上是为了方便我们在恢复数据库当使用。但有时这些归档日志有时确实给我们的小问题一点点,因此,这些存档日志,或者需要我们注意。







本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/5045972.html,如需转载请自行联系原作者


相关实践学习
日志服务之数据清洗与入湖
本教程介绍如何使用日志服务接入NGINX模拟数据,通过数据加工对数据进行清洗并归档至OSS中进行存储。
相关文章
|
2月前
|
存储 Oracle NoSQL
Oracle 表空间、数据文件、schema的关系
Oracle 表空间、数据文件、schema的关系
149 2
|
2月前
|
XML Java 数据库连接
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——hibernate的config文件(hibernate.cfg.xml)
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——hibernate的config文件(hibernate.cfg.xml)
|
9月前
|
Oracle 关系型数据库 数据库
9-4 Oracle管理表空间和数据文件
9-4 Oracle管理表空间和数据文件
|
1月前
|
SQL Oracle 关系型数据库
mysql和oracle 命令行执行sql文件 数据库执行sql文件 执行sql语句
mysql和oracle 命令行执行sql文件 数据库执行sql文件 执行sql语句
44 0
|
1月前
|
存储 SQL Oracle
oracle 存储过程导出sql语句 导出为文件
oracle 存储过程导出sql语句 导出为文件
117 0
|
2月前
|
存储 监控 Oracle
Oracle数据文件:数据王国的秘密藏宝图
【4月更文挑战第19天】Oracle数据文件是数据库物理存储的核心,存储实际数据,犹如数据王国的宝藏。它们对数据库性能至关重要,影响数据分布和访问效率。有效管理数据文件涉及合理规划大小、数量,监控使用情况,利用自动扩展功能,并能实现跨磁盘存储和高可靠性。理解数据文件原理有助于优化数据库性能和资源利用,发掘更多数据潜力。
|
2月前
|
运维 Oracle 关系型数据库
Oracle日志文件:数据王国的“记事本”
【4月更文挑战第19天】Oracle日志文件是数据库稳定运行的关键,记录数据变更历史,用于恢复和故障处理。它们协调并发操作,确保数据一致性和完整性。日志文件实时写入操作信息并定期刷新到磁盘,便于数据恢复。然而,日志文件需备份和归档以保证安全性,防止数据丢失。日志文件,数据王国的“记事本”,默默守护数据安全。
|
2月前
|
运维 Oracle 安全
Oracle的三重奏:密码文件、警告文件与跟踪文件
【4月更文挑战第19天】Oracle数据库的三大守护者:密码文件保护系统免受未经授权访问,如同宝藏的“密码锁”;警告文件似“哨兵”,记录错误信息,助于及时解决问题;跟踪文件扮演“侦探”角色,详尽记录操作,便于性能优化和故障排查。这三份文件共同确保数据王国的安全与稳定。作为管理员,重视并善用它们是关键。
|
2月前
|
运维 Oracle 关系型数据库
Oracle服务器参数文件:数据王国的“调控大师”
【4月更文挑战第19天】Oracle服务器参数文件,数据库的“调控大师”,掌控着内存管理、进程调度等关键设置。通过参数调整如SGA_MAX_SIZE和PROCESSES,实现性能优化和故障防控。虽然挑战重重,但成功的性能调优带来无尽成就感。它在备份恢复中也扮演重要角色,保障数据一致性与可用性。成为真正的“调控大师”,为数据王国效力!
|
2月前
|
存储 Oracle 安全
Oracle控制文件:数据王国的导航仪
【4月更文挑战第19天】Oracle控制文件是数据库的关键组件,存储结构信息和元数据,用于数据库启动、恢复。它指引数据库找到所需文件,保证数据完整性。控制文件的多重备份和定期更新确保其安全可靠。作为数据库导航仪,它对管理员理解和维护数据库至关重要,为数据存储和恢复提供关键支持。