级别: 中级
IBM 多伦多实验室
2002 年 2 月
关系数据库只代表数据的逻辑视图,所以我们一定要关心数据的物理存储。要把最少访问的数据放在最慢的设备上。
DB2 存储的宏观管理
关系数据库仅表示数据的逻辑视图 — 那么我们为什么还要关心数据的物理布局呢?有几个值得关心的理由。首先,并非存储系统中的所有磁盘都具有相同的存取速度。假定我们可以分配给 DB2 管理的所有硬件可能不相同,那么对其中数据的存取速度就不可能相同。如果是这种情况,那么,将最少访问的数据存放到最慢的设备上,也许是值得一试的。
其次,您可能知道关于数据的某些事情,而 DB2 根本不会知道:
- 将来会发生什么,譬如某个给定月份的预计销售,
- 当本地电话区号进行分割之后将更改的电话号码(从而改变了潜在主键),
- 或者您计划的兼并一家公司,其拥有的数据现在必须合并到现有的模式中。
如果这些事情都没有发生,您就不得不应验一句老话以证明有必要阅读本文的剩余部分:如果不能估量它,就不可能管理它。
让我们从一些基础知识开始:使用 DB2 可以获得多大的信息?回答这些问题的首要参考资料是 SQL Reference 手册的附录 A,它讨论了一般限制。下面是存储限制的列表,其中一些在 SQL Reference 手册中。这些也是绝对限制。有关特定页大小的强制限制,请参阅附录 A 中最后的一张表 —“Database Manager Page Size Specific Limits”。请注意有些限制是“每分区”或“每节点”的。在 DB2 个人版、工作组版和企业版中,这些都是绝对限制,但对于企业扩展版,它们可以乘以 999。(它允许 999 个节点,节点也称为分区。)
SMS 表空间中表的最大数目 65 534 DMS 表空间中表的最大数目 51 000 数据库中表空间的最大个数 4096 表中的最大列数 500-1012(随页大小改变) 视图中的最大列数 5 000 包含所有开销的最大行长度 4005-32 677 字节(随页大小改变) Varchar 的最大长度 32 672 字节 长字段的最大长度(CLOB,BLOB) 2 GB 每分区中表的最大大小 64-512 GB(随页大小改变) 每分区中索引的最大大小 64-512 GB(随页大小改变) 每分区中表的最大行数 4,000,000,000 包含所有开销的最长索引键 1024 字节 索引键中的最大列数 16 表中的最大索引数 32 767 或存储器 SQL 语句/视图中引用的最大表数目 存储器 SQL 语句中主机变量引用的最大个数 32 767 最长的 SQL 语句(以字节计) 65 535 选择列表中的最大元素个数 1012 表中的最大约束数 存储器 INSERT 语句中的最大值数 1012 UNIQUE 约束中的最大列数
(由 UNIQUE 索引支持)
16 UNIQUE 约束中列的最大合并长度
(由 UNIQUE 索引支持)
1012
引用的最大合并长度 1024 分区键中
的最大列数
500 服务器的最大并行用户数 64 000 级联触发器的最大运行时深度 16 常规 DMS 表空间的最大大小 512 GB 长 DMS 表空间的最大大小 2 TB 临时 DMS 表空间的最大大小 2 TB 每实例的最大并行用户数 64 000 最大分区数 999 DMS 表空间中的最大表对象数 51 000 最大数据库(不包含长字段) 4096*65,535*0.5 TB 最大 EEE 数据库(不包含长字段) 4096*65,535*0.5 TB * 999 个节点
您做的三个基本选择决定了上述限制:
- EEE 数据库还是未分区数据库(如工作组版或企业版)
- 选择 4K、8K, 16K 还是 32K 的页大小
- SMS 表空间还是 DMS 表空间(系统管理的还是数据库管理的)
比起其它 DB2 版本,选择企业扩展版会使大多数物理限制增加三个数量级,因此这是您攻破“声障”(或其它对于用户等价的限制)的较简单武器。另有两篇文章讨论了选择 EEE 的含义和优点:
- http://www7b.boulder.ibm.com/dmdd/library/techarticle/adamache/0430_adamache2.html
- http://www7b.boulder.ibm.com/dmdd/library/techarticle/adamache/0529_adamache.html
4K 页是缺省值。对于您想要的每种另外的页大小,必须创建具有相匹配的页大小的缓冲池、表空间和临时表空间。较大的页大小的主要好处是表可以包含:
- 更多数据(4K 页大小可包含 64 GB 数据,页大小 8K、16K 和 32K 成倍递增直到 512 GB)
- 更多列(4K 页大小可包含 500 列,所有更大的页大小可包含 1012 列)
- 更宽行(这 4 种页大小的最大行宽度分别为 4005、8101、16 293 或 32 677字节)
- 更长的 Varchar(大致和行宽度相同)
SMS 表空间还是 DMS 表空间(系统管理的还是数据库管理的):生的与熟的
SMS 表示系统管理的存储(system managed storage):由操作系统通过使用文件系统来管理所有 DB2 对象。对于迅速增长和收缩的表空间(如临时表空间),或者对于您无法执行大量维护和监控的数据库中的所有数据,这是一种很理想的方式。DMS(数据库管理的存储(Database Managed Storage))要求您预测数据的增长和/或准备好将容器添加到正在运行且磁盘空间不足的表空间中。容器可以是文件系统中的文件或原始设备(raw device)。在原始设备(还有原始日志)上的 DMS 表空间被称为“生的”。使用文件系统的 SMS 表空间和 DMS 表空间被称为“熟的”(可能是为了向您选择的 Fine Young Cannibals 或 Claude Levi-Strauss 表示敬意)。
让我们首先来确定 SMS 还是 DMS:
SMS DMS 划分带区 是 是 (两者都能分割数据用于并行 I/O) 对象管理 操作系统(具有唯一的文件名称) DB2 空间分配 按要求增长/收缩 预分配 管理的容易程度 好 DBA 密集型 性能 好 优
正如上面的第二篇参考文章(2)所提到的,系统管理的存储(SMS)表空间适用于系统数据(临时表空间和目录表空间)和只能进行少量维护的数据库 — 因为它们数量太多而无法保证在设计和维护上对其进行大量投资。对于临时表空间需要的快速磁盘空间分配和取消分配而言,SMS 是正确的选择。
DMS 使您能够在最多三个独立表空间中拥有一个表的数据、多个长字段(如 LOB)和索引。这使您可以选择将长字段放到较慢的磁盘上而将索引放到较快的磁盘上。您还获得了颗粒度更小的备份和恢复选项。对于长字段(LOB 或 LONG VARCHAR),使用具有文件系统容器的 SMS 或 DMS。注:应该避免使用 LONG VARCHAR:VARCHAR 可以和长字段一样,而 LONG VARCHAR 就函数和标准支持方面而言,是 LOB 的绝对子集。LONG VARCHAR 仅仅是 DB2 版本 1 遗留的一个数据类型而已,DB2 因此获得了向后兼容的好名声。
将长字段放置到文件系统(无论 SMS 还是 DMS)上的容器中,使它们可以利用操作系统文件系统的高速缓存。DB2 将不使用它自己的内存(在缓冲池中)来高速缓存长字段。对于目录表空间:使用具有文件系统容器和小数据块大小(2 或 4 页)的 SMS 或 DMS。在目录表空间中有许多相对较小的表,而 DMS 对于每个表需要两倍的数据块(比 SMS 多一倍)。此外,目录表中还有几个 LOB 列,它们都以与上面描述的用户 LOB 相同的方式利用文件系统高速缓存。
对于常规用户数据,是选择 SMS 还是 DMS 取决于一些因素。应避免在文件系统上使用 DMS,因为它集中了 SMS 和 DMS 的缺点(与原始设备相比,文件系统的速度有可能较慢,而同样需要额外管理,以预测和估量当表增长时所需要增加的额外容器)。为了使便利程度最大化和实现很好的性能,选择 SMS,特别是如果您正在使用带有高级文件系统的先进操作系统(如 AIX 和 Solaris 的最新发行版)。这些操作系统擅长将重要文件高速缓存到内存中。为了使性能最佳,选择具有原始容器的 DMS。原始容器通常胜过文件容器,因为它们避免了要通过操作系统及其文件系统的额外路径让 DB2 读取数据。
决定如何跨表空间分配表取决于一些因素。DB2 OS/390 版的 DBA 偏爱将每个表放到它自己的表空间中。对于 Unix 和 Windows 上的 DB2 而言






