Oracle 日志文件切换次数是归档 _ lag _ 目标的两倍

我的主要预生产数据库服务器上出现了一个奇怪的问题。在我的生产和预生产环境中，我们都设置了ARCHIVE_LAG_TARGET参数，以定期强制进行日志切换。我知道这不是现代的最佳实践，我们打算很快将该参数归零，但现在它就是这样。在生产中，参数设置为300 (五分钟)，并按预期工作:


SQL> 显示参数归档 _ 目标

名称类型值
-
archive_lag_target整数300

SQL> 选择first_time
2来自v $ log_history
3 WHERE first_time > SYSDATE - 1/4
4按第一次DESC排序;

第一次
------------------------
2/10/2017 5:18:06下午
2/10/2017 5:13:05下午
2/10/2017 5:08:05下午
2/10/2017 5:03:04下午
2/10/2017 4:58:04下午
2/10/2017 4:53:04下午
2/10/2017 4:48:04下午
2/10/2017 4:43:06下午
2/10/2017 4:38:06下午
2/10/2017 4:33:06下午
2/10/2017 4:28:05下午
2/10/2017 4:23:05下午
2/10/2017 4:18:05下午
2/10/2017 4:13:04下午
2/10/2017 4:08:04下午
2/10/2017 4:03:03下午
2/10/2017 3:58:03下午
2/10/2017 3:53:06下午
2/10/2017 3:48:06下午
2/10/2017 3:43:05下午

第一次
------------------------
2/10/2017 3:38:05下午
2/10/2017 3:33:04下午
2/10/2017 3:28:04下午
2/10/2017 3:23:04下午
2/10/2017 3:18:03下午
2/10/2017 3:13:03下午
2/10/2017 3:08:05下午
2/10/2017 3:03:05下午
2/10/2017 2:58:05下午
2/10/2017 2:53:04下午
2/10/2017 2:48:04下午
2/10/2017 2:43:04下午
2/10/2017 2:38:03下午
2/10/2017 2:33:03下午
2/10/2017 2:28:02下午
2/10/2017 2:23:02下午
2/10/2017 2:18:05下午
2/10/2017 2:13:04下午
2/10/2017 2:08:04下午
2/10/2017 2:03:04下午
2/10/2017 1:58:03下午

第一次
------------------------
2/10/2017 1:53:03下午
2/10/2017 1:48:03下午
2/10/2017 1:43:03下午
2/10/2017 1:38:02下午
2/10/2017 1:33:02下午
2/10/2017 1:28:02下午
2/10/2017 1:23:04下午
2/10/2017 1:18:04下午
2/10/2017 1:13:04下午
2/10/2017 1:08:03下午
2/10/2017 1:03:03下午
2/10/2017 12:58:03下午
2/10/2017 12:53:02下午
2/10/2017 12:48:02下午
2/10/2017 12:43:02下午
2/10/2017 12:38:02下午
2/10/2017 12:33:01下午
2/10/2017 12:28:01下午
2/10/2017 12:23:04下午
2/10/2017 12:18:03下午
2/10/2017 12:13:03下午

第一次
------------------------
2/10/2017 12:08:02下午
2/10/2017 12:03:02下午
2/10/2017 11:58:02上午
2/10/2017 11:53:02上午
2/10/2017 11:48:01上午
2/10/2017 11:43:01上午
2/10/2017 11:38:01上午
2/10/2017 11:33:00上午
2/10/2017 11:28:00上午


在预生产中，参数设置为7200 (120分钟)。但是，日志文件切换每小时发生一次。实际的日志切换总是发生在这个服务器上的参数中定义的持续时间的一半，无论设置什么值 (例如，当我1800年设置它时，切换每15分钟发生一次):


SQL> 显示参数归档 _ 目标

名称类型值
-
archive_lag_target整数7200

SQL> 选择first_time
2来自v $ log_history
3 WHERE first_time > SYSDATE - 1/4
4按第一次DESC排序;

第一次
------------------------
2/10/2017 4:02:16下午
2/10/2017 3:02:13下午
2/10/2017 2:02:14下午
2/10/2017 1:02:14下午
2/10/2017 12:02:12下午


我已经搜索了DBMS_SCHEDULER，cron和DBA_SOURCE，并验证没有proc/job进行任何日志文件切换，并且我尝试将ARCHIVE_LAG_TARGET参数设置为0，并返回到7200，结果相同。所有其他与日期/时间相关的功能 (DBMS_SCHEDULER等) 按预期工作。对于预生产服务器上的每个数据库都是如此，所以我开始怀疑在服务器级别发生了一些不寻常的事情，但我不确定从哪里开始寻找 (两个服务器都在RHEL 5.11上)。关于可能发生的事情有什么想法吗？

提前感谢您的协助!

你可以看看你的警报。日志。

如果有人/某物正在运行: 更改系统存档日志当前

然后你会看到它。

不幸的是，如果有人运行: alter system switch日志文件

然后，您在警报日志中看不到该命令 (仅是效果)。

但是要仔细检查，您可以运行:

审计变更系统

只是要仔细检查是否没有脚本等正在执行此操作，但是当您更改设置时频率确实会发生变化这一事实表明它没有任何外部内容。

如果禁用archive_lag_target，切换会完全消失吗？(我只是在考虑一种解决方法，您可以通过cron/scheduler等手动进行操作)。

值得聊聊以支持。