了解DB2中的数据访问频率和变化
不同温度带数据管理解决方案指的是将被频繁访问的数据存储在快速存储器中(热数据),而被访问频率相对较低的数据则存储在相对较慢的存储器中(温数据),极少被访问的数据则会被存储在企业最慢的存储器中(冷数据)。开发这套解决方案需要一套关键性能指标
不同温度带数据管理解决方案指的是将被频繁访问的数据存储在快速存储器中(热数据),而被访问频率相对较低的数据则存储在相对较慢的存储器中(温数据),极少被访问的数据则会被存储在企业最慢的存储器中(冷数据)。开发这套解决方案需要一套关键性能指标 (KPI),用来测量数据的“温度”并协助制定包含数据的运营和业务决策。为了演示这套解决方案,假设您的数据被分段管理为如下几个类别:
31 天内的数据
31 天到 90 天内的数据
91 天到 180 天内的数据
181 天到 365 天内的数据
超过 365天 的数据
假设两年期的数据的被访问频率低于 90 天的数据的被访问频率,虽然这可能合乎情理,但要更详细地地了解访问和变化的频率,则会引起其他业务决策的制定。例如,在过去六个月中没有任何变化而忽然在一个月里有 100 行数据完成了抽取、转换和加载的循环 (ETL) 变化,您可能并不想采取任何行动。或者,如果在那一个月里有 10,000 行数据完成了 ETL 循环变化,您可能就该要考虑采取以下一个或多个措施了:
执行某种形式的采样行动,确定是否有进一步分析的必要
重新执行相关报告
调查 ETL 过程,了解发生如此重大变化的原因
保留受影响的摘要表和物化查询表 (MQT)
使用 IBM DB2 High Performance Unload 来处理受影响的数据或整个数据表
备份数据表空间
重新整理数据(或只整理索引)
运行 runstats 工具
执行某种形式的存储管理或归档
确定已发生变化的数据,并同时确定数量和变化频率,这能为运营和业务决策的制定带来宝贵的意见。本文分享了一些可用的度量标准来帮助您理解频率、数量、变化的百分比和能导致您数据发生变化的行为。
开发关键性能指标
图 1 显示的是一个表格的条形图表示法,其中十二月、十一月、十月、九月、八月和七月,相对于六月、五月、四月、三月、二月和一月,变化率较高,被访问率也更高。
图 1:访问频率和变化频率
理解访问频率、变化率和其他有用的度量
当被激活后,DB2 中的“一直连接”度量会提供快速简单的度量报告,该度量随后可用于开发一个关于数据访问模式和变化的数据活动的业务视图。被激活后就会产生这些度量,可存储于用户定义的表中以供进一步分析。
表度量
图 2 列出了一些关键度量,每个表和每个表的范围分区都可以通过 MON_GET_TABLE 的表函数来获取这些度量。
表或范围分区被访问的次数
阅读行数(表或范围分区)
插入的行数(表或范围分区)
更新行数(表或范围分区)
删除的行数(表或范围分区)
对任何行的列值未导致任何变化的更新行数(表或范围分区)
表或范围分区所在的表空间
图 2:表和范围分区的活动度量
这些度量能帮助您回答下列问题:
共有多少行发生变化?给定时期(发出和存储调用表函数的结果时)内的变化率为多少?
给定的一周内共有多少“新增的”行被处理?
有多少更新语句执行后并未引起实际的更新(图 2 中的第 6 项)?
一个表空间中被更新的总行数是多少?
特定时期内共有多少行被删除?
索引度量
当索引度量不提供数据温度的信息时,它们还是可以通过使用表函数 MON_GET_INDEX 来解释索引利用率和索引性能,从而完成您的数据图。图 3 中列举了那些度量的一个子集:
惟一扫描的索引次数
访问扫描的索引次数
关键列的更新次数
包含列的更新次数
索引跳转扫描的次数
页拆分的的次数
图 3:索引利用率度量的子集
上一篇: 通用mysql数据库连接类代码
下一篇: 一些影响数据库访问速度的原因分析
推荐阅读
-
JavaScript中的数据属性和访问器属性
-
Oracle和DB2数据库中的Translate使用讲解
-
linux系统中 redis 保存数据的5种形式 linux后端模式启动 jedis无法通过IP地址和端口号访问如何修改linux防火墙
-
Android学习09-----Android中数据的存储和访问 (1) By SharedPreferences
-
JavaScript中的数据属性和访问器属性
-
Javascript对象中的数据属性和访问器属性实例详解
-
Oracle和DB2数据库中的Translate使用讲解
-
了解DB2中的数据访问频率和变化
-
linux系统中 redis 保存数据的5种形式 linux后端模式启动 jedis无法通过IP地址和端口号访问如何修改linux防火墙
-
Javascript对象中的数据属性和访问器属性实例详解