DB2 Viper 2 中可帮助企业成长的新特性

重新设计的重分发实用程序、对行压缩的增强和数据库角色

随着企业的成长,系统和数据库管理员要面临很多挑战;其中就包括如何增加数据库的容量,如何有效地存储更多的数据,以及如何管理数量日益增长的用户的特权和权限。本文展示如何利用 DB2® Viper 2 (Viper 2 是 DB2 V9.5 的开发代号)中的这三个重要特性来克服这些挑战:新的重新设计的重分发实用程序、对行压缩的增强以及数据库角色。

Kevin Yeung-Kuen See (see@ca.ibm.com), 软件开发人员, EMC

Kevin See 是 CISSP,在过去十年一直是 IBM 多伦多实验室的一名专职软件开发人员。他曾在 DB2 Security Development 小组和 DB2 SQL and Catalog Development 小组工作。他是 IBM 认证的 XML 及相关技术解决方案开发人员,同时也是 DB2 认证的解决方案专家(DBA for OS/390、DBA for Linux/Unix/Windows 和 DB2 Family Application Development)。他还是 ISC2 认证的信息系统安全专家。他撰写了两篇 IBM Developer Works 安全性方面的文章,并且正在与人合作撰写一本关于 DB2 安全性方面的书。



2007 年 11 月 19 日

简介

随着企业的成长,越来越多的用户和客户需要访问数据库中的数据。因此,需要增加数据库的容量,以满足这一需求。与此同时,容量的增加又间接地增加了硬件需求,以便在物理上能够存储日益增长的信息和数据。虽然与十五年前相比(那时候一个 250 MB 的硬盘就要花费 200 美元),硬盘的成本降低了很多,但是对于企业来说,增加磁盘驱动器仍然需要一笔不容忽视的成本。

最后,随着内部用户和客户数量的增加,需要确保在适当的级别上为适当的人员授予特权,以避免数据库的潜在安全风险。

DB2 Viper 2 提供了一个 最近重新设计的离线重分发数据库分区组实用程序,通过该实用程序,不必使用之前版本的 REDISTRIBUTE DATABASE PARTITON GROUP 所要求的那么多的数据库日志空间或时间就可以增加容量。

行压缩 是在 DB2 9 中引入的。行压缩的一个优点是,如果压缩有效,则可以提高查询的性能,因为预取器可以将更多的数据放进缓冲池。但是,只能使用离线 reorg table 命令或 inspect 实用程序来创建压缩字典。DB2 Viper 2 中引入了 自动字典创建特性,以进一步增强行压缩。

最后,Viper 2 中现在提供了 数据库角色特性。通过该特性可以使权限和特权的建模更贴近企业结构。它还可以缓解由组特权限制导致的某些问题。

1. 重新设计的重分发数据库分区组实用程序

欲调用这个最近重新设计的实用程序,可像之前那样发出 REDISTRIBUTE DATABASE PARTITON GROUP 命令,但是这里可以指定更多的选项(见 1.2 小节的演示)。1.3 小节会详细解释该特性。

为了添加新的数据库分区,首先需要更新实例,使之包括新的分区。和之前的版本一样,如果数据库管理器已经被停止,或者您愿意通过 db2stop 使数据库管理器离线,则可以使用 db2start add node 命令来更新。如果数据库实例仍在运行,那么可以使用 sqleaddn API 或者 add dbpartitionnum 命令。

将新的数据库分区添加到实例之后,该实例中的每个数据库就可以利用新添加的数据库分区。可以选择将这个额外分区添加到某一个数据库分区组。建议发出 ALTER DATABASE PARTITION GROUP 语句来定制表空间设置,并控制新分区中的容器布局。如果想复制分区组中第一个分区的设置,则可以在 REDISTRIBUTE DATABASE PARTITON GROUP 命令中利用新的 add dbpartitionnum 选项。

和从前一样,有三种方法可生成数据库分区映射:平均法,通过分布数组指定权重(使用 distfile),以及用户指定(使用 targetmap)。

旧版本的重分发实用程序通过子选择语句使用特殊的 insertdelete。对于每个重分发的表,它都要进行提交。因此,该实用程序会生成很多数据库日志活动。如果数据库日志文件比较小,则会很快用完日志空间,并导致重分发失败。对于所移动的每一行,有两个动作 — insert 和 delete。数据是逐行移动的。因此,这样大大增加了重分发时间。

新版本的重分发实用程序使用小型日志记录模型和页级数据移动(见 1.1 小节中的解释)。因此可以减少对数据库日志文件的使用和提高数据移动的速度。

性能在三个方面得到了提高:

  • 消除了逐行操作(使用页级数据移动)
  • 支持并发表
  • 将多个操作合并成一个操作

通常,在数据库分区组重分发之后,需要在重分发的表上执行离线的 table reorgindex recreation(必要时)和 runstats。这些操作中:redistributetable reorgindex createrunstats,每个操作都需要扫描一次表数据。因此,如果能将所有这三个操作合并成一个操作,则可以大大提高性能。此外,日志记录被减至最少,以免多次分解重分发实用程序,并且不必管理大量的活动日志空间和日志归档空间。最后,重分发实用程序的可用性方面也得到了提高,现在可以指定表顺序,并且可以逐个表地停止和继续重分发数据表。此外,新版本还引入了一个用户友好的进程监视特性和一个 SQL 接口,可以从任何客户机远程访问该特性。可以通过命令行处理器(CLP)(list utilitieslist utilities show details)或 管理视图(SNAPUTILSNAPUTIL_PROGRESS)或管理表用户定义函数(UDF)(SNAP_GET_UTILSNAP_GET_UTIL_PROGRESS 检索进程信息。

1.1 非前滚可恢复性

由于与每种对象类型的数据移动相关的所有更新都没有被记录到日志中,因此重分发实用程序不是前滚可恢复的。这意味着,通过 redistribute 操作进行前滚的效果是,所有被重分发的表都被标记为 “invalid”(无效)。这些表没有任何用处,只得删掉。

建议在运行离线重分发实用程序之前,对数据库进行完全备份。最起码要确保在使用重分发实用程序之前采取了足够的表空间备份,以便必要时能将数据库恢复到 redistribute 操作之前的时间点上。

当该实用程序开始重分发一个表时,它将与该表有关的所有表空间(数据表空间、索引表空间和 long 表空间)都置于 BACKUP PENDING 状态,并将这个表本身标记为 unavailable 和 redistribute_pending。在这个表被重分发之后(回到正常状态),需要进行一个表空间级的备份,以便重新获得对该表的全部访问权。

理论上讲,可以在数据库分区组中尚未重分发的表上执行 selectinsertupdatedelete 语句。而且,当重分发实用程序仍在运行时,如果在与该表相关的表空间上执行了表空间备份,那么也可以在被重分发的表上执行相同的操作。但是,由于重分发不是前滚可恢复的,如果由于任意原因使重分发恢复选项 — 继续或终止 — 不能继续或终止之前失败的重分发,那么在重分发期间并发运行的任何事务都可能被丢失。因此,最好不要执行只读操作(例如 SELECT)之外的任何操作。

*******************************************************************
提示:
如果日志中间有重分发操作,那么不要前滚这样的日志!

在使用重分发实用程序前后总是进行备份。
*******************************************************************

1.2 最近重新设计的实用程序的语法

清单 1. 语法图
>>-REDISTRIBUTE DATABASE PARTITION GROUP--database partition group-->

>--NOT ROLLFORWARD RECOVERABLE-------------------------------------->
 
>--+-+-UNIFORM------------------+--+--+----------------------------+->
   | '-USING DISTFILE--distfile-' |   '--| ADD/DROP DBPARTITION |--+
   +-USING TARGETMAP--targetmap------------------------------------|
   +-CONTINUE------------------------------------------------------+
   '-ABORT---------------------------------------------------------'

>--+---------------------------------------+------------------------>
   |          .-,----------.               |
   |          v            |    ,--ONLY-,  |
   '--TABLE-(---table name-+-)--+-------+--+
                                '-FIRST-,

>--+----------------------------+----------------------------------><
   '--| REDISTRIBUTE OPTIONS |--'  

ADD/DROP DATABASE PARTITION SPEC:
>--+-----------------------------------------------------+---------->
   |                             .-,----------------.    |
   |                             v                  |    |
   +--ADD--+-DBPARTITIONNUM--+-(---n--+---------+--+-)--+
           '-DBPARTITIONNUMS-'         '--TO m--'

>--+-----------------------------------------------------+---------->
   |                              .-,---------------.    |
   |                              v                 |    |
   +--DROP--+-DBPARTITIONNUM--+-(---n--+--------+--+-)--+
            '-DBPARTITIONNUMS-'         '--TO m--'

REDISTRIBUTE OPTIONS:
|--+---------------------------------------------+------------------>
   |                                             |
   +---PARALLEL TABLE --n------------------------+
   |                                             |
   |   ,--COMPACT ON---,                         |
   +---+               +-------------------------+
   |   '--COMPACT OFF--'                         |
   |                                             |
   |   ,--INDEXING MODE AUTOSELECT--,            |
   +---+                            +------------+
   |   +--INDEXING MODE INCREMENTAL-+            |
   |   +--INDEXING MODE REBUILD-----+            |
   |   '--INDEXING MODE DEFERRED----'            |
   |                                             |
   +---DATA BUFFER --n---------------------------+
   |                                             |
   |   ,--STATISTICS USE PROFILE--,              |
   +---+                          +--------------+
   |   '--STATISTICS NONE---------'              |
   |                                             |
   '---STOP AT--local-isotime-------------------'

注意,关键字方面有一个变化。旧的关键字 ROLLBACK 已经不赞成使用,而被新的关键字 ABORT 取代。这是因为 ROLLBACK 很容易与事务回滚混淆,而 ABORT 则与其他实用程序更加一致。

1.3 最近重新设计的实用程序中的特性

第一个特性是为已有数据库分区组添加或删除数据库分区,以及在相同命令上执行重分发的能力。这在过去是由两个步骤组成的一个过程,首先需要发出 ALTER DATABASE PARTITION GROUP 语句来添加或删除分区。如果您正在添加数据库分区,那么会被请求为新的分区指定表空间信息。

可以在同一个命令上同时指定添加和删除数据库分区,但是必需先添加,后删除。否则,语法就不能被识别。如果想撤掉一些旧的计算机,并添加更强大的计算机到数据库 DPF 集群中,那么您很可能会同时指定添加和删除。注意,如前所述,添加分区选项会自动根据组中第一个分区的表空间设置在新分区上创建表空间。

在发出 REDISTRIBUTE DATABASE PARTITION GROUP 命令时,可以指定 8 个新选项:TABLE FIRSTTABLE ONLYPARALLEL TABLECOMPACTINDEXING MODEDATA BUFFERSTATISTICSSTOP AT。可以将所有这些选项应有到开始的 redistribute 命令上,或者应用到随后的 redistribute continueredistribute abort 命令上。

TABLE FIRST
TABLE FIRST 选项允许指定数据重分发期间优先于其他表的一组表。在这组表被重分发之后,再根据 DB2 决定的顺序对数据库分区组中剩下的表进行重分发。如果命令成功,并返回 sqlcode 0,则组中所有的表都被重分发。

TABLE ONLY
TABLE ONLY 选项允许指定数据重分发期间将被重分发的一组表。在重分发这组表之后,不再重分发数据库分区组中剩下的表。因此,分区组只是部分重分发,剩下的表可以在下次使用 redistribute 命令和 continue 选项来重分发。

PARALLEL TABLE
PARALLEL TABLE 选项告诉重分发实用程序,在表级并行执行重分发,并同时重分发其中的多个表。如果不显式地指定该选项,DB2 默认地使用两个表的并行度(parallel table 2 选项)。

COMPACT
COMPACT ON 是重分发实用程序的默认选项,它像离线 table reorg 那样执行空间压缩。可以显式地指定或者关闭该选项。

INDEXING MODE
默认情况下,当重分发数据时,使用索引模式 autoselect。这意味着,DB2 从重新构建和增量索引维护两种方法中选择最合适的方法。也可以指定重新构建或者增量选项。如果按照指定的方法不能合法地使用索引,则重新创建索引。如果您想先将所有索引标记为坏索引,以后再重新创建它们,那么可以指定 deferred 选项。

DATA BUFFER
和装载实用程序一样,可以指定想从实用程序堆中获得多少内存来运行这个实用程序。如果不指定一个值,DB2 自行决定一个最适合的值,并使用那个值。

STATISTICS
如果一个表已经有一个来自之前运行的 runstats 操作的 statistics profile,那么可以指定 statistics use profile(或保留默认设置)。当数据被移动到适当的分区之后,该实用程序自动使用已有的 statistics profile 在任何表上执行 runstats。可以通过指定 STATISTICS NONE 关闭该选项。

可能出现这样的情况:表已经有一个 statistics profile,虽然指定了 statistics 选项,但是实用程序不能执行统计信息收集。如果所有分区都处于 combo 状态,都在发送和接收数据,那么不能收集统计信息。这通常被称作交叉数据移动(xcross data movement)。例如使用具有如下数据移动的目标映射的重分发:
partition 11 -> partition 11, 19, 51
partition 19 -> partition 11, 19, 51
partition 51 -> partition 11, 19, 51
因此,每个分区都将数据发送到所有其他分区,同时留有部分数据。

STOP AT
STOP AT 允许指定一个时间,当到了这个时间时,即使重分发实用程序还没有完全完成所有表的重分发,也必须停止执行。重分发实用程序估计重分发一个表需要多长时间,并比较当前时间和停止时间(如果指定了的话),看看是否能在允许的时间内完成。如果估计可以按时完成,那么它就开始重分发那个表。由于这只是一个估计,因此未必能在指定时间停止,但是尽可能接近指定的时间。

1.4 监视重分发进程

DB2 Viper 2 允许使用已有的实用程序监视界面监视重分发实用程序的进程:CLP(LIST UTILITIESLIST UTILITIES SHOW DETAILS 命令)或管理视图(SNAPUTILSNAPUTIL_PROGRESS)或管理表 UDF(SNAP_GET_UTILSNAP_GET_UTIL_PROGRESS)。

下面是正在进行数据重分发时发出 db2 LIST UTILITIES SHOW DETAILS 后得到的输出。这里正在用一个新添加的分区对数据库分区组 RDST_V10_015 进行重分发。指定的其他选项有 COMPACT ON (默认)、INDEXING MODE INCREMENTALPARALLEL TABLE 3。还应注意,该输出只显示了一个分区。实际的输出会显示每个分区,包括新添加的分区。

清单 2. 监视重分发进程的示例输出
db2 list utilities show detail

ID                               = 1
Type                             = REDISTRIBUTE
Database Name                    = RDST819
Partition Number                 = 11
Description                      = RDST_V10_015 UNIFORM ADD NODES
                                   COMPACT ON SPACE REUSE RECORD LEVEL
                                   INDEXING MODE INCREMENTAL
Start Time                       = 02-20-2007 23:21:33.785819
State                            = Executing
Invocation Type                  = User
Progress Monitoring:
   Estimated Percentage Complete = 8
   Summary:
      Total Work                 = 1965600
      Completed Work             = 155221
      Total Number Of Tables     = 15
      Tables Completed           = 0
      Tables In Progress         = 3

   Current Table 1:
      Description                = "NEWTON  "."RDST_V10_015A"
      Total Work                 = 655200 bytes
      Completed Work             = 55001 bytes

   Current Table 2:
      Description                = "NEWTON  "."RDST_V10_015B"
      Total Work                 = 450200 bytes
      Completed Work             = 54220 bytes

   Current Table 3:
      Description                = "NEWTON  "."RDST_V10_015C"
      Total Work                 = 978901 bytes
      Completed Work             = 46000 bytes

1.5 示例场景

在线图书销售商 “XYZ” 有一个三分区的 DPF 集群(为简化问题,假设这三个分区分别使用分区号 11、19 和 51),用于存储客户交易(在表空间 CUSTOMER 中)、内部 HR 信息和很多其他数据的后端 DB2 数据库。他们注意到,有一个分区在性能上不如另外两个分区,因为它是一个较旧的、不够强大的机器。

成功地完成了一项生意后,IT 部门购买了两台新机器。系统管理员或 DBA 被要求将这两台机器(假设分区号分别为 171 和 999)编入集群中,并撤掉那台旧机器(假设分区号为 19)。

由于数据库的某一部分是 24x7 地被使用的,因此对系统中每个数据库分区组和每个表的变更必须逐步进行,因为维护窗口非常小,而系统又需要立即上线运行。另外还需要收集统计信息,重新构建所有无效的索引。

首先,必需使用 add dbpartitionnumsmodify the db2nodes.cfg 添加两个新的分区,将这两个新分区包括进来。这样,实例级的工作就完成了。

下一步是决定重分发的表的优先级。显然,在这种情况下,与在线图书销售有关的任何表都是优先的。假设数据库分区组 SALES 包含与图书销售事务有关的所有表,且表 TRANS(包含客户信用卡交易)比表 CATALOG(包含更多静态的目录信息)和其他相关的表优先级更高。

首先发出以下命令:

redistribute database partition group SALES uniform
 add dbpartitionnums (171,999)  drop dbpartitionnums (19) 
 table (TRANS) first stop at xxxx compact on statistics 
 use profile indexing mode rebuild

接着,为表空间 CUSTOMER 执行一个表空间级备份,以便能够重新获得对 TRANS 和 CATALOG 表的完全访问权。

几周过去了。在接下来的一个维护窗口中,您决定只重分发 CATALOG 表,因为还有其他具有更高优先级的项目要做。您很可能会执行像下面这样的命令:

redistribute database partition group SALES CONTINUE 
table (CATALOG) ONLY compact on statistics 
use profile indexing mode rebuild

您需要为表空间 CUSTOMER 执行一个表空间级备份,以便能够重新获得 TRANS 和 CATALOG 表的完全访问权。

您想重分发剩下的表,但是时间有限,因此使用 STOP AT 选项:

redistribute database partition group SALES CONTINUE 
stop at xxx compact on statistics 
use profile indexing mode rebuild

继续使用以上的 redistribute continue 命令和 STOP AT 选项,直到重分发完所有的表。如果有更多的表要重分发,但是由于 STOP AT 时间限制重分发被停止,那么该命令返回 sqlcode +1379。

下面是 sqlcode +1379 的一个例子:

SQL1379W  Database partition group "RDST_V10_017" has been partially
redistributed. The number of tables redistributed is "1", and the 
number of tables yet to be redistributed is "2". Reason code = "2".

如果所有表最终都被重分发,那么最后一次带 STOP AT 选项的 redistribute continue 命令将返回:

DB20000I  The REDISTRIBUTE DATABASE PARTITON GROUP 
command completed. successfully.

每当 redistribute 命令完成时,记住在被重分发的表所在的表空间上执行一个表空间级备份。否则,该表空间仍然处于 backup pending 状态。

当所有表和数据库分区组都从驻留在旧机器上的分区中转移出来之后,可以使用 drop dbpartitionnums 从实例中完全删除分区。

注意:记住也要重分发 IBMDEFAULTGROUP 数据库分区组。IBMDEFAULTGROUP 是在数据库创建时自动创建的。

2. 对行压缩的增强

行压缩特性是 DB2 9 中最流行的特性之一。该特性弥补了已有的列级压缩、系统默认值压缩和值压缩选项。但是,在压缩输入到表中的数据之前,为了利用行压缩,必须首先使用 DB2 inspect utility 或离线 table reorg 构建一个字典。在 DB2 Viper 2 中,有一个称作 Automatic Dictionary Creation (ADC) 的新特性为解决这一需求提供的便利。

2.1 ADC 简介

ADC,顾名思义,是自动创建压缩字典的处理过程。首先必须启用表属性 COMPRESS,以便应用 ADC。此外,只有当物理表数据对象或分区中没有压缩字典时,才能运行 ADC。如果已经有一个字典,则不能激活 ADC。ADC 的前提是根据抽样的一小部分表数据自动创建一个代表性的压缩字典。创建好字典并自动将插入表之后,以后填充的所有数据都会被压缩。图 1 演示了 ADC 概念。

图 1. ADC
ADC

2.2 更多执行行压缩的方法

除了 inspect 实用程序和离线 table reorg 外,只要启用了表属性 COMPRESS ,并且有足够的可用数据(数据已经在表中,还有新的数据行或数据行的扩展),就可以在 LOAD INSERTLOAD REPLACEREDISTRIBUTE DATABASE PARTITION GROUPINSERTUPDATE 期间自动构建一个字典。

和离线 table reorg 一样,LOAD REPLACEKEEPDICTIONARYRESETDICTIONARY 选项。只需在 REPLACE 关键字后指定 KEEPDICTIONARYRESETDICTIONARY 关键字。如果没有指定任何关键字,且表属性 COMPRESS 已启用,则使用 KEEPDICTIONARY 行为。

为了与新的 ADC 特性同步,离线 table reorgKEEPDICTIONARY 行为已经被更改。欲了解更多信息,请参阅 “2.4 使用离线 reorg 实用程序的行压缩中的行为的变化” 小节。

如果在 inspect 工具中使用离线 table reorgrowcompestimate 选项,则表中的数据将被完全压缩。对于其他接口,如 图 1 所示,抽样数据(用于构建 ADC 字典)直到执行离线 table reorg 时才被压缩。

2.3 影响 ADC 的因素

有两个因素会影响 ADC:可用于抽样的最小(阈值)数据量(ADC_THRESHOLD)和抽样缓冲区中有用数据的最小百分比(ADC_MINPCT)。这两个值由 DB2 在内部预先设置。

在不同的字典构建接口中,这两个因素的用法不同。当达到 ADC_THRESHOLD 时,ADC 就开始执行。但是,在抽样期间,装载和重分发实用程序不使用 ADC_MINPCT。

在使用装载实用程序将数据添加到一个表中,以及用重分发实用程序将数据重分发到表的一个新分区中的最后,这两个实用程序都会检查传入的新数据的数量,看看是否至少有 ADC_THRESHOLD * ADC_MINPCT 这么多的数据。如果有,那么它们仍然生成一个压缩字典,但是在这里,没有被压缩的记录,因为所有数据已经被移到表中。

装载实用程序和重分发实用程序的字典构建是异步的,所以在构建字典的同时,可以将数据装载或移动到新的分区。构建好字典之后,任何新传入的数据都要进行压缩。如果有两个并发的线程在执行到一个表的插入操作,那么会出现类似的情况。其中一个线程可能正在构建字典,而另一个线程则继续插入数据到表中,而不必等到构建完字典之后才对行进行压缩。

2.4 使用离线 reorg 实用程序的行压缩中的行为的变化

在 DB2 9 中,REORG TABLE 命令中的默认压缩字典指令是 KEEPDICTIONARY。如果表属性 COMPRESS 被设为 YES,并且表中还没有压缩字典,则 KEEPDICTIONARY 指令不管表中数据量如何,都会尝试构建一个压缩字典并将其插入表中。在这个场景中,只要表中存在一个有效的记录,就尝试创建一个字典。

随着 ADC 的引入,REORG TABLE KEEPDICTIONARY 场景的行为已经发生了变化。只有当表的大小等于 ADC 阈值时,才将字典插入到表中。

2.5 对于数据行小于或等于最小记录长度的表的行压缩中的行为变化

在 DB2 9 中,在构建字典时,任何小于或等于数据库管理器最小记录长度的数据行都不用于抽样,并且在行压缩期间不会被压缩。从 DB2 Viper 2 开始,所有数据行都参与抽样。但是,即使创建了字典,小于或等于数据库管理器最小记录长度的数据行仍不会被压缩。

2.6 用于压缩信息的新的表 UDF 和视图

DB2 Viper 2 还包括一个新的表 UDF SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO 和一个新的管理视图 SYSIBMADM.ADMINTABCOMPRESSINFO。

新的管理视图 SYSIBMADM.ADMINTABCOMPRESSINFO 返回关于一个数据库的所有模式中所有表的压缩信息的报告。由于它是一个视图,因此可以加入谓词,以限制输出结果,使之符合要求。

新的表 UDF SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO 有两个功能:一是报告指定表的压缩信息,二是根据当前表数据生成对新的压缩信息的估计。该 UDF 带有三个输入参数:tabschema、tabname 和 execmode。前两个参数可以使用空字符串或 NULL,以执行通配符(*)搜索。如果最后一个参数使用空字符串或 NULL,则假定为默认选项,即 REPORT。

SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO UDF 的语法为:

>>- SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO- -(--tabschema--,--tabname--,--execmode--)--<

下面是关于如何使用该 UDF 获得表 ROWCOMP.MDC 的压缩统计信息报告的例子:

select * from table(SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO('ROWCOMP','MDC','REPORT'
)) as T
TABSCHEMA
                                                 TABNAME

                   DBPARTITIONNUM DATA_PARTITION_ID COMPRESS_ATTR DICT_BUILDER
                 DICT_BUILD_TIMESTAMP       COMPRESS_DICT_SIZE   EXPAND_DICT_SIZ
E     ROWS_SAMPLED PAGES_SAVED_PERCENT BYTES_SAVED_PERCENT AVG_COMPRESS_REC_LENG
TH
--------------------------------------------------------------------------------
------------------------------------------------ -------------------------------
--------------------------------------------------------------------------------
------------------ -------------- ----------------- ------------- --------------
---------------- -------------------------- -------------------- ---------------
----- ------------ ------------------- ------------------- ---------------------
--
ROWCOMP                                                                         
                                                 MDC                            
                                                                                
                                0                 0 Y             TABLE GROWTH  
                 2007-05-25-09.15.43.000000      66432                32768      
   2041                  66                  66                     176

  1 record(s) selected.

通过查看 pages_saved_percent 和 bytes_saved_percent 可以发现,这个表压缩得很好,节省了 66% 的存储空间。

ESTIMATE 对于判断对表进行压缩时可以多大程度上节省存储很有用。注意,为了使用该功能,不需要将表属性 COMPRESS 设为 yes。利用返回的数据,可以决定是否执行离线 table reorg,以利用行压缩。如果表是一个范围集群表(不支持行压缩),可以考虑将其变换为范围分区表(支持行压缩)。ESTIMATE 的另一个优点是允许比较已有字典与用最新表内容构建的新字典的有效性。

3. 数据库角色

随着企业中雇员人数的增长,维护对数据的适当访问控制成为一项挑战。如果企业周转较快,或者人员调动频繁,那么这个问题就更为棘手。直观的想法是将特权或权限与一个组或个人相关联,需要这组特权或权限的组或个人可以从外部通过系统管理员请求成为这个组的成员。

这个想法从理论上看还可以。但是,有两个缺点:

  • 需要系统管理员(如果您没有这些角色)定义组并为必须属于该组的每个人赋予从属关系。
  • 存在一些限制,授给一个组的权限或特权不被认同。 要获得关于这些限制的更多信息,请参阅 参考资料 小节中 “Understanding DB2 9 security” 的 “Group privileges restriction” 小节。

3.1 数据库角色简介

对于数据库角色,最简单的描述是 “在数据库组中”。对角色的更正式的定义是 “可以将一个或多个特权或数据库权限组在一起,并且可以授予给用户、组、PUBLIC 或其他角色的一个数据库对象”。

数据库角色可用于填补外部组关系留下的鸿沟。数据库安全管理员对角色从属关系有严密的控制。注意,默认情况下数据库管理员或系统管理员并不拥有数据库安全管理员权限。必须由 DBA 或 SYSADM 将数据库安全管理员权限授给个人。

与组特权不同,与角色相关联的特权在特权或权限检查期间也会被考虑。但是,被授给一个组的与一个角色相关联的特权与组特权具有相同的限制。

角色从属关系由数据库安全管理员来管理。在授予角色从属关系时,数据库安全管理员可以选择将这项能力授权给其他人。例如,如果数据库安全管理员想要用户 henry(授权 ID 为 HENRY)来管理 ROLE CE_SECURITY,并使之成为那个角色的成员。下面的 SQL 语句可以同时执行这两个任务:

    GRANT ROLE CE_SECURITY TO USER HENRY WITH ADMIN OPTION

如果只授予从属关系,那么可以忽略 WITH ADMIN OPTION 子句。当从一个用户、组或角色那里收回角色从属关系时,管理 “被回收” 角色的能力也随之被撤销。

实例级权限:SYSADM、SYSMAINT、SYSCTRL 和 SYSQUIESCE 不能赋给一个角色。对于这些权限,仍然必须依赖于外部组从属关系。

在数据库连接建立期间,同时会获得角色从属关系(和组从属关系)。成功地认证之后,授给连接用户的任何角色都会自动激活。在 DB2 Viper 2 中,没有任何方法可以显式地启用或禁用任何被授予的角色。

在 DB2 Viper 2 中,有两个新的表函数可用于获得特权和权限信息。AUTH_LIST_ROLES_FOR_AUTHID 表函数返回给定授权 ID 所属角色的列表。而 AUTH_LIST_AUTHORITIES_FOR_AUTHID 表函数则返回授权 ID 直接或间接被授予的所有权限(该函数用于替代被弃用的 GET AUTHORIZATIONS 命令和 sqluadau API)。

在医院场景中,角色 INTERN 被授给角色 DOCTOR,而角色 DOCTOR 又被授给角色 SPECIALIST,然后角色 SPECIALIST 被授给用户 JUSTIN。JUSTIN 属于组 STAFF,而角色 EMPLOYEE 被授给组 STAFF。JUSTIN 还属于一个特殊的组 PUBLIC,并且角色 VISITOR 被授给 PUBLIC。检索被授给用户 Justin 的所有角色。清单 3 显示关于如何使用 AUTH_LIST_ROLES_FOR_AUTHID 表函数获得被授给某个授权 ID 的所有角色从属关系的语法。

清单 3. AUTH_LIST_ROLES_FOR_AUTHID 表函数上相同的查询和输出
SELECT substr(1, 7, GRANTOR) as GRANTOR, GRANTORTYPE, substr(1, 10, GRANTEE) as GRANTEE, 
GRANTEETYPE, substr(1, 10, ROLENAME) as ROLENAME, ADMIN FROM 
TABLE (SYSPROC.AUTH_LIST_ROLES_FOR_AUTHID ('JUSTIN', 'U') ) AS T

GRANTOR GRANTORTYPE GRANTEE    GRANTEETYPE ROLENAME   ADMIN
------- ----------- ---------- ----------- ---------- -----
SECADM1 U           DOCTOR     R           INTERN     N    
SECADM1 U           SPECIALIST R           DOCTOR     N    
SECADM1 U           JUSTIN     U           SPECIALIST N    
SECADM2 U           STAFF      G           EMPLOYEE   N    
SECADM3 U           PUBLIC     G           VISITOR    N

假设用户授权 ID ‘SEE’ 是实例所有者。清单 4 显示了关于如何使用 AUTH_LIST_AUTHORITIES_FOR_AUTHID 表函数获得给定授权 ID 的数据库和实例级权限的语法。

清单 4. AUTH_LIST_AUTHORITIES_FOR_AUTHID 表函数上相同的查询和输出
SELECT * FROM TABLE (SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ('SEE', 'U') ) AS T 
ORDER BY AUTHORITY

AUTHORITY                 D_USER D_GROUP D_PUBLIC ROLE_USER ROLE_GROUP ROLE_PUBLIC D_ROLE
------------------------- ------ ------- -------- --------- ---------- ----------- ------
BINDADD                   Y      N       Y        N         N          N           *     
CONNECT                   Y      N       Y        N         N          N           *     
CREATE_EXTERNAL_ROUTINE   Y      N       N        N         N          N           *     
CREATE_NOT_FENCED_ROUTINE Y      N       N        N         N          N           *     
CREATETAB                 Y      N       Y        N         N          N           *     
DBADM                     Y      N       N        N         N          N           *     
IMPLICIT_SCHEMA           Y      N       Y        N         N          N           *     
LOAD                      Y      N       N        N         N          N           *     
QUIESCE_CONNECT           Y      N       N        N         N          N           *     
SECADM                    N      N       N        N         N          N           *     
SYSADM                    *      Y       *        *         *          *           *     
SYSCTRL                   *      N       *        *         *          *           *     
SYSMAINT                  *      N       *        *         *          *           *     
SYSMON                    *      N       *        *         *          *           *

3.2 角色层次和组织图

只要不会导致循环,就可以将角色的从属关系授给另一个角色。可以创建一个角色层次,以便将组织图和对于一个 “任务角色” 相同的相关特权和权限映射到一个角色对象。然后,就可以将那个角色对象的从属关系授给被归为在一个特定 “任务角色” 中的任何用户。显然,通过将角色的从属关系授给 USER、GROUP 或 PUBLIC,仍然可以接收对特权或权限的附加需求。

3.3 角色和 LBAC

作为对基于标签的访问控制(LBAC)的 DB2 Viper 2 数据库角色增强的一部分,可以对一个角色或组授予或收回安全标签或豁免权。默认情况下,在创建策略时,不会考虑被授给一个角色或组的安全标签上的特权或豁免权。为了启用它们,需要使用新的 ALTER SECURITY POLICY 语句修改安全策略。

3.4 示例场景

下面来看看一个简单的场景。

图 2. 示例组织图
示例组织图

给定图 2 中所示的一个组织结构,用户可能属于以下几种类型之一:Director、System Test Manager、Functional Test Manager、Integration Test Manager 或三个测试领域中某一领域的测试者。

对于一家质量保证组织来说,一个常见的挑战是收集整个测试状况和进展。假设该组织使用一种像 IBM® Rational® Enterprise ClearQuest® test management 这样的工具,该工具执行测试并将测试结果存储到一个后端 DB2 数据库中。

显然,主管应该能够看到整个进展,而测试者只需看到自己的进展。通过构建一个映射组织图的角色层次,并授予对表中所需数据的访问权,主管(被授予角色 DIRECTOR)可自动看到数据。

为构建这个角色层次,应该执行下面的 SQL 语句:

CREATE ROLE DIRECTOR
CREATE ROLE SVT_MANAGER
CREATE ROLE FVT_MANAGER
CREATE ROLE INTEGRATION_MANAGER
CREATE ROLE SVT_TESTER
CREATE ROLE FVT_TESTER
CREATE ROLE INTEGATION_TESTER

GRANT ROLE SVT_MANAGER TO DIRECTOR
GRANT ROLE FVT_MANAGER TO DIRECTOR
GRANT ROLE INTEGRATION_MANAGER TO DIRECTOR

GRANT ROLE INTEGATION_TESTER TO INTEGRATION_MANAGER
GRANT ROLE FVT_TESTER TO FVT_MANAGER
GRANT ROLE SVT_TESTER TO SVT_MANAGER

假设有一个底层的基本表,它存储每个测试者的所有测试用例名称(NAME)、测试结果(VERDICT)、相关缺点(DEFECTS)和评论(NOTES)。造就这个链的惟一相关信息是列 VERDICT。

每个测试者将 VERDICT 列上的 SELECT 授给他们所属的角色。例如,测试者 KEVIN 输入:

GRANT SELECT ON TABLE KEVIN.MYTEST (VERDICT) TO ROLE FVT_TESTER.

然后,管理层可以访问所有测试结果,并且可以做类似下面的一些事情,以推断出总体成功率。

VALUES ((
SELECT SUM(VERDICT) FROM KEVIN.MYTEST,... all the other tester table .... 
WHERE VERDICT = 'PASS') / (
SELECT SUM(VERDICT) FROM KEVIN.MYTEST,... all the other tester table .... ))

结束语

阅读本文之后,您应该对如何利用 DB2 Viper 2 的三个新特性解决三种常见的挑战:增加数据库容量,有效地存储更多的数据,以及管理数量日益增长的用户的特权和权限,有了更深入的理解。

参考资料

学习

获得产品和技术

  • DB2 Viper 2 open beta:现在就去注册,开始了解 DB2 的未来。
  • 下载 IBM 产品评估版,获得来自 DB2、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

讨论

条评论

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=Information Management
ArticleID=269996
ArticleTitle=DB2 Viper 2 中可帮助企业成长的新特性
publish-date=11192007