【专家深度热文】DB2不可同日而语! （上）

BMC中国 2021-05-16

1100

第1部分-行业和DBA趋势

在这里与大家探讨DB2 for z/OS如何不断变化及其原因，以及这些变化在管理、维护和开发DB2数据库及应用方面意味着什么。一个基本前提，如果您直到现在一直在使用DB2，我相信您会同意，2016年的DB2环境已不同于15年、10年甚至5年前。行业在变，数据库管理员(DBA)的工作方法在变，DB2也在变 - 我们必须面对过去DB2工作方式已不再适用今天现代DB2的现实。

我们先来看一些影响IT和业务，促使IBM不断改变DB2 for z/ OS的行业发展趋势。

行业趋势

首先，也是最明显的趋势，我们需要保存比以前更多的数据。根据IDC最新调查，未来十年数字宇宙将继续以每年40%的速度增长。到2020年，IDC估计，数字宇宙的数据量将达到44 ZB，相当于44万亿GB。为明确ZB的大小，请参阅图1。

这种数据增长是多种原因造成的。企业正在迅速将更多业务转移到网上，以最大程度聚拢人气，充分利用广泛使用的智能设备(智能手机、平板电脑等)。更多“物”接入互联网(构成物联网，简称IoT) ，生成可进行收集跟踪的数据流。社交媒体 (如推特、脸书等) 用于跟踪营销和其他用途的数据爆涨，也促使创建存储的数据量急剧增长。我们必须考虑到，随着业务的发展和扩张，所有这些因素都将造成数据量增长。我们的确已生活在大数据时代。

能够收集如此大量数据已成为大数据行业的一种趋势，其本身是各种趋势的集中体现。大数据运动的本质是从大量数据中迅速得到重要结果 – 包括结构化和非结构化数据 – 提高业务决策能力。因此，大数据集中表现为以下趋势和功能：
• 商业智能–结构化查询和报告
• 云计算–根据需要调用大型计算池可用资源
• 分布式数据–数据通常利用低廉的商品化硬件在网络上进行物理分布
• NoSQL和Hadoop –面向存储和处理大量数据的新型数据持久化方法
• 分析工具– 用于多种来源和不同类型的数据
• 联网设备– 联网设备数量超过2011年全球人口
• 传感器–更多传感器更加频繁地产生更多数据
• 物联网– 机器生成供其他机器读取和使用的数据

大数据代表了IT需求和技术的重大转变。数据量及其生成速度显著增长，为揭示尚不了解的信息和趋势提供了机会。

最后值得注意的一点，IDC预计非结构化数据量 (即非严格意义的数字、字符或日期/时间数据)，占所有数字化信息的90%。非结构化数据正在越来越多地进入我们的数据库系统。

数据库管理(DBA)趋势

数据库管理可以另一个角度透视我们的数据和DB2当前状态。传统上，DBA是负责保证企业存取数据的数据库的应用功能和有效性的技术人员。但是，现代DBA远不止是保持数据库系统正常运行。大部分DBA拥有多年IT经验，并从事数据库相关技术的工作，包括应用开发、中间件实施、交易处理、商业智能和网络等领域。因此，今天的DBA不只是DBA，也就是说，DBA不再100%单纯负责数据库的维护和运行。

另一个趋势是，曾经的单一DBMS DBA少了很多。二十 (抑或十) 年前，仅负责DB2 for z/OS的DB2 for z/OS DBA很常见。但在这个异构时代，许多DBA需要管理多个数据库管理系统 (DB2和Oracle，或DB2 z OS、DB2 LUW及IMS；甚至DB2和NoSQL数据库)。当这种方式将重点冲淡之后，DBA很难成为开发人员和管理所想象的特定DBMS专家。

最重要的是，很少请DBA管理更多的数据。正如本文第一部分讨论的，存储和访问的数据量越来越大，但并没有转变为DBA用工数量的增加。虽然美国劳工统计局预计，2014年到2024年，DBA的增长率达到11%，“高于平均速度”，但仍低于每年2%的水平。对比今后十年数据年增长率40%，很容易看到，如果企业想应对数据存储量快速增长的话，他们并没有做出很好的规划。

DB2不可同日而语

所有这些大数据和DBA的发展趋势导致DB2 z / OS环境不断变化。在今后几个月的后续文章中，我们将讨论企业和DBA面临的一些DB2 z / OS最大变化。我们将重点分析数据库结构，如通用表空间和LOB、IDAA混合交易分析处理、SQL发展趋势，以及自动维护如何改变我们管理DB2的方法。

因此，一定要每月进行一次复查，了解DB2 for z / OS在许多方面已不同于过去的DB2!

第2部分-通用表空间

这个系列的第1部分，我们大致了解了对数据库系统和数据库管理员构成影响的趋势。今天的文章中，我们将探讨数字时代DB2 for z/OS环境的重大变化和面临的挑战。

近十年来，最大的变化是引入了新型表空间–称为通用表空间，或UTS。UTS不仅是DB2的新功能，而且迅速成为新老DB2应用表空间的事实标准。有时，通用表空间取代现有分段表空间和传统分区表空间。我们将在本文后面介绍为什么出现这种情况，但首先简要说明通用表空间。

两种通用表空间

作为DB2 9的新功能，通用表空间兼具分区表空间和分段表空间的最佳特性。由于采用空间图页面 (与分段表空间一样),通用表空间可变行长改进了空间管理。此外，与分段表空间一样，UTS提高了批量删除性能，并且可在批量删除后立即重用表段。与分区表空间一样，通用表空间可以扩大 (数据量可达128TB)，包含多个分区。

通用表空间有两种类型：

1. 增加分区 (PBG): PBG UTS随着数据量的增长建立新分区，不需要指定键值范围。这种类型的UTS有利于表随着时间扩大，增加分区极限，且可利用分段。
2. 范围分区 (PBR): 范围分区或PBR UTS与传统分区表空间一样，需要指定分区的键值范围。PBR UTS从根本上说增加了现有分区表空间的分段。

两种UTS可以只含一个表，但IBM演示表明，这一点将来某个时间可能改变。

范围分区UTS基本是分段、分区表空间。极限键值范围必须在表DDL中指定。支持最早传统分区表空间的索引分区，不支持PBR UTS。因此，传统分区表空间转换成PBR UTS之前，必须首先从索引控制的分区转换成表控制的分区。查看本博客文章，了解迅速转换表控制分区的技巧。

第二种UTS是增加分区通用表空间。顾名思义，PBG UTS可随着表空间中数据的增长自动添加新分区。随着应用使用UTS的时间延长，表中的数据逐渐增加。当PBG UTS达到最大尺寸时，表空间自动增加新的分区。新分区的特性与现有分区相同，包括压缩信息、自由空间等。

您可以利用DDL关键字控制UTS类型：NUMPARTS、MAXPARTITIONS和SEGSIZE。要创建PBR UTS，可以指定NUMPARTS和SEGSIZE。要创建PBG UTS，必须设置MAXPARTITIONS和SEGSIZE参数。MAXPARTITIONS表示PBG UTS可以增加的分区总数量极限。当心，因为如果只设置NUMPARTS参数，而未设置SEGSIZE，那么创建的是传统分区表空间。如果只设置SEGSIZE参数 (未设置NUMPARTS或MAXPARTITIONS)，则创建的是传统分段表空间。

为什么通用表空间是DB2的未来?
截至目前 (DB2 11 for z/OS)，大致有四种表空间可供选择：
1.   分段表空间
2.   通用增加分区 (PBG) 表空间
3.   通用范围分区 (PBR) 表空间
4.   传统分区表空间

当然，对于新数据库，最好不考虑传统分区表空间，因为PBR UTS更有效 (传统分区很可能未来某个时刻被弃用）。从技术角度看，还有两种类型表空间 (LOB和XML表空间)，但它们只能在特定情况下使用 (我们将在这个系列后续文章中探讨LOB）。

那么，为什么我建议在可能的情况下，最好使用通用表空间而不是分段表空间? 有几个原因。首先，因为通用表空间更新，几乎每个DB2部署都需要。其次，DB2许多新功能只能使用通用表空间。只能采用UTS的新功能包括：
•   克隆表
•   散列表
•   当前已提交锁定
•   挂起DDL
•   内插LOB
•   XML多版本
•   ALTER TABLE删除列

这一趋势很可能继续。由于IBM推出新版DB2的一些新功能只能采用UTS，因此DBA延用非UTS表空间会更加困难，他们肯定不能使用老式表空间无法支持的任何新功能。

这意味着，如果您目前的确只使用分段表空间，那么绝对有必要配置多表表空间。我推荐的最好做法是所有新的表空间通用(多表表空间可以分割除外)。

那么，分段表空间未来情况如何? 近期内，分段表空间仍将得到支持。据我猜测，IBM将在某一时间提供多表UTS功能，然后在某一时间弃用分段表空间。不过，这只是我的猜测。截至我写这篇博客时，IBM还没有确认提供多表UTS，在将多表放入一个表空间时，仍建议 (且仅建议)采用分段表空间的方法。我建议避免多表表空间，除非有很多非常小的表，并在数据集极限以内 (DB2 V11为200K)。

对于表空间，我一般建议传统分区表空间向PBR UTS迁移，分段表空间向PBG UTS迁移的转换项目缓慢进行。这样，您可以等待推出最新、最强大的DB2表空间技术，便于随时随处,在您认为合适的情况下，使用当前及未来版本DB2的所有新功能。

总结
为了确保系统最新状态并支持新功能，所有DB2表一定要采用通用表空间。唯一例外是多表分段表空间，而且其数量不应过多。
祝您成功实现DB2数据库通用化!

第3部分-非结构化数据和LOB

这个系列第1部分，我们了解了数据库和数据库管理 (DBA) 的发展趋势；第2部分，介绍了DB2环境不断变化的表空间。在第3部分中，我们将探讨迅速发展的非结构化数据的作用，及其对DB2数据库采用LOB保存数据产生的影响。

非结构化数据增长

虽然结构化数据仍是大多数企业信息基础架构的基石，但非结构化数据正在变得越来越重要。而且，“系统中”非结构化数据远多于结构化数据。事实上，IDC分析师预计，所有数字化信息中，非结构化数据占到90%。

非结构化数据的增长往往是由于企业保存大量音频、视频和图像，多媒体数据量不断增长造成的。不过，这只是部分情况。文本文档、各种商务表格、信件和文件，最重要的是电子邮件，极大地提高了非结构化数据日益增长的重要性。

随着企业数字信息规模的扩大，多种类型的非结构化数据被采集、存储并用于分析。不仅有内部生成的数据，也有来自许多外部数据源的数据。

DB2和非结构化数据

DB2 for z/OS可采用BLOB、CLOB和DBCLOB数据类型（统称为LOB），来保存非结构化数据。从历史上看，LOB用来补充关系型产品，如DB2，以提高与当时面向对象数据库竞争的能力。这种情况最早出现在20世纪90年代末。当时的想法是用关系表保存图像、音频和视频数据等非结构化数据。

但是，DB2 for z/OS用户迟迟没有在主机数据库中使用LOB。造成这种情况的原因很多，其中最重要的一点是，DB2 for LOB经过几个版本成熟过程之后，才成为企业应用的实用工具。早期部署在DB2中的LOB存在一定缺陷，难以管理和使用。但IBM随后纠正了许多缺陷，现在一些工具可以帮助企业利用并有效管理DB2 LOB。

另一种推广LOB使用的新动力是大数据运动的全面兴起。大数据促使企业采集分析更多数据，以及多样类型的数据，从而具备业务洞察力。大数据推动DB2使用LOB的一个典型例子是，DB2增加了JSON支持。JSON对象可以BLOB形式存储在DB2中。

因此，越来越多的企业在DB2数据库采用LOB数据–支持非结构化数据，大数据项目，及存储文档和多媒体数据。不过，有时我听到DBA这样说：“哦，好了，我不使用LOB，所以我不必担心这个问题。” 这会给你带来麻烦，因为你用LOB已经有一段时间了，不管你是否知道。因为LOB数据自第7版开始已成为DB2编目的一部分，过去的几个DB2版本中，DB2编目使用的LOB列数量一直在增加。如下表所示，DB2编目现在有42个 LOB列。因此，即使未创建任何带LOB列的DB2用户表，也会有带LOB列的DB2系统表。例如，SYSIBM.SYSVIEWS所含CLOB包含用于创建VIEW的源文本。

LOB也用在DB2目录中，在DBD01“表”中，BLOB列用于保存DBD数据 (2GB)。在SPT01“表”中，有两个BLOB列，分别用于保存数据和解释信息。

LOB用于DB2
我不想在这篇博客中教您在DB2中使用LOB的方法。只要说为确保准确性和可用性，LOB需要不同的管理和维护策略就够了。但我想提出一些采用LOB可能产生的管理问题。

首先切记，大部分LOB大于典型列数据。我的意思就是LOB = 大对象 (LOB = Large OBject)。随着数据尺寸增长会出现管理问题，如处理数据的工具运行时间过长，数据访问性能等。您还需要注意，是否记录LOB数据变更。如果记录LOB变更，由于LOB数据尺寸的缘故，需要压缩记录。如果不记录LOB变更，一定要有足够的方法恢复LOB数据，因为日志中没有镜像复本之间的变化。一般来说，通常希望避免做LOB记录。您可以在LOB表空间DDL中设定“不记录”(NOT LOGGED) 关闭LOB记录。

与SQL一起使用LOB数据有很多限制。LOB数据不像传统结构化数据库中的数据，因此，DB2有一些限制，例如：
•   LOB不能用在GROUP BY或ORDER BY子句中
•   LOB 不能设定SELECT DISTINCT
•   LOB 不能用在MERGE语句的INCLUDE (列名) 子句中
•   LOB不能定义检查约束、主键、唯一或外键
•   LOB不能用在断言中，EXISTS、LIKE和NULL除外

这些仅用于说明。还有其他限制，所有限制可参阅IBM SQL参考手册。

除非是内插LOB，即整个LOB保存在基表中，LOB需要LOB表空间、辅助表和LOB索引。建立辅助表和索引时，与建立正态表和索引一样，不需要指定列。建立辅助表时，需要指定LOB列和基表，DB2自动生成所需的列。建立辅助索引时，只需指定辅助表， DB2隐式生成所需的索引键。

每个表可含0、1或多个LOB列，每个LOB实例的尺寸最大为2GB。每个至少有1 个LOB的表必须含ROWID；ROWID为17字节可变长度字段。一页LOB表空间不得含有一个以上LOB，而一个LOB可以跨多页LOB表空间。LOB表空间中的辅助表，只能保存一个基表的LOB列；这个列必须有一个且只能有一个索引。所有这些会改变DB2表和表空间的管理和维护方法。

现在，我们回过头来更深入一点谈谈LOB的尺寸。每个LOB实例最大为2G–这是一行！每个LOB表空间可以有多达254个不同的数据集，每个DSSIZE为2G至64G，总计大约16太字节 (TB)。这是一个分区，因此，如果有4096个分区 (这是最大值)，那么一个LOB的总尺寸将大于66,000 TB。想想这种情况。我想，无论对于谁来说，这个尺寸都是相当大的!

除非所有LOB数据都是静态的–即绝对不变– 否则您的LOB数据集规模将不断增长。您准备好工具运行如此之大的表空间了吗?

从基础表中删除LOB列时，DB2不会自动清理LOB表空间。删除LOB列之后，您可以自己显式清除LOB表空间，也可以供另一个LOB重用。

最后，LOB列并没有真正更新。老版LOB被回收，分配新版。因此，LOB与我们用来管理的传统数据略有不同。

LOB会出现哪些错误?
当LOB组成部分之间不一致时会出现LOBS错误。众所周知，“正常”DB2索引可能与其关联的表不一致，但LOB索引会将这个问题放大。
1. LOB索引中找不到基表行中的ROWID版本号。
2. LOB索引中的条目可能未被基表任何行引用。
3. LOB数据本身可能不在LOB索引指定位置。
4. LOB表空间中的LOB可能未被LOB索引引用。

校验数据(CHECK DATA)可用来发现错误1和2 (上表): 校验LOB (CHECK LOB)可用来发现错误3和4。但CHECK LOB有可能将4类错误转化为2类错误，因此需要谨慎处理。

再有就是LOB索引一致性问题。如果LOB索引与基表数据不一致，LOB数据不能存取。不能直接进入LOB表空间，除非通过LOB索引。如果LOB索引与LOB表空间不一致，DB2会访问错误行的LOB数据。

维护LOB
DB2采用分层结构维护LOB表空间中的LOB数据。

LOB表空间中的LOB数据可以分配到大量不同的LOB表空间页面中。请记住，这种LOB数据非常大。DB2使用地图页面结构确定数据页。顶部是地图第一页，LOB索引保存的正是这一页的编号。这个第一页地图包含页面列表，可以是其它地图页和数据页。它还可以包含LOB数据总尺寸。如果所有数据页未被地图页引用，或者，如果这个地图页未被更高层级地图页正确引用，LOB数据将丢失。

维护这些指针和结构时，会由于各种情况发生错误。要验证LOB结构上是否正确，必须按以下顺序运行一系列DB2工具：
1.   运行CHECK DATA，检查LOB索引中是否也可以找到基表中设定的ID字段。
2.   运行CHECK INDEX，检查LOB索引是否有效。
3.   运行CHECK LOB，检查LOB表空间内部结构是否正确。
当然，还有更简单的方法。确实应该考虑采用了解LOB细微差别的现代化工具，这样，可以相应地进行恰当的管理。

底线
我们的DB2数据库中以LOB形式存储的非结构化数据将越来越多，这是企业和行业发展趋势决定的。这种数据不同于传统结构化数据，必须考虑这些差别，进行妥善管理。为此，需要深入了解并进行规划，以避免不一致和错误。

这些只是我个人的看法，不代表BMC立场、策略和观点。

作者介绍：

Craig S. Mullins是数据管理战略师、研究员和顾问。他目前担任Mullins Consulting公司总裁及首席咨询师、TheDatabaseSite.com发行人/编辑。

欲了解BMC更多资讯和相关活动，请点击“阅读原文”注册参加：BMC大数据助力数字化业务转型网络研讨会。期望您的参与。

db2

文章转载自BMC中国，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

【专家深度热文】DB2不可同日而语! （上）

评论