1
_大数据量删除的思考 - 3.pdf
5墨值下载
大数据量删除的思考 - 3
译者 王显伟 · 沃趣科技高级数据库工程师
出品 沃趣科技
在本系列的上一部分中，我们研究了在大数据删除表和索引和案例。在这一部分中，我们将继续讨论不同案例
所隐含的工作量，然后考虑删除策略，或者需要制定减少工作量的策略。
基本开销部分
除了时间本身，我们还要关注其它三个指标，即大数据删除的过程中：生成的undo和生成的redo以及发生的I/
O量。这些因素并不是相互独立的，这在优化删除的一般性讨论中引入了很多复杂性，并且删除操作本身可能会
影响同时运行的其他会话，并且同时其他会话也可能影响大数据删除。
Redo ：对每个数据块的更改都会生成redo，描述如何修改块以及几十个字节的开销：如果表上有四个索引，
那么可以认为是删除的每一行更改5个块（一个表块，四个索引叶块）。
Undo ：每次删除行时，通过在undo段中写入如何重新插入该行的说明以及如何“撤销删除”索引条目来“保
留”该行。每个undo条目都有几十个字节的开销，每个undo条目都是对数据块的更改，因此生成更多redo，
结合两个重做源，单行删除和四个受影响的索引可以产生大约1KB的重做，加上删除的行和索引条目的大小。
I / O ：将数据块读入缓冲区缓存中以删除一行，同时必须读入缓冲区缓存每个受删除行影响的索引叶块。在某
个阶段，oracle必须构造出已更改的数据（和索引）块，其中包括一直在更改的undo块，这个时不得不面对的
等待，但幸运的是，写入可能会在后台处理，并且可能不会影响删除的速率; 但另一方面，对于一个非常大的删
除，我们可能会发现生成的undo量是如此之大，并且表和索引的读取如此随机，以至于数据库不断的刷新
buffer cache进而导致写入极为缓慢。
并发 (1) ：即使只有一个只读会话，undo和redo日志也不会停止产生日志，如果其他会话必须检查已修改
（但尚未提交）的块，那么必须使用undo块来检查提交时间并生成已更改的块的读取一致版本，以便可以看到
我们要删除的行。这有两个影响，第一其他会话最终可能会物理读取undo块（增加I / O负载），然后强制数据
库刷新buffer写入磁盘，以使buffer可用于它们要创建的读取一致性副本（进一步增加I/ O负载），第二，如果
另一个会话必须从磁盘读取我们已经更改的块，那么它将要做的第一件事就是准备应用”延迟块清除”对于它
将在那里找到的未提交的更改（即将的删除的数据）, 即使发现它不需要进行清除oracle仍然会生成60个字节的
undo，并且每次从盘中读取这样的块，读取会话将生成另外60个字节，直到我们最终提交并且下一个读取块的
会话执行“适当的”延迟块清除。大数据的删除运行运行时间越长速度越慢，这些并发效应可能是其中一个重
要原因。
并发 (2) ：那么并发性问题可能会更严重——甚至忽略了另一个会话可能正在锁定我们要删除的行的可能性，
并让会话等待TX锁。即使没有其他会话更改我们尝试删除的任何行，它们也可能更改与要删除的行共享块的
行，并且我们必须创建这些块的读取一致性副本，以检查开始删除时当前是否存在数据，以及当我们开始的时
候就在那里的数据还没有消失——我们需要做一个“写一致性”删除：最好这意味着我们可以做大量的工作检
查，最坏的情况下，这意味着我们可能会发现我们的会话发现一个它无法处理的不一致，然后回滚并重新启动
自动删除。后者可能有点罕见，前者是导致大型删除在运行过程中变得越来越慢的两个关键原因之一。
一些有趣的数据
在上一部分中，我们提供了一些代码来创建一个包含四个索引的表，以作为一些思想实验的基础，现在使用该
数据来生成一些性能数据。在我这样做之前，值得一提的是优化器如何计算删除的成本，其实非常简单：成本
是等效“selectrowid from ...”查询的成本，用于标识要删除的行的rowid。优化器不允许访问表的成本删除
行，也不允许维护索引的成本。
在一个简单的删除案例，如 “deletefrom t1 where client_ref < ‘F’” 这意味着oracle将会在三个执行计划
中选择一个，可能是全表扫描t1和索引扫描client_ref或者采用索引快速全扫描client_ref，实际上，直达12c优
化器才会选择indexfast full scan，这一点可以说是oracle的一个bug，直到12.1.0.2生版本才被修复。
下面我们看看两个删除语句的几个数字：第一个将删除date_open超过五年前的所有行（即最旧的50％的数
据），第二个将删除带有引用的客户端以字母A到E开头的代码（小于20％的数据）。
delete from t1
where date_open < add_months(sysdate, -60);
5000000 rows deleted.
我们假设六种不同的场景，当没有索引时，从表中删除，第二个场景只有主键索引，第三个场景中有主键和
client_ref索引，在所有这三种情况下，删除将遵循完整的表扫描。
最后三个场景将包含所有四个索引（主键，date_open，date_closed和client_ref）; 第一个方案将使用表扫
描，第二个将使用索引快速全扫描的date_open索引-在默认情况下出现的，事实上，与12C的路径-最后将使用
索引范围扫描的date_open索引。
从v $ sesstat视图我们可以看到redo条目的数量，redo大小和undo更改向量大小，每次删除的实际执行时间，
这里需要注意的是，执行时间对于一般情况来说并不是一个好的指标，因为假如使用的是固态磁盘，所以任何I/
O都会非常快，而且运行时可以与访问和修改的块数相比，缓冲区缓存的大小受到的影响最大。
另外一点需要明确说明 - 在每次测试之后都使用drop table purge方式并重新创建表，因此每次的测试结果与
先前的测试是无关的，具体测试结果如下：
of 5
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论