将 DB2 for i 表和索引同时移动到固态硬盘

从固态硬盘投资中获取最大价值的一种更简单、高效的方法

当 DB2 for i 索引或表位于固态硬盘(SSD)中时,可以获得显著的性能优势。Change Physical File Member (CHGPFM) 和 Change Logical File (CHGLFM) 命令现在可用于同时将索引或表的某个成员(或分区)移入或移出 SSB 存储设备。

Mark J. Anderson (mja@us.ibm.com), DB2 for i 首席架构师, IBM

Mark J. Anderson photoDB2 for i 首席架构师,主要负责 DB2 for i 的架构、设计和实现。IBM Information Management Architecture Board 和 SQL Language Council 的成员。



2011 年 8 月 24 日

DB2 for i 媒介首选项概述

固态硬盘(SSD)支持在 2009 年中期发布 V5R4 和 IBM i 6.1 时被添加到 IBM i。使用 SSD 硬盘要比使用传统磁盘快许多,因此可以为大多数应用程序提供性能增益。然而,SSD 的成本要高于传统磁盘,因此,必须使用户能够从其 SSD 投资中获取最大程度的受益。最大化 SSD 投资收益的方法就是将 DB2 for i 数据放到 SSD 中,这将最大化应用程序的性能。

那么,什么样的数据应放在 SSD 中,从而最大限度地提高性能?

有三种关键的数据,通常不适合放到 SSD 中。

  1. 鲜少访问的数据。例如,如果您的表中保存的是很少访问的历史数据,那么肯定不希望它们占用昂贵的 SSD 存储设备。
  2. 频繁执行写操作的数据。即便 SSD 写操作要快于传统的磁盘,但是磁盘写缓存通常提供良好的磁盘写性能,从而使这两种类型的磁盘可以实现相差无几的写性能。因此,日志接收器并不适合放到 SSD 中,因为它们通常都是频繁执行写操作的。
  3. 按顺序读取的数据。当按顺序读取 IBM i 中的数据时,在使用数据之前,需要使用预提取(pre-bring)逻辑和缓冲,将数据提取到内存中。

最适合放入 SSD 的数据是 DB2 for i 对象,其中包含的数据是频繁地随机访问的。例如,对保存在 SQL 索引或键控(keyed)逻辑文件中的键值执行随机的键查找操作。

可以有多种方法将 DB2 for i 对象放到 SSD 中,但是效率最高的一种方法就是使用 DB2 媒介首选项属性。媒介首选项可以针对索引或键控文件指定,请求将底层索引对象分配到 SSD 存储设备。也可以对表或物理文件指定媒介首选项,请求将数据本身分配到 SSD 存储设备。然而,由于数据本身通常要比索引大很多,将随机访问最频繁的索引分配到 SSD 是使用价格更昂贵的 SSD 存储设备的最佳方式。


创建索引或数据并移动到 SSD 的早期方法

V5R4 中首次提供的 SSD 支持允许用户在创建时指定媒介首选项,或稍后使用如下所示的命令进行修改:

   CRTPF FILE(MJATST/pf1) UNIT(255)
    
   CRTLF FILE(MJATST/lf1) UNIT(255)
    
   CHGPF FILE(MJATST/pf1) UNIT(255)
    
   CHGLF FILE(MJATST/lf1) UNIT(255)

在 IBM i 6.1 版本中,UNIT(*SSD) 被添加到 CL 命令中,作为 UNIT(255) 的一种替代选择。IBM i 6.1 版本还允许用户在 SQL 语句中指定媒介首选项,如下例所示:

   CREATE TABLE sales 
    (unid INT primary key, salesdate DATE, itemnbr INT, quantity INT, price DECIMAL(9,2) )
   UNIT SSD
    
   CREATE INDEX salesinx on sales (unid) UNIT SSD
    
   ALTER TABLE sales ALTER UNIT SSD

如果 SQL 表是一个分区表,每个分区(成员)都可以有一个单独的媒介首选项。这允许用户对表进行分区,从而将某个表分区中频繁访问的数据放到 SSD 中,而访问不频繁的数据放到传统磁盘上的其他表分区中。例如,当前数据可以放到 SSD 上的分区,而历史数据可以放到传统磁盘上的分区:

   CREATE TABLE sales 
    (unid INT primary key, salesdate DATE, itemnbr INT, quantity INT, price DECIMAL(9,2) )
    PARTITION BY RANGE(salesdate NULLS LAST)
    (PARTITION sales2006 
         STARTING ('2006-01-01') ENDING('2006-12-31') INCLUSIVE UNIT ANY, 
    PARTITION sales2007 
         STARTING ('2007-01-01') ENDING('2007-12-31') INCLUSIVE UNIT ANY, 
    PARTITION sales2008 
         STARTING ('2008-01-01') ENDING('2008-12-31') INCLUSIVE UNIT SSD )

   ALTER TABLE sales ALTER PARTITION sales2007 
         STARTING ('2007-01-01') ENDING('2007-12-31') INCLUSIVE UNIT ANY

尽管 V5R4 特别是 IBM i 6.1 中对媒介首选项的支持非常丰富,然而还存在一些不足之处:

  • 对于已分区的 SQL 表来说,媒介首选项可以在分区(成员)级别进行控制,但是对于具有多个成员的 DDS 创建的物理文件则无法实现这一点。
  • 对于分区的 SQL 索引,无法对不同的分区(成员)指定不同的媒介首选项,更别说带有多个成员的 DDS 创建的键控逻辑文件。
  • 最后,所有现有语句和 CL 命令在整个文件上需要一个互斥型锁。

通过添加 CHGPFM 和 CHGLFM 命令解决了上述这些缺陷,这两个命令也可以通过以下 PTF 组(Group PTF)获得:IBM i 6.1 (SF99601 Version 19) 和 IBM i 7.1 (SF99701 Version 6)。在 V5R4 上尚无打算支持这些增强功能。


使用 CHGPFM 将数据移动到 SSD

CHGPFM 命令可以将成员(或分区)的数据移动到 SSD,或从其中移出。例如:

   CHGPFM FILE(MJATST/SALES) MBR(SALES2007) UNIT(*SSD) 
    
   CHGPFM FILE(MJATST/SALES) MBR(SALES2007) UNIT(*ANY)

注意,如果物理文件使用了键控(可能因为它有一个 Primary Key 约束),其隐式索引也将通过这些命令被移动到 SSD 或从中移出。


使用 CHGPFM 和 CHGLFM 将索引移到 SSD

将索引移入或移出 SSD 有一点复杂。索引在几个不同的情形下创建:

  • 为键控物理或逻辑文件创建索引。这包括 DDS 创建的文件和 SQL 索引,以及带有 Primary Key 约束的物理文件。CHGPFM 或 CHGLFM 命令将把与键控或逻辑文件有关的索引移入或移出 SSD。例如:
   CHGPFM FILE(MJATST/pf1) MBR(m1) UNIT(*SSD)

   CHGLFM FILE(MJATST/lf1) MBR(m1) UNIT(*SSD)
  • 为 Unique 或 Foreign Key 约束创建索引。CHGPFM 不会将 Unique 或 Foreign Key 索引移入或移出 SSD。
  • 可以为 DDS 创建的连接逻辑文件创建多个索引。CHGLFM 将把与连接逻辑文件有关的所有二级索引移入或移出 SSD。

那么,在以下情形应该怎么做?

  1. 您有一个键控的物理文件,但只希望将索引放到 SSD,而不希望将数据本身放到其中,因为物理文件中的数据量非常大。
  2. 您有一个索引与 Unique 或 Foreign Key 约束关联并且该索引被大量的查询所使用,您希望将这个索引放入 SSD。
  3. 您有一个连接逻辑文件,但是只希望在 SSD 中保存键的索引,而不是二级索引。

处理以上所有情形的方法是创建一个简单的键控逻辑文件或 SQL 索引,它们共享您希望放在 SSD 上的索引(或访问路径)。

使用 CHGLFM 和索引共享将索引移动到 SSD

当数据库管理员发现您正在创建的索引与现有索引相同,或在某些情况下是后者的一个子集时,那么这时将发生索引共享。此时不会创建并维护一个全新的索引,而是会共享这个相同的索引。

当多个文件共享一个索引时,如果这些共享文件的其中任何一个的媒介首选项指定了 SSD,那么该索引将有一个 SSD 媒介首选项。如果这些共享索引的文件都没有指定 SSD,那么索引的媒介首选项为 ANY。

假设您有一个 DDS 创建的键控物理文件,并且只希望在 SSD 中保存索引而不是数据。您可以创建一个键控逻辑文件或 SQL 索引,它们共享物理文件的索引。下面举了一个 SQL Create Index 语句的例子,它实现了索引共享。

   CREATE INDEX inx1 ON pf1 (key1) PAGESIZE 8

现在,您可以对新的逻辑文件或 SQL 索引发出 CHGLFM 命令,将索引移入或移出 SSD,而数据保持不动:

   CHGLFM FILE(MJATST/inx1) UNIT(*SSD)

注意,如果在创建共享索引时指定 SSD 属性,索引将在此时移动到 SSD。

要使逻辑文件或索引实现共享,索引属性必须一致。例如,带有 LIFO 属性的索引不能与带有 FIFO 属性的索引进行共享。以下属性必须保持一致:

  • 关键字段和关键字段的顺序(有时,允许关键字段的子集)
  • 升序或降序
  • 完全一样的键顺序(UNIQUE、UNIQUE WHERE NOT NULL、LIFO、FIFO 和 FCFO)
  • 排序顺序或交替的排序序列
  • 逻辑页面尺寸(例如,在上面的 CREATE INDEX 语句中,需要 PAGESIZE)
  • 最大尺寸(*MAX1TB,*MAX4GB 或 EVI)

判断现有索引的属性以及您创建的索引是否共享访问路径的最简单的方法是使用 System i Navigator 中的 Show Indexes 函数。Show Indexes 任务显示现有索引中您希望共享的所有属性(参见下面的图 1 和图 2)。

图 1. 对表启用 Show Indexes
图 2. Show Indexes 示例

Show Indexes 只显示真正的索引,而不显示只共享另一个文件的索引的文件。创建了新索引之后,刷新 Show Indexes 列表。如果在 Show Indexes 列表中看到了索引,那么其中一个属性一定是不一致的。比较新索引的属性和希望共享的索引的属性,看看它们是否匹配。在 CREATE INDEX 语句或逻辑文件的 DDS 中纠正索引,然后重试。Show Indexes 函数还显示每个索引的媒介首选项,因此一旦您创建了共享索引并将媒介首选项更改为 SSD,刷新 Show Indexes 列表后将显示 SSD 媒介首选项。


CHGPFM 和 CHGLFM 并发性

如前所述,之前所有用于修改媒介首选项的方法都要求对整个文件使用互斥型锁。如果任何应用程序当前正在访问文件或文件的任何成员,那么将导致无法修改媒介首选项。相反地,如果能够获得互斥型锁,那么并发应用程序就无法访问文件,并因为锁超时失败。

和以前的方法不同,CHGLFM 和 CHGPFM 不需要用到互斥型锁。将需要使用 *SHRUPD 锁,但是它只与对文件使用 *SHRNUP、*EXCLRD 或 *EXCL 锁的任务冲突。这一次,DB2 引擎获得一个互斥捕捉,用于同步地移动数据,因此当锁超时没有发生时,其他任务将等待数据移动的完成。在某个时候我们可以修改命令来异步地移动数据,这样就可以令其他任务不必等待数据移动操作的完成。


如何知晓有多少索引或数据实际位于 SSD 中?

当将对象移动到 SSD 时,如果 SSD 中的空间不足,那么将只有部分对象会存储到 SSD 中。因此,您有时希望知道有多少对象被实际存储到 SSD 中。幸运的是,以下 PTF 组附带的一组增强功能解决了这个问题。

  • V5R4 (SF99504 Version 28)
  • IBM i 6.1 (SF99601 Version 16)
  • IBM i 7.1 (SF99701 Version 4)

提供了新的目录视图,可以返回有关实际为索引和数据分配的磁盘的信息。

  • QSYS2.SYSPARTITIONDISK 是一个视图,返回有关 DB2 for i 表和物理文件的分配信息。例如,以下 Select 语句会报告 MJATST 模式(库)中所有 SQL 表或物理文件的数据分配信息:
   SELECT MAX(table_schema) AS table_schema, MAX(table_name) AS table_name, 
      MAX(table_partition) AS table_partition, 
      SUM(CASE WHEN unit_type = 1 THEN unit_space_used ELSE null END) AS ssd_space,
      SUM(CASE WHEN unit_type = 0 THEN unit_space_used ELSE null END) AS non_ssd_space
   FROM qsys2.syspartitiondisk a
   WHERE system_table_schema = 'MJATST'
   GROUP BY a.table_schema, a.table_name, table_partition
   ORDER BY 1,2,3

下面的 SELECT 语句将返回 MJATST 模式(库)中在 SSD 上有一些分配的任意 SQL 表或物理文件。

   SELECT 	DISTINCT table_schema, table_name, table_partition
   FROM qsys2.syspartitiondisk a
   WHERE system_table_schema = 'MJATST' and UNIT_TYPE = 1
  • QSYS2.SYSPARTITIONINDEXDISK 视图将返回有关 DB2 for i 索引(例如,键控文件、约束索引和 SQL 索引)的分配信息。例如,以下 Select 语句将报告 MJATST 模式(库)中表或物理文件上的所有索引的分配信息:
   SELECT index_schema, index_name, index_member, index_type, 
     SUM(CASE unit_type WHEN 1 THEN unit_space_used ELSE 0 END)/COUNT(*) AS ssd_space, 
     SUM(CASE unit_type WHEN 0 THEN unit_space_used ELSE 0 END)/COUNT(*) AS nonssd_space 
   FROM qsys2.syspartitionindexdisk  b 
   WHERE system_table_schema = 'MJATST' 
   GROUP BY index_schema, index_name, index_member, index_type

以下 SELECT 语句将返回 MJATST 模式(库)中在 SSD 上有一些分配的的表或物理文件的任何索引:

   SELECT DISTINCT index_schema, index_name, index_member, index_type
   FROM qsys2.syspartitionindexdisk  b 
   WHERE system_table_schema = 'MJATST' and UNIT_TYPE = 1;

结束语

CHGPFM 和 CHGLFM 提供了将索引和数据移入和移出 SSD 的简单、灵活的方法,这样您就可以最大化您的 SSD 投资。增强的命令不需要像以前的方法一样使用互斥型锁。


参考资料

可以在下面找到有关 SSD 和最新增强的额外信息:

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=IBM i, Information Management
ArticleID=753599
ArticleTitle=将 DB2 for i 表和索引同时移动到固态硬盘
publish-date=08242011