Oracle的Insert、Update、Delete等DML操作速度的提高

说的小谎.

在Oracle数据库中，Insert、Update、Delete三个操作是对数据库中的数据进行插入、更新以及删除。在进行这些操作时，如果数据库中的记录比较多时，则所需要的时间比较长。如需要利用一个Update语句更新大量记录时，即使更新的内容很简单，如只是将价格提升10%，但是仍然需要花费比较成的时间。所以从某种程度上来说，进行这些操作时其执行速度跟内容的大小关系不大，反而跟记录的多少却有很大的关系。那么在Oracle数据库中，能否采取一些措施来提高这些操作的速度呢?为此笔者有如下两个建议，希望对大家有所帮助。

建议一：在执行这些操作时不向重做日志中写东西。

在执行更新、插入、删除操作时，默认情况下，其在更新数据的同时，也会像重做日志文件中记录这些改变。如利用Update语句将数据库中产品的价格提高10%时。数据库会更改这些价格，同时也会在重做日志中记录这些改变。显然，更新一个数据，数据库要进行两项工作。为此，当更新所涉及到的记录比较多时，这个更新操作就可能要耗费比较长的时间。此时，可能需要更新内容本身字符的多少，跟其更新的效率并不具有很大的联系。其执行的速度主要跟其更新所涉及到的记录数量有关。

为此，有时候在追求其更快的执行速度时，我们往往需要在这些语句中加入一个nologging选项。如在使用Update语句更新价格信息时，加上这个Nologging选项就可以显著提高其执行的速度。更新操作所涉及到的记录越多，其效果越明显。那么这个可选项到底有什么作用呢?顾名思义，这个参数就是告诉数据库系统，在执行这个操作的时候，不要忘重做日志中记录相关的信息。也就是说，此时数据库系统只需要做一件工作即可，至需要更改数据，而不会产生重做日志文件。在理想的状态下，这么设置可以将这些操作的速度提高一倍。所以在进行大规模的更新、删除、插入记录等操作时，笔者往往建议大家加上这个可选项，以提高执行的速度。

不过如果采用这个可选项的话，也有一个缺点。因为其不会产生重做日志，所以如果数据更新失败或者出现其他一些意外故障，就不能够利用重做日志来恢复数据。为此如果对于数据的准确性要求非常苛刻的话，采用这种方式来提高这些操作的执行速度，可能并不是一种合理的方法。其是以牺牲数据的安全性来获取性能上的改进。虽然这些操作出现故障的几率比较少见，但是在使用这个可选项时，数据库管理员必须要了解这个风险。在可能的情况下，即使做好风险的评估与预防。

建议二：调整重做日志的大小来提高执行速度。

上面这种方法由于不产生重做日志，虽然提高了执行的速度，但是也带来了一定的安全风险。那么是否有两全其美的方法呢，即能够提高执行速度，又能够保障数据的安全呢?在Oracle数据库中就有这么一个两全其美的方法。就是调整重做日志的大小来提高执行速度。来具体讲解这个方案时，笔者要强调的是此时数据库仍然会产生重做日志。为此其效果没有上面这种方法好。但是其可以保障数据的安全，在出现问题时，仍然可以利用重做日志来恢复数据。所以说，这是在安全与速度之间实现了一个均衡。

在对记录进行大批量的更新时，在重做日志中产生相关的记录会花费比较多的时间。其实这个时间也可以分为两个部分。一是往重做日志中记录相关信息的时间;二是重做日志进行切换的时间。在Oracle数据库的联机重做日志中，往往同时有多个重做日志文件。当某个重做日志文件满时，则会将后续的记录写到下一个重做日志文件中。但是在写入之前，其需要对这个即将被覆盖的重做日至进行归档，也就是进行备份。在这个备份的时候，Update等更新操作不得不进行等待。要等待其归档完成之后，再继续进行更新并产生重做记录。也就是说，联机重做日志只有在被归档后才能够被覆盖，在这个归档的过程中，其他相关的操作必须等待，直到有可能的联接重做日志。为此，如果这个重做日志的文件比较小，而利用Update更新的记录又比较多时，此时就可能需要使用多个重做日志文件来保存这些更改信息。此时就需要进行多次等待才行。那么就无形之中增加了这个操作的执行时间。所以，经常需要对数据库进行大容量的更新、删除或者插入记录等操作的，最好能够调整这个重做日志文件的大小，以减少重做日志归档的等待时间，提高数据库的性能。

在调整这个重做日志文件之前，数据库管理员最好能够先确认一下，这个重做日志文件归档的频率。如果归档的频率比较高，那么增加重做日志文件的大小，往往可以明显的提高数据库的性能，特别是插入、删除、更新等操作的效率。那么该如何来判断这个重做日志文件归档是否频繁呢?在Oracle数据库中有比较多的方法。其实重做日志文件就跟普通的文件相同，其也有更新时间等属性。为此在操作系统上，可以对比几个重做日志文件的更新时间，来判断其归档的频率是否频繁。另外在Oracle数据库中还有一个动态视图，名字为v$log_history。在这个视图中存放着重做日至切换的相关记录。如数据库管理员可以查询最近50个重做日志的切换记录，看看其相关的时间有多长，从而来判断这个重做日志的切换是正常的，还是太过于频繁。一般情况下，只要增加这个重做日志文件的容量，就可以为大批量的更新、删除等操作提供比较大的重做日志空间。此时执行一个大批量的更新操作时，可能只需要使用一个重做日志文件即可。此时，在重做日志上所花的时间，就是只有产生重做记录的那部分时间，而没有重做日志切换归档时的等待时间。所以，经过类似的调整之后，往往可以在很大程度上提高数据库的性能。另外还有一种可行的方法是，不调整重做日志文件的大小，而是增加重做日志文件的数目。如此也可以在频繁的日志切换过程中提供足够的日志空间。不过笔者还是倾向与增加重做日志文件的容量来解决这个问题。

不过重做日志文件也并不是越大越好。重做日志文件越大，其归档的时间也就越长。俗话说，过之而不及。有时候这反而会给数据库的安全与性能带来负面的影响。根据笔者的经验，笔者认为这个重做日志文件切换的时间间隔最好能够在30分钟-40分钟之间。因为现在即使再复杂的更新或者删除操作，基本上可以在这个时间内完成。否则的话，可能就是语句方面有问题，需要对SQL语句进行优化。所以将这个日志归档的时间间隔确定在这个时间范围之内是合理的。作为合格的数据库管理员，需要持续追踪这个日志切换的时间间隔。可以通过查看两个连续重做日志文件之间的更新时间间隔或者数据库系统的日志切换记录来查看这个日志切换的频率。

当调整完重做日志文件的大小之后，数据库管理员仍然需要在一段时间内追踪这个日志切换的频率。以判断调整后的重做日志文件是否能够实现既定的目标。如果效果不明显的话，可能还需要再次调整这个重做日志文件的大小。

Oracle数据库管理员可以使用ALTER DATABASE ADD LOGFILE语句来创建比较大的日志文件。注意此时需要及时将比较小的日志文件删除。否则的话，大小重做日志文件混用，并不能够起到预计的效果。为此在调整日志文件大小时一般的步骤就是先创建多个大日志文件，然后再将小日志文件删除。一般情况下，在删除小日志文件过程中，最好不要通过删除重做日志文件组来实现。也就是说，在原有的重做日志文件组下面，建立大的重做日志文件;然后只删除小的重做日志文件。即重做日志文件组仍然保持不变。改变的只是其内部的重做日志成员而已。

我不要演i

你会变成大海,然后被鲨鱼吃掉!