问个v$flash_recovery_area_usage的问题

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 0
ARCHIVELOG 0 0 0
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0 0
FLASHBACKLOG 99.93 60.42 485


看空间使用率都99。93了
这是否有问题
又如何处理

11 个解决方案

#1

肯定有问题，满了，数据库就会HANG住，甚至宕机。

可以有2种途径解决：
1  减小db_flashback_retention_target参数值，减少需要保留的FLASHBACKLOG
2  增加db_recovery_file_dest_size参数值，增加闪回区空间。(前提是你有足够的存储空间)

#2

还有第三种方法，不过要宕机时间。就是关闭flashback功能。

shutdown immediate
startup mount
alter database flashback off;
alter database open;

#3

我查资料一般都是用ARCHIVELOG
这个满了就会hang住
但是这里怎么是 FLASHBACKLOG 
有些不理解
不敢肯定满了是否会出问题

#4

flashback log是flashback database必须的。
你既然设置了flashback最短时间，ORACLE就需要为你负责。
如果你不改，10gR2后ORACLE会覆盖最早的flashback log，并将你的flashback_on 该为off

#5

我理解你的意思就是要不把空间增大到能存储设置的1440的需求
要么就等着挂掉
是不是这个意思？

#6

我不知道你的版本，如果是10gR1，是这样的。
如果是10gR2，不会挂，但结果不是你想要的。

#7

引用 3 楼 yuzhenhuan01 的回复:

我查资料一般都是用ARCHIVELOG
 这个满了就会hang住
 但是这里怎么是 FLASHBACKLOG
 有些不理解
 不敢肯定满了是否会出问题

archivelog默认也是在flash_recovery_area里保存的，不过可以移走。

你可以用archive log list;看看archive log的地址 或者是  show parameter log_archive_dest;

不过根据你上面的1楼的方法解决
CONTROLFILE 0 0 0
ONLINELOG 0 0 0 0
ARCHIVELOG 0 0 0
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0 0
FLASHBACKLOG 99.93 60.42 485 
来看
archivelog类型没有占用空间
都是FLASHBACKLOG 占用的

所以应该按

#8

10.2.0.4.0的
还一个问题
按说我设置的1440，那为什么查询v$flashback_database_logfile还有一天前的日志文件呢
不应该自己回收空间么
还是说必须自己去设置定时任务清除或手工清除

#9

现在是2010-01-12 16点05分左右，你的意思是，有2010-01-11 16点05分前的日志？
那么下次ORACLE写的话，会自动删除用不到的日志，腾出空间给新日志。
这个触发点是ORACLE需要空间，如果空间还够，ORACLE会保留以前的日志。

#10

ok
明白了
按照这个说法，那还有不少可以回收利用的空间
谢谢解惑
结贴了

#11

1楼的