alter database clear unarchive logfile group命令应该不可以clear active状态的日志。想要通过命令达成目的，估计只有resetlog。
如果强行被删除，必然会造成数据丢失，只是多少的问题，因为active状态的redo，对应的redo record没有完全执行完成，数据没有下盘，这时候又没归档，low cache rba没有向前推进，本质上就是数据丢了。

current状态的确实不能用unarchived参数，可惜不好模拟active状态的日志组，不过我猜测用unarchived去清理active的日志，同样会遇到ORA-01624: log 1 needed for crash recovery of instance PROD1 (thread 1) 这样的报错吧。我比较疑惑的是，根据官方文档的说法：

If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the statement.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

什么叫做没有被归档的redo？按我的理解，没有被归档（或者归档正在进行但是还没有完成）的redo，其状态不就是Active和Current么？ 难道还有Inactive状态的redo仍然还没有被归档的情况？

我的实验模拟当中，就遇到个这么奇怪的情况，我手工rm掉了一个Inactive状态的redo，尝试直接用 alter database clear logfile group 2; 命令，就遇到了 ORA-00350: log 2 of instance PROD1 (thread 1) needs to be archived 的报错，然后用 alter database clear unarchived logfile group 2; 就成功了。

redo日志的active，current状态和是否归档无关，关键是redo record是否下盘。归档模式下inactive的redo log也有可能未归档。

前几天才遇到过inactive未归档redo log的故障；由于存储问题导致redo group 1出逻辑坏块，导致数据库启动时进行redo前滚失败而无法启动；执行alter database clear unarchived logfile xxxx后成功拉起来，就出现了inactive未归档日志组

ACTIVE - Log is active but is not the current log. It is needed for
crash recovery. It may be in use for block recovery. It may or may not
be archived

当发生log switch时，会发生log switch引发的thread checkpoint，log switch checkpoint完成，即对应的脏块全部写入datafile，则active会转换为inactive(如果归档模式下，有可能未归档)，所以当active状态时，对应脏块并未完全写入datafile，如果此时丢失了或者clear了active的logfile，如果对应的log file中有需要前滚或者回滚的事务，则肯定会发生数据的丢失，造成数据库内部的不一致。

肯定会呀

谢谢各位专家的回答，我仔细回忆了一下，发现自己其实走入了一个误区，日志状态的变更，取决于日志里面的日志条目所对应的data脏块是否已经全部写进了数据文件，而和是否已经归档了并没有联系。所以Inactive状态也仍然存在没有被归档的情况，这取决于归档进程的工作是否足够迅速了，或者数据库处于的是手动归档模式。
那么在归档模式之下，对于Inactive的日志是否可以被覆盖，则取决于它是否已经被归档了。

所以，当处于Active的redo被强行清理掉之后，会发生什么情况呢？我简要的分析了一下：

1. redo 里面的条目虽然被清理掉了，但是此时因为实例是存活的，也就是内存当中的data buffer还是完整的，dbwr在满足他的触发条件下，仍然可以正常将redo对应的脏块继续写入数据文件，这种情况下就不会丢失数据；
2. 数据库实例down掉，此时我们去重启数据库，那么在根据checkpoint的最后位置进行实例恢复的时候，因为对应的redo条目被删除，实例恢复肯定会失败，此时就只能做不完全恢复了，数据丢失是肯定的；
   综上，数据是否会丢失，最终取决于发生这种故障的时候，实例是否正常存活了。

谢谢各位！