虽然重做日志文件非常的重要，但是有时候数据库管理员仍然需要忍痛割爱，将某些重做日志文件组或者组成员删除。如当硬盘出现物理损坏，此时就无法往这个位置存放重做日志。此时为了避免重做日志的错误，就需要将其删除，然后再新建一个重组日志组成员等等。所以，有时是删除只是为了其更需更好的工作而已。但是删除重做日志文件组或者其成员毕竟不是一件简单的工作。在做这个操作的时候，数据库管理员需要注意几个限制条件。
限制条件一：数量上的限制。
通常情况下，Oracle数据库系统治少需要两个重做日志文件组。如果数据库系统中只有两个重做日志文件组，而出于某种原因数据库管理员需要删除其中的一个重做日志文件组，则数据库会拒绝这个操作。如故确实有必要需要删除这个重做日志文件组，那么数据库管理员必须先新建一个重组日志文件组。然后再把需要删除的日志文件组删除。这是Oralce数据库对于重做日志文件组数量上的限制，作为数据库管理员必须无条件的遵守。
另外对于组成员来说，也有类似的限制。每个重做日志文件组，必须要有一个有效的成员。如因为硬盘介质错误等原因需要把唯一的一个组成员删除，此时Oracle数据库系统会提示错误信息，拒绝类似的操作。此时数据库系统如果仍然像保留这个重做日志文件组，则只好先建立一个组成员，或者将某个失效的组成员设置为有效，然后再删除不起作用的组成员。其次需要说明的是，如果在重做日志文件中采用多路复用组的话，则最好还要保证多个组中成员数量是相同的(不是强制性限制)。这主要是因为在多路复用组下，如果每个组的组成员数量相同的话，则多路复用重做日志才可以变得对称。虽然说在每个组中的成员数量不同，并不会对数据库的运行造成负面影响。但是为了后续恢复以及管理的需要，笔者建议，如果采用多路复用的话，在删除组成员时，需要考虑重做日志文件的对称性问题。即最好能够保证删除某个组成员后，每个组的组成员数量是相同的。
这个数量上的限制，主要是为了保障重做日志文件的安全性。从某种程度来说，正是因为这个限制才确保数据库管理员可以利用重做日志文件把数据恢复到故障点。为此作为数据库管理员，必须要尊重这个限制条件，并积极的遵守它。
限制条件二：最好不要强制删除重做日志文件组。
通常情况下，重做日志文件组对应文件有三种状态。如果Oracle数据库系统不能够访问重做日志文件，则这个文件就会变成Invalid状态;如果Oracle数据库系统觉得重做日志文件不完整或者有错误时，则这个重做日志文件就会变为许久未用状态。当下次失效日志文件所属的组变成活动组时，这个失效日志文件才会再次变成有效状态。删除重做日志文件组时，跟这些文件到状态息息相关。
默认情况下，重做日志文件组也分为两种状态，分别为活动状态与非活动状态。在删除重做日志文件组时，笔者建议是先把重做日志文件组设置为非活动状态。然后再进行删除。这么操作有一个好处就是保障重做日志文件组与对应的日志文件与控制文件的关系。如确保更新了数据库的相关控制文件。不过这个限制条件跟第一个限制条件不同，并不是强制性的。如果数据库管理员需要删除当前的活动组，也是可以的。只是需要先强制进行日志切换。虽然这么做也是可行的，但是笔者强烈反对这么操作。因为在强制进行日志切换的过程中，如果操作不当的话，则很有可能破坏重做日志文件的完整性。后续出现问题时利用重做日志文件来恢复数据时，可能会出现问题。同理，在删除组成员的时候，这个组成员也不能够属于当前组或者活动组。如故确实需要删除某个活动组或者当前组的成员时，也是可以的，必须要先强行进行日志切换。
为此，除非有特殊的必要，一定需要把当前活动的重做日志文件组删除。否则的话，还是多走一步，先将重做日志文件组设置为非活动状态，然后再进行删除。这更加的保险一点。另外，在删除联机重做日志文件组之前要确保它已经归档。如此的话，可以保障重做日志文件(归档模式下)的完整性。当出现数据库故障时，可以利用这个重做日志文件将数据库恢复到出故障的点。无论是对于重做日志文件组，还是其组成员，都有这方面的要求，尽量避免对活动的组或者当前组进行删除操作。