SQL语句是一种方便的语言，同样也是一种“迷惑性”的语言。这个主要体现在它的集合操作特性上。无论数据表数据量是1条，还是1亿条，更新的语句都是完全相同。但是，实际执行结果（或者能否出现结果）却是有很大的差异。
笔者在开发DBA领域的一个理念是：作为开发人员，对数据库、对数据要有敬畏之心，一个语句发出之前，起码要考虑两个问题：目标数据表的总数据量是多少（投产之后）？你这个操作会涉及到多大的数据量？不同的回答，处理的方案其实是不同的。
更新大表数据，是我们在开发和运维，特别是在数据迁移领域经常遇到的一种场景。上面两个问题的回答是：目标数据表整体就很大，而且更新范围也很大。一个SQL从理论上可以处理。但是在实际中，这种方案会有很多问题。
本篇主要介绍几种常见的大表处理策略，并且分析出他们的优劣。作为我们开发人员和DBA，选取的标准也是灵活的：根据你的操作类型（运维操作还是系统日常作业）、程序运行环境（硬件环境是否支持并行）和程序设计环境（是否可以完全独占所有资源）来综合考量决定。
首先，我们需要准备出一张大表。
1、环境准备
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 – Production
准备一张大表。
SQL> create table t as select * from dba_objects;
Table created
SQL> insert into t select * from t;
72797 rows inserted
SQL> insert into t select * from t;
145594 rows inserted
（篇幅原因，中间过程略……）
SQL> commit;
Commit complete
SQL> select bytes/1024/1024/1024 from dba_segments where owner='SYS' and segment_name='T';
BYTES/1024/1024/1024
--------------------
1.0673828125
SQL> select count(*) from t;
COUNT(*)
----------
9318016
Executed in 14.711 seconds
数据表T作为数据来源，一共包括9百多万条记录，合计空间1G左右。笔者实验环境是在虚拟机上，一颗虚拟CPU，所以后面进行并行Parallel操作的方案就是示意性质，不具有代表性。
下面我们来看最简单的一种方法，直接update。
2、方法1：直接Update
最简单，也是最容易出问题的方法，就是“不管三七二十一”，直接update数据表。即使很多老程序员和DBA，也总是选择出这样的策略方法。其实，即使结果能出来，也有很大的侥幸成分在其中。
我们首先看笔者的实验，之后讨论其中的原因。先创建一张实验数据表t_target。
SQL> create table t_targettablespace users as select * from t;
Table created
SQL> update t_target set owner=to_char(length(owner));
（长时间等待……）
在等待期间，笔者发现如下几个现象：
ü 数据库服务器运行速度奇慢，很多连接操作速度减缓，一段时间甚至无法登陆；
ü 后台会话等待时间集中在数据读取、log space buffer、空间分配等事件上；
ü 长期等待，操作系统层面开始出现异常。Undo表空间膨胀；
ü 日志切换频繁；
此外，选择这样策略的朋友还可能遇到：前台错误抛出异常、客户端连接被断开等等现象。
笔者遇到这样的场景也是比较纠结，首先，长时间等待（甚至一夜）可能最终没有任何结果。最要命的是也不敢轻易的撤销操作，因为Oracle要进行update操作的回滚动作。一个小时之后，笔者放弃。
updatet_target set owner=to_char(length(owner))
ORA-01013: 用户请求取消当前的操作
（接近一小时未完成）
之后就是相同时间的rollback等待，通常是事务执行过多长时间，回滚进行多长时间。期间，可以通过x$ktuxe后台内部表来观察、测算回滚速度。这个过程中，我们只有“乖乖等待”。
SQL> select KTUXESIZ from x$ktuxe where KTUXESTA<>'INACTIVE';
KTUXESIZ
----------
62877
（……）
SQL> select KTUXESIZ from x$ktuxe where KTUXESTA<>'INACTIVE';
KTUXESIZ
----------
511
综合这种策略的结果通常是：同业抱怨（影响了他们的作业执行）、提心吊胆（不知道执行到哪里了）、资源耗尽（CPU、内存或者IO占到满）、劳而无功（最后还是被rollback）。如果是正式投产环境，还要承担影响业务生产的责任。
我们详细分析一下这种策略的问题：
首先，我们需要承认这种方式的优点，就是简单和片面的高效。相对于在本文中其他介绍的方法，这种方式代码量是最少的。而且，这种方法一次性的将所有的任务提交给数据库SQL引擎，可以最大程度的发挥系统一个方面（CPU、IO或者内存）的能力。
如果我们的数据表比较小，经验值在几万一下，这种方法是比较合适的。我们可以考虑使用。
另一方面，我们要看到Oracle Update的另一个方面，就是Undo、Redo和进程工作负载的问题。熟悉Oracle的朋友们知道，在DML操作的时候，Undo和Redo是非常重要的方面。当我们在Update和Delete数据的时候，数据块被修改之前的“前镜像”就会保存在Undo Tablespace里面。注意：Undo Tablespace是一种特殊的表空间，需要保存在磁盘上。Undo的存在主要是为了支持数据库其他会话的“一致读”操作。只要事务没有被commit或者rollback，Undo数据就会一直保留在数据库中，而且不能被“覆盖”。
Redo记录了进行DML操作的“后镜像”，Redo生成是和我们修改的数据量相关。现实问题要修改多少条记录，生成的Redo总量是不变的，除非我们尝试nologging选项。Redo单个日志成员如果比较小，Oracle应用生成Redo速度比较大。Redo Group切换频度高，系统中就面临着大量的日志切换或者Log Space Buffer相关的等待事件。
如果我们选择第一种方法，Undo表空间就是一个很大的瓶颈。大量的前镜像数据保存在Undo表空间中不能释放，继而不断的引起Undo文件膨胀。如果Undo文件不允