求解释逻辑standby数据库alert日志频繁报ORA-19815而实际操作系统空间没有使用

[wangwei]

求解释逻辑standby数据库alert日志频繁报ORA-19815而实际操作系统空间没有使用

ORA-19815: WARNING: db_recovery_file_dest_size of 85899345920 bytes is 85.91% used, and has 12106660864 remaining bytes available.
************************************************************************
You have following choices to free up space from 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 as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
闪回去设置情况：
SQL> show parameter db_recovery_file_dest


NAME TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_recovery_file_dest string
/oracle/ora11g/oracle/fast_rec
overy_area
db_recovery_file_dest_size big integer
80G
SQL>


归档设置情况：
SQL> show parameter archive


NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
archive_lag_target integer 0
log_archive_config string DG_CONFIG=(orcl,orcldg,orcldg2
)
log_archive_dest string
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_
DEST
VALID_FOR=(ALL_LOGFILES,ALL_RO
LES)
DB_UNIQUE_NAME=orcldg2


log_archive_dest_2 string SERVICE=orcl ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRI
MARY_ROLE)


NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
DB_UNIQUE_NAME=orcl
闪回区使用情况：
SQL> select * from v$flash_recovery_area_usage;


FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------ ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 0 0 0
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 85.41 0 182
可以看出FOREIGN ARCHIVED LOG 文件占的空间比较多

查看rman备份以及归档日志，显示都没有
RMAN> list backup;

using target database control file instead of recovery catalog
specification does not match any backup in the repository

RMAN>

RMAN> list archivelog all;

specification does not match any archived log in the repository

RMAN>

操作系统下闪回恢复区的使用情况，foreign_archivelog才用了406M 和查询oracle视图使用完全不一样
[oracle@tts fast_recovery_area]$ du -sm *
407 ORCLDG2
[oracle@tts fast_recovery_area]$ cd ORCLDG2/
[oracle@tts ORCLDG2]$ ls
archivelog foreign_archivelog onlinelog
[oracle@tts ORCLDG2]$ du -sm *
1 archivelog
406 foreign_archivelog
1 onlinelog
[oracle@tts ORCLDG2]$ pwd
/oracle/ora11g/oracle/fast_recovery_area/ORCLDG2
[oracle@tts ORCLDG2]$

这是什么原因导致的，oracle bug 求解，现在把归档不放在闪回区 ，来避免alert日志报错

[bw555]

在controlfile中记录着每一个archivelog的相关信息，当我们在OS下把这些物理文件delete掉或异常变动后，在controlfile中仍然记录着这些archivelog的信息，当我们手工清除archive目录下的文件后，这些记录并没有被我们从controlfile中清除掉，也就是oracle并不知道这些文件已经不存在了!这时候我们要做手工的清除。 crosscheck archivelog all；的作用就是检查控制文件和实际物理文件的差别。 delete expired archivelog all;就是同步控制文件的信息和实际物理文件的信息。 如果单独执行crosscheck而没有执行delete那么备份还是失败的，原因是那些控制文件的信息和实际的信息还是不同。

[wangwei]

谢谢回复： 1.我不是在os直接删除归档日志的 用的delete archivelog all删除的 2.从查询闪回区使用情况来看不是归档日志占的空间而是FOREIGN ARCHIVED LOG占的空间，这个日志是用primary端传输过来的 3.我怀疑这可能是bug

[bw555]

目前现象是oracle识别的比os识别的要多，先同步下试试，看看能不能修复这个问题