很显然，归档重做日志是按照需要经常备份的，但是备份在线重做日志有意义吗？ 联机重做日志是否是一个开放且活跃的文件，以便在此状态下进行复制是浪费时间（与备份打开的数据库相同）？
如果联机重做日志在20分钟内没有切换（以便日志可用于归档），那么如果系统发生故障并需要进行介质恢复，并且您没有备份联机重做日志，那么您肯定丢失了最后20分钟的交易？
我知道有其他更强大的方式来传输重做信息，以确保没有丢失，但我仍然对在线重做日志文件的状态感兴趣。
谢谢你的时间。
澄清更新…
定期运行的常规后台进程会将已存档的日志文件和联机日志文件发送出去。 我对这个过程没有太多的控制。 联机日志文件是否可用，或者在备份时如果正在写入日志，它们是否会损坏？
另一件要考虑的事情是备用数据库。 您可以将其configuration为使日志写入器向具有备用数据库的远程系统上的侦听器（实时应用）写入重做。 这几乎是实时完成的。 如果系统发生故障而无需恢复，则可以减less停机时间。 只要激活备用数据库，然后去。
有关在不同磁盘上镜像重做日志组的build议是非常好的build议。 通常情况下，一次只有一个日志组处于活动状态，其余的已经存档或正在等待存档。 你不想复制活动的 – 在恢复的情况下，这可能是无用的。
简而言之，不会在db运行时复制实时重做日志，并希望在完成后有任何有价值的东西。
build议您使用双工/复用联机重做日志。 这样他们被写入两个不同的物理磁盘。 如果一个失败，你的数据库将停止（因为它不能写入重做日志）。 您可以closures中止，然后在存活的重做日志上启动数据库，然后在解决问题时，可以使用所有多路复用重新启动数据库。
这取决于你的意思是由备份。 如果你的意思是传统意义上的，那么DCookie给出了正确的答案：“简而言之，不要在数据库运行时不能复制实时重做日志，并且希望在完成后有任何有价值的东西。” 另一方面，有一些更新的备份types技术可能需要时间点logging卷。 如果他们可以在时间点捕捉数据文件，控制文件和重做日志，那么确实有用。 如果在数据库启动时恢复这些数据，则performance得好像在捕捉时拉动了电源。 任何未提交的交易都将被回滚，但是没有提交的交易将被丢失，直到进行交易。
如果你想“冲洗”当前的重做日志，以确保你有一个存档，你可以发出一个
alter system switch logfile; 来自SQLPLUS或RMAN
这将强制当前日志的存档，然后您可以备份到现场。
另一个select是使用较小的重做日志，这样数据库的自然事务率就会导致一个日志切换和归档，您可以更方便地进行归档。
“alter system switch logfile”不会强制当前日志的存档，它只会切换到当前的下一个日志，使其可用于归档。 “alter system archive log current”会强制当前日志的存档。
如果您的联机日志在重新启动时可用并且没有损坏，则Oracle应该能够识别它们并重播它们以及存档的日志。 唯一会丢失的是在崩溃时尚未交付的交易。
当然，如果你的硬盘崩溃了，你将失去所有没有备份的东西。 这就是为什么你应该有一些镜像或更好的重做日志存储在不同的磁盘/控制器/计算机上。