|
虽然重做日志文件非常的重要但是有时候数据库管理员仍然需要忍痛割爱将某些重做日志文件组或者组成员删除如当硬盘出现物理损坏此时就无法往这个位置存放重做日志此时为了避免重做日志的错误就需要将其删除然后再新建一个重组日志组成员等等所以有时是删除只是为了其更需更好的工作而已但是删除重做日志文件组或者其成员毕竟不是一件简单的工作在做这个操作的时候数据库管理员需要注意几个限制条件 限制条件一数量上的限制 通常情况下Oracle数据库系统治少需要两个重做日志文件组如果数据库系统中只有两个重做日志文件组而出于某种原因数据库管理员需要删除其中的一个重做日志文件组则数据库会拒绝这个操作如故确实有必要需要删除这个重做日志文件组那么数据库管理员必须先新建一个重组日志文件组然后再把需要删除的日志文件组删除这是Oralce数据库对于重做日志文件组数量上的限制作为数据库管理员必须无条件的遵守 另外对于组成员来说也有类似的限制每个重做日志文件组必须要有一个有效的成员如因为硬盘介质错误等原因需要把唯一的一个组成员删除此时Oracle数据库系统会提示错误信息拒绝类似的操作此时数据库系统如果仍然像保留这个重做日志文件组则只好先建立一个组成员或者将某个失效的组成员设置为有效然后再删除不起作用的组成员其次需要说明的是如果在重做日志文件中采用多路复用组的话则最好还要保证多个组中成员数量是相同的(不是强制性限制)这主要是因为在多路复用组下如果每个组的组成员数量相同的话则多路复用重做日志才可以变得对称虽然说在每个组中的成员数量不同并不会对数据库的运行造成负面影响但是为了后续恢复以及管理的需要笔者建议如果采用多路复用的话在删除组成员时需要考虑重做日志文件的对称性问题即最好能够保证删除某个组成员后每个组的组成员数量是相同的 这个数量上的限制主要是为了保障重做日志文件的安全性从某种程度来说正是因为这个限制才确保数据库管理员可以利用重做日志文件把数据恢复到故障点为此作为数据库管理员必须要尊重这个限制条件并积极的遵守它 限制条件二最好不要强制删除重做日志文件组 通常情况下重做日志文件组对应文件有三种状态如果Oracle数据库系统不能够访问重做日志文件则这个文件就会变成Invalid状态;如果Oracle数据库系统觉得重做日志文件不完整或者有错误时则这个重做日志文件就会变为许久未用状态当下次失效日志文件所属的组变成活动组时这个失效日志文件才会再次变成有效状态删除重做日志文件组时跟这些文件到状态息息相关 默认情况下重做日志文件组也分为两种状态分别为活动状态与非活动状态在删除重做日志文件组时笔者建议是先把重做日志文件组设置为非活动状态然后再进行删除这么操作有一个好处就是保障重做日志文件组与对应的日志文件与控制文件的关系如确保更新了数据库的相关控制文件不过这个限制条件跟第一个限制条件不同并不是强制性的如果数据库管理员需要删除当前的活动组也是可以的只是需要先强制进行日志切换虽然这么做也是可行的但是笔者强烈反对这么操作因为在强制进行日志切换的过程中如果操作不当的话则很有可能破坏重做日志文件的完整性后续出现问题时利用重做日志文件来恢复数据时可能会出现问题同理在删除组成员的时候这个组成员也不能够属于当前组或者活动组如故确实需要删除某个活动组或者当前组的成员时也是可以的必须要先强行进行日志切换 为此除非有特殊的必要一定需要把当前活动的重做日志文件组删除否则的话还是多走一步先将重做日志文件组设置为非活动状态然后再进行删除这更加的保险一点另外在删除联机重做日志文件组之前要确保它已经归档如此的话可以保障重做日志文件(归档模式下)的完整性当出现数据库故障时可以利用这个重做日志文件将数据库恢复到出故障的点无论是对于重做日志文件组还是其组成员都有这方面的要求尽量避免对活动的组或者当前组进行删除操作 限制条件三需要手工删除重做日志文件 删除了重做日志文件组或者成员后其对应的重做日志文件没有被自动删除如在Oracle数据库中删除了某个重做日志文件组成员之后其对应的重做日志文件其实并没有从硬盘上删除这个删除重做日志文件组成员的操作只是更新了数据库控制文件中的相关内容只有控制文件中的这些内容被更新重做日志文件组的成员才能够被删除所以说在删除了重做日志组成员之后其对应的重做日志文件没有被自动删除需要注意的是如果把整个重做日志组删除也是类似的道理不会把整个组所使用的重做日志文件中硬盘中删除而只是为删除的需要更新了控制文件中的相关内容 为此其实无论是删除重做日志文件组还是删除组成员都需要分两步走首先就需要删除重做日志文件组或者组成员确保这第一步正确完成之后在进行第二步第二步就是找到这个组或者成员对应的重做日志文件然后利用相关的命令来手工删除它虽然说不删除的话也没有多少影响但是这个重做日志文件往往都比较大不过把没用的重做日志文件不及时清除的话日积月累会越积越多这些没有的重做日志文件不仅白白耗用了宝贵的硬盘空间而且在恢复时有可能还会产生误导为此及时清除这些遗留下来的重做日志文件是非常有必要的 限制条件四及时进行删除与调整 由于某些特定的原因需要进行重做文件日志组或者组成员删除的那么可能对于时效性方面也有比较严格的要求如由于硬盘介质出现故障导致某个组成员对应的重做日志文件无法正常保存时此时数据库管理员就应该马上调整这种状况先删除这个组成员(在有必要的情况下可能需要先建立一个组成员)然后再删除操作成功后再删除对应的重做日志文件如此的话可以有效的减少由于组中的单个成员原因而导致写入重做日志文件时失败的可能性所以有时候对于这个清理的及时性要求也非常高一般情况下当重组日志文件写入有错误时数据库管理员会受到来自于数据库系统的警告信息此时如果数据库管理员发现是因为硬盘介质等原因造成的写入错误则数据库管理员需要及时进行调整以免因小失大导致整个重做日志文件失效 另外对于一个比较通用的建议就是在删除重做日志文件组或者组成员的时候最好能够先对重做日志文件进行备份如果采用归档模式的话那么就可以直接对重做日志文件进行归档操作让数据库系统自动进行备份操作如此就可以最大限制的减少这个删除组或者成员操作的风险再者就是除非有特殊的必要最好不要轻易删除重做日志文件组或者成员因为其是跟重做日志文件是拴在同一个绳上的蚂蚱如果删除了重做日志文件组或则成员必定会给其对应的重做日志文件造成毁灭性的打击为此除非有特殊的必要则最好删除重做日志组或者成员有时候可以利用设置为非活动状态来代替不过向第四个限制条件提到的在一些必须要删除的情况下数据库管理员也不能够手软要快刀斩乱麻 |
