问题产生：
最近同事连接开发环境oracle数据报错，一开始简单更加了下归档空间，每次加5G，语句如下：
查看归档空间大小：
show parameter db_recovery;
查看使用占比：
select * from v$flash_recovery_area_usage;
增加归档空间：
alter system set db_recovery_file_dest_size=30G;
后来每过3天左右就又满聊，是时候看看了。
第一步：
统计下归档日志文件大小：
select trunc(first_time) "time", sum(block_size * blocks) / 1024 / 1024 / 1024 "size(g)" from v$archived_log
group by trunc(first_time) order by trunc(first_time);
从结果看，每天产生1个多G的量，甚至2023-12-27号产生4.5G这么恐怖的归档。另外通过查看某个时间点前其实每天只占用90M左右空间，之后就开始产生几百兆到大于1G的日志归档。
然后开始分析下归档日志空间占用大的对象。
第二步：
查询大对象：
select * from (
select to_char(dhs.begin_interval_time, 'yyyy-MM-dd HH24:mi:ss') snap_time, dhsso.object_name, SUM(dhss.db_block_changes_delta) sum_change
from dba_hist_snapshot dhs inner join dba_hist_seg_stat dhss on dhs.snap_id = dhss.snap_id and dhs.instance_number = dhss.instance_number
inner join dba_hist_seg_stat_obj dhsso on dhss.obj# = dhsso.obj# and dhss.dataobj# = dhsso.dataobj#
where begin_interval_time > sysdate - 30
group by to_char(dhs.begin_interval_time, 'yyyy-MM-dd HH24:mi:ss'), dhsso.object_name order by 3 desc
)where rownum<=10;
结果查看：
好家伙，应该就是它了，DATA_CHECK_SYNC， 去连接我们的数据库查了下这个表，表数据为空。为了验证就是这个表产生了大量归档日志，开始下一步，查看日志文件。
第三步：
安装软件 toad for oracle, 安装过程跳过。我是安装了12.1.0.22版本的（软件自行获取许可，懂得都懂-_-）。
打开软件，把出问题的数据库连接上，依次选择 database -> diagnose ->logMiner。
1.设置如图，点next
2.选择你要分析的日志文件，然后next
3.选择分析的时间段等参数，点finish
4.点一下这个按钮，就可以看到结果了
从结果可以看到，确实是有大量插入 "DATA_CHECK_SYNC 这个表的操作，记录完毕，拜拜
