--OLAP：DB2® Universal Database 中引入的在线分析处理（OLAP）函数，这些函数扩展了关系模型、使关系模型能够理解行集合内的排序方式（ordering）。
排列函数 第一类引入到 DB2 中的 OLAP 函数是 排列（ranking）函数，它们是在 DB2 Version 6 中引入的。这些排列函数提供了定义一个集合（使用 PARTITION 子句），然后根据某种排序方式对这个集合内的元素进行排列的能力。例如，假设我们有一个雇员表，现在要对每个部门内的雇员薪水进行排列。要实现这一点，我们需要一个函数调用，这个函数调用可以完成以下工作：
将分区（集合）定义为各个部门，将集合内的排序方式定义为按薪水排序。 按照惯例，我们一般会将薪水高的排在前面，所以我们将指定一个对薪水的降序排序方式。下面的例子展示了这个查询的查询和输出。
select empnum, dept, salary, rank() over (partition by dept order by salary desc nulls last) as rank, dense_rank() over (partition by dept order by salary desc nulls last)as denserank, row_number() over (partition by dept order by salary desc nulls last)as rownumber from emptab;

EMPNUM DEPT SALARY RANK DENSERANK ROWNUMBER
------ ---- ------ ---- --------- ---------
6 1 78000 1 1 1
2 1 75000 2 2 2
7 1 75000 2 2 3
11 1 53000 4 3 4
5 1 52000 5 4 5
1 1 50000 6 5 6
--------------------------------------------------
9 2 51000 1 1 1
4 2 - 2 2 2
注意，rank 函数本身没有参数。这是因为 rank 函数不对任何参数执行任何计算。相反，rank 函数只是着眼于行集合--以及每一行在集合中的位置--正如排序方式所定义的那样。那么，我们如何为这个函数定义集合和排序方式呢？两者都是用 OVER 子句定义的。在这个例子中，因为我们要在每个部门内进行排列，因此我们通过按部门划分分区来定义集合。这样做的效果是可以确保只有那些在 dept 列具有相等值的行才参与排列。对排列函数的而言， 分区（partition） 和 集合（set）这两个术语是等价的。在 PARTITION 子句后面，我们有一个 ORDER BY 子句，这个子句定义了分区内的排序方式。在这里，我们想将高薪排在前面，因此我们将排序方式定义为降序。除了指定降序以外，我们还指定 NULLS LAST。在 SQL 中，空值排在前面，意即空值显得要大于所有其他非空的值。这就给排列带来了问题，因为我们可能并不想将为空的薪水排在前面。因此，我们使用 NULLS LAST 子句来更改默认的排序方式，这样就可以将空值排在后面了。（注意，NULLS LAST 子句是在 DB2 V7 中引入的；不过，在 V6 中使用一个 CASE 表达式来强加排序方式也是可以的。） 现在，让我们看一下输出。前 6 行都是 Department 1 的雇员，每一行都被赋予一个按薪水降序排列所得的名次。注意，在 Department 1 中，有两个雇员的薪水都是 75000，这两行都被赋予第二的名次。这是因为 rank 函数提供了一种 “奥林匹克式”的排列方式，在这种方式中，两个相等的值得到相等的名次。因为有两行“结在一起，同获第二”，所以就没有排在第 3 的行。相反，接下来的一行排在第 4，因为根据排序方式，有 3 行严格地排在这一行之前。 对于 Department 2，注意其中有一个行具有为空的薪水。因为我们指定了 NULLS LAST，所以这一行被排在非空行的后面。如果我们没有指定 NULLS LAST 的话，Department 2 中两行的排列顺序就要倒过来了。 到现在，您可能会问自己，在上面的例子中，其他两个输出列 denserank 和 rownumber 是什么呢？DB2 实际上有三个不同的排列函数。首先是 rank 函数，它提供了奥林匹克式的排列方式，这在前面已经描述过了。其他两个函数分别是 dense_rank和 row_number。Dense_rank 很像 rank，在这个函数中，“结”中的行排名是相等的。这两个函数惟一的不同之处在于对跟在结后面的值的处理方式，在 Dense_rank函数中排名是按 1 递增的（而不是像 rank 函数那样按结中行的数量来递增）。因而，这里不会出现排名有间隔的现象（因此函数名中才用了“dense”）。虽然 Employee 11 的薪水在 rank 函数中获得的名次是第 4，但是 denserank 函数返回的值是 3。 最后一列给出 row_number 函数的输出。Row_number 也执行一次排列，但是当碰到有结的情况时，结中的行要进行任意的（也就是说，不是确定的）排序。这在对有重复值的数据进行分析时很有用。row_number 函数一个有趣的方面是它是惟一不要求提供排序方式的排列函数。如果在没有指定排序方式的情况下调用 row_number 函数，则所有的行都将被当作结中的行来对待，因而这些行是任意排序的。这对于在输出中给行排序来说很有用。
在 DB2 Version 7 中还引入了许多其他的 OLAP 函数。在引入这些函数之前，DB2 支持两类基本的函数，分别是 标量（scalar）函数和 聚集（aggregate） 函数。标量函数是那些对单个行中的值进行操作、并在每一行返回一个结果的函数。arithmetic 和 string 函数就是标量函数的例子。例如，下面的查询使用了 DIGITS 标量函数来格式化 salary 字段。

该函数对每一行执行结果计算，并且该计算只使用当前行中的 salary 值。

select empnum, salary, digits(salary) as digits from emptab where dept = 1;

EMPNUM SALARY DIGITS
----------- ----------- ----------
1 50000 0000050000
2 75000 0000075000
5 52000 0000052000
聚集函数（也叫 列 或 集合 函数）的行为有所不同。聚集函数对一组行进行操作，并在输出中将这些行聚集（或者合并）到单个的行中。聚集函数的一个例子是 sum 函数，这个函数计算一组值的和，并将这个和放入一个结果行中。例如，下面的查询计算每个部门中所有雇员薪水的总和。GROUP BY 子句用于表明要聚集的集合（或分区）是各个部门中所有行的集合。对于每个部门都返回一行，给出该部门中所有薪水的总和。
select dept, sum(salary) as sum from emptab group by dept;
DEPT SUM
----------- -----------
1 383000
2 51000
3 209000
- 84000

在 DB2 V7 中引入的 OLAP 函数引入了一类新的函数，我们称之为 标量-聚集（scalar-aggregate） 函数。这些函数像标量函数，因为它们也是在每一行返回单个的值，但是它们也像聚集函数，因为它们要对一个集合中多个行中的值执行计算，以计算出结果。下面的标量-聚集函数执行的是与 sum 聚集函数一样的计算，但是这个函数返回的是没有合并行的结果：

select dept, salary, sum(salary) over (partition by dept) as deptsum, avg(salary) over (partition by dept) as avgsal, count(*) over (partition by dept) as deptcount, max(salary) over (partition by dept) as maxsal from emptab;
DEPT SALARY DEPTSUM AVGSAL DEPTCOUNT MAXSAL
----- ------- - ------- ------- --------- --------
1 50000 383000 63833 6 78000
1 75000 383000 63833 6 78000
1 52000 383000 63833 6 78000
1 78000 383000 63833 6 78000
1 75000 383000 63833 6 78000
1 53000 383000 63833 6 78000
2 - 51000 51000 2 51000
2 51000 51000 51000 2 51000
3 79000 209000 69666 3 79000
3 55000 209000 69666 3 79000
3 75000 209000 69666 3 79000
- - 84000 84000 2 84000
- 84000 84000 84000 2 84000

注意，该查询没有包含 GROUP BY 子句。相反，该查询使用了 OVER 子句来对数据分区，以便 sum 函数对同一部门中的行执行计算，并在每一个部门内的每一行中返回该部门所有薪水的总和。按惯例，为了在每一行中包括那样的聚集结果，我们需要使用一个联合，但是现在 OLAP 函数为此提供了更简易的模式。我们推荐使用这种类型的函数作为 报告 函数，因为这种函数是对集合计算总和，并在每一行中都报告一次结果的。我曾经在前面和后面的例子中使用了 SUM， 但是大部分聚集函数（例如 AVG、MIN、MAX、STDEV，等等）都使用 OVER 子句。在 DEPTSUM 列右边的其他列显示了平均薪水、部门中雇员的人数以及部门中的最高薪水。惟一不支持作为标量-聚集函数的聚集函数是线性回归函数。

这些报告函数一个强大的用处就是计算比率和百分比。要计算某个雇员的薪水占整个部门薪水总和的百分比，只需简单地用报告的薪水总和去除该雇员的薪水。

select empnum, dept, salary, sum(salary) over (partition by dept) as deptsum, decimal(salary,10,2) / sum(salary) over(partition by dept) as percentage from emptab;
EMPNUM DEPT SALARY DEPTSUM PERCENTAGE
------ ----- -------- ----------- --------

1 1 50000 383000 0.1305
2 1 75000 383000 0.1958
5 1 52000 383000 0.1357
6 1 78000 383000 0.2036
7 1 75000 383000 0.1958
……
如果我们在要进行聚集的集合中引入一个排序方式，会出现什么情况呢？答案是，我们不处理一个 报告（ reporting ） 函数，而是处理一个 累加（ cumulative ）函数。累加函数是一种标量-聚集函数，它对当前行 以及集合中当前行之前（相对排序方式而言）的所有行进行操作。让我们为这个例子使用一个不同的表。假设我们有一个这样的表，它记有当前历年的每月销售业绩。那么，我们如何计算每个月的 年至今日（year-to-date） 销售数字呢？这里，我们要计算每月销售的累加和。我们可以这样做：

select date, sales, sum(sales) over (order by date) as cume_sum, count(*) over (order by date) as setcount from sales where year(date) = 2000;
DATE SALES CUME_SUM SETCOUNT
---------- ------------ ------------ ---------
01/01/2000 968871.12 968871.12 1
02/01/2000 80050.05 1048921.17 2
03/01/2000 757866.14 1806787.31 3
04/01/2000 58748.13 1865535.44 4
05/01/2000 40711.69 1906247.13 5
06/01/2000 241187.78 2147434.91 6
07/01/2000 954924.16 3102359.07 7
08/01/2000 502822.96 3605182.03 8
09/01/2000 97201.45 3702383.48 9
10/01/2000 853999.45 4556382.93 10
11/01/2000 358775.59 4915158.52 11
12/01/2000 437513.35 5352671.87 12

每月销售量和到当前日期的累加销售量

让我们看一下结果。对于第一行，累加和就等于这一行的销售量。对于第二行，累加和等于一月份和二月份销售量的和（968871.12 + 80050.05 = 1048921.17）。类似地，第三行的结果是一月份、二月份和三月份销售量的和。在 CUME_SUM 列右边的列执行一个累加计数，给出在集合中行的数量。例如，第一行只有一行被求和（也就是该行本身），第二行有两行被求和（该行本身以及前一行），依此类推。上面的图给出了销售数字以及在前面的查询中计算出的累加和的图形化表示。

如果我们有多年的数据，并且想计算 每一年内 到当月的累加和，那么我们也可以像下面这样使用 PARTITION BY 子句：

select date, sales, sum(sales) over (partition by year(date) order by month(date)) as cume_sum from sales where year(date) >= 2000;
DATE SALES CUME_SUM
---------- ------------ -----------
01/01/2000 968871.12 968871.12
02/01/2000 80050.05 1048921.17
03/01/2000 757866.14 1806787.31
04/01/2000 58748.13 1865535.44
05/01/2000 40711.69 1906247.13
06/01/2000 241187.78 2147434.91
07/01/2000 954924.16 3102359.07
08/01/2000 502822.96 3605182.03
09/01/2000 97201.45 3702383.48
10/01/2000 853999.45 4556382.93
11/01/2000 358775.59 4915158.52
12/01/2000 437513.35 5352671.87
01/01/2001 476851.71 476851.71
02/01/2001 593768.12 1070619.83
03/01/2001 818597.97 1889217.80
...

使用 PARTITION BY 子句计算累加和

现在，请注意 2001年1月那一行是如何重置的。这是因为日期按年划分了分区，而在 2001年内 没有在一月份之前的行，因此 cume_sum 就等于一月份的销售量。这个例子还演示了另一件有趣的事情，那就是 OVER 子句使用的参数可以是表达式，而不仅仅是列值。
在更复杂的例子中，甚至可能会将其他的聚集函数嵌入到标量-聚集函数调用中。这很有用，因为在执行分析之前先执行某种类型的聚集（例如，将销售量聚集到月的层次上）是十分常见的。这就引发了下面的问题：何时处理标量-聚集函数？答案是在处理选择清单中剩下的部分时处理这些函数。通常，一个查询的处理顺序是这样的：
From 子句
Where 子句
Group By 子句
Having 子句
选择清单
您可以看到，选择清单是在查询的所有其他部分处理完之后才被处理的。这意味着如果您有谓语（在 WHERE 或 HAVING 子句中），或者您有任何作为 GROUP BY 子句结果的聚集，那么在处理标量-聚集函数之前首先要应用这些东西。例如，让我们看下面的查询：

select year(date) as year, sum(sales) as sum, sum(sum(sales)) over (order by year(date)) as cume_sum from sales where year(date) >= 1995 group by year(date);
YEAR SUM CUME_SUM
----------- ------------- ------------
1995 7731162.39 7731162.39
1996 4127017.98 11858180.37
1997 7211584.76 19069765.13
1998 4149296.50 23219061.63
1999 6278023.54 29497085.17
2000 5352671.87 34849757.04
2001 5736777.81 40586534.85

对一个聚集的累加和

在这个例子中，我们访问表（在 FROM 子句中指定）并应用 WHERE 子句，然后应用 GROUP BY 子句并计算每年的销售总量。最后，我们处理选择清单，包括所有的标量-聚集函数。

这里还要讲一点。因为标量-聚集函数是在 WHERE 子句 之后处理的，因此在一个谓语中引用标量-聚集函数是不可能的。相反，如果您想这么做，您就必须 嵌套 标量-聚集函数调用，要么是嵌套在一个公共表表达式内，要么是嵌套在一个嵌套查询内。这在执行返回前 n 行结果的查询时变得很有用。

一个这样例子就是编写一个用于选择具有最高销售总量的3年的查询。我们可以通过对每年的销售量排列、然后选择名次为 3 或者更小的行这种方法来做这件事。

with ranked_years (year, sum, rank) as (select year(date) as year, sum(sales) as sum, rank() over (order by sum(sales) desc) as rank from sales group by year(date) ) select year, sum, rank from ranked_years where rank <= 3;
YEAR SUM RANK
----------- ------------- -------
1995 7731162.39 1
1997 7211584.76 2
1999 6278023.54 3

Top n查询的例子

在这个例子中您可以看到，我们有一个公共表表达式，它执行聚集来计算每年的销售总量，然后对销售总量进行排列。接着，外围的选择使用这个结果表并添加一个谓语，使得查询只返回那些名次 <=3（也就是销售总量排在前3名）的行。要计算中数、百分位以及其他分布统计，也可以执行类似的查询。

我希望至此我已经传达了这些新 OLAP 函数是什么以及如何使用它们的大致信息。实际上，有关这些函数的内容比我在这里描述的要多得多。因此，敬请关注另一篇更详细介绍这些函数的文章。

我想告诉你的是，DB2 已经使用这些 OLAP 函数的实现扩展了关系模型，因而现在关系模型就可以理解相对于数据集合的 排序方式。如果您曾经试过编制牵涉到排序方式的查询，您就知道这些查询可以变得多么的困难和复杂（即使是像中数这样的简单查询也是如此）。OLAP 函数为您提供了可以高效、简明地编制那样的查询的工具。随着对 DBMS 的需求的日益增长，显然必须将传统的关系模型加以扩展,以便能够处理那些越来越复杂的分析，而这些函数正是 DB2 打破局限的一个例子。

在現實的DB2應用中大家可能經常會遇到一些錯誤,錯誤的原因是對DB2的
限制不太了解而引起的,在此我簡單地總結一下,歡迎大家繼續﹐以便和大家共享﹐
共同探討﹐共同近步﹗(以下主要以DB2 7.X為例)。

1. 一個表中的列的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
2. 一行的最大長度
4KB頁大小的限制=4005
8KB頁大小的限制=8101
16KB頁大小的限制=16293
32KB頁大小的限制=32677
3. 一個表的每個分區的最大規模(千兆字節)
4KB頁大小的限制=64
8KB頁大小的限制=128
16KB頁大小的限制=256
32KB頁大小的限制=512
4. 一個索引的每個分區的最大規模(千兆字節)
4KB頁大小的限制=64
8KB頁大小的限制=128
16KB頁大小的限制=256
32KB頁大小的限制=512
5. 一個選擇列表元素的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
6. 一個GROUP BY子語句列的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
7. 一個GROUP BY子語句列的最大長度(字節數)
4KB頁大小的限制=4005
8KB頁大小的限制=8101
16KB頁大小的限制=16293
32KB頁大小的限制=32677
8. 一個ORDER BY子語句列的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
9. 一個ORDER BY子語句列的最大長度(字節數)
4KB頁大小的限制=4005
8KB頁大小的限制=8101
16KB頁大小的限制=16293
32KB頁大小的限制=32677
10. 一個INSERT語句中數值的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
11. 一個UPDATE語句中數值的最大個數
4KB頁大小的限制=500
8KB頁大小的限制=1012
16KB頁大小的限制=1012
32KB頁大小的限制=1012
12. 一個常規DMS表空間的最大規模(千兆字節數)
4KB頁大小的限制=64
8KB頁大小的限制=128
16KB頁大小的限制=256
32KB頁大小的限制=512

简介

在数据仓库中，事实表或历史表的大小是摆在设计人员和管理员面前的一个挑战。这些表通常包含数亿行数据，有时候甚至包含数千亿行数据。对于这种规模的表，主要关心以下几点：

• 查询性能
• 将大量新数据插入到这些表中
• 每月或每个季度删除大量过时的数据

随着时间的推移，DB2 继续添加和增强特性，以解决这些需求。DB2 9 for Linux, UNIX, and Windows 中一个重要的增强是表分区特性。这导致以下问题：

• 有哪些这样的特性？
• 每个特性对解决上面关心的问题有什么作用？
• 我应该使用哪些特性？
• 如何将这些特性结合起来使用以增强效果？

这些就是本文要解决的问题。阅读本文之后，读者将可以：

• 理解每个特性对于解决相关问题的独特作用。
• 明白如何有效地将这些特性结合起来使用。

有了这些背景，读者就足以进一步研究他们感兴趣的特性的细节。

特性概述

三个互补的 CREATE TABLE 选项

CREATE table 语句现在提供了三种方式来组织数据库表中的数据。

您可以任意组合使用这些子句，以达到期望的效果。表 2 总结了与这些特性相关的术语，本文中用到的其他一些特性也列在下面。

简要对比

每种特性都为分组表中的数据提供了独特的方法，并对解决与事实表或历史表相关的需求有独特的作用。

DPF 是最老的特性，通过它可以将数据库分成多个数据库分区。每个数据库分区有它自己的一组计算资源，包括 CPU 和存储。在 DPF 环境中，根据 CREATE TABLE 语句中指定的分区键，表中的每个行被分布到一个分区上。当处理一个查询时，请求也相应地被划分成多个部分，以便让各个数据库分区各自处理其负责的那些行。实际上，DPF 是一种可伸缩特性。DPF 可以通过增加数据库分区来提高处理能力，因此，随着表的增长，仍然可以保持较高的查询性能。这种能力常常被称作使用 DB2 的无共享架构提供线性的可伸缩性。

DPF 的作用不仅仅体现在表设计上。它还是调整和配置整个数据库系统的一种方法。现在已经有了关于配置那样的系统，以取得最佳性能、可靠性和增长的能力的建议实践。客户可以购买建议的硬件和软件以及配置，它们都放在一个称做 BCU (Balanced Configuration Unit) 的解决方案中。

MDC 是在 DB2 Version 8 中引入的，通过它可以在物理上将在多个维上具有类似值的行聚合在一起放在磁盘上。这种聚合能为常见分析性查询提供高效的 I/O。例如，对于 Product=car，Region=East，并且 SaleMonthYear = Jan09 的所有行，可以将它们存储在相同的存储位置，即所谓的块（block）。在 CREATE table 语句中定义维的时候，就为每种值的组合预留了存储空间。实际上，MDC 是一个能最大化查询性能的特性，对于数据仓库中常用的查询更是如此。这包括需要根据几个列中的值的组合选择行的查询。例如，DATE is between "Jan-01-2004" and "Feb-01-2005" AND Country IS NOT "United States" AND Product="Cell Phones"。

TP 是在 DB2 9 中引入的，与 MDC 类似，它也可以将具有近似值的行存储在一起。但是，TP 的以下特征是 MDC 所不具备的：

• TP 支持按照一个维将一个表分区成多个数据分区。一种常见的设计是为每个月的数据创建一个数据分区。MDC 则支持定义多个维。
• 通过 TP，用户可以手动地定义每个数据分区，包括将被包括到那个分区的值的范围。MDC 则为每种惟一的 MDC 维值组合自动定义一个单元格（并创建块来存储那个单元格的数据）。
• 每个 TP 分区是一个单独的数据库对象（不同于其他作为单个数据库对象的表）。因此，TP 支持为 TP 表附加和卸除数据分区。卸除的分区成为一个常规表。而且，必要时可以将每个数据分区放在它自己的表空间中。

实际上，TP 不同于其他特性的优势在于为表添加或删除大量数据这个方面，即转入和转出。对于熟悉使用 Union All View (UAV) 来按日期对历史表分区的读者，TP 可以作为一种功能相似但是更为高级的解决方案。

表 3 总结了这些特性之间的比较：

互补特性

本节详细阐述前面提出的观点，这 “三个朋友” 既是独立的，又是互补的。

当设计一个表时，对每个特性的使用可以认为是独立的。例如，

• 是否使用 MDC 和 TP 对于决定 DPF 的分布键没有影响。
• 一个列是否被用作 MDC 维对于是否应该将它作为表分区键没有影响，反之亦然。每个决定都可以单独做出。

每个特性的工作方式，例如索引方面，不会随着新的分区特性的引入而改变。例如，当引入 MDC 时，它的索引方面不会改变 DPF 在索引方面的工作方式。同样，当引入 TP 时，也不会改变 DPF 或 MDC 在索引方面的行为。在学习这些特性的时候，记住这一点有助于避免陷入困惑。

例如，假设您在学习 TP 的过程中碰到了 "TP has global indexes" 这个语句。那么，您应该不会推断 DPF 在处理索引方面的行为会有所变化。在这样的语句中，术语 "global" 仅仅是指索引对于多个 TP 数据分区来说是全局的。

通常来讲，一个特性不能用于解决数据库设计中与另外一个特性相关的不足或问题。值得注意的例子有：

• TP 不能解决与 DPF 相关的问题，不管这个问题是 DPF 数据倾斜还是 DPF 中的管理活动速度降慢。不管有没有同时使用 TP，DPF 之前的补救方法仍然适用。
• TP 不能用于纠正不好的 MDC 设计。

总之，如果存在与 DPF、MDC 或 TP 相关的问题，那么还是应该尝试适用于那个特性的解决方法。

表设计

数据仓库中的事实表（或历史表）非常适合使用上述每种特性，如下面的表 4 所示。

表设计的经验法则

本节让您对于设计决定的性质有一个感性的认识（也仅仅是感性的认识），并给出一些经验法则。后面列出的参考资料提供了更全面的设计指南。

对于 DPF，在选择一个分布键时，应首选那种能使数据行均匀地分布在多个数据库分区上的列。当不具备这样的条件时，就会造成数据倾斜。这意味着一个或一些数据库分区承担了更重比例的表行，从而造成了性能瓶颈。具有很多不同值的列是较好的选择。还有一种考虑是选择能最大化联结性能的列。

另一个 DPF 设计决定是数据库分区的数量。数据库分区的数量不算是表设计方面的考虑。实际上，它是整个系统设计上的考虑，需要根据整个数据库预期的原始数据大小和服务器硬件的能力来决定。很多系统需要的数据库分区不超过 20 个。但是，最大的系统可能需要更多的数据库分区。由于数据仓库有越来越大的趋势，数据库分区的数量有望增加。

对于 MDC，一个关键的决定是用哪些列作为 MDC 维。设计上的挑战是找到最佳的一组维和最佳的粒度，使得组织最大化，存储需求最小化。较好的选择是具有以下一部分或全部特征的列：

• 用于范围、等于或 IN 列表谓词
• 用于转入、转出或其他大规模的行删除
• 被 GROUP BY 或 ORDER by 子句引用
• 外键列
• 星型数据库的事实表中 join 子句中的列
• 粗粒度，也就是说不同的值很少的列

典型的设计是用一个表示日期的列作为一个 MDC 维，再加上 0 到 3 个其他列作为其他维，例如 region 和 product_type。

对于 TP，设计决定包括选择用作表分区键的列和分区的数量。通常表分区键是基于时间的列。每个分区与每次转入的数据量相符。例如，每月转出数据的表，对于每个月的数据都有一个分区。对于 TP，在设计时需要特别考虑的一点是，需要处理不在 CREATE table 语句中定义的值范围内的行。

对于需要每月根据 sale_date 转出数据的数据库，一种典型的设计是使用 sale_date 作为表分区键，并为每个月创建一个单独的分区。

通常，有一个 MDC 维是基于时间的列，这样一来，同一个列既可以用于 MDC，又可以用于 TP。MDC 的粒度可以比 TP 数据库分区更细一些。

下面的表总结了以上几点。

设计的例子

表 6 展示了一些典型的表设计的例子。Transactions 历史表代表关系数据仓库中的一个典型的表。Recent transactions 表代表运营数据存储中的一个表，这种数据存储实际上是只有最近数据的一个数据仓库。

注 1：对于 Transactions 历史表上的 MDC 维，另一种设计方案是以更细的粒度定义 Transaction 日期，例如每周或每天。更好的查询性能与增加的存储需求之间的平衡取决于数据和查询的特征。

再添上 MQT

MQT 简介

阐明了以上三个特性相互区别、相互补充的关系之后，有必要进一步扩大讨论，谈一谈 MQT（物化查询表）。MQT 和分区特性都是为在相同的情况下（即数据仓库事实表或历史表）使用而设计的。因此，为了全面考虑如何使用本文中谈到的分区特性，需要解决涉及到 MQT 的情况下的一些特殊的考虑。

MQT 是基于一个查询的结果而定义的表。从另一种角度来看，MQT 就像结果集存储在一个表中的一个视图。MQT 可以提高涉及以下方面的复杂查询的响应时间：

• 基本表中的数据上的聚类或计算
• 基本表的联结
• 一个或多个较大基本表中常被访问的一部分数据。

当基本表中的数据发生改变时，需要相应地更新 MQT。MQT 特性为适应各种运营需求而进行更新提供了多种选项。

与分区特性比较

下面的表为表 3 增加了关于 MQT 的一行。

与分区特性一起设计 MQT

与分区特性一起设计 MQT 时，在设计上的考虑可以总结为以下几点：

• 可以在使用分区特性的任意组合的表上创建 MQT。例如，可以在一个或多个使用 MDC 和 TP 的表上创建 MQT。基本表上分区特性的使用不需要考虑将来是否会在这个表上创建 MQT。然而，MQT 的设计却可能受到基本表上使用的分区特性的影响。例如，如果基本表使用了 DPF 进行分区，那么 MQT 的设计就应该考虑是否要在各个数据库分区上复制 MQT。
• MQT 也可以使用分区特性。例如，可以使用 MDC 或 TP 对 MQT 分区。

典型的设计

接下来进一步介绍前面的 Transactions 历史表的例子，下面是这些表上定义的一些 MQT：

• MQT 1 - transaction totals per day per account type
• MQT 2 - Year-to-Date totals per state

关键考虑：查询性能

对这一考虑的描述

现在我们来看看在评价和使用这些特性时关键的考虑角度：性能，尤其是通常的数据仓库业务的用户查询的性能。这些查询有以下特征：

• 从事实表中选择在几个维上符合标准的行。这意味着要将几个维表与事实表相联结。
• 使用分组或聚类函数，例如 COUNT、GROUP BY 和 ORDER BY。
• 返回包括很多行的结果集，从数千行到数百万行。
• 这些查询是由用户或他们的 BI 工具生成的。这意味着这些查询更多情况下是临时性的，事务处理系统中的性能测试和调优方法对于它们并不适合。

虽然人们倾向于想到更快的性能，但最好还是说成更好的 性能。谈到性能，就应该包括以下一些方面：

• 峰值查询执行性能
• 查询执行性能的稳定性
• 对于数据仓库中各种具有不同特征的工作负载的性能
• 设计数据库以达到性能目标是否容易
• 为达到性能目标需要付出的代价

与过去相比，现在在设计数据库以达到性能目标的过程中还需要考虑的一点是硬件的发展趋势。随着 CPU 处理能力的不断提高以及存储设备容量的不断扩大，I/O 带宽是一个潜在的性能瓶颈。在这种环境下，I/O 效率是设计时要关键考虑的一点。

本节阐释每个分区特性对查询执行性能的作用。在后面的小节中我们还会谈到转入和转出的性能。

DB2 分区特性发挥作用

使用 DPF 与不使用 DPF 相比可以提供更多的计算资源，从而对性能产生积极的影响。当 DB2 优化器为一个查询形成查询访问计划时，它将工作划分到多个数据库分区上，这些数据库分区是并行工作的。之后，再收集各个数据库分区上得到的结果，并返回给查询提交者。

MDC 对性能的贡献在于提高检索数据的效率。在多个维上具有近似值的数据存储在相同的位置，这使得 I/O 操作变得更高效，而 I/O 操作正是数据仓库中一个常见的瓶颈。而且，MDC 特性还包括块索引，在块索引中，对于每个块的数据（而不是每一行的数据）都有一个条目。这使得执行索引操作时有更高的效率。为了发挥它潜在的性能，必须为 MDC 表设计一组最佳的（或者至少是够好的）维。MDC 只对那些包括维列的查询有好处。MDC 对于查询是完全透明的。最后，MDC 在管理方面有两个值得注意的优点：

• MDC 块索引意味着需要的 RID 索引更少。管理方面的一个优点是用于索引的存储空间减少了。
• 由于新行是插在表中具有近似值的行附近的位置，因此数据仍然是聚合的，而不需要运行 REORG 实用程序。

TP 通过分区排除提高查询性能。例如，假设 Transactions 历史表有 36 个分区，每个月对应一个分区。对于一个选择过去 12 个月的数据的查询，优化器知道不必扫描这 12 个月之外的其他分区的数据。这种分区排除既适用于索引扫描，也适用于表扫描。TP 只对那些包括表分区键列的查询有利。

关键考虑：插入新数据

对这一考虑的描述

将来自运营系统的新数据插入到仓库中的事实表，这个过程称作 ETL、摄取（ingest）、填充数据仓库或者转入。下面的例子演示了可能遇到的各种情况。

例 1 - 使用 LOAD 每日摄入数据

• 在业务日结束后，运营系统中包含五十万到两亿条记录的多个平面文件如期到来。
• 一个客户脚本使用 DB2 Load 实用程序将每个文件装载到事实表中。这是在一个每夜批处理窗口中当表离线的时候完成的。
• 在下一个业务日一开始，查询这个表的用户就可以看到前一天的数据。

例 2 - 使用 insert 的准实时摄取

• 每过 30 分钟，一个包含 1 万到 10 万条记录的文件到来。
• 当该文件到来时，用户编写的一个程序将这些记录添加到一个 staging 表中，然后使用 insert 语句将这些记录添加到事实表中。

例 3 - MQT 刷新

在有 MQT 的时候，它们被看作将新数据添加到数据仓库这个过程中的一部分。比较特别的是，这种情况下可以使用 MQT 刷新策略。通常，ETL 过程是手动地指定何时更新 MQT，而不是让更新自动发生。

• 对于例 1，很可能是在每夜更新的所有任务完成之后立即更新。
• 对于例 2，MQT 通常是每天更新一次。因此，即使底层的数据是周期性地更新的，访问 MQT 的查询全天返回的都是相同的结果。

DB2 分区特性发挥作用

DB2 分区特性对于转入会有帮助，但是有时候也会带来新情况，客户在转入过程中要适当考虑这一点。

通过 DPF 可以更快速地添加数据，因为每个数据库分区可以并行工作。另一方面，DPF 又需要考虑将行发送到适当的数据分区。

与不使用 MDC 相比，使用 MDC 可以改善转入过程。其优点包括：

• 更少的物理 I/O：MDC 表的 RID 索引更少，因此在转入期间更新索引时需要的物理 I/O 更少。
• 更快的插入：MDC 表减少了页面争用和锁，因此有助于使用多个并行的流来执行插入。
• 并发的业务查询能拥有更好的性能：MDC 表减少了页面争用的锁，这一点同时也有利于并发业务查询的性能。

另一方面，如果使用 MDC，建议预先根据 MDC 维对数据进行排序。

在某些情况下，TP 有助于转入操作。TP 允许将行添加到一个分区，然后再在准备好的时候将那个分区附加到表上。然而，在这里的例子中，这个选项并不适用。还记得吗，我们的示例表（Transactions 历史表）对于每个月都有一个单独的分区，而我们是每天添加一次或多次数据。在这种情况下，在一个月开始之前，即这个月还没有开始每天添加数据之前，需要为这个表添加一个空白的分区。

最后，MQT 还增加了转入过程中要考虑的因素。特别是，需要决定何时更新 MQT。

关键考虑：删除数据

对这一考虑的描述

当数据在数据仓库中存放了一段时间后，对于业务用户来说它就不再有用了，因此需要删除它们，为新数据腾出空间。这个过程称作转出、清洗（purging）和归档。下面的例子演示了可能遇到的各种不同的情况。

通常，转出涉及到以下业务规则，并关系到如何使用 DB2 分区特性的问题：

1. 删除到了一定年龄的行：这是最简单也是最常见的业务需求。在传统的历史表中，一般的期限为 36 个月。对于最近历史表，一般期限为 60 到 180 天。
2. 根据业务规则删除到了一定年龄的行：在这种情况下，有些行虽然到了一般的退休年龄，但是仍然需要保留。例如，为了为争议或调查提供证据，可能需要保留某个历史事务。
3. 使数据仍然可以被访问，但是释放存储：这种情况有时候称作归档，而不是转出。在这种情况下，行必须对用户查询可见，但是需要将这些很少被访问的行转移到更便宜的、性能更低的存储上。这种业务需求可以通过 Tivoli Hierarchical Storage Manager (HSM) 之类的工具来解决。

通常，MQT 也需要放进来考虑。通常，MQT 也需要更新，以删除相应的总结数据。例如，如果从事实表中删除了 2003 年 3 月的数据，那么也需要删除 MQT 中关于那个月的总结数据。

DB2 分区特性发挥作用

为了支持转出，针对不同的业务需求，DB2 分区特性有一些值得注意的特性。

先说 DPF，这个特性对转出作用不大。使用 DPF 与不使用 DPF 相比，转出操作相差不大。

MDC 和 TP 都为转出操作带来好处。在任何 DB2 版本中，一个特性可能比另一个特性提供更好的转出性能，但是随着时间的推移，这两个特性应该大致相当。在比较这些特性时，更重要的是看每个特性在某些转出情况下特有的优势。

对于基本的、常见的转出情况（也就是说，只是删除到了一定年龄的行），TP 显然是首选。如果使用 TP，那么转出可以通过一个简单的 DETACH 操作来完成。而且，TP 是惟一适合以下情况的特性：

• 将转出的数据移动到另外一个位置（也就是说移动到一个表或数据库中），而不仅仅是删除它。
• 使用 Tivoli HSM 之类的工具将这些较老的、很少被访问的行转移到更便宜的存储中，但是用户查询仍然可以看到它们。

MDC 是惟一适合以下情况的特性，与基本转出相比，下面这些情况要求更高，但是不大常见：

• 客户希望在并发查询活动期间执行转出，但是他们不能接受在 DETACH 操作期间 TP 暂时需要的 zlock 的影响。
• 客户不希望修改他们的应用程序或脚本。也就是说，他们不想用 TP 的 DETACH 语句代替他们的 DELETE 语句。
• 客户想删除除时间维（表是在这一列上进行数据分区的）以外的其他维上的大量数据。
• 客户想根据业务规则删除到了一定年龄的行。在这种情况下，他们可以发出一条 SELECT 语句来识别符合条件的行，然后再 DELETE 那些行。

对于 MQT，当从 MQT 中删除相应的总结数据时，建议在 MQT 上使用表分区，并与基本表定义一样的数据分区。

删除数据的其他选项

虽然转出是删除过时数据的常见方式，但是应该注意到，客户有时候也使用其他方式来删除数据，这些方式不需要借助分区特性。这些方式有：

• 刷新表：在某些数据仓库中，整个表每年删除一次，然后装载一个替代的表，这个新表包含了除不再需要的数据以外的所有数据。
• 清洗：在某些最近历史表中，每过一些天就删除整个表，并重新创建表，数据将放在有更长历史的另一个表中。然后，重新创建的空表又可以摄取新的数据，直到清洗日的到来。

结束语

本文介绍了以下 DB2 表设计特性：表分区、MDC、DPF 和 MQT。这些特性并肩作战，一起解决客户在查询性能、插入新数据和删除老数据方面关心的问题。下面的表总结了这些 DB2 特性如何解决各种客户需求。

最近在看一些DB2的DPF方面的东西，有两个概念有一些搞不懂。
就是“分区兼容性”和“并置”两个概念。
资料是这样写的：

分区兼容性

可对分区键的对应列的基本数据类型进行比较，并可将它们声明为是分区兼容的（partition compatible）。分区兼容的数据类型具有如下属性：具有相同值但有不同类型的两个变量会按相同的分区算法映射至同一个分区号。 分区兼容性具有下列特征：

基本数据类型与另一个相同的基本数据类型兼容。
内部格式用于 DATE、TIME 和 TIMESTAMP 数据类型。它们彼此都不兼容，且都不与 CHAR 兼容。
分区兼容性不受带有 NOT NULL 或 FOR BIT DATA 定义的列的影响。
对兼容数据类型的 NULL 值的处理是完全相同的；对不兼容数据类型的 NULL 值的处理可能不相同。
用户定义的类型的基本数据类型用于分析分区兼容性。
对分区键中相同值的小数的处理是完全相同的，即使它们的标度和精度不同。
字符串中（CHAR、VARCHAR GRAPHIC 或 VARGRAPHIC）的尾部空格会被散列算法忽略。
BIGINT、SMALLINT 和 INTEGER 是兼容的数据类型。
REAL 和 FLOAT 是兼容的数据类型。
不同长度的 CHAR 和 VARCHAR 是兼容的数据类型。
GRAPHIC 和 VARGRAPHIC 是兼容的数据类型。
分区兼容性不适用于 LONG VARCHAR、LONG VARGRAPHIC、CLOB、DBCLOB 和 BLOB 数据类型，因为它们不能作为分区键。

并置
并置（collocation）是安置同一个数据库分区中包含相关数据的不同表中的行。并置的表使 DB2 可以更有效地使用连接策略。

您可能会发现，作为对特定查询的响应，两个或多个表频繁地提供数据。在此情况下，您会希望这样的表中的相关数据的位置尽可能地靠近。在数据库被物理地划分为两个或多个数据库分区的环境中，必须有一种方法可将划分的表的相关碎片尽可能地靠近。完成此过程的功能称为表并置。

当存取用于连接或子查询的多个表时，DB2(R) 通用数据库（DB2 UDB）能够识别要连接的数据是否位于相同数据库分区上。于是 DB2 就可以在存储数据的数据库分区上执行连接或子查询，而不必在数据库分区之间移动数据。这种局部地执行连接或子查询的能力具有显著的性能优点。

要发生并置，表必须：

在相同数据库分区组中，且这个数据库分区组不能处在再分配期间。（在再分配期间，数据库分区组中的表可能使用不同的分区映射 —— 它们不是并置的。）
有包含相同数量的列的分区键。
分区键的相应列是分区兼容的。
如果一个表在一个单分区数据库分区组中，且该分区组是在另一个表所在的同一个分区上定义的，那么也可以发生并置。

pub中这么回答：

比如int, char, varchar之类能够被散列的数据类型就是分区兼容性得，其他类似LOB, LF等类型不能被散列的就不是
对于并置，比如我有两个表A,B，其中A包含列c1 int, c2 char，B包含c1 varchar, c2 int
然后表A按照c1分区，表B按照c2分区，也就是说，当用户插入一行数据到表A，首先会对A.c1进行散列，然后模分区数量，把新的数据插入相应的分区，而对于表B则是对B.c2进行相同算法散列。
这样当查询select * from c1,c2 where A.c1=B.c2的时候，由于A.c1和B.c2的数据类型相同，使用相同的散列算法，如果A.c1与B.c2相等，那么他们肯定在同一分区，这样的话进行join的时候就不需要再分区间移动数据，只需要在本分区join完后向coord partition返回数据

这边转载了一个恢复drop后的表的一个操作，类似于oracle 10g中的闪回！

DB2在历史文件中保存了备份，恢复，装载数据，删除表等操作.

假设数据库名为sample, 您可以用下面的命令列出删除表的记录: db2 "list history dropped table all for sample"

下一步是从以前的备份中恢复删除表所在的表空间, 备份所在的目录是c:db2backup.
without rolling forward指明不需要前滚.
db2 "restore db sample tablespace(userspace1) from c:db2backup taken at 20041102100931 without rolling forward without prompting"

第三步是把所删除表的数据卸载到某一目录中
db2 "rollforward db sample to end of logs and complete recover dropped table 00000000000002010002000d to c:db2backup"

第四步是用历史文件中保留的该表的DDL语句重建该表

第五步是重新装载数据到该表. p(1,2)表明装载该表的第一个和第二个字段的内容. recoverme是表名

db2 "load from c:db2backupnode0000data OF DEL METHOD p(1,2) insert into recoverme"

1.查看本地实例
C:>db2ilist
DB2

---本地实例为db2
2.查看当前正在使用的实例
C:>db2 get instance

当前数据库管理器实例是：DB2

3.查看节点编目情况，得到非本地的实例
C:>db2 list node directory

节点目录

目录中的条目数 = 1

节点 1 条目：

节点名 = DB164
注释 =
目录条目类型 = LOCAL
协议 = TCPIP
主机名 = 169.254.11.164
服务名称 = 50000

C:>db2 list node directory show detail

节点目录

目录中的条目数 = 1

节点 1 条目：

节点名 = DB164
注释 =
目录条目类型 = LOCAL
协议 = TCPIP
主机名 = 169.254.11.164
服务名称 = 50000
远程实例名 = db2
系统 =
操作系统类型 = 无

可以看到本地有169.254.11.164上的DB164实例的节点编目。

4.查看所有数据库和实例的对应信息。
C:>db2 list db directory

系统数据库目录

目录中的条目数 = 3

数据库 1 条目：

数据库别名 = DW
数据库名称 = DW
节点名 = DB164
数据库发行版级别 = a.00
注释 =
目录条目类型 = 远程
认证 = SERVER
目录数据库分区号 = -1
备用服务器主机名 =
备用服务器端口号 =

数据库 2 条目：

数据库别名 = CCP_BUSI
数据库名称 = CCP_BUSI
节点名 = DB164
数据库发行版级别 = a.00
注释 =
目录条目类型 = 远程
认证 = SERVER
目录数据库分区号 = -1
备用服务器主机名 =
备用服务器端口号 =

数据库 3 条目：

数据库别名 = MYDB
数据库名称 = MYDB
数据库驱动器 = D:DB2
数据库发行版级别 = a.00
注释 =
目录条目类型 = 间接
目录数据库分区号 = 0
备用服务器主机名 =
备用服务器端口号 =

---可以看到db164上有2个数据库DW和CCP_BUSI，下一步就连结到DW上看看

5.attach到db164上
C:>db2 attach to db164 user db2admin
输入 db2admin 的当前密码：

实例连接信息

实例服务器 = DB2/NT 8.2.0
授权标识 = DB2ADMIN
本地实例别名 = DB164

6. 查看db164上的锁信息
C:>
C:>db2 get snapshot for locks on dw

数据库锁定快照

数据库名称 = DW
数据库路径 = F:DB2NODE0000SQL00001
输入数据库别名 = DW
挂起的锁定 = 0
当前已连接的应用程序 = 6
当前正等待锁定的代理进程数 = 0
快照时间戳记 = 2007-11-21 16:06:10.510838

应用程序句柄 = 395
应用程序标识 = A9FE0B84.O009.0465C1073117
序号 = 0008
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

应用程序句柄 = 336
应用程序标识 = A9FE0BA6.I708.071121064255
序号 = 0004
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

应用程序句柄 = 280
应用程序标识 = A9FE0BA6.N806.071121031820
序号 = 0011
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

应用程序句柄 = 95
应用程序标识 = A9FE0B86.NA06.015D01013815
序号 = 0042
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

应用程序句柄 = 62
应用程序标识 = A9FE0BA6.MF05.071121013410
序号 = 0005
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

应用程序句柄 = 54
应用程序标识 = A9FE0BA6.M305.071121013157
序号 = 0008
应用程序名 = QuestCentral.exe
CONNECT 授权标识 = CCP
应用程序状态 = UOW 正在等待
状态更改时间 = 未收集
应用程序代码页 = 1386
挂起的锁定 = 0
总计等待时间（毫秒） = 未收集

在数据库的开发和管理过程中，时常用到需要查询链接对应的IP地址!
一般都是用这个命令db2 list applications,但是db2的这个命令有一个不合理的地方，就是他显示IP是以16进制的形式，
所以通常需要把进程对应的“应用程序标识”的小数点前的那个字符串，转换成10进制的数来检查IP。

于是乎我写了一个小过程，可以把那个字符串直接转换成ip地址的形式，不敢独享，现公布给大家。

程序如下：

-- Start of generated script for 169.254.11.164-db2-DW (ccp)
-- Nov-15-2007 at 17:35:12
drop PROCEDURE CCP.GETIP;
SET SCHEMA CCP ;

SET CURRENT PATH = "SYSIBM","SYSFUN","SYSPROC","CCP";

CREATE PROCEDURE CCP.GETIP
(IN I_IP VARCHAR(8),
OUT O_IP VARCHAR(20)
)
LANGUAGE SQL
NOT DETERMINISTIC
CALLED ON NULL INPUT
EXTERNAL ACTION
OLD SAVEPOINT LEVEL
MODIFIES SQL DATA
INHERIT SPECIAL REGISTERS
begin
/*
--auther:Z.X.T
--DATE:2007-11-15
--描述，本过程可以把16进制的IP转换成一般的IP形式
--I_IP 输入：长度为8的16进制数，如'AABBCCDD'
--O_IP 输出：ip地址形式如：192.168.1.0
*/
declare first_IP1 varchar(3);
declare first_IP2 varchar(3);
declare first_IP3 varchar(3);
declare first_IP4 varchar(3);
declare first_IP11 INTEGER;
declare first_IP21 INTEGER;
declare first_IP31 INTEGER;
declare first_IP41 INTEGER;
if(I_IP='*N0') then
set O_IP ='本地';
return;
end if;
if(length(I_IP)!=8) then
set O_IP ='输入错误';
return;
end if;
set first_IP1=Ucase(substr(I_IP,1,2));
set first_IP2=Ucase(substr(I_IP,3,2));
set first_IP3=Ucase(substr(I_IP,5,2));
set first_IP4=Ucase(substr(I_IP,7,2));
set first_IP11=INTEGER(case substr(first_IP1,1,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP1,1,1) end)*16
+INTEGER(case substr(first_IP1,2,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP1,2,1) end);

set first_IP21=INTEGER(case substr(first_IP2,1,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP2,1,1) end
)*16
+INTEGER(case substr(first_IP2,2,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP2,2,1) end);

set first_IP31=INTEGER(case substr(first_IP3,1,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP3,1,1) end
)*16
+INTEGER(case substr(first_IP3,2,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP3,2,1) end);

set first_IP41=INTEGER(case substr(first_IP4,1,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP4,1,1) end
)*16
+INTEGER(case substr(first_IP4,2,1) when 'A' then '10' when 'B' then '11' when 'C' then '12'
when 'D' then '13' when 'E' then '14' when 'F' then '15'
when 'G' then '0' else substr(first_IP4,2,1) end);

set O_IP=rtrim(char(first_IP11))||'.'||rtrim(char(first_IP21))||'.'||rtrim(char(first_IP31))||'.'||Rtrim(char(first_IP41));
end;

#SYNC 10;
commit;

-- End of generated script for 169.254.11.164-db2-DW (ccp)

ok，存储过程完成!下来测试下看看!

C:>db2 list applications

授权标识 应用程序名 应用程序 应用程序标识 DB 代理进程
句柄 名称 序号
-------- -------------- ---------- ------------------------------ -------- -----
CCP db2bp.exe 341 A9FE0B84.G710.033705103339 DW 1
CCP QuestCentral.e 325 A9FE0B84.G510.00F5C5102039 DW 1
CCP QuestCentral.e 323 A9FE0B84.G410.00F5C5102026 DW 1
CCP QuestCentral.e 302 A9FE0B84.C10F.00F5C5100723 DW 1
CCP QuestCentral.e 262 A9FE0B84.I50F.00F5C5093513 DW 1
CCP QuestCentral.e 258 A9FE0B84.I20F.00F5C5093332 DW 1
CCP QuestCentral.e 186 A9FE0B84.LF0E.00F5C5084450 DW 1
CCP clemlocal.exe 178 A9FE0BA6.B007.071115083616 DW 7
CCP QuestCentral.e 82 A9FE0B84.AE0C.00F5C5082400 DW 3
TEST db2jccWebConta 329 A9FE0B9E.F181.071115102030 CCP_BUSI 12
TEST QuestCentral.e 320 A9FE0B88.N00C.019845101725 CCP_BUSI 2
TEST QuestCentral.e 318 A9FE0B88.MD0C.019845101711 CCP_BUSI 1
TEST db2jccWebConta 317 A9FE0B9E.F081.071115101401 CCP_BUSI 11
TEST QuestCentral.e 313 A9FE0B88.G20C.019845101424 CCP_BUSI 1
TEST QuestCentral.e 309 A9FE0B88.F10B.019845101203 CCP_BUSI 1
TEST QuestCentral.e 306 A9FE0B88.E20B.019845100938 CCP_BUSI 3
TEST QuestCentral.e 298 A9FE0B88.A90B.019845100509 CCP_BUSI 10

C:>db2 list applications

授权标识 应用程序名 应用程序 应用程序标识 DB 代理进程
句柄 名称 序号
-------- -------------- ---------- ------------------------------ -------- -----
CCP db2bp.exe 341 A9FE0B84.G710.033705103339 DW 1
CCP QuestCentral.e 325 A9FE0B84.G510.00F5C5102039 DW 1
CCP QuestCentral.e 323 A9FE0B84.G410.00F5C5102026 DW 1
CCP QuestCentral.e 302 A9FE0B84.C10F.00F5C5100723 DW 1
CCP QuestCentral.e 262 A9FE0B84.I50F.00F5C5093513 DW 1
CCP QuestCentral.e 258 A9FE0B84.I20F.00F5C5093332 DW 1
CCP QuestCentral.e 186 A9FE0B84.LF0E.00F5C5084450 DW 1
CCP clemlocal.exe 178 A9FE0BA6.B007.071115083616 DW 7
CCP QuestCentral.e 82 A9FE0B84.AE0C.00F5C5082400 DW 3
TEST db2jccWebConta 329 A9FE0B9E.F181.071115102030 CCP_BUSI 13
TEST QuestCentral.e 320 A9FE0B88.N00C.019845101725 CCP_BUSI 2
TEST QuestCentral.e 318 A9FE0B88.MD0C.019845101711 CCP_BUSI 1
TEST QuestCentral.e 313 A9FE0B88.G20C.019845101424 CCP_BUSI 1
TEST QuestCentral.e 309 A9FE0B88.F10B.019845101203 CCP_BUSI 1
TEST QuestCentral.e 306 A9FE0B88.E20B.019845100938 CCP_BUSI 3
TEST QuestCentral.e 298 A9FE0B88.A90B.019845100509 CCP_BUSI 10

C:>db2 connect to dw

数据库连接信息

数据库服务器 = DB2/NT 8.2.0
SQL 授权标识 = DB2ADMIN
本地数据库别名 = DW

C:>db2 call CCP.GETIP('A9FE0B88',?)

输出参数的值
--------------------------
参数名： O_IP
参数值： 169.254.11.136

返回状态 = 0

C:>

1.停止事例和数据库
db2stop
db2admin stop
2.改计算机名字并重启
原来为ZXT
修改为ZXTZ
重启
3.修改IBMSQLLIBDB2下的db2nodes.cfg
原来为
0 zxt ZXT 0
1 zxt ZXT 1

修改为
0 zxtz ZXT 0
1 zxtz ZXT 1
4.修改注册信息
C:>db2set db2system
ZXT
修改为

C:>db2set -g db2system=ZXTZ

5.uncatalog 本地node
C:>db2 list admin node directory show detail

节点目录

目录中的条目数 = 1

节点 1 条目：

节点名 = ZXT
注释 =
目录条目类型 = LOCAL
协议 = TCPIP
主机名 = ZXT
服务名称 = 523
远程实例名 =
系统 = ZXT
操作系统类型 = 无

C:>db2 uncatalog node zxt
DB20000I UNCATALOG NODE 命令成功完成。
DB21056W 只有在刷新目录高速缓存以后，目录更改才会生效。
6.catalog 本地node
C:>db2 catalog admin tcpip node ZXTZ remote ZXTZ system ZXTZ
DB20000I CATALOG ADMIN TCPIP NODE 命令成功完成。
DB21056W 只有在刷新目录高速缓存以后，目录更改才会生效。

C:>db2 update admin cfg using DB2SYSTEM ZXTZ
DB20000I UPDATE ADMIN CONFIGURATION 命令成功完成。

C:>db2 update admin cfg using SMTP_SERVER ZXTZ
DB20000I UPDATE ADMIN CONFIGURATION 命令成功完成。

7.启动数据库
C:>db2admin start
SQL4406W 已成功启动“DB2 管理服务器”。

C:>db2start
2007-11-14 15:42:50 1 0 SQL1063N DB2START 处理成功。
2007-11-14 15:42:51 0 0 SQL1063N DB2START 处理成功。
SQL1063N DB2START 处理成功。

C:>db2 connect to mydb

数据库连接信息

数据库服务器 = DB2/NT 8.2.0
SQL 授权标识 = ADMINIST...
本地数据库别名 = MYDB

本文介绍如何通过使用 DB2DART 工具降低 DB2 数据库管理表空间的高水位标记。

对于 DB2 数据库管理（DMS）表空间的高水位标记（HWM）是指该表空间曾经使用到的最大数据页数。如果使用：

db2 list tablespaces show detail

看到某个 DMS 表空间的已用页数低于高水位标记，则有可能通过如下方法降低高水位标记：

1、重组表空间的某个表；

2、将某个表中的数据导出，然后将它删除，重新创建该表再将数据导入。

在以上的方法中，首先要找到持有高水位标记的那个表，这可通过 DB2DART 命令（在停止实例后方可使用）加上 /DHWM 选项，提供表空间标识，然后从命令所产生的报告文件中获得。

而要了解通过对该表进行哪些操作可降低 HWM 的建议，可使用 DB2DART 加上 /LHWM 选项，从产生的报告文件中获得。使用 /LHWM 选项时，要求用户给出表空间的标识以及希望 HWM 降低到的页数（虽然不能保证 HWM 一定能降低到这一用户期望值），如果该值使用 0，则表明由 DB2 将 HWM 降低到能够达到的最低值。

另外还可利用 DB2DART 加 /RHWM 选项来移去 DMS 表空间中不再需要的空间映射数据块来降低 HWM，这些空间映射数据块在其映射的数据被删除时是不会被删除的

附：db2dart 使用方法

1.db2dart xx /db (xx为数据库名)

2.db2dart xx /DHWM /RPT c: (需要根据提示输入表空间号)

3.db2dart xx /RHWM(需要根据提示输入表空间号)

清单 9. DB2 获取配置信息的脚本（db2getconf.bat）

@echo off
::---------------------------------------------------------------------------::
:: This is a Windows Shell Script to collect DB2 system information. The
:: information collected is stored in a file name with the following format:
:: <instance>.<database>.YYYYMMDD.HHMMSS.rpt 
::---------------------------------------------------------------------------::
set script_name=%~n0
set script_log=%~n0.log
set script_ver=1.0
set DB2INSTANCE=DB2
set DB2DATABASE=SAMPLE

title %script_name% v%script_ver%
echo %script_name% v%script_ver% started on %date% at %time%

::---------------------------------------------------------------------------::
:: Set Script Date Variable
::---------------------------------------------------------------------------::
for /F "tokens=1-4 delims=/ " %%i in ('echo %date%') do (
    set script_date=%%l%%j%%k
    )

::---------------------------------------------------------------------------::
:: Set Script Time Variable
::---------------------------------------------------------------------------::
for /F "tokens=1-4 delims=:. " %%i in ('echo %time%') do (
    set script_time=%%i%%j%%k
    )

::---------------------------------------------------------------------------::
:: Set Script Report File
::---------------------------------------------------------------------------::
set script_rpt=%db2instance%.%db2database%.%script_date%.%script_time%.rpt

::---------------------------------------------------------------------------::
:: Collect DB2 Services Configuration (Requires Windows Resource Kit)
::---------------------------------------------------------------------------::
echo %script_name% v%script_ver% collecting DB2 Services configuration...
echo DB2 Services Configuration > %script_rpt%
srvinfo | find "DB2" >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect DB2 Services data, RC=%errorlevel%
   type %script_log%
   )

::---------------------------------------------------------------------------::
:: Collect DB2 Registry Configuration
::---------------------------------------------------------------------------::
echo %script_name% v%script_ver% collecting DB2 Registry configuration...
echo DB2 Registry Configuration >> %script_rpt%
db2set -all >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect DB2 Registry data, RC=%errorlevel%
   type %script_log%
   )

::---------------------------------------------------------------------------::
:: Collect DB2 Database Administration Server (DB2DAS00) Configuration
::---------------------------------------------------------------------------::
echo %script_name% v%script_ver% collecting DB2DAS00 instance configuration...
db2 get admin cfg >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect DB2DAS00 instance data, RC=%errorlevel%
   type %script_log%
   )

::---------------------------------------------------------------------------::
:: Collect DB2 Instance Configuration
::---------------------------------------------------------------------------::
echo %script_name% v%script_ver% collecting %DB2INSTANCE% instance 
configuration...
db2 get dbm cfg >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect %DB2INSTANCE% instance data, RC=%errorlevel%
   type %script_log%
   )

::---------------------------------------------------------------------------::
:: Collect DB2 Database Configuration
::---------------------------------------------------------------------------::
echo %script_name% v%script_ver% collecting %DB2DATABASE% database 
configuration...
db2 get db cfg for sample >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect %DB2DATABASE% database data, RC=%errorlevel%
   type %script_log%
   )

db2 connect to %DB2DATABASE%
if not %errorlevel% == 0 (
   echo ERROR: Unable to connect to %DB2DATABASE% database, RC=%errorlevel%
   type %script_log%
   )

db2 "select BUFFERPOOLID, BPNAME, NPAGES from SYSCAT.BUFFERPOOLS" >> 
%script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect %DB2DATABASE% database bufferpool data, 
RC=%errorlevel%
   type %script_log%
   )

db2 list tablespaces show detail >> %script_rpt% 2> %script_log%
if not %errorlevel% == 0 (
   echo ERROR: Unable to collect %DB2DATABASE% database tablespace data, 
RC=%errorlevel%
   type %script_log%
   )

db2 connect reset
if not %errorlevel% == 0 (
   echo ERROR: Unable to reset connection from %DB2DATABASE% database, 
RC=%errorlevel%
   type %script_log%
   )

echo %script_name% v%script_ver% completed on %date% at %time%

您甚至可以将这些信息存储在数据库的表中，这样这些信息就与数据库备份镜像保存在一起。定期地维护这些系统信息的历史记录可以为以后进行容量规划提供极有价值的帮助。

DB2 安全性审计

现在让我们看一个 DB2 系统命令的较好示例，该命令在用脚本语言进行自动化时非常有用。DB2 审计工具是一个实用程序，可以利用它充分地增强 DB2 实例和数据库安全性审计。它由名为 db2audit.exe 的 DB2 系统命令完全管理和控制。该命令使您能够全面地实现非常严格的 DB2 UDB 安全性审计实践。您可以配置、启动和停止安全性审计，并可以从该工具清除和抽取审计数据。这个过程是非常耗时的日常工作，但很容易用脚本语言使其自动化。例如，在您配置并启动 DB2 审计工具之后，您也许希望创建并调度一个脚本以定期地清除审计数据并将审计数据抽取到报告文件中。

清单 10. DB2 获取审计报告脚本（db2getaudit.bat）

@echo off
::---------------------------------------------------------------------------::
:: This is a Windows Shell Script to collect DB2 Audit Facility information.
:: You must first start the DB2 Audit Facility (db2audit start) and optionally
:: configure scope and status (db2audit configure scope all status both). It
:: flushes and extracts the audit data to the default DB2 Audit Facility
:: directory (sqllib<instance&g