用户表空间（USERSPACE）

用户表空间也是数据库创建时自动创建的，表空间名称为USERSPACE1，数据库中的用户表默认存放于这个表空间中，用户表空间是可选的，一个数据库可以有多个用户表空间。必须至少有一个用户表空间（没有用户表空间的话数据库无法存放用户数据）。用户表空间也可以是SMS表空间或DMS表空间，通常使用DMS表空间。

临时表空间（TEMPSPACE）

临时表空间也是数据库创建时自动创建的，数据库管理器使用临时表空间在执行SQL操作时存储临时数据，例如排序，表重组，索引创建以及表链接等操作所产生的中间表都由临时表空间存储，数据库必须至少有一个临时表空间，也可以有多个。创建数据库时默认创建的临时表空间名称为TEMPSPACE1，且为SMS表空间。但是这个表空间的名称可以是任意的，当另外的临时表空间被创建后，该默认临时表空间也可以被删除。（但必须保证数据库有一个临时表空间）。临时表空间也可以是DMS表空间。另外，DB2支持系统临时表空间和用户临时表空间两种类型，系统临时表空间必须存在，用户临时表空间可以有0个或多个，用来声明临时表。

除了根据管理和用途划分表空间类型，还可以根据容量将表空间划分为常规表空间和大型表空间。但是这里的常规表空间和大型表空间都是针对DMS表空间而言，SMS表空间大小上限还不及常规表空间。

行指针

首先考虑一个问题：逻辑上，数据以数据行（元组）的形式保存在数据库的表中，但物理上，根据数据库磁盘存储的知识（数据库深入学习笔记----磁盘存储内部结构），数据肯定是存储在数据文件上的，确切的说是存储在数据块（页）上。那么，数据库是如何根据表中的行寻址到物理磁盘上数据页中的数据呢？

Oracle和DB2的解决方案是使用一种新的数据结构：行指针（或行指示器），Oracle数据库中称为ROWID，DB2中称为RID。在实际的数据库表中，每张表都会附加一个特定的隐藏列，即行指针列，也就是说，每一行数据都有一个行指针属性，它指向该行数据在物理磁盘中的具体位置。实际上不管是Oracle还是DB2，行指针都是可以参与SQL查询的（毕竟是有效的行属性。Oracle中的ROWID可以直接当作属性进行查询，DB2中则需要使用rid函数查询RID）如下图是DB2数据库的RID格式：

常规表空间

在DB2 V9之前，RID具有4个字节（32位）长度，其中3个字节用于数据页寻址，最后1个字节用于数据页内槽号寻址（《数据库深入学习笔记----磁盘存储内部结构》介绍过，每一行数据都是一条记录，存储在数据页的数据存储空间里，每一条记录都对应槽目录中的一个槽号）。

由RID的结构我们就可以计算出数据页能够容纳的记录数（行数）和表空间的容量了：

因为一个RID只有1个字节（8位）槽号，所以，一个数据页存储的记录数的最大值为255条（2的8次方-1，为什么要减1？这是因为磁盘存储那篇文章已经讲过，有的数据页是会有一个可用空间控制记录（FSCR）的，所以需要预留）。（说明：8位能寻址的范围就是0-255，槽号编号就只能是0-255，如果记录再多，就无法被槽目录编号了，无法被寻址，数据存了也是白存。）

同理，可以根据3个字节的页号，得出一个表空间最多能容纳16777216（16M，2的24次）个数据页。那么，如果是一个数据页4KB的话，表空间大小就是16M*4KB=64GB了。如果一个数据页32KB的话，就是16M*32KB=512GB。（DB2表空间支持的页面大小有4KB,8KB,16KB和32KB四种，一个表空间只能使用一种大小的数据页）

可以想象，如果数据库表中的行长度（一行所占用的存储空间）太小，由于一个数据页理论上最多只能存储255行（实际上，每一页允许存储的记录数通常少于255条），那必然造成数据页空间的浪费，比如4KB页，长度为12B的行存满页面也只占用12B*255=3060B的空间，剩下的1036KB多的空间只能浪费。下表显示了页面空间被浪费前的最小行长度：

一旦表空间中满足了最大页限制，有以下三种方案可供选择：

1.在视图中把这些表连接起来（多个表空间中的表在视图中合在一起）；

2.使用DB2的数据库分区功能（DPF，Database Partitioning Feature），横跨多个分区将数据进行组合；

3.使用范围分区表。

无论哪种方案都需要将一些数据进行迁移并可能对应用程序进行修改，这无疑是很繁琐的。

大型表空间

为了能够让数据页中容纳更多的行（记录）以及表空间中容纳更多的数据页，DB2 V9引入了一种新的行指针（RID，行指示器）格式。数据页标记由3个字节增加到4个字节，槽位由1个字节增加到2个字节，这种6字节的RID格式最终将表空间大小上限扩充到原来的32倍。即4KB页的表空间最大容量为2TB，32KB页的表空间最大容量为16TB。同时，每个数据页所能容纳的行数理论上也扩大为65000多行，但由于规定每一行的最小长度为12B左右，所以，实际上4KB页能容纳的最大行数为4KB/12KB=341行左右，32KB页则是2300行左右。

下表是4种页实际用于存储数据的空间大小和实际允许存放的行数：

这种RID格式很好的解决了表空间大小受限以及数据页空间浪费（不再受制于槽号，而是行长度）的问题。但同时也带来了管理上的挑战，比如备份和恢复。事实上，当表开始增长到TB级的时候，就应该考虑使用一些诸如表分区，数据库分区等技术来进行大型数据量的管理了。

使用旧的4字节RID格式的表空间就是常规表空间，使用新的6字节RID格式的表空间就是大型表空间了。DB2 V9中大型表空间是DMS表空间的默认类型，当然也可以显式的创建常规表空间（指明表空间为REGULAR）。很显然，SMS表空间是不可能支持大型表空间的。

支持6字节RID格式的表空间包括：系统临时表空间，用户临时表空间，用户常规表空间。也就是说，只有系统表空间是不能创建为大型表空间的。因为目前的编目表不足以达到能够及时保证较大的表空间大小的状态。

大型表空间在DB2 V9之前叫长型表空间，用于存储长型或 LOB 表列，以弥补常规表空间在处理长型或LOB数据上的不足。

常规表空间向大型表空间的迁移

DB2 V9不会自动将常规表空间升级为大型表空间，但是可以手动升级：ALTER TABLESPACE tablespacename CONVERT TO LARGE。

ALTER命令不会物理地改变表空间的结构，只是改变了编目方式以指示表空间可以支持6字节的RID格式。要注意的是：

1.执行LARGE升级后需要立即COMMIT WORK，进行事务提交，否则表空间上会持有排它锁，同时在该表空间中对表所做的其他工作不会继续执行，直到该锁解除为止。

2.一旦表空间被修改为LARGE，为了更好的利用6字节RID的优势，还需要继续数据重组和索引重组。如果不进行索引重组，那么先前存在的表将延续每页255行以及3字节数量的限制，因为索引使用的仍是旧的RID，无法索引到超出原范围的页。而数据重组（表重组）与索引重组的影响不同，索引重组影响表空间中页的数量，表重组影响的是页中存放的行数。