前言--现象描述
远程plsq登录报错“
ORA-00257: archiver error.Connect internalonly, until freed
alert后台日志报错：
Errors in file/oracle/app/oracle/diag/rdbms/pdunq/ptext/trace/ptext_arcc_19603.trc:
ORA-19809: limit exceeded for recoveryfiles
ORA-19804: cannot reclaim 42910720 bytesdisk space from 23622320128 limit
ARCc: Error 19809 Creating archive log fileto‘/oracle/app/oracle/flash_recovery_area/PDUNQ/archivelog/2015_05_14/o1_mf_1_190_%u_.arc‘
Thu May 14 10:08:18 2015
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/ptext/trace/ptext_arcd_19605.trc:
ORA-19815: WARNING:db_recovery_file_dest_size of 23622320128 bytes is 100.00% used, and has 0remaining bytes available.
************************************************************************
You have following choices to free up spacefrom recovery area:
1. Consider changing RMAN RETENTION POLICY.If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such astape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increasedb_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMANDELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
1，先进去查看是否磁盘已经满了，df -h检查OK，磁盘空间足够了
[[email protected] ptext]$ pwd
/home/oradata/ptext
[[email protected] ptext]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 57G 20G 35G 37% /
tmpfs 12G 2.1G 10G 18% /dev/shm
/dev/sda1 194M 32M 153M 18% /boot
/dev/mapper/vg001-lv001
63G 49G 12G 81% /home/oradata
df: `/root/.gvfs‘: Permission denied
[[email protected] ptext]$
2，查看归档日志的路径
SQL> show parameter log_archive_dest;
NAME TYPE VALUE
----------------------------------------------- ------------------------------
log_archive_dest string
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
NAME TYPE VALUE
----------------------------------------------- ------------------------------
log_archive_dest_19 string
log_archive_dest_2 string SERVICE=pdunq_dg lgwr sync af
firm VALID_FOR=(ONLINE_LOGFILE
S,PRIMARY_ROLE) DB_UNIQUE_NAME
=ptext
.......
3，VALUE值有为空的情况，再查看archivelog list;检查一下归档目录和logsequence
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 192
Next log sequence to archive 194
Current log sequence 194
SQL>
4. 检查flash recovery area的使用情况,可以看见archivelog的使用率很大，达到93.62%
SQL> select * fromV$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------------------------------- ---------------
CONTROLFILE .13 0 1
ONLINELOG 2.93 0 3
ARCHIVELOG 93.62 0 141
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
5. 计算flash recovery area已经占用的空间
SQL> selectsum(percent_space_used)*3/100 from v$flash_recovery_area_usage;
SUM(PERCENT_SPACE_USED)*3/100
-----------------------------
2.9988
SQL>
6. 找到recovery目录, show parameterrecover
SQL> show parameter recover;
NAME TYPE VALUE
----------------------------------------------- ------------------------------
db_recovery_file_dest string /oracle/app/oracle/flash_recovery_area
db_recovery_file_dest_size big integer 22G
recovery_parallelism integer 0
SQL>
7 上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下(db_recovery_file_dest目录=/oracle/app/oracle/flash_recovery_area)
进归档目录，删除一些归档日志，转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）
[[email protected] ~]$ cd/oracle/app/oracle/flash_recovery_area
[[email protected] flash_recovery_area]$
8，手动去/oracle/app/oracle/flash_recovery_area目录下删除归档日志文件
cd /oracle/app/oracle/flash_recovery_area/PDUNQ/archivelog
rm -rf 2015_01* 2015_02* 2015_03* 2015_04*2015_05_0*
---------------------------------------------------------------------------------------
注意:
在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。
---------------------------------------------------------------------------------------
9. 检查一些无用的archivelog
RMAN> crosscheck archivelog all;
返回：对归档日志的验证失败
10. 删除过期的归档
RMAN> delete expired archivelog all;
返回:RMAN-08137: 警告: 因为仍需要归档日志, 所以未删除
delete archivelog until time ‘sysdate-1‘ ; 删除截止到前一天的所有archivelog
也报错
google打不开，只好baidu了下，说如果测试环境或者开发环境可以强行删除所有归档：
delete noprompt force archivelog all;
11，然后查看归档日志使用率，已经到了0.57%了，如下所示：
SQL> select * fromV$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE
-------------------- -------------------------------------------
NUMBER_OF_FILES
---------------
CONTROL FILE 0 0
0
REDO LOG 0 0
0
ARCHIVED LOG .57 0
3
FILE_TYPE PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE
-------------------- -------------------------------------------
NUMBER_OF_FILES
---------------
BACKUP PIECE 20.86 20.82
7
IMAGE COPY 0 0
0
FLASHBACK LOG 0 0
0
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE
-------------------- -------------------------------------------
NUMBER_OF_FILES
---------------
FOREIGN ARCHIVED LOG 0 0
0
7 rows selected.
SQL>
12，plsq可以正常登录了，alert后台日志也正常了。
plsq也可以登录了，一切OK了。归档满了，需要定时清理，一味的增大db_recovery_file_dest_size的值也不是长久得事情，磁盘总归是有限制的，oracle的归档日志和mysql的binlog一样，都可以强行清理掉，注意的时候如果是生产环境要注意备库的数据是否已经同步过去了，如果同步过去了，就可以强行删除归档日志释放空间，否则还是小心为上。