flash_recovery_area：ORA-19815错误

今天oracle遇到一个问题，这里记录一下

说明：

1.数据库中有一张表,字段长度设置的很大，很多是1000以上，然后今天系统卡死，在服务器查看cpu和内存都是100%，执行session查看，发现有session在查这张表，kill掉后，内存、cpu能够释放掉了，
2.查看这张表，发现里面有很多空记录，结果是由于不正常的插入导致的，于是使用delete语句删除这些记录，结果引发了ora-19815的错误，报错时，其他的用户也无法再登上。

引发原因：

1.ORA-19815：在ORACLE10g和11g版本，ORACLE默认的日志归档路径为闪回恢复区（$ORACLE_BASE/flash_recovery_area）。对于这个路径，ORACLE有一个限制，就是默认只有2G的空间，而且不只是归档日志的默认路径，也是备份文件和闪回日志的默认地址，这样的话归档日志锁使用的空间就达不到2G，在没有设置好这个路径大小的情况下，很多系统都遇到过归档日志满而无法归档导致数据库夯住的问题
(1)通过archive log list来查看归档日志备份目录
(2)查看闪回恢复区信息show parameter db_recover
(3)查看闪回恢复区使用情况

select name,SPACE_LIMIT,SPACE_USED from v$recovery_file_dest;
--或
 select * from v$flash_recovery_area_usage;

2.导致原因，归档日志和闪回恢复区存在一个目录下，delete语句删除那张大表（字段定义不规范，字段长度太随意）产生大量的redoLog，导致recovery_file_dest设定的空间不足（这次爆掉时磁盘的空间是有很多剩余的）

处理:

方法1.修改db_recovery_file_dest_size大小

 alter system set db_recovery_file_dest_size=8G scope=both; 

这种方式只是临时解决，虽然闪回恢复区ORACLE会自动管理，如果闪回恢复区空间不足就会清理掉没用的数据，但是如果备份策略不是很完善，数据库非常繁忙的情况下，还有可能遇到这种情况，建议修改归档日志的路径，将归档日志放到其他不受限制的路径下来解决这个问题，通过下面的SQL来修改归档日志的存放路径

--oracle需要 启动到mount状态
alter system set log_archive_dest_1='location=/data/arch';

然后将数据库启动到OPEN状态。

方法2.通过删除flash recovery area中不必要的备份来释放flash recovery area空间

--export ORACLE_SID=xxx

rman target /
--登录

rman>alter database mount;
--startup mount

rman>crosscheck archivelog all;
--检查控制文件和实际物理文件的差别

rman>delete NOPROMPT expired archivelog all;
同步控制文件的信息和实际物理文件的信息

rman>
delete expired archivelog all;
--或
delete noprompt archivelog all completed before 'sysdate -2';
--删除归档
rman>alter database open;
--启动

最后对于那张大字段表，将字段大小修改后再删了，否则删的时候可能仍然导致卡死