虽然重做日志文件非常的重要，但是有时候数据库管理员仍然需要忍痛割爱，将某些重做日志文件组或者组成员删除。如当硬盘出现物理损坏，此时就无法往这个位置存放重做日志。此时为了避免重做日志的错误，就需要将其删除，然后再新建一个重组日志组成员等等。所以，有时是删除只是为了其更需更好的工作而已。但是删除重做日志文件组或者其成员毕竟不是一件简单的工作。在做这个操作的时候，数据库管理员需要注意几个限制条件。

　　限制条件一：数量上的限制。

　　通常情况下，Oracle数据库系统治少需要两个重做日志文件组。如果数据库系统中只有两个重做日志文件组，而出于某种原因数据库管理员需要删除其中的一个重做日志文件组，则数据库会拒绝这个操作。如故确实有必要需要删除这个重做日志文件组，那么数据库管理员必须先新建一个重组日志文件组。然后再把需要删除的日志文件组删除。这是Oralce数据库对于重做日志文件组数量上的限制，作为数据库管理员必须无条件的遵守。

　　另外对于组成员来说，也有类似的限制。每个重做日志文件组，必须要有一个有效的成员。如因为硬盘介质错误等原因需要把唯一的一个组成员删除，此时Oracle数据库系统会提示错误信息，拒绝类似的操作。此时数据库系统如果仍然像保留这个重做日志文件组，则只好先建立一个组成员，或者将某个失效的组成员设置为有效，然后再删除不起作用的组成员。其次需要说明的是，如果在重做日志文件中采用多路复用组的话，则最好还要保证多个组中成员数量是相同的 (不是强制性限制)。这主要是因为在多路复用组下，如果每个组的组成员数量相同的话，则多路复用重做日志才可以变得对称。虽然说在每个组中的成员数量不同，并不会对数据库的运行造成负面影响。但是为了后续恢复以及管理的需要，笔者建议，如果采用多路复用的话，在删除组成员时，需要考虑重做日志文件的对称性问题。即最好能够保证删除某个组成员后，每个组的组成员数量是相同的。

　　这个数量上的限制，主要是为了保障重做日志文件的安全性。从某种程度来说，正是因为这个限制才确保数据库管理员可以利用重做日志文件把数据恢复到故障点。为此作为数据库管理员，必须要尊重这个限制条件，并积极的遵守它。

　　限制条件二：最好不要强制删除重做日志文件组。

　　通常情况下，重做日志文件组对应文件有三种状态。如果Oracle数据库系统不能够访问重做日志文件，则这个文件就会变成Invalid状态; 如果Oracle数据库系统觉得重做日志文件不完整或者有错误时，则这个重做日志文件就会变为许久未用状态。当下次失效日志文件所属的组变成活动组时，这个失效日志文件才会再次变成有效状态。删除重做日志文件组时，跟这些文件到状态息息相关。

　　默认情况下，重做日志文件组也分为两种状态，分别为活动状态与非活动状态。在删除重做日志文件组时，笔者建议是先把重做日志文件组设置为非活动状态。然后再进行删除。这么操作有一个好处就是保障重做日志文件组与对应的日志文件与控制文件的关系。如确保更新了数据库的相关控制文件。不过这个限制条件跟第一个限制条件不同，并不是强制性的。如果数据库管理员需要删除当前的活动组，也是可以的。只是需要先强制进行日志切换。虽然这么做也是可行的，但是笔者强烈反对这么操作。因为在强制进行日志切换的过程中，如果操作不当的话，则很有可能破坏重做日志文件的完整性。后续出现问题时利用重做日志文件来恢复数据时，可能会出现问题。同理，在删除组成员的时候，这个组成员也不能够属于当前组或者活动组。如故确实需要删除某个活动组或者当前组的成员时，也是可以的，必须要先强行进行日志切换。

　　为此，除非有特殊的必要，一定需要把当前活动的重做日志文件组删除。否则的话，还是多走一步，先将重做日志文件组设置为非活动状态，然后再进行删除。这更加的保险一点。另外，在删除联机重做日志文件组之前要确保它已经归档。如此的话，可以保障重做日志文件(归档模式下)的完整性。当出现数据库故障时，可以利用这个重做日志文件将数据库恢复到出故障的点。无论是对于重做日志文件组，还是其组成员，都有这方面的要求，尽量避免对活动的组或者当前组进行删除操作。

　　限制条件三：需要手工删除重做日志文件。

　　删除了重做日志文件组或者成员后，其对应的重做日志文件没有被自动删除。如在Oracle数据库中删除了某个重做日志文件组成员之后，其对应的重做日志文件其实并没有从硬盘上删除。这个删除重做日志文件组成员的操作，只是更新了数据库控制文件中的相关内容。只有控制文件中的这些内容被更新，重做日志文件组的成员才能够被删除。所以说，在删除了重做日志组成员之后，其对应的重做日志文件没有被自动删除。需要注意的是，如果把整个重做日志组删除，也是类似的道理。不会把整个组所使用的重做日志文件中硬盘中删除，而只是为删除的需要，更新了控制文件中的相关内容。

　　为此，其实无论是删除重做日志文件组还是删除组成员，都需要分两步走。首先就需要删除重做日志文件组或者组成员。确保这第一步正确完成之后，在进行第二步。第二步就是找到这个组或者成员对应的重做日志文件，然后利用相关的命令来手工删除它。虽然说不删除的话，也没有多少影响。但是这个重做日志文件往往都比较大，不过把没用的重做日志文件不及时清除的话，日积月累，会越积越多。这些没有的重做日志文件，不仅白白耗用了宝贵的硬盘空间，而且在恢复时有可能还会产生误导。为此及时清除这些遗留下来的重做日志文件，是非常有必要的。

　　限制条件四：及时进行删除与调整。

　　由于某些特定的原因需要进行重做文件日志组或者组成员删除的，那么可能对于时效性方面也有比较严格的要求。如由于硬盘介质出现故障导致某个组成员对应的重做日志文件无法正常保存时，此时数据库管理员就应该马上调整这种状况。先删除这个组成员(在有必要的情况下，可能需要先建立一个组成员)，然后再删除操作成功后再删除对应的重做日志文件。如此的话，可以有效的减少由于组中的单个成员原因而导致写入重做日志文件时失败的可能性。所以，有时候对于这个清理的及时性要求也非常高。一般情况下，当重组日志文件写入有错误时，数据库管理员会受到来自于数据库系统的警告信息。此时如果数据库管理员发现是因为硬盘介质等原因造成的写入错误，则数据库管理员需要及时进行调整。以免因小失大，导致整个重做日志文件失效。

　　另外，对于一个比较通用的建议，就是在删除重做日志文件组或者组成员的时候，最好能够先对重做日志文件进行备份。如果采用归档模式的话，那么就可以直接对重做日志文件进行归档操作，让数据库系统自动进行备份操作。如此就可以最大限制的减少这个删除组或者成员操作的风险。再者，就是除非有特殊的必要，最好不要轻易删除重做日志文件组或者成员。因为其是跟重做日志文件是拴在同一个绳上的蚂蚱。如果删除了重做日志文件组或则成员，必定会给其对应的重做日志文件造成毁灭性的打击。为此除非有特殊的必要，则最好删除重做日志组或者成员。有时候可以利用设置为非活动状态来代替。不过向第四个限制条件提到的，在一些必须要删除的情况下，数据库管理员也不能够手软，要快刀斩乱麻。