DB2 10.1存储器组之一

• 本质
– 这个从SMS到DMS到自动存储到存储器组的过程本质上来说反映了数据治 理从少到多，从多到科学Hale Waihona Puke Baidu命周期管理的生态发展过程。
• 存储器的诞生
– 随IBM在10.1引入了存储器组的概念，应对这种数据生命周期管理 的需求。存储器组为不同阶段，不同性能要求的数据匹配不同的存 储服务，也就是不同的存储器组。 – 存储器组的诞生，也是基础设施云化，SOA化的典型实践，让存储 变得简单，将DBA在表空间的维护工作解脱出来。
存储器组参数设置
– 以希捷的ST3146707LC 146G服务器硬盘为例，平均寻道时间为4.7ms，内部传输速率470，转 速10000转/分。则 OVERHEAD=4.7+（((1/10000)*60*1000)/2）=7.7ms DEVICE READ RATE=470 – DATA TAG是给WLM用的，可设1到9，惯例上说阙值定义中将小数对应于高级别的服务品质
•
创建存储器组
存储的规划
• 存储路径准备
– 使用了9块普通一样的SCSI磁盘，并为每个磁盘都创建了独立的PV，VG，LV， 然后都用MAKEFS.REISERFS格式化LV。我在服务器下创建了9个目录：/d ~/l 。将9个LV和9个目录映射关系写入fstab，mount -a，所有LV都挂载到目录上了 ，用df -h确认一下。 存储器组的大小
创建存储器组
存储器组创建的最佳实践
• 创建数据库时create database不要指定automatic storage子句 • 存储器组的所有路径应具有相同介质特征：等待时间、设备读 速率和大小 （如果不能请取平均，企业级应用不存在该问题） • 推荐使用data tag，配合WLM，根据数据确定应用优先级
– – – CREATE STOGROUP sg_hot ON ‘/d’ DEVICE READ RATE 800 OVERHEAD 3.725; CREATE STOGROUP sg_warm ON ‘/e’,‘/f’ DEVICE READ RATE 600 OVERHEAD 5.725; CREATE STOGROUP sg_cold ON ‘/g’,‘/h’ DEVICE READ RATE 400 OVERHEAD 7.725
•
DMS
–
•
automatic storage
–
出现原因
存储器组的诞生
• 现有系统的问题
– 自动存储器一定程度解决了DMS的高维护工作量，但是由于让所有表 空间都使用数据库的存储目录，就导致了大家吃大锅饭。 – 也就是自动存储扼杀了表空间的个性化定制的能力，导致数据生命周 期管理流程中，不能根据不同生命阶段，选择合适的存储设备。
出现原因
各种表空间能力概况比较
• SMS
– 不需要预定容器，只能增加容器，不能修改容器属性或删除容器大小，容量最多有512G（32K页大小）。数 据在磁盘上不连续不利于预取，常规表不能数据索引大对象分别存放，分区表中不支持大对象另存单独表空 间。SMS表空间的extentsize， prefetchsize（稍微有用点）参数意义不大，发挥不出参数的威力。容器路径 只支持目录名，无法使用裸设备。
– 随着数据库和数据的数量成倍的增长，DMS在性能方面满足了要求 ，但是维护工作量很高 – 于是业界又有了更高的要求，既需要DMS的高性能和较大的空间容 量，又希望具有SMS的维护便捷性 – 自动存储就可以自动判断使用DMS还是SMS，而且可以让所有表空 间都使用数据库建库时指定的目录，降低了数据文件的管理工作量 。
DMS支持数据连续物理存储，支持磁盘位置选择（AIX），支持大对象单独存放表空间，可扩展（平衡，不 平衡用extend）收缩填加删除容器，容器支持裸设备和文件，支持no file system caching(优先CIO，否则 DIO）。大型DMS支持32KB页大小的16TB容量 要求健库时automatic storage是yes（默认是yes）自动存储的临时表空间都是SMS，其他都是DMS，自动存 储表空间使用的是库的自动存储路径 ON ＇XXX＇（如未指定路径，则使用实例目录
出现原因
表空间发展的原因
• SMS
– 早期社会数字化程度低，核心系统数据量小，连接少，BI应用少，对 性能和数据连续读要求不高，所以交给OS维护数据库文件比较合适
• DMS
– 随着数据的大爆炸发展，以及核心系统要支撑应用的成倍增长，对 表空间的大小、性能和个性化定制较高要求，催生了DMS
• 自动存储
•
默认存储器组
– IBMSTOGROUP，路径为/home/db2inst – 如果无默认存储器组，那么用户创建的第一个存储器组既为默认存储器组 – CREATE STOGROUP的SET AS DEFAULT 设置默认存储器组
•
存储器组状态
– NOT_IN_USE，IN_USE，DROP_PENDING – 第一个说明路径已分配给存储器组，但未关联到表空间；第二个说明存储器组已关联到了表空 间；第三个说明已发出删除路径命令，但表空间还在使用
创建存储器组
创建存储器组
• • 权限
– 需要SYSADM,SYSCTRL实例权限
命令
– CREATE STOGROUP sg_hot ON ‘/d’ DEVICE READ RATE 800 OVERHEAD 3.725
•
•
存储器组数量
– 一个STOGROUP最多可设128个存储路径，一个数据库最多有256个存储器组
– 对于数据仓库，假设用RAID5（每个LUN用24个盘，一般不用这么多），每个盘用 146G，则一个数据库的存储器组容量为（24—1）×136×128×256=100PB。数据 仓库，9.7之后32KB大页大型自动表空间容量可达64TB，存储器组提供的容量可以 包含1500个自动表空间
•
•
三个存储器组
DB2 10.1新技术存储器组详解之一
存储器组出现原因、概念、存储器组的创建 孙扬 db2china社区ID: sunyangnj
目录
• 出现原因
– 表空间发展的原因 – 表空间能力概括比较 – 存储器的诞生
• 存储器组概念介绍 • 存储器组创建
– 存储器组规划 – 存储器组的创建 – 存储器组创建的最佳实践
存储器组概念
• 存储器组是什么
– 一组路径列表。存储器组对应数据库不同类型或者级别的存储器层。一个存 储器组中的存储器们最好具有相同的媒体特性（OVERHEAD，DATA READ RATE，RAID保护度、容量）。 怎么分配存储器组
– 根据表空间数据对应服务质量要求为表空间分配存储器组。比如访问频率、响应 时间要求、数据宜变性等。一个表空间只能使用一个存储器组，一个存储器组可 以被多个表空间使用。可以用ALTER TABLESPACE 为表空间更换存储器组。 只有自动存储表空间才可使用存储器组。