在几乎所有的数据库系统中，使运行在系统上的工作负载取得良好的性能是一项十分重要的任务。依靠 IBM DB2 Spatial Extender 的帮助，你可以在数据库中将空间数据和你希望存储的其他数据无缝的集成在一起。该扩展器提供了一组数据类型来表示空间信息。但是，DB2 Universal Database™（DB2 UDB）数据库引擎还不能识别空间数据的确切属性，并且也没有提供内建的专用数据类型。所以，在为获得最佳性能而调优空间数据库时，需要比通常调优其他 DB2 UDB 数据库时考虑更多的东西。本文介绍了在使用 DB2 Spatial Extender 时应该考虑的基本优化步骤，并对此作了详细解释。 EQ@UAM}K  
b0 *9KFa  
　　简介 mT^"mT{zK  
Nng_  
　　DB2 UDB for Linux®、UNIX® 和 Windows® 从 7.1 版开始就提供了 DB2 Spatial Extender，用于支持空间数据的存储、管理和修改（请参阅 参考资料 一节，下载 DB2 Spatial Extender）。可以用专用于空间信息及其属性的结构来扩展已有的数据类型。 +^9l'X=  
yrh?9)Qt  
　　对于每个数据库系统，无论它支持的功能有多好，如果不能为构建在系统上的应用程序提供所要求的性能，就毫无价值。因此，性能调优是一项非常关键的任务。这不仅是数据库管理员的任务，也是应用程序开发人员的任务。DB2 UDB 已经提供了各种各样的工具来帮助调优和监视系统，例如“Configuration Advisor”和“Design Advisor”。它们都可以通过 Control Center 访问。 #7`"-d  
6Y,sG4,A  
　　DB2 Spatial Extender 附带了一个 Index Advisor，可以用它来优化包含空间数据的列上定义的索引。然而，索引调优只是性能调优的一部分，还可以通过调整其他一些参数来提高空间操作的性能，例如 inline length、聚集或表空间类型。在下面几节中，我们将解释其中每个参数，并展示它们相对于未经修改的系统的效果。我们在一台配有 1.2 GHz CPU 和 1 GB 物理内存的 IBM ThinkPad T30 上进行了评测。操作系统是 SUSE Linux 9.3，所有评测都基于带 FixPak 9 的 DB2 UDB Version 8.2。请注意，我们没有执行实际的基准测试，而是集中在单个更改上，这样做只是为了展示特定调优选项的效果。您不能简单地将结果中显示的数据与其他系统进行比较。 *]3<8j-BG  
1~Bn/#1  
　　基本性能调优 9DI&O`yM  
Rw+2 Zx  
　　在任何性能调优过程中，第一步是为系统取得一个良好的基线。运行 DB2 Configuration Advisor 对该任务有所帮助（请参阅 参考资料 一节，获得对 DB2 Configuration Advisor 的介绍和关于调优数据库性能的信息）。可以从 Control Center 中通过右键单击一个数据库来启动 Configuration Advisor，如图 1 所示。

图 1. 启动 Configuration Advisor R#M5.M6~<  
{b7(w
a  
　
　 <A 4p=.G&  
LX}V<x-  
　　您只需回答关于整个系统的一些简单问题，在任何情况下您应该都知道这些问题。下面是这些问题的一个简化列表，并提供了我们作出的选择，后者以 斜体 显示。从我们的选择中可以看出，我们从一开始就关注性能。您具有的场景可能要求不同的选择，例如对于锁和恢复方面的问题就是如此。 +#Xl,J  
51</Gyp(:  
　　您想将多少内存用于 DB2 实例？ 809 MB（80%）。 $`qhIrK  
h:k6LM  
　　您将执行更多的数据仓库操作，还是执行更多的事务性操作？ 都有。 SC]d(]  
}Y& *xc1  
　　您的事务是长还是短？一分钟预期有多少事务？ 较短的事务；一分钟 60 个。 b 0PH:\}  
S6
(F!= /  
　　对您来说，更快的恢复与更快的事务哪个优先？ 更快的事务。 hQrV~P9\c  
DsWQjmI  
　　数据库已经包含了数据吗？ 还没有包含数据。 |bGUm<h  
pzQW+kI/  
　　本地和远程连接的平均数量是多少？ 平均 5 个本地连接，2 个远程连接。 e#O*0H.  
H[$*2&O J  
　　您想使用哪种隔离级别？ Cursor stability （更少的锁）。 )w0_w  
Vy\$emJ#y  
　　在回答这组问题之后，Configuration Advisor 将提供对建议修改项的总结。现在您可以立即应用建议的修改，或将一个任务保存在任务中心。您应该检查每一项修改，确定它们对系统是否有意义。如果想根据自己的需要进行调整，那么可以在任务中心创建一个包含配置修改的任务，然后按照自己的需要修改任务脚本。在系统上运行 Configuration Advisor 之后可以得到如图 2 所示的结果。最值得注意的是对缺省缓冲池大小的修改。增加缓冲池大小通常是提高系统整体性能的最重要的决定，因为它指定可以将多少数据缓存在内存中，从而减少对（较慢的）磁盘 I/O 的需要。 Us=hV["1  
..s018}@  
　　图 2. Configuration Advisor 的建议 *!]vG-\  
otS[D\%J  
　　
|">4 Kn6<s  
g,*hq 6  
　　其他更改主要针对将可用内存划分出一些必要的缓存，例如包缓存和编目缓存，或者调整短事务的设置（日志记录和排序）。除了减少辅助日志文件的决定之外，所有更改都将被接受，不需任何人为干涉。我们将辅助日志文件的数量设为 10，以避免在空间导入操作期间可能发生的问题。取决于您的系统以及在那组问题中给出的答案，您得到的建议可能不同。 `17.A w^  
n
xlk  
　　性能比较 j@JP5tHW*  
D'~mOo7Lx  
　　首先在一个新安装的系统上，在应用建议的配置更改之前，我们运行一组空间操作。这些操作的执行时间通过操作系统命令 time 或 DB2 的 db2batch 工具来测量。最后，我们清除数据库，应用 DB2 Configuration Advisor 建议的配置，并重复相同的操作。为得到比较可靠的结果，我们多次执行导入操作和查询，对测量到的时间取平均值。这些空间操作如下所示：

使用 Spatial Extender 命令行工具 db2se 从 DB2 Spatial Extender 附带的第一张 Data & Maps CD 中将 shapefile 文件 europe/roads.shp 导入一个名为 ROADS 的表中。 m%/I,$9}up  
<dIP 6|+O  
　　执行一个空间操作，该操作使用一个简单的空间查询将这个表中所有的几何图形与一个固定的 linestring 进行比较。 -B8kB@VJ  
h'k< : $n1  
　　在空间列上创建一个网格索引。  rE_Q0F  
%'><@?ThX  
　　清单 1 展示了确切的步骤和它们产生的性能结果。可以在 下载 一节中找到 SQL 脚本 test_config_advisor.sql。 6)haDj~  
{0s0N<fX9  
　　清单 1. 未调优的数据库上的空间操作 wERi,P[L  
fbT## Zn|o  
$ time db2se import_shape testdb -fileName /home/stolze/europe/roads w4KuRBleEq  
　　　　-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1 I# ?m}(  
　　　　-spatialColumn shape -typeName ST_LineString -idColumn id 3wA.[y  
　　　　-commitScope 1500 -messagesFile /home/stolze/import.msg @#tdSD^`M  
GSE0000I　The operation was completed successfully. L +
mle  
real　　 ]930[Io  
　　　　　　　　　　2m19.086s UuEIi!X%  
　　　　　　　　 IJoS E0w  
user　　0m0.050s V2A/ el~  
sys　　 0m0.021s 3Y1kr#q  
$ db2batch -d testdb -f test_config_advisor.sql -i complete -s on x.O~f*j;  
--------------------------------------------- AqcNl7a  
Statement number: 1 N3D='`9  
SELECT id s" ,9(Y|I  
FROM　 roads 1LA3YXE  
WHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString( J9^)|$  
　　　　　'linestring(10 50, 20 40)', 1003)) = 1
Ln=7! 0s  
Prepare Time is:　　　　　 0.000　　　seconds ,lJhy3v)}  
Execute Time is:　　　　　 1.248　　　seconds  20%V'[\  
Fetch Time is:　　　　　　 0.000　　　seconds r~`\@lg  
　　　　　　　　　　Elapsed Time is:　　　　　 1.248　　　seconds ~dZ"Yz$n&  
　　　　　　　　 Xr#:@8Y;  
--------------------------------------------- <SJg<_Iv~  
Statement number: 2 nt_E^/  
CREATE INDEX roads_grid_index ON roads(shape) J{u/0qJ_d  
　 EXTEND USING db2gse.spatial_index(0.27, 0.54, 1.6) rA,nU5f  
　　　　　　　　　　Elapsed Time is:　　　　　 25.503　　 seconds j@2s3aX6  
　　　　　　　　 biMkE  
--------------------------------------------- V%a?,-w  
{jc

4jP1  
　　注意，测试系统使用的配置是次优的，因为导入的数据是从与数据库和数据库日志在同一个硬盘驱动器上的文件中读取的。因而，读操作与日志写和缓冲池中的数据页的写操作之间存在竞争。可能需要将各种特定于磁盘的任务分配到不同的文件系统上。当使用 DB2 Spatial Extender 导入工具导入 shapefile 文件时，建议不要尝试直接从 CD 装载数据，而是先将它复制到一个硬盘上。CD-ROM 驱动器不是很适合读 shapefile 文件的访问模式，因此整个操作的速度会急剧降慢。

在应用了 Configuration Advisor 的建议之后，重复前面列出的步骤就产生了清单 2 中的结果。可以看到，仅仅是导入操作的性能就提高了 11%，查询的速度快了 28%，甚至创建索引所花的时间也只有之前的 90%。所以不应当忽视最基本的性能调优。 !v !Pyf  
*.bi~\= i  
　　清单 2. 调优后的数据库上的空间操作 tEq`@-^f  
 86pG^wDW  
$ time db2se import_shape testdb -fileName /home/stolze/europe/roads xrL`yV5  
　　　　-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1
(g2 [m'D  
　　　　-spatialColumn shape -typeName ST_LineString -idColumn id QK1~]n  
　　　　-commitScope 1500 -messagesFile /home/stolze/import.msg $TC%lI   
GSE0000I　The operation was completed successfully. jC:`~F<hY<  
real　　 J"=@SHCT  
　　　　　　　　　　2m2.848s 9!pm99v*  
　　　　　　　　 q-K
#K';  
user　　0m0.051s 2(dZ*I_o  
sys　　 0m0.027s !I g' K  
$ db2batch -d testdb -f test_config_advisor.sql -i complete -s on :k;hQ;f?  
--------------------------------------------- 8cw9-eu  
Statement number: 1 V6e",zRDw  
SELECT id kT[zi<06
 
FROM　 roads rNj.&Z?  
WHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString( @DYZt a Z  
　　　　　'linestring(10 50, 20 40)', 1003)) = 1 3)}2p'$v}  
Prepare Time is:　　　　　 0.000　　　seconds ~QLDUq  
Execute Time is:　　　　　 0.895　　　seconds L4`@vd"T}  
Fetch Time is:　　　　　　 0.000　　　seconds N
kkks{  
　　　　　　　　　　Elapsed Time is:　　　　　 0.895　　　seconds 3w2"l&9s  
　　　　　　　　 7940U*!  
--------------------------------------------- 29i   
Statement number: 2 7(z$W}5C  
CREATE INDEX roads_grid_index ON roads(shape) X^{x ];L  
　 EXTEND USING db2gse.spatial_index(0.27, 0.54, 1.6) 1]KJ wC  
　　　　　　　　　　Elapsed Time is:　　　　　 22.980　　 seconds `_Gri&B+  
　　　　　　　　 !u>- +3<4  
--------------------------------------------- Xp;ezgfj  
},0[]khT.  
　　DB2 内部对空间数据的处理 1pyw\   
w eh'KWH  
　　空间数据可能变得非常复杂，需要很多空间来存储一个几何图形中各个点的信息。例如，表示整个美国的区域的几何图形由 60 个多边形组成，总共有 198569 个点来定义那些多边形。按照 Spatial Extender 内部格式，这个几何图形的完整定义要使用 0.9 MB 的磁盘空间（使用了压缩）。如果几何图形按照 ESRI 几何图形格式编码，那么它实际上需要 3.1 MB 的磁盘空间（请参阅 参考资料 一节，了解关于 ESRI 几何图形格式的更多信息）。所有信息封装在一个 ST_Geometry 值中，这意味着这个值在数据库中也需要大约 1 MB 的磁盘空间。另一个例子是只表示一个点的空间值。对于 X 和 Y 维，我们只有用于两个浮点值的 8 个字节。将一个点表示成 ST_Point 值会增加一些开销，但是我们谈论时仍然当作是几个字节。

DB2 表中一个行中存储的所有值的总大小不能超过表空间的页宽。一个例外是大型对象（LOB），它最大可达 2 GB。DB2 支持的最大页宽是 32K。所以存储需要 1 MB 空间的几何图形需要类似于 LOB 的存储机制。但总是为点数据使用那种机制就过分了。为了解决千差万别的需求，DB2 实现了一种用于存储空间数据（或通常的结构数据）的混合方法。如果一个空间值超过了某个大小（即所谓的 inline length），那么这个值就被存储为 BLOB。否则，这个值就存储为 VARCHAR FOR BIT DATA 值。下一节 将详细讨论如何为空间列设置 inline length，以及通过更改设置可以获得的好处。之后，我们讨论 空间数据聚集，为 编写空间 SQL 查询、调优 空间网格索引 提供指南，最后我们解释如果经常要修改数据，则建议使用哪种 表空间类型。 O9 h%loN  
!Mn[6<Y  
　　设置空间列的 inline length n: R&X
_  
yTj(C:R%  
　　在 上一节 中，我们解释了 DB2 存储需求多变的空间数据的内部机制。确定几何图形是存储为 VARCHAR FOR BIT DATA 还是 BLOB 的决定因素就是所谓的 inline length，这个参数适用于任何表中的空间列。如果空间值的内部表示需要的字节数少于 inline length 设置中指定的值，那么它将以 内联（inline） 的方式存储为 VARCHAR FOR BIT DATA。否则，这个值将被 大对象化（lobify），并在该表的 LONG 表空间中存储为 LOB。 6;8q<u+Jk  
o11W~%%  
　　应该记住，以内联方式存储数据比以大对象化方式存储数据要可取得多。原因是，内联的数据当作 VARCHAR FOR BIT DATA 对待。这个值与同一行中所有其他属性一起存储在一个数据页中。一旦数据存储在那样一个页上，那一页将通过缓冲池来访问，这样可以利用先进的缓存技术，从而尽量避免文件 I/O。而对于 LOB 则截然不同，它总是直接从磁盘读取。 D,"U8 {  
3YJUg83=  
　　所以经验法则非常简单：将 inline length 设置得尽可能高，以便让尽可能多的空间值以内联方式存储。当然，实际情况并不像看上去的那么简单。高的 inline length 值告诉 DB2 空间值实际上可以在单独一行中占用很多字节。每一行的最大大小要受到针对表定义的页宽和属性（列）的限制。例如，如果有一个页宽为 4 KB（4096）的表空间，那么一行的最大大小不能超过 4005 字节（请参阅 参考资料 一节，了解关于 SQL 限制的更多信息）。如果这个表有一个不能为空的 INTEGER 列和一个可以为空的 VARCHAR(100) 列，再加上一个空间列，那么最多可以将 inline length 设置为 4005 - 6 - 4 - (1+2+100) - 1 = 3891，其中 6 个字节用于行的前缀，4 个字节是 INTEGER 列需要的空间，(1+2+100) 个字节是为 VARCHAR(100) 预留的，最后 1 个字节用于空间列的 NULL 指示符（请参阅 参考资料 一节，找到关于数据库对象和 CREATE TABLE 语句的一本书）。可以看到，其他列的长度和 inline length 实际上是相互竞争的。为了进一步增加 inline length，可以将表放在页宽为 8K、16K 甚至 32K 的表空间上。这样，对于之前的例子，就可以分别将 inline length 设为 7987、16179 或 32563 字节。

inline length ^QtQuFBW  
n5oieR  
　　当在数据库中创建一个新的结构类型时，DB2 将根据类型定义中指定的属性计算那个数据类型的缺省 inline length。可以在系统编目视图 SYSCAT.DATATYPES 的 INLINE_LENGTH 列上找到一个结构类型的缺省 inline length。如果在 CREATE TABLE 或 ALTER TABLE ... ADD COLUMN ... 语句中定义表的列时没有显式地指定 inline length，那么将沿用缺省值。 L5dWvO)\  
\suJ7 "V  
　　可以使用 ALTER TABLE ... ALTER COLUMN ... SET INLINE LENGTH ... 语句修改（增加）已有空间列的 inline length。除非通过 REORG TABLE 语句 加 LONGLOBDATA 选项重组存储在表中的数据，否则这种修改只影响 DB2 编目和随后的数据修改。如果值的大小小于新的 inline length，那么这个重组过程将把大对象化的空间值转换成内联值。 8hn(ZQ7  
u3=-pNT  
　　选择适当的 inline length {V: QD1g:  
_w7?VmYu]  
　　在将所有空间数据存储到 32K 的表空间上并且将 inline length 设置成尽可能大的值之前，应该首先分析您的数据实际上有多大以及其他参数可能对页宽产生的影响。如果只有 ST_Point 值，那么每个点将需要最多 245 字节的物理存储，如清单 3 所示。在这种情况下，甚至 减少 inline length 更有帮助，因为可以使用更小的页宽和/或在表中使用更多的列。但是要注意，ALTER TABLE 语句只允许增加 inline length。如果想使用更小的值，那么必须在创建表的时候指定。Spatial Extender 导入过程允许显式地为空间列指定 inline length。 e+u~ER  
R=4t>.  
　　在结构类型中嵌套 LOB I
/DfnFD{  
] O_ Ux7  
　　虽然 points 属性被定义为 BLOB，但是 DB2 并不会单独地存储它。相反，整个几何图形信息（包括 BLOB 数据）都存储在一起 —— 至于存储为内联值还是大对象化值，则取决于列的 inline length。结构类型的实现使所有属性值并置到一个二进制流中，任何添加的必要的元信息和产生的二进制流在物化（也就是存储到一个表中）的时候，或者存储为内联值，或者存储为大对象化值。 (8gLn  
c6DHF)IY  
　　这种方法使任何处理 LOB 的应用程序可以以内联方式存储短的 LOB 值，并利用 DB2 的缓冲池。 B^Laig|R  
ICfPIr5q  
　　清单 3 展示了如何计算每个几何图形在以内联方式存储时需要多少磁盘空间。我们假设所有几何图形都存储在一个名为 SPATIAL_DATA 的表的 GEOMETRY 列中。第一个查询使用 LENGTH 函数。该函数显示以内联方式存储的值的宽度。如果是大对象化的值，那么它显示引用实际值的定位符的宽度。所以只有知道所有空间值都是内联值时，才可以放心地使用该函数。因此，下面的查询根据空间数据类型的属性来计算数据的宽度。关于属性的信息可以从 DB2 编目视图 SYSCAT.DATATYPES 和 SYSCAT.ATTRIBUTES 获得。如果空间数据是使用结构类型实现的，那么在 SQL Reference 中关于 CREATE TYPE 语句的解释中提到的判断结构类型值宽度的法则同样适用（请参阅 参考资料 一节，了解关于 CREATE TYPE 语句的信息）。具体地说，ST_Geometry 类型定义 16 个属性，它的子类型都没有添加自己的属性。除了三个属性外，所有属性都是所谓的 短属性。其中两个非短属性 anno_text 和 ext 没有被使用，第三个非短属性 points 包含内部编码为 BLOB 的几何图形信息。除了实际的数据外，DB2 需要维护强制的 null 指示符（1 个字节）和长度信息（4 个字节）。因此，几何图形的大小可以通过公式 “32 + 16*10 + 5 + LENGTH(points) = 197 + LENGTH(points)” 得出。

清单 3. 几何图形的空间需求 ~ATrBS[  
SaiD^u?  
-- maximum space requirement for spatial point data h}AN].  
CREATE TABLE test ( p db2gse.ST_Point INLINE LENGTH 3800 )@ PX [6W=  
INSERT INTO test VALUES ( db2gse.ST_Point( ) ,<#/  
　　　　　　　　　　　　　　 1234567890123456, 1234567890123456, 2.&Hc;7  
　　　　　　　　　　　　　　 1234567890123456, 1234567890123456, 0) )@ L=ZP_8n$  
SELECT LENGTH(p) FROM test@ %(0y880BvZ  
1 p7}oqS;k,p  
----------- $-MV& vS0  
　　　　245 e 4#
!o4  
　1 record(s) selected. ?)y 6$+  
-- determining the size of all geometries in a table -n R+Z  
SELECT 197 + LENGTH(geometry..points) cImvWq;\  
FROM　 spatial_data@ hvs!
=T  
-- calculating #geometries that would be stored inline/lobified 21^"#f0  
-- for a given inline length A47@/+Zl~  
SELECT SUM(inline) AS inline, COUNT(*) - SUM(inline) AS lobified 88{!Z9N`l  
FROM　 ( SELECT CASE U s!z  
　　　　　　　　　 WHEN 197 + LENGTH(geometry..points) <= <inline_length> ]=Qh)5[WA  
　　　　　　　　　 THEN 1 K#GCe3  
　　　　　　　　　 ELSE 0 +? kU%m  
　　　　　　　　END HmzEMeEQry  
　　　　 FROM　 spatial_data ) AS t(inline)@ n;SlG  
C\W9!rD  
　　性能比较 ] Wr7e:  
G$I 4PPrI?  
　　为了演示小的 inline length 与大的 inline length 的效果，我们首先将 shapefile 文件 europe/roads.shp 导入到一个 inline length 为 292 的表中。这是 DB2 允许的最小值。接着运行一个 SQL 脚本，该脚本确定有多少几何图形以内联方式存储，有多少几何图形必须以大对象化的方式存储。然后测量执行一个简单空间查询的时间，并显示在执行期间产生的语句快照的一个摘录，以揭示影响性能的最突出的因素。整个过程在 inline length 为 2000 的情况下再重复一遍，2000 这个值足以导致那个 shapefile 文件中的所有几何图形都以内联方式存储。下载 一节中包含了我们运行 db2batch 时使用的脚本 test_inline_length.sql。 ^V]9afF7?8  
O\m|BRdi  
　　清单 4. 不同 inline length 设置的效果 :Fl?=#/P\  
\3|JR  
$ time db2se import_shape testdb -fileName /home/stolze/europe/roads n Tl87($%  
　　　　-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1 IP-%F34Q|  
　　　　-spatialColumn shape -typeName ST_LineString -inlineLength 292 YL As/M-b  
　　　　-idColumn id -commitScope 1500 N'o6% &  
GSE0000I　The operation was completed successfully. SqDhPNV  
real　　 t*k!%m>9(  
　　　　　　　　　　3m15.604s M"gJ;{  
　　　　　　　　 "}1KOcT;,B  
user　　0m0.050s Udx>3&r  
sys　　 0m0.026s DQl$An  
$ db2batch -d testdb -f test_inline_length.sql -i complete -s on \YXHtd  
--------------------------------------------- un/^Qz  
Statement number: 1 ZJp3s&
"|  
SELECT SUM(inline) AS inline_storage, B,Fof6  
　　　 COUNT(*) - SUM(inline) AS lobified_storage :]i0o9  
FROM　 ( SELECT CASE ~nakspSaI  
　　　　　　　　　 WHEN 197 + LENGTH(shape..points) <= Gv+NdN,  
　　　　　　　　　　　　　 ( SELECT inline_length it.ERGwL  
　　　　　　　　　　　　　　 FROM　 syscat.columns K9_BQY6,  
　　　　　　　　　　　　　　 WHERE　colname = 'SHAPE' AND .4,e4u+83  
　　　　　　　　　　　　　　　　　　tabname = 'ROADS' ) 15Ig>@  
　　　　　　　　　 THEN 1 a(=ZNF  
　　　　　　　　　 ELSE 0 M*0 &\ce  
　　　　　　　　END }K<7eDph]  
　　　　 FROM　 roads ) AS t(inline) ufW@bw!  
INLINE_STORAGE LOBIFIED_STORAGE　 NAm`r>  
-------------- ---------------- Y CE8  
　　　　 89595　　　　　　21384 f<3A W]w  
--------------------------------------------- X4K).Yd`{  
Statement number: 2 $Q%QIuS[  
SELECT id I_FeqGbg  
FROM　 roads gQdCl:B?ov  
WHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString( ^l.{S%|4  
　　　　　'linestring(10 50, 20 40)', 1003)) = 1 Y`x4BT  
Prepare Time is:　　　　　 0.000　　　seconds　 T8,$PLs  
Execute Time is:　　　　　 0.854　　　seconds　 ,E[t+>5G  
Fetch Time is:　　　　　　 0.000　　　seconds　 BJr3/]r  
　　　　　　　　　　Elapsed Time is:　　　　　 0.855　　　seconds /8-u>6w  
　　　　　　　　 |j@P:Wz  
Buffer pool data logical reads　　　　　　　 = 16818 %rfZ2HD R4  
Buffer pool index logical reads　　　　　　　= 19731 Og?Z8h _c  
Direct reads　　　　　　　　　　　　　　　　 = 3088 u(3/rnn~*t  
　　　　　　　　　　Direct read requests　　　　　　　　　　　　 = 1544 t:6}u`  
　　　　　　　　 $v3J)9ac  
Direct read elapsed time (ms)　　　　　　　　= 18 W>[rM,ENv  
--------------------------------------------- w i Eavst  
$ db2 "DROP TABLE roads" ! Af5V!,F  
$ time db2se import_shape testdb -fileName /home/stolze/europe/roads <+'10Tx/[  
　　　　-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1 bS62*0%<O  
　　　　-spatialColumn shape -typeName ST_LineString -inlineLength 2000 q;Ip!+&  
　　　　-idColumn id -commitScope 1500 f(k> e16}  
GSE0000I　The operation was completed successfully. x24L"hJCK  
real　　 eQ|&7  
　　　　　　　　　　1m57.212s eN.rnK-  
　　　　　　　　 :Q=(_5~  
user　　0m0.049s W`ZniWP?  
sys　　 0m0.027s LVi]&6yzJ  
$ db2batch -d testdb -f test_inline_length.sql -i complete -s on W\N<?b|'^B  
--------------------------------------------- "s")'Bt  
Statement number: 1 (?-Z\?t},  
SELECT SUM(inline) AS inline_storage, X ]^am2t]  
　　　 COUNT(*) - SUM(inline) AS lobified_storage LOpu J  
FROM　 ( SELECT CASE x1A9tD\z  
　　　　　　　　　 WHEN 197 + LENGTH(shape..points) <= ~D]wnBwb  
　　　　　　　　　　　　　 ( SELECT inline_length ;7=`y|  
　　　　　　　　　　　　　　 FROM　 syscat.columns Q)2-.bpe  
　　　　　　　　　　　　　　 WHERE　colname = 'SHAPE' AND uK:[11Qz  
　　　　　　　　　　　　　　　　　　tabname = 'ROADS' ) +4xT.b@  
　　　　　　　　　 THEN 1 <SHR:u]ZJ  
　　　　　　　　　 ELSE 0 8K9\$n  
　　　　　　　　END +Qd{YS/i+)  
　　　　 FROM　 roads ) AS t(inline) S@D\G^p#K^  
INLINE_STORAGE LOBIFIED_STORAGE　 :$kdVU]pNX  
-------------- ---------------- '5W> G_F  
　　　　110979　　　　　　　　0　 {/;I(7F/o  
--------------------------------------------- u>^|OcW  
Statement number: 2 _# q\ ~U1  
SELECT id A L?RM)g  
FROM　 roads OPd i>|  
WHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString( hTdrncW  
　　　　　'linestring(10 50, 20 40)', 1003)) = 1 Or _LzA  
Prepare Time is:　　　　　 0.000　　　seconds @I{TmpL\=  
Execute Time is:　　　　　 0.792　　　seconds SaXpF/ yn;  
Fetch Time is:　　　　　　 0.000　　　seconds xxc|\n  
　　　　　　　　　　Elapsed Time is:　　　　　 0.792　　　seconds IpJw7&k*  
　　　　　　　　 MJn dLx  
Buffer pool data logical reads　　　　　　　 = 17337 `x[KL1hs  
Buffer pool index logical reads　　　　　　　= 19731 bQVgP"'8  
Buffer pool index physical reads　　　　　　 = 0 n|
w49  
　　　　　　　　　　Direct reads　　　　　　　　　　　　　　　　 = 2 zj`i6g  
　　　　　　　　 Gr!cwe*  
Direct read requests　　　　　　　　　　　　 = 1 `#{OcYDJA\  
Direct read elapsed time (ms)　　　　　　　　= 0 Oo[}#` W  
---------------------------------------------

从结果中可以看出，对于重要操作，较大的 inline length 可以增加 40% 的速度，对样本数据的查询也快了 7%。这两种差异的底层原因是，当使用较小的 inline length 时，有超过 20000 个几何图形（大约 20% 的数据）以大对象化的方式存储。DB2 直接从磁盘读（写） LOB 数据。而在第二种场景中，大部分的直接读是不需要的，因为可以用存储在缓冲池中的内联数据来满足查询。注意，大对象化的数据所占的 20% 的比例实际上不算很坏。如果由于稍微复杂一点儿的几何图形导致更多的数据不能以内联方式存储，那么这里演示的差异还要大大增加。 4mJ*JHWH  
)
9mxe  
　　聚集空间数据 A Mf3@8  
>k~~tdA|#k  
　　根据某个属性聚集数据是一种常见的、也是非常有用的技术，这种技术可以物理地组织一个表的数据。通过对底层的观察可以发现，具有相似值的数据常常一起被访问。所以，可以将类似的数据存储在接近的位置，使得对那些数据的访问不必分散到表空间中很多不同的页上，而是分布在临近的几个页上。根据空间数据的空间属性或几何图形间的距离聚集空间数据是很自然的。空间查询是展示局部数据访问（换句话说，现实中临近的几何图形常常被一起访问）的最好例子之一。例如，如果您看一个城市的街道地图，那么很可能对那个城市的所有街道感兴趣，而对地区另一边某个其他城市的街道不感兴趣。所以在物理上将那个城市的一些行存储在相邻的位置的确很有意义。 O_
djP%"v  
"av=i;]M  
　　在 DB2 中建立数据聚集属性的方法是根据一个索引对表进行重组。然而，如果由于空间索引的复杂性质导致 DB2 REORG TABLE 命令不理解空间索引，事情就不会那么容易了。关于这个问题有一个容易的方法，即使用一个列，这个列的值是根据涉及的图形计算的。这个列上声明的数据类型必须保证 DB2 能在这个列上创建一个本地 B- 树索引。这里使用空间填充曲线来保存空间和拓扑属性（请参阅 参考资料 一节，找到 H. Sagan 撰写的书籍）。我们在几何图形上取一个点，即形心点， 计算那个点在空间填充曲线上的值，并将结果存储在一个附加的列中。最后，在附加列上创建一个索引，并根据那个索引对表进行重组。 yhj_FrLDC  
}"y/KZ(  
　　定义聚集列 %^W.i"H0f  
bZ>6V0{=  
　　在实际扩展这个包含空间数据的表并添加聚集列之前，必须定义一个函数，这个函数计算几何图形的形心点在空间填充曲线上的值。幸运的是，DB2 Spatial Extender 已经提供了大部分的逻辑，我们只需根据自己的目的将它们组合到一起。首先，有一个为多边形定义的方法 ST_Centroid。将这个方法应用到 ST_Envelope（对于任何非空的几何图形，它总是返回一个多边形）的结果上将得到我们需要的那个点。接下来就是基于 Z 顺序的索引机制的键生成器函数，该函数是 DB2 Spatial Extender 自带的（请参阅 参考资料 一节，了解关于 Index Extensions 的信息）。Z 顺序实际上是一种空间填充曲线 —— 这与我们想象的一样。关于键生成器函数的信息可以通过 db2look 工具或直接从 DB2 编目视图获得。键生成器如清单 5 中定义的那样。

清单 5. Z 顺序索引的键生成器函数 &\Ms  
3*b"f<l3  
CREATE FUNCTION db2gse.GseZordIdxKeyGen ( srsId INTEGER, ~ysKMW  
　　　xMin DOUBLE, xMax DOUBLE, yMin DOUBLE, yMax DOUBLE, -_GMk.  
　　　xOffset DOUBLE, xScale DOUBLE, yOffset DOUBLE, yScale DOUBLE ) Z!Z1q~]/  
　 RETURNS TABLE ( coordsysId INTEGER, zValue BIGINT ) `Wk8DW  
　 SPECIFIC ST_ZixKeyGen Su$Pi  
　 EXTERNAL NAME 'db2gsefn!gseZOrderIndexKeyGenerator' YQC8OQ  
　 ...@ [ R&E0e[  
^C> ,\<  
　　现在我们可以创建一个附加的函数，该函数将组合之前提到的函数，并为任何给定的几何图形产生空间填充 Z 曲线上的标量值。最终得到的 computeZValue1 函数定义如清单 6 所示，在 下载 一节中的 zvalue_fct.sql 文件中也可以找到该函数。该函数以一个几何图形作为输入，另外还带有 4 个参数，这 4 个参数定义如何将点几何图形的 X 和 Y 维上的浮点坐标转换成用于计算 Z 值的整数值。当然，如果您不需要更多的灵活性，那么可以在函数主体中直接使用常量，而不是参数。注意，按照 DB2 Spatial Extender 范例，在乘上比例系数之前，浮点值要减去偏移量。清单 6 中的第二个函数 computeZValue 是第一个函数的变种。它使用一种不同的方法为 db2gse.GseZordIdxKeyGen 函数提供输入参数。外壳的计算和外壳形心的提取需要在 DB2 引擎与 Spatial Extender 之间进行通信。通过添加 ST_MinX、ST_MaxX、ST_MinY 和 ST_MaxY 方法，提取几何图形的最小和最大 X 和 Y 坐标，并直接计算形心，可以避免这种通信。 SiD)]0sO  
@Y[q&S  
　　清单 6. 为几何图形生成 Z 值的函数 h^^nA|zy{0  
(jt f Q  
CREATE FUNCTION computeZValue1 ( g db2gse.ST_Geometry, ({ GIx>7  
　　　xOffset DOUBLE, xScale DOUBLE, yOffset DOUBLE, yScale DOUBLE ) ^33'x1=  
　 RETURNS BIGINT Rzzb
6Os  
　 LANGUAGE SQL jn$!F@}  
　 DETERMINISTIC :ZSgud}  
　 NO EXTERNAL ACTION 2-+{5wBMT=  
　 RETURN SELECT t2.zValue 2^HWB8J  
　　　　　FROM　 TABLE ( VALUES (g..ST_Envelope()..ST_Centroid()) ) AS t1(p), /FciQ <;*  
　　　　　　　　 TABLE ( db2gse.GseZordIdxKeyGen ( p..ST_SrsId(), IEl;E(|e  
　　　　　　　　　　　　　　p..ST_X(), p..ST_X(),　p..ST_Y(), p..ST_Y(), Jxx.( *H  
　　　　　　　　　　　　　　xOffset, xScale, yOffset, yScale ) ) AS t2@ m#)w`  
CREATE FUNCTION computeZValue ( g db2gse.ST_Geometry, 8(RZ KyBz  
　　　xOffset DOUBLE, xScale DOUBLE, yOffset DOUBLE, yScale DOUBLE ) + RiPnuoD  
　 RETURNS BIGINT v@E4R?  
　 LANGUAGE SQL 79zG!!dG  
　 DETERMINISTIC b+< CIQ  
　 NO EXTERNAL ACTION z{B'Q`(,  
　 RETURN SELECT zValue !lvJw}$qC  
　　　　　FROM　 TABLE ( db2gse.GseZordIdxKeyGen ( g..ST_SrsId(), :=jN Tj@  
　　　　　　　　　　　　　　(g..ST_MinX() + g..ST_MaxX() / 2), g_I/[pQ578  
　　　　　　　　　　　　　　(g..ST_MinX() + g..ST_MaxX() / 2), Wn jA0)  
　　　　　　　　　　　　　　(g..ST_MinY() + g..ST_MaxY() / 2), "fSEz 4UA  
　　　　　　　　　　　　　　(g..ST_MinY() + g..ST_MaxY() / 2), tww(@kV{v  
　　　　　　　　　　　　　　xOffset, xScale, yOffset, yScale ) ) AS t@

以后我们将使用该函数的第二个版本，因为从清单 7 可以看出，它运行起来要快得多。db2batch 运行的总结表明，很多时间花在 db2agent 过程中，这个过程执行空间函数 ST_envelope 和 ST_Centroid。虽然看上去 ST_MinX 和相关的方法将导致前面提到的通信开销，但在这里有所不同，因为那 4 个方法只是访问几何图形的结构类型的属性，这完全是在 DB2 引擎内部处理的。 yFPT>Hc  
&kO0{/61  
　　清单 7. 比较生成 Z 值的函数 Pk# ?S,n!  
)f262F[,  
$ db2se import_shape testdb -fileName /home/stolze/europe/roads op\!(F >k  
　　　　-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1 DiW lE  
　　　　-spatialColumn shape -typeName ST_LineString -idColumn id (qiqo
  
　　　　-commitScope 1500 O4?S^v<*  
GSE0000I　The operation was completed successfully. &e~k0q{  
$ db2batch -d testdb -f test_zvalue_fct.sql -i complete -s on ~V m||TN  
--------------------------------------------- @U4gw_iK  
Statement number: 1 R 908}+[~  
SELECT computezValue1(shape, -180, 1000, -90, 1000) ~?WB*M$W  
FROM　 roads *wJ6>05RT  
Prepare Time is:　　　　　 0.000　　　seconds KUK-'  
Execute Time is:　　　　　 5.737　　　seconds 1a/-U  
Fetch Time is:　　　　　　 106.706　　seconds ,'g  
　　　　　　　　　　Elapsed Time is:　　　　　 112.443　　seconds Xu8S9T`Yz  
　　　　　　　　 h|s)l1-:  
--------------------------------------------- xq:h GkA  
Statement number: 2 ZOr2N367|  
SELECT computezValue(shape, -180, 1000, -90, 1000) P\2}5CN  
FROM　 roads C(-(#N$mw  
Prepare Time is:　　　　　 0.000　　　seconds EN^Qu=X|=X  
Execute Time is:　　　　　 0.130　　　seconds =7?sL)7  
Fetch Time is:　　　　　　 2.702　　　seconds 6TXu0Ip  
　　　　　　　　　　Elapsed Time is:　　　　　 2.832　　　seconds ?b{r/>q  
　　　　　　　　 |e*PCjT  
--------------------------------------------- 2%d/"
   
Summary of Results K1B'OQO  
================== }|zQ"ztn  
　　　　　　　　Elapsed　　　　　　 Agent CPU　　　　 Rows　　　Rows RilG'"O:  
Statement #　　 Time (s)　　　　　　Time (s)　　　　　Fetched　 Printed 7)V:y'kP  
1　　　　　　　　　 112.443　　　　　　 101.000　　 110979　　　　 0 kZ!L}} [  
2　　　　　　　　　　 2.832　　　　　　　 2.560　　 110979　　　　 0 @s[gCY\;S  
~wJ9M y~  
　　最后一步是扩展表，使表根据几何图形的拓扑信息组织数据。我们假设有一个名为 ROADS 的表，这个表是在 shapefile 文件 europe/roads.shp 的基础上创建的。第一个想法可能是添加一个新的列，并使用 GENERATED ALWAYS AS ( ... ) 语法来填充和维护它。但是，该函数的两个变种都使用子选择（第一个版本中的空间函数使用一个便笺式存储器来存放前后两个调用之间传递的信息），并违反了生成的列的某些约束。所以我们必须像清单 8 那样借助于触发器。为了确保所有已有的行都得到适当的处理，运行 UPDATE 语句。按照空间属性聚集这些行的效果取决于在查询时对一个数据子集的访问。如果使用表扫描，那么聚集就不会真正有益，因为 DB2 仍然必须读取所有的行，那么物理排序不很重要了。所以我们创建一个空间网格索引，这个索引将在查询时用到。所有步骤同样可以在附带的 zvalue_clustering_setup.sql 文件中找到。