下班的时候,想不到又遇到了ORA-19815错误,这个10g的数据库最近数据量狂增,每天产生大约5~6个G的归档:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 85.00% used,
and has 8052259328 remaining bytes available.
*************************************************************
You have the following choices to free up space fromflash recovery area:1. Consider changing your RMAN retention policy. If you are using dataguard, then consider changing your RMAN archivelog deletion policy.2. Backup files to tertiary device such as tape using the RMAN command BACKUP RECOVERY AREA.3. Add disk space and increase the db_recovery_file_dest_size parameter to reflect the new space.4. Delete unncessary files using the RMAN DELETE command. If an OS command was used to delete files, then use RMAN CROSSCHECK and DELETE EXPIRED commands.
db_recovery_file_dest_size设置的是50G,在当前的备份策略下已经不足够.只好临时扩展一下恢复区:
SQL> show parameter recov
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 50G
recovery_parallelism integer 0
SQL> alter system set db_recovery_file_dest_size=65G scope=both;
System altered
SQL> show parameter recov
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 65G
recovery_parallelism integer 0
再修改下冗余策略,释放部分磁盘空间:
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




