【专家热文】DB2不可同日而语（下）

BMC中国 2021-05-16

706

第4部分-数据结构和其他DDL

欢迎继续阅读应对DB2 for z/OS变化的系列第4部分。第1部分介绍了数据库和DBA趋势；第2部分介绍了通用表空间的变化；第3部分讨论了LOB与非结构化数据的作用。但DB2数据结构也发生了影响我们使用和管理DB2 for z OS方式的其他变化。今天，我们将在第4部分说明其中的部分变化及其影响。

现代存储

主机磁盘，或DASD，通常等同于3380或3390。我们以硬盘与数量之间一比一的关系来理解物理硬件设备。但是现在，这些物理设备已由磁盘阵列取代。阵列是单个逻辑设备或多个逻辑设备中，两个或以上物理磁盘存储设备的组合。

这些磁盘阵列一般称为RAID设备，RAID意为独立磁盘冗余阵列。RAID的基本概念是将多个磁盘设备组成将系统视为单个硬盘的阵列。RAID具有高可用性和快速故障切换能力，因为硬盘可以热插拔，即在阵列运行过程中更换硬盘。

IBM DS8000系列是IBM System z主机平台比较流行的磁盘存储系统之一。它是专为高速OLTP和大型数据库文件设计的，支持ESCON和FICON连接高速15K RPM FC硬盘。

按照z/OS的理解，主机磁盘存储阵列仍然模拟3390磁道架构。您可能听说过，您的站点使用3390-3型磁盘。这个型号指老式三倍容量3390型磁盘，其数据存储量略低于3GB。现代磁盘阵列几乎可以模拟所有卷配置，架构柱面最高达65,520。

不过，这里需要了解的重要一点是，读写是在存储环境下磁盘阵列中的多个物理磁盘上，而不是单个3390设备上进行的。采用日志结构文件等概念，缓存容量达到GB级的新型磁盘架构和设备，对数据库物理设计方面的考虑因素产生显著影响。基于数据集布局的常规数据库设计规则已不那么重要，大多数情况下可以忽略。

SMS-托管存储。另一个重要的存储相关变化是SMS，即系统托管存储。利用SMS，系统确定数据集位置，从而最大限度减少DBA的工作量。SMS是DB2 10 for z/OS的要求，因为自DB2 10开始，DB2目录必须采用SMS-托管。而且，凡数据集大于4 GB的表空间或索引，要求采用DFSMS-托管数据集。

z/OS采用IBM DFSMS实现SMS。

不采用DFSMS，用户需要负责在磁盘中分布DB2数据集。这个过程需要定期检查，可以在工作负载发生变化时，也可以在存储服务器配置变更时检查。此外，正如我们刚才讨论的，RAID设备不能保证数据集的放置真正实现您所要求的分离，因为RAID设备在后台将数据分散在多个磁盘中，这个过程是无法控制的。

采用DFSMS，DBA可以自动完成数据集布局。许多企业大部分DB2数据集布局已采用SMS。采用DFSMS，可以相对比较简单地实现所有DB2数据集布局和设计目标。DFSMS具有必要的灵活性，可为DB2管理员提供可能需要的每一种支持。

当然，要想实现成功部署，存储管理员和DB2管理员之间需要达成一致，共同建立符合各自目标的环境。同时，一定要尽可能将数据分开放置，以便于访问所需类型的数据。

压缩。再有一个DB2存储相关的问题是压缩，我认为，大多数企业未充分利用压缩。今天的DB2环境下，硬件辅助压缩可以达到很高的压缩率，具有优异性能。作为一条经验法则，任何至少50页的表空间都需要压缩，DSN1COMP显示压缩率至少可达到25%。

早期版本DB2可以调用的CPU开销压缩，不是现代表空间压缩的主要问题。对于连续数据存取，如顺序预取，I/O的节省可以显著提高性能。这是因为压缩页面比未压缩页面可以包含更多的行，因此，每次I/O可将更多数据读入缓冲池。

自DB2 9 for z/OS开始可以压缩索引。许多导致压缩表空间的同样理由，促使用户考虑压缩索引。索引压缩与表空间压缩明显不同，即使最终结果(降低存储量)是一样的。

第一个重要区别是索引压缩不使用Ziv-Lempel算法，也不需要字典。这意味着，新插入的索引关键字压缩无需等待LOAD或REORG运行。数据压缩与索引压缩最显著的区别或许就是数据调入缓冲池的方式不同。索引叶节点解压后存入缓冲池。这不同于表空间压缩，后者数据页压缩后读入缓冲池，然后再逐行压缩。索引叶节点压缩解压在页面层进行。这种方法在性能上要比每次搜索索引，重复解压多个索引关键字效果更好。另一个区别是，DB2仅压缩索引叶节点，而不是其他类型的索引页 (非叶节点，非根)。叶节点在索引中所占比例最大。DB2压缩索引关键字以及RID列表。

混合交易分析处理 (HTAP)

随着大数据分析的兴起，越来越多的企业希望利用在线分析处理(OLAP)和数据挖掘技术深入分析数据。这些分析查询在数据访问、设计和性能要求方面不同于交易查询。但越来越多的企业要求能够对同一DBMS中的相同数据，进行在线交易处理(OLTP)和在线分析处理。

IBM利用IBM DB2 Analytics Accelerator for z/OS，简称IDAA，满足这种需求。IDAA是与z Systems主机和DB2 for z / OS集成的设备，可进行高速分析处理–速度提高了几个量级。安装后，DB2优化器 (Optimizer) 可以感知IDAA，并建立与IDAA之间进行工作负载传输的访问方案。也就是说，不必改变程序即可利用强大的IDAA。

但这也意味着增加了管理的工作量，如配置IDAA，设置DB2 for z/ OS与IDAA设备之间数据同步。从而再次证明，DB2不可同日而语!

其他值得注意的变化

此时，我要冒博客文章过大的风险，但在过去几个DB2版本演进过程中，我们的确看到数据结构的新变化。我不想逐一描述，而是简要说明其中的一些主要变化，并为那些想了解更多详细信息的人提供链接。

DB2 10 for z/OS推出散列表。散列，或散列函数，是将一组定义数据元素转换成小数组的算法，通常一个整数即可作为阵列或磁盘存储位置的索引。散列用于单值查找效率特别高，如主键查找，但用于顺序访问效率比较低。

DB2 10 for z/OS增加了时态数据支持。时态表将一段时间与数据关联，表明数据在数据库中有效或改变的时间。传统数据库存储的数据在当前时间点默示为有效；不能跟踪数据过去或未来的状态。时态支持得以保存不同的数据库状态，查询不同状态下的数据。这意味着，支持时态数据的DDL不同，以及进行查询的SQL语法不同 (时间进程查询)。

DB2 11 for z/OS增加了透明归档，有点类似于系统时态表。透明归档便于数据库管理员将频繁使用的运营数据，与可以存档的非活跃数据分开。这样，可通过减小表空间尺寸提高性能，有助于防止无意间访问非活跃数据。

过去的几个版本还引入了几种新的数据类型，包括二进制、pureXML、DECFLOAT、具有不同精度的TIMESTAMP和TIMESTAMP WITH TIME ZONE。更不用说DB2 11 for z/OS不再使用同义词。这意味着，它们现在仍然存在并起作用，但很快就会消除。这也意味着，您很快就会有看到所有使用同义词的地方，将用别名取代或直接访问表。

基本准则

DB2用于存储数据的DB2基础设施和结构正在发生变化...而且速度很快。因此，企业及其数据库管理员必须做好准备迎接变革，以确保经济高效地构建现代DB2数据库和应用。否则，将对业务产生不利影响，再用老办法做事将得不到支持。

第5部分-SQL和开发趋势

我们在第一部分介绍了影响行业的宏观趋势；第2、第3和第4部分，我们考察了影响DB2 for z / OS数据库和管理的主要变化。接下来，我们来看看开发方面的情况。

现代编码技术

DB2生命周期过程中，主机应用开发发生了巨大变化。一开始并在之后很长一段时间，大部分DB2程序采用COBOL编写，经过编码使用静态SQL。这意味着，SQL绑定之后才能运行，访问路径固定不变。而且也意味着，几乎任何程序中的任何SQL访问路径，数据库管理员(DBA)都要通过PLAN_TABLE调用。

转眼到了现在，COBOL编写静态SQL已经成为例外，而非规则。哦，当然，这些COBOL编程的静态SQL仍然有，以CICS或批处理方式运行，但新的开发已不再采用这种方法。目前，程序员使用IDE构建代码，利用分布式数据访问通过网络或GUI访问主机DB2数据。他们现在采用Java和.NET。

大多数现代分布式应用开发项目通常依赖于应用开发框架。两种最常用的框架是Microsoft .NET和Java/ J2EE。这些框架使用动态SQL，而不是静态的。

另一种动力是商品化现成ERP和CRM应用的使用，如SAP、PeopleSoft和Siebel。这些应用不受特定数据库管理系统(DBMS)限制，且得到多种不同DBMS的支持，其中之一是DB2 for z/OS。由于更容易实现多厂商DBMS支持，因此这些应用使用动态SQL。

所以，DB2应用的开发方式已经改变。这意味着， DB2管理方式也要改变。不是依靠已有访问路径，DBA必须开发获取动态SQL语句的访问路径。准备好的动态SQL可以缓存在动态语句缓存中，这样，相同的SQL语句下一次运行可重用语句小的操作步骤。BIND命令可用来捕获缓存中的语句，查找使用的访问路径。而动态语句缓存类似缓冲池，最近使用最少的语句被刷新，为新语句腾出空间…所以，可能找不到寻找的动态SQL，最起码在没有帮助工具或脚本的情况下找不到。

这种变化使许多企业遇到SQL性能问题。因为动态SQL很容易产生系统性能问题。谁也不知道动态SQL运行状况。而且不能进行跟踪，因为DBA不习惯监控和调整动态SQL…或者，根本没有进行相应监控和调整的工具。因此，这些动态SQL性能问题仍是深不可测的黑洞。

新的SQL功能

不仅新的编程范式造成现代DB2使用的管理问题。新的SQL语句和函数以及功能数量，也随着每个新版DB2继续增加。这种情况喜忧参半。从好的方面看，SQL功能的扩展便于编程和访问DB2数据。但问题是这些新功能更加难懂，很难学习。

许多企业未投入足够力量培训工作人员进一步加剧了这个问题。如果DBA没有经过所有新功能的培训，新的SQL会造成严重问题。严重到怎样的程度? 想想看，企业迁移到DB2 11 for z/OS，而只是进行了阅读手册的培训。那么，相当一部分DBA不知道新的SQL代码。开发人员可以像编程人员一样，通过手册学习如何使用新功能或数组。开发人员的积极性值得肯定，但如果出现问题，可能没有人知道如何支持新功能。

SQL增加的新功能相当多。如果只以前三个新版本为重点(DB2版本 9、10和11)，我们可以列出新推出的SQL编程相关的增强功能包括：新的数据类型TRUNCATE (DECFLOAT, VARBINARY)、乐观锁、抓取连续 (FETCH CONTINUE)、角色(ROLE)、合并 (MERGE)、选择合并(SELECT from MERGE)、纯XML (pureXML)、子查询和全查询(FETCH FIRST & ORDER BY)先抓取后排序、INTERSECT、 EXCEPT、指示变量 (Indicator Variables)、TIMESTAMP精度和时区、移动 (Moving) 合计和移动平均、内联和非内联SQL (Inline and Non-inline SQL) 标量函数、SQL表函数、扩展隐性转换、RANK()、ROW_NUMBER()、XQuery、透明归档查询、IDAA/分析、grouping sets子句、ROLLUP、Hadoop访问…

要学习的太多了!

总结

目前，应用开发人员面临的情况正在以极快的速度发生变化。除非管理和DBA能力适应新的开发方法，否则这些变化将产生影响业务的问题。

第6部分-自主化

到目前为止，我们了解了行业和数据库管理 (DBA) 的发展趋势 (第1部分)，DB2 for z/OS 大量数据库和管理的变化 (第2、3、4部分)，以及SQL和开发趋势 (第5部分)。接下来，我们介绍任务的管理方法，以及如何将传统管理方法转变为自主化方法。

自动化与自主化
随着时间的推移，许多传统上需要DBA监控维护的数据库管理任务，已采用智能自动化软件来管理。这句话的关键是 “智能”。哦，当然，多年来我们已在许多方面实现了自动化，无论生成JCL，重组(REORG)作业排程，还是编写一系列脚本改变数据库结构。

在开发计算机应用支持业务流程的过程中，我们只是实现了企业中每项工作的自动化。但是，大多数情况下，这些自动化步骤仍需要大量人工介入或干预。

自主化是由简单的自动化转变为利用智能软件技术管理数据库。

什么是自主化?
那么，什么是自主化? 自主计算指自我管理分布式计算资源，适应无法预测的变化，同时避免操作员和用户的复杂性。自主化概念远远超过简单的自动化。

在数据库管理系统 (DBMS) 情况下，自主化的目标是使计算机系统能够进行自身管理。自主化要求感知环境，了解不断变化的使用模式和资源，能够适应要求的改变。通过自主化可以够优化手动任务，降低复杂程度。这对于当前及IT人员精益化时代特别重要。

在更高层面上，自主计算分为四个方面：
1.   自动化，即利用性能和用量指标，以及管理员制定的高级策略制定自身决策。
2.   自适应，即针对变化的条件自动进行调整。
3.   感知，即系统可以监视 (或感测)操作环境及当前状态，确定是否达到特定目的。
4.   自我管理，即可以进行自身优化和维护，不需要人工交互。

当然，自主化还可以在很多方面进行 “自我”管理。自主系统支持许多不同类型的自我管理功能，例如：
•   自我配置：自动配置系统及其组件；
•   自我修复：自动发现并修复故障；
•   自我优化：自动监控资源，保证达到规定要求的最佳状态；
•   自我保护：主动识别并防止任意攻击；
•   自我检查：了解本身及其与其他系统的交互，从而做出明智的决策；
•   自我组织：主动修改数据结构并加以组织优化数据访问。

与许多事情一样，要求企业一蹴而就全面实现自主化是不现实的。自主计算可分成以下5个阶段逐步完成：
1.   基础
2.   托管
3.   预测
4.   自适应
5.   全面自主化

前三个阶段是被动的，即系统建议管理员采取必要的纠正措施，但任何行动都不是自动处理。基础阶段必须进行人工处理，利用IT专业人员的能力和经验管理相应任务。托管阶段利用管理技术和工艺增强人工处理能力。而第三个阶段真正开始进行更加自主的维护管理。这个预测阶段在不同组件之间引入相关的新技术和新方法。

然后，我们进入主动阶段，自动完成纠正措施。自适应阶段利用收集的指标和信息自动采取纠正措施。在最终阶段，即自主管理阶段，主动监测和分析业务策略和目标–甚至可以根据新的观察结果修改这些策略和目标。基本上，所有这些阶段可以归结为识别问题，但并非只是找出问题，而是采取措施修复问题。

信任，但要验证
由值得信赖的顾问评估自主功能的准确性，是不断向自主管理发展的重要组成部分。技术人员第一次接触自主技术往往产生怀疑。例如， DBA听到某个软件可以自动调整参数、作业或数据通常会说：“等一下！先告诉我什么问题，您建议我应该做什么。”

DBA希望了解建议，在一定程度上建立起对技术的信任。这是自主软件的第一个阶段。您可以分成三步解决问题：
1.   发现问题
2.   分析解决方案的状况
3.   实施解决方案

DBA容易接受自主化的前两步，但最后一步通常需要一些时间。经过一段时间检查软件提出的建议后，技术人员开始相信精心编写和开发的自主解决方案。这时，完全实现自主化管理…不仅发现问题，进行分析，找到解决办法，而且自动解决问题。

现代数据库管理需要自主化
数据量不断增长、DBMS功能和异构环境不断变化是今天IT系统的主要特点。随着主机经验丰富的专业人员退休，新录用的数据库管理员减少，很容易出现难以管理最佳实践的问题。

自主化的关键是能够管理现代DB2系统。我们看到，IBM将越来越多的自主化功能整合到DB2基本功能中，如实时统计 (RTS)、RUNSTATS反馈和配置等。

您可以采用先进的工具和实用程序强化完善自主化管理，充分利用DB2的功能和指标不断监控、管理并优化DB2应用和数据库。

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

作者介绍：

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

db2

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

【专家热文】DB2不可同日而语（下）

评论