分区数据库环境下 DB2 LOAD 性能调优

最新推荐文章于 2023-08-30 16:30:06 发布

mydriverc2

最新推荐文章于 2023-08-30 16:30:06 发布

阅读量2k

点赞数 1

分类专栏：数据库类

数据库类专栏收录该内容

95 篇文章 1 订阅

订阅专栏

转自： http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1112wul/

DB2 LOAD 线程模型

在本文中，除非特别声明，对于 DB2 LOAD 的讨论都是在分区数据库环境下。同时本文专注于讨论分区数据库环境下 DB2 LOAD 的性能调优，不再对分区数据库中的基本概念进行赘述，阅读本文的读者需要对分区数据库概念有基本的了解。LOAD 作为 DB2 的实用程序，广泛地应用于各种数据移动场景中，尤其是在数据仓库的 ETL 过程中，LOAD 更是占据了主导地位。因此如何有效地提升 LOAD 性能，在数据移动场景中满足客户的需求和期望，是至关重要的。在对 LOAD 性能进行调优之前，首先需要理解 LOAD 中各相关线程的作用和特点，从而有针对性地进行调整、优化。LOAD 线程模型如图 1 所示。

图 1. LOAD 线程模型

在 DB2 中，LOAD 操作请求由代理线程 db2agent 受理，该线程负责派生、协调、监视相关 LOAD 线程。LOAD 内部相关线程的处理流程，从预分区代理线程（db2lpprt）开始。预分区代理只存在于 Coordinator 分区节点，读入输入数据源，通过 TCP/IP 网络将数据记录分发至各数据库分区的分区代理线程（db2lpart）。分区代理存在于各数据库分区，对数据记录的分区键进行计算从而决定该条记录应去往哪个数据库分区。当分区代理决定了数据记录的去向，即通过 TCP/IP 网络将数据记录发送至各对应分区的媒体录入线程（db2lmr）。媒体录入线程对数据记录进行初步处理，通过共享内存将数据记录发送给格式化线程（db2lfrm），该线程对所有数据记录进行格式化，并将格式化后的数据记录发送给 Ridder 线程（db2lrid），Ridder 线程为每条记录分配 RID，并创建表空间扩展数据块（EXTENT），随后将扩展数据块发送给缓存处理线程（db2lbm），由该线程将数据最终写入到磁盘上。

在接下来的章节，我们会详细地分析 LOAD 各相关线程的作用，以及可能对其性能造成影响的各方面因素。这些因素包括，系统级参数、网络参数、实例级参数、数据库级参数，LOAD 参数等。造成 LOAD 性能瓶颈的可能原因有很多，如 CPU 受限、内存瓶颈、网络受限、I/O 瓶颈等等。通过以 DB2 LOAD 线程模型为纲，对 LOAD 性能调优进行细化，目的是做到有的放矢，让调优更有针对性。

LOAD 线程解析与参数调优

在本章节中，我们将以 LOAD 内部处理流程的顺序逐一解析相关线程的作用，以及影响其性能的因素，并对相关关键参数的设置给出了参考建议。

预分区代理线程 (db2lpprt)

预分区代理只存在于 Coordinator 分区节点中，该线程的数量会因参数设置不同而有所变化。该线程的主要作用是读取输入数据源，并通过 TCP/IP 网络以 Round-robin 的方式将数据记录平均分发到各数据库分区的分区代理线程（db2lpart）。

可能对该线程的处理性能造成影响的因素包括网络和 I/O。预分区代理从磁盘读取输入数据源，除存储设计本身的因素外，I/O 相关的参数设置不当，有可能造成 I/O 瓶颈；读取的数据记录需要通过 TCP/IP 网络发送至各数据库分区，除了网络本身带宽因素外，网络相关参数设置不当，也会对 LOAD 整体性能造成影响。

系统级参数：

queue_depth 该参数指定磁盘 I/O 请求队列的长度，会影响磁盘 I/O 性能，尤其是在数据库等 I/O 密集型应用中。将该参数的值设置较大有利于获得更好的性能。
maxpgahead 该参数指定顺序预读取的最大数据页数，默认值为 8，但通常增加该值能够获得更好的顺序读取性能。

网络参数：

tcp_nodelayack 该参数决定 TCP 接收方是否立即将确认包（ACK）返回给发送方，当开启该参数时（tcp_nodelayack = 1），TCP 接收方立即返回 ACK 包，不产生延迟；当关闭该参数时（tcp_nodelayack = 0）TCP 接收方会最多延迟 200ms 才将 ACK 包返回给发送方。
tcp_recvspace 该参数指定 TCP/IP socket 默认数据接收缓存大小。
tcp_sendspace 该参数指定 TCP/IP socket 默认数据发送缓存大小。

分区数据库环境下，LOAD 的数据流向是单向的，数据接收方不会将接收到的数据发送回发送方，即分区代理线程不会将接收到的数据记录再发送给预分区代理线程。因此，可以通过开启参数 tcp_nodelayack（tcp_nodelayack = 1）来消除网络延迟，提升网络性能。对于参数 tcp_recvspace 和 tcp_sendspace，通常建议将该值设置较大，以提升网络性能。

LOAD 参数：

ANYORDER 如果指定该文件类型修饰符，则 DB2 会为每一个输入数据源分配一个预分区代理线程，且 LOAD 在向表空间容器中写入格式化的数据记录时，不会维持输入数据源中数据记录的原始顺序；若未指定该参数，则只分配一个预分区代理来顺序处理各输入数据源。在 I/O 资源没有被充分利用的情况下，建议指定该参数在数据读取阶段提升 I/O 性能。

分区代理线程 (db2lpart)

分区代理线程的数量和所在数据库分区，都可以通过参数来指定，每一个数据库分区并不要求一定要有分区代理线程存在。分区代理通过 Round-robin 的方式从预分区代理接收数据记录，对每一条数据记录的分区键（Distribution Key）进行计算，并创建 Distribution Map 项，从而决定该条记录应该去往哪个数据库分区。

分区阶段的 CPU 开销比加载阶段的 CPU 开销要小得多，很难用足所有的 CPU 资源，因而 CPU 基本上不会成为性能瓶颈。这一阶段的性能瓶颈更可能来自网络的限制，因为分区代理需要将分布好的数据记录通过 TCP/IP 网络发送到对应的数据库分区上。因此在分区阶段，也需要考虑上述网络参数的设置。

LOAD 参数：

PARTITIONING_DBPARTNUMS 该选项指定分区代理线程的数量和所在数据库分区，这些因素都会对 LOAD 的性能产生影响。通常，在预分区代理未遭遇 CPU 瓶颈、I/O 瓶颈的情况下，适当增加分区代理的数量可以改善 LOAD 整体性能。

媒体录入线程 (db2lmr)

媒体录入线程通过 TCP/IP socket 获取分布到本数据库分区上的数据记录，该线程获得缓存空间，存储并解析输入数据。在 LOAD 线程模型中，每个数据库分区只有一个媒体录入线程。该线程的主要作用是对数据记录进行语法解析与检查，如果发现不符合目标表定义的数据列，则将该条数据记录转储到 DUMP 文件中。可以通过指定文件类型修饰符来避免语法检查。

LOAD 参数：

FASTPARSE 该文件类型修饰符指定媒体录入线程无需对输入数据记录进行语法解析和检查，进而提升 LOAD 性能。当输入数据源本身比较健壮，不存在语法错误时，推荐使用该文件类型修饰符。启用该参数，LOAD 性能可获得一定程度的提升。

格式化线程 (db2lfrm)

格式化线程获取缓存空间，接收来自媒体录入线程解析后的数据记录，将数据记录中的各种数据类型格式化为二进制数据，并创建记录列表，最后将记录列表发送至 Ridder 线程（db2lrid）。该线程的数量可通过参数来设置，通常格式化过程是 LOAD 加载阶段中最消耗 CPU 资源的一项工作，因此合理的配置 CPU 资源至关重要。

LOAD 参数：

CPU_PARALLELISM 该参数设置 LOAD 格式化线程的数量，默认值为每一个数据库分区中可用 CPU 数量（注意，不是物理机器中可用 CPU 数量），通常默认值已经是最优设置，无需手动更改该参数。需要注意的是，当分配给 LOAD 实用程序的内存资源（DATA BUFFER）不能满足请求的 EDU（db2lfrm）数量时，LOAD 内部会降低 CPU 并行度。
DATA BUFFER 该参数指定 LOAD 用于内部处理的内存容量，默认值为数据库实用程序堆（UTIL_HEAP_SZ）可用值的四分之一。但是该默认值通常情况下过低，不能满足 LOAD 对内存的需求，应手动更改将其设置为更高。该参数对 LOAD 性能的影响非常重要，较小的内存空间可能导致 CPU 并行度的下降。
NOROWWARNINGS 在加载过程中，LOAD 会为每一条被拒绝、未格式化的数据行记录消息，消息文件的写入会对 LOAD 性能产生较大影响，有时甚至占据大部分 LOAD 处理时间。如果更加注重 LOAD 性能，而不关心数据行被拒绝的原因，可以启用该文件类型修饰符来避免向消息文件中写入记录级别的警告信息，从而提升 LOAD 性能。

Ridder 线程 (db2lrid)

Ridder 线程获取缓存空间，接收来自格式化线程的记录列表，为列表中的每条记录分配 RID，并创建表空间扩展数据块（EXTENT），创建好的扩展数据块通过共享内存发送至缓存处理线程（db2lbm）。Ridder 线程同时还负责索引键排序与索引创建、统计信息收集、一致点检查等工作。需要注意的是，每个数据库分区只有一个 Ridder 线程，但 Ridder 线程负责的工作繁多而又复杂，所以在该阶段需要各方面的调优从而使得该处理线程不致成为 LOAD 整体性能的瓶颈。

LOAD 参数

STATISTICS LOAD 在加载数据的过程中，可以同时收集表和索引的统计信息，这比 LOAD 运行完成后用 RUNSTATS 来收集统计信息要高效的多，因为后者需要对表数据进行重新扫描。但是收集统计信息会造成比较严重的开销，且收集统计信息的工作由唯一的 Ridder 线程来完成，最多可影响 LOAD 300% 的性能，通常占据了 LOAD 的绝大多数处理时间。通常建议将此参数设置为 NO。

Ridder 线程另一项很重要（同时对 LOAD 性能影响较大）的工作是索引的维护，包括索引的排序和重建。LOAD 支持三种索引模式（REBUILD,INCREMENTAL,DEFERRED），可以通过关键字 INDEXING MODE 来指定。

表 1. 索引模式

REBUILD	INCREMENTAL	DEFERRED
该索引模式下，如果是脱机 LOAD 模式，则在开始索引重建之前，将当前已存在索引对象置为无效；如果是联机 LOAD 模式，则创建一份新的索引影像，允许并发用户访问旧的索引对象，当最终提交时，会用新的索引影像替换旧的索引对象。	该索引模式下，只需要将新插入数据记录的索引键添加到已有的索引对象即可。如果是联机 LOAD 模式，新插入但还未提交的记录索引键，通过伪插入（pseudo-inserted）算法对用户是不可见的，LOAD 提交后对用户立即可见。该索引模式下，LOAD 会对新插入记录的索引更改进行日志记录，产生少量日记记录开销。	该索引模式下，将当前索引对象置为无效，不会重建或追加索引。如果 LOAD 完成后，没有显示地重建索引（CREATE INDEX），那么索引管理器会根据数据库配置参数 INDEXREC（ACCESS,RESTART 等）的设置来选择重建索引的时机。

无论目标表上有多少索引，LOAD 会为每一个索引做排序，这些排序是顺序进行的，索引对象的创建也是顺序进行的，统一由一个代理线程 db2agent 依次顺序完成。与此不同的是，索引管理器在创建索引时，采用了不同的机制。当通过 CREATE INDEX 来创建索引时，在分区数据库环境下，会生成多个代理线程来创建索引。鉴于每个 db2agent 都会分配私有排序堆（SORTHEAP），因此 CREATE INDEX 方式能够更好地利用内存资源。所以通常情况下，如果不是必需，不推荐在 LOAD 过程中创建索引；更有效的方式是在 LOAD 前，将目标表索引对象删除，在 LOAD 完成后，通过 CREATE INDEX 方式在目标表上重建索引。通常在以下两种情况，才推荐在 LOAD 过程中创建索引：

LOAD 加载的数据量（INSERT 方式）与目标表现存数据量相比，较小，这时推荐采用索引模式 INCREMENTAL 来维护索引；此时如果采用 CREATE INDEX 方式，会对目标表所有数据行进行索引重建。
目标表索引数量过多，导致 CREATE INDEX 方式的并行扫描、排序的时间甚至超过了 LOAD 过程中表扫描、排序的时间。

如果只关心 LOAD 整体性能，而忽略索引对象的维护，推荐采用在 LOAD 前删除目标表索引对象，LOAD 完成后以 CREATE INDEX 方式来维护索引的方式，因为索引对象的创建和维护会造成比较严重的开销，经常占据 LOAD 的绝大多数处理时间。但如果客户明确要求需要测试 LOAD 过程中创建、维护索引的场景，则需要考虑如下因素来尽量提升该阶段的性能。

实例级参数

SHEAPTHRESH 该参数确定了实例内所有私有排序内存总量的软上限，当实际值超过该参数设置时，新的排序请求获得的内存空间将远远小于所请求的内存容量大小，因此推荐增大对该参数的设置，从而为排序请求设定更大的可用内存空间。
DIAGLEVEL 该参数指定向 DB2 诊断文件 db2diag.log 中写入的内容，如果将该参数设置为 4，即包含信息性消息，则会大量增加写入的信息量。不同线程对 db2diag.log 文件的写入，会加 X 锁（eXclusive 锁），频繁地对 db2diag.log 文件访问，可能导致不同程度的锁等待，从而影响整体性能。通常建议将该参数降至为 3，即只包含错误和警告信息。

数据库级参数

SORTHEAP 该参数确定了每个代理线程 db2agent 用于排序的内存空间大小。当所需要排序的数据量超过该参数的设定时，排序数据会溢出到临时表空间的缓冲池中，如果缓冲池依然不足以容纳溢出的排序数据，则溢出数据最终被写到磁盘上，造成额外的 I/O 开销。因此，在允许的情况下，尽量增大对该参数的设置，同时要尽可能地创建更大的缓冲池，避免额外的 I/O 开销。
NUM_IOSERVERS 该参数指定数据预读取线程的数量，鉴于可能造成的 I/O 开销，应考虑增大对该参数的设置。
NUM_IOCLEANERS 该参数指定脏数据写入线程的数量，鉴于可能造成的 I/O 开销，应考虑增大对该参数的设置。

缓存处理线程 (db2lbm)

缓存处理线程通过共享内存从 Ridder 线程获取格式化的扩展数据块，形成数据页，并将其写入磁盘。如果指定 COPY YES 选项，则缓存处理线程会将扩展数据块和数据页发送给媒体写入线程（图 1.中未标出），后者将数据写入至 Load Copy。

LOAD 参数

DISK_PARALLELISM 该参数确定了每个数据库分区内缓存处理线程的数量，默认值为表空间容器数量或者格式化线程数量的四分之一（取最大值）。通常该参数的默认值已经是最优配置，无需手动更改。但是当表空间横跨的磁盘较多，如表空间是创建在磁盘阵列上时，增大该参数的设置有利于获得更好的性能。
COPY YES 由于 LOAD 过程中记录的日志内容较少，在可恢复数据库中，在 LOAD 完成后，目标表所在表空间会处于 Backup Pending 状态，用户无法对表空间进行 DML 操作（INSERT,UPDATE,DELETE），数据库要求立即对表空间进行备份。为了避免在 LOAD 完成后，表空间处于 Backup Pending 状态，可以指定 COPY YES 选项，从而在 LOAD 过程中对表空间进行备份，该备份称为 Load Copy。

需要注意的是，在 LOAD 过程中，表空间备份本身和将备份写入磁盘所造成的 I/O 开销，都会对 LOAD 整体性能产生影响。如果存储系统不能提供足够的并行 I/O 进而消化掉备份所带来的 I/O 消耗，那么在 LOAD 过程中对表空间进行备份就会成为性能瓶颈。可以通过选项 COPY NO 和 NONRECOVERABLE 指定在 LOAD 过程中不要备份表空间，二者区别在于：

COPY NO LOAD 过程中不备份表空间，但 LOAD 完成后，表空间处于 Backup Pending 状态，需要手动对表空间进行备份，否则无法进行 DML 访问。
NONRECOVERABLE LOAD 过程中不备份表空间，LOAD 完成后，表空间可以进行正常的访问，但是当数据库进行恢复和前滚操作时，LOAD 对目标表进行的更改将丢失，目标表也会处于异常状态，无法访问。

通常在性能测试中，为了提升 LOAD 整体性能，采用 COPY NO 选项，在 LOAD 完成后，手动地对目标表所在表空间进行备份。

实例演示

在本章节中，对 LOAD 进行实例演示，通过关键参数调整前后的对比来展示性能调优的效果。实例演示分为四部分，即硬件环境、数据库环境、测试场景和测试结果。

硬件环境

该实例演示的硬件环境为两台 IBM SystemX 3650，架构为 x86_64，配置为双核 2.6GHz CPU，16GB 内存，900GB 硬盘存储。两台 Server 通过 1Gbit 以太网进行通信。

数据库环境

操作系统环境为 SuSE Linux Enterprise Edition，内核为 2.6.16.60；数据库版本为 DB2 9.7 for Linux，UNIX and Windows。分区数据库环境：在每台 Server 上创建两个数据库分区，总共四个数据库分区。这样每个数据库分区占用的资源大致为 1 个 CPU，7GB 内存，400GB 存储空间。

测试场景

本 LOAD 测试的输入数据源为 DEL 格式，记录数为 10485760，达到千万行数量级，文件存储大小为 2.7GB。本次测试的测试方法论为，保证其他关键参数不变，对关注参数（某一个参数）进行调整，对比调整前后 LOAD 性能情况，从而展示该关注参数对 LOAD 性能的影响。此次测试的关注参数包括：ANYORDER，FASTPARSE，STATISTICS，COPY YES/NO，DATA BUFFER，SORTHEAP，SHEAPTHRES。下文将逐一对这些场景进行描述。测试用目标表结构及其创建语句如下：

清单 1. 目标表结构

				
 CREATE TABLE LOAD_PERF (A INT,B INT,C CHAR(128),D CHAR(128))

场景 1

目标表无索引，在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：未指定 ANYORDER
调整后：指定 ANYORDER

清单 2. 调优前 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY FASTPARSE NOROWWARNINGS INSERT INTO LOAD_PERF 
 STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

清单 3. 调优后 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

场景 2

目标表无索引，在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：未指定 FASTPARSE
调整后：指定 FASTPARSE

清单 4. 调优前 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER NOROWWARNINGS INSERT INTO LOAD_PERF 
 STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

调优后的 LOAD 命令请参看清单 3.

场景 3

目标表无索引，在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：指定 STATISTICS YES
调整后：指定 STATISTICS NO

清单 5. 调优前 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS REPLACE INTO 
 LOAD_PERF STATISTICS YES COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

调优后的 LOAD 命令请参看清单 3.

场景 4

目标表无索引，在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：指定 COPY YES
调整后：指定 COPY NO

清单 6. 调优前 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY YES TO /home/wulei/LOAD/ DATA BUFFER 5000 
 PARTITIONED DB CONFIG PARTITIONING_DBPARTNUMS(0,1,2,3)

调优后的 LOAD 命令请参看清单 3.

场景 5

目标表无索引，在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：采用默认 DATA BUFFER 值，数据库参数 UTIL_HEAP_SZ 默认值为 5000
调整后：手动设置 DATA BUFFER 值为 5000

清单 7. 调优前 LOAD 命令

				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY NO PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

调优后的 LOAD 命令请参看清单 3.

场景 6

目标表有索引，索引列数量为一列，数据类型为 Integer，索引为非唯一索引。LOAD 中索引模式 INDEXING MODE 为默认的 REBUILD 方式。在保证其他关键参数不变的前提下，对比以下情况 LOAD 性能提升效果。

调整前：采用参数 SORTHEAP，SHEAPTHRES 的默认值；默认值分别为 SORTHEAP = 256 SHEAPTHRES = 0，另参数 SHEAPTHRES_SHR = 5000
调整后：手动设置 SORTHEAP = 5000，SHEAPTHRES = 10000

调优前后的 LOAD 命令请参看清单 3.

清单 8. 参数设置命令

				
 DB2 UPDATE DB CFG FOR TESTDB USING SORTHAEP 5000 
 DB2 UPDATE DBM CFG USING SHEAPTHRES 10000

测试结果

对应上文描述的各测试场景，现将测试结果陈列如下，通过对比调整前后 LOAD 耗时情况来展示调优效果。

场景 1

表 2. 测试结果

	ANYORDER	LOAD 耗时
调整前	未指定	4 分 26 秒
调整后	指定	4 分 25 秒

场景 2

表 3. 测试结果

	FASTPARSE	LOAD 耗时
调整前	未指定	4 分 26 秒
调整后	指定	4 分 23 秒

场景 3

表 4. 测试结果

	STATISTICS	LOAD 耗时
调整前	YES	4 分 22 秒
调整后	NO	4 分 15 秒

场景 4

表 5. 测试结果

	COPY	LOAD 耗时
调整前	YES	5 分 41 秒
调整后	NO	4 分 17 秒

下图展示了调优前后系统的 I/O 情况，通过下图可以看出，当指定 COPY YES 时，系统需要进行的 I/O 操作明显增加，I/O 访问量是调优后的 2~3 倍，进而严重影响 LOAD 整体性能。

图 2. 调优前系统 I/O

图 3. 调优后系统 I/O

场景 5

表 6. 测试结果

	DATA BUFFER	LOAD 耗时
调整前	默认值	5 分 15 秒
调整后	手动设置	4 分 19 秒

场景 6

表 7. 测试结果

	SORTHEAP,SHEAPTHRES	LOAD 耗时
调整前	默认值	9 分 17 秒
调整后	手动设置	7 分 30 秒

下图展示了调优前后系统的 I/O 情况，通过下图可以看出，当采用参数默认值时，系统需要进行的 I/O 操作明显增加，这是因为默认的排序堆设置不足以容纳需要排序的数据量，当缓冲池的空间有限时，LOAD 会将数据缓存到磁盘上。如图所示，调优前 I/O 访问量是调优后的 2~3 倍，严重影响了 LOAD 整体性能。

图 4. 调优前系统 I/O

图 5. 调优后系统 I/O

附件中包含了实例演示中各场景的测试脚本和测试结果，供读者下载。

缩写术语索引

本文中使用了一些英文缩写术语，目的在于突出文章重点内容，而尽量减少读者注意力的分散，现将缩写术语解释如下：

EDU Engine Dispatchable Unit，DB2 内部各类线程，引擎调度单元。
RID Record ID，数据记录唯一 ID 标识，由数据页号和数据页内记录槽号构成。
EXTENT 表空间扩展数据块，由若干数据页组成，是表空间存储和访问数据的基本单元，同时也是表空间容器写入的基本单位，当数据写满一个 EXTENT 时，则开始到下一个容器中写入数据。
RUNSTATS 该 DB2 命令用于收集表、索引的各类统计信息。
Load Copy 在 LOAD 过程中，对目标表所在表空间进行的备份，称作 Load Copy。

回页首

下载