解决Oracle归档日志存满的问题
归档日志archivelog：
- 可以配置单个日志文件的大小（oracle安装时设置或安装后修改配置）；
- 可以配置日志文件占用的（总）空间大小。
日志文件产生的多少，主要取决于数据库中数据变化的频率。
一般配置项如下：
--以dba角色登录
conn / as sysdba
--（建议）重新指定归档日志存储目录，需注意目录一定要先建好，linux下操作系统的oracle用户要有权限访问此目录
alter system set log_archive_dest_1='location=D:\archivelog' scope=spfile;
alter system set log_archive_start=TRUE scope=spfile;
--定义日志文件的命名格式
alter system set log_archive_format='arch%t_%s_%r.arc' scope=spfile;
--修改日志文件占用的（总）空间大小
（建议）alter system set db_recovery_file_dest_size= 40G;（与日志删除频率配合，查看此参数：show parameter db_recovery_file_dest_size）
--重新挂载后生效
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
1.Oracle重启的时候提示这个错，原因是因为闪回归档区的空间满了
ORA-03113: end-of-file on communication channel Process ID: 14263 Session ID: 335 Serial number: 5
直接startup是起不来的
下面是出错到解决的全过程：
sqlplus / as sysdba，进入数据库
startup mount;启动mount状态
alter database mount;
alter database open;
报如下错误：
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 252
Session ID: 1 Serial number: 3
到这一个步骤，就停下来。
nomount 状态 数据库获取spfile的配置来启动数据库，其实这个时候可以通过 show parameter，查看 background_dump_dest 这个参数 来了解alter 文件到底存放在那里了。
mount 状态，数据库实例已经获取了控制文件.控制文件里面有数据文件的指针，等等很多信息。
background_dump_dest /u01/app/oracle/fast_recovery_area
然后查看这个日志：(/u01/app是安装路径)
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
最后有这两句
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_arc1_7251.trc: ORA-19815: WARNING: db_recovery_file_dest_size of 4385144832 bytes is 100.00% used, and has 0 remaining bytes available.
查看这个文件，查看错误信息：(上面日志里记录的)
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_arc1_7251.trc
ORA-19815:这一行提示了db_recovery_file_dest_size使用100%，闪回归档区满了
/u01/app/oracle/fast_recovery_area //是存档日志存放目录
现在做的操作是删除存档日志或者增大闪回恢复区(当然还有别的方法)
我的处理方法是增大闪回恢复区,下边是我的操作过程：
(确定数据库是关闭的或者修改完重启数据库 )
#SQL> show parameter recover
SQL> show parameter db_recovery_file_dest_size;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size big integer 2G
SQL> alter system set db_recovery_file_dest_size=10G scope=spfile;
系统已更改。
SQL> alter database open;
数据库已更改。
SQL> show parameter db_recovery_file_dest_size;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size big integer 3G
SQL>alter database open noresetlogs;
Database altered. //提示这个就好
然后查看数据库状态
select open_mode from v$database;
显示READ WRITE就OK了。
2.客户使用过程中不能登录业务系统，经检查后发现后台日志报错
ORA-00257: archiver error. Connect internal only, until freed.
该错误是由于归档日志满了，造成的。
查看了下V$FLASH_RECOVERY_AREA_USAGE，看看归档目录使用的情况。果然是归档满了。
SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 99.9 0 255
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
注：可以看出，ARCHIVELOG日志已经达到99.9%了。造成归档满的原因是因为有一个用户在做大量更新操作
同样是增大闪回恢复区(参考上面第一种错误解决方法)
SQL> select * from v$flash_recovery_area_usage; --查看空间占用率
SQL> select * from v$recovery_file_dest; --查看归档日志的存放位置;
rman清空归档日志方式
$ rman
RAM> connect target /
RAM> crosscheck archivelog all; --查看可以所有的归档文件
RAM> delete expired archivelog all; --清空过期的归档文件
如何确认归档日志是否过期,rman有一个保留策略,可以定义多少天之前的日志算为过期;
RAM> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
让恢复窗口成为14天大小。
RAM> show all; --查看所有的rman策略.
SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO'; --查看所有归档，未删除的归档日志
定时清理归档日志
将clear_arc.sh加入定时任务
#crontab -l
00 00 * * * clear_arc.sh
#clear_arc.sh
rman target / nocatalog cmdfile clear.rcv
#clear.rcv
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
crosscheck archivelog all;
delete expired archivelog all;
