起源

今天跟往常一样，登陆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.trcOracle Database 11gEnterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith thePartitioning, OLAP, Data Mining and Real Application Testing optionsWindows NT VersionV6.1 Service Pack 1CPU                 : 4 - type 8664, 2 PhysicalCoresProcess Affinity    : 0x0x0000000000000000Memory (Avail/Total):Ph:2805M/6087M, Ph+PgF:6761M/12173MInstance name: oracleRedo thread mountedby this instance: 1Oracle processnumber: 19Windows 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.cARCH: 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.ckrsi_dst_fail: dest:1err:19809 force:0 blast:1DDE: 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.565USER (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 sysdbashutdown abort     ----关闭进程startup mount       ---- 装载数据库select * from v$recovery_file_dest; ---查询归档日志db_recovery_file_dest_size=10737418240; --设置归档日志空间为10GExit ---到这里空间大小已经设置完毕

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

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并不知道这些文件已经不存在了。

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

后记

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

你可能感兴趣的文章