- 论坛徽章:
- 0
|
问一个简单的问题，请各位不吝赐教
[quote]原帖由 "lusimon"]对于操作系统来说，SQL和QUERY处理的Optimizer是不同的。SQL是有SQE处理，Query是由CQE。IBM将慢慢使用SQE取代CQE，所以SQL是以后的发展方向。[/quote 发表：
你说SQE、CQE可能没几个人能看懂，既然已经提及，我就顺带详细解释一下: 
最新设计的iSeries DB2 UDB查询引擎已经今非昔比了，无论是现在的SQL查询引擎（SQE）还是传统查询引擎（CQE）都可以处理你的查询请求，但是SQL查询引擎（SQE）简化并加速了查询。处理包含传统查询引擎（CQE）的基本功能外，SQL查询引擎（SQE）还提供以下功能：
l 将查询优化器移到机器界面（MI）层以下，以加速查询的处理
l 在统计管理器的面板中将改良过的统计分开处理
l 使用了面向对象的设计来加速传递新的数据库功能
l 使用更灵活，更独立的数据访问方式来提供自主的查询循环控制
l 使用增强的算法来提供更好的响应能力和查询处理能力
l 增强了对处理需要长时间运行的复杂查询提供了的性能
l 保留对查询操作的路径，以提高其易用性
优化器移至MI层以下：
在操作系统 OS/400 V5R2上, 为了提供对元数据更快的访问速度，SQE优化器是在MI层以下创建的，这样做同时也是为了更精确地统计和更好地了解整个操作系统（包括内存，CPU，硬盘驱动器的能力等）。
大多数的CQE的处理机制是位于MI层以上的，但是处理SQE的主要机制都是位于MI层以下的，这使得SQE在处理查询的时候更加有效率。因为在CQE中处理查询的时候，在优化器和查询的执行部件之间的交互要反复穿越MI层，这样做的结果就使得接口相关的性能下降了。但对于SQE，这种行为就不存在。
只有集成在操作系统内的数据库才能够自由地获取系统极其数据的内部详细信息，使用SQE，就可以有效地获取详细系统信息。除了集成在操作系统中以外，iSeries DB2 UDB 将继续增强其在业界独特的位置。
统计管理器面板：
使用了SQE后，统计数据的收集和分析从优化器中移走了，并且现在分别由两个不同的部件：统计管理器和元数据管理器来处理。统计管理器生成并维护列的统计数据，元数据管理器回答由优化器在查询最优路径时提出的问题。这使得优化器从回答数据统计问题的处理中解放出来。
元数据管理器为优化器提供三种统计数据：记录计数，记录选择（选择的记录数）和基数性（特殊计数）。当优化器询问元数据管理器一个问题（例如：在表tableCar中有多少红色汽车）时，元数据管理器就会从表的索引或者对颜色字段的统计结果中找出答案：
SELECT *
FROM tableCar
WHERE color = 'Red'
如果元数据管理器没有从表索引或统计结果中得到答案，它会产生一个默认的回答。同时，它会从后台向统计管理器抛出这个问题，如果下次有相同的问题问出，那么会产生一个更精确的答案。这种优化器和统计管理器之间的交互提供了优化器对适当的统计的自动处理的需要。
对于每一个答案，元数据管理器同时还会返回一个信心级别，当比默认回答好的答案返回的时候，信心级别就会提高。这使元数据管理器能够致力于对统计问题找到最佳答案，而优化器致力于使用这些答案，与信心级别结合，给应用提供最佳的计划。您要想浏览表的统计结果，打开iSeries操作导航器，选择“库”，然后用鼠标右键点中要浏览的表，选择“统计数据”。
面向对象的设计：
SQE查询优化器是运用了面向对象的理念设计并实施的，它使用查询的树型结构，树型结构的每一个节点是独立的，并且可以重复使用的部件。这些节点可以以任何顺序及组合与另外的节点交互或者接口。
这种设计使得在产生新的查询方法的时候有更大的灵活性。它允许SQE独立地执行和优化这些节点，因此更加灵活有效。
图1向您展示了一个SQE中索引探测器节点的实施。NODE1代表一个典型的节点探测器访问方法， NODE1与 NODE2是相互独立的。
每一个节点都可以被独立地执行和优化。在图1的例子里，NODE2只有一个功能：将索引找出来并存在内存中。因此，这似的树型结构中的其它节点可以调用NODE2来执行应用要求的查找索引的功能。所以，SQE实现了数据库新功能和附加功能的开发简易性和可用性，并且加速其新功能的传递。
数据访问功能：
SQE比CQE提供了更多数据访问方法的功能和机会，总体来说，查询引擎需要具备两方面的素材来满足查询：包含数据的数据库对象和将提取的信息组成有用信息的指令。您可以使用两种永久的数据库对象―表（物理文件）和索引。当这些条件对于SQE和CQE都符合时，SQE有更好的技术将对于更好的使用这些对象，特别是对于索引。
当考虑使用索引时，CQE试图检查大多数，如果不是所有，将会在表上创建索引，直到CQE超时。相反的，SQE只考虑元数据管理器返回的和表的列吻合的索引。这大大减少了优化器需要考虑的索引数量，并且摒弃了由于索引在创建时的不同顺序引起的歧义。
更重要的是，优化器可以更频繁地使用索引以找出更快的数据访问路径。由于对单个节点的关注，索引可以在查询的树型结构中更灵活地被使用。下面是一个实现对一个字段不符合ORDER BY的排序：
CREATE INDEX IX1 ON T1(C1 ASC)
SELECT T1.C1
FROM T1
ORDER BY T1.C1 DESC
索引的键值是升序的，而查询要求降序，当您使用CQE的时候，这个索引是没法使用的，但是，这对于SQE却不是问题，它只需要在索引的树型结构中加入一个反向的节点就可以处理这样的排序要求了。
这种索引的一个缺点是，在索引和表中对数据的访问通常是随机的，所以会增加系统I/O和调页的频率。SQE的优化器智能地将事先装载的逻辑放置到查询的树型结构中，以减少在随机数据上的I/O等待时间，并使得其更有效地利用系统资源并更快地返回查询结果。
除了表和索引，查询引擎会希望使用临时对象来保存中间结果，临时对象对于通过改善系统I/O来提高性能并满足客户的需求（例如：ORDER BY的排序结果）。当需要时，CQE首先会使用临时结果，这或多或少能提高性能；而对于SQE，它会更积极地使用临时结果，无论是不是会提高查询性能。
哈希表就是一个临时对象的例子，当将两个表联合的时候，经常会用到，特别是索引不可用的时候。CQE在有限的情况下使用到哈希表来实现表的联合，一旦用了哈希联合，表中剩余部分的联合也必须使用哈希表。对于SQE，任何表的联合，都会用到哈希表，并将哈希表和索引及全表检索混合使用。
因为SQE优化器更倾向于使用哈希表和排序列表，实际数据的访问就稍显不同。尽管也满足了查询的定义，但是可能就不象以前操作系统版本上对实际数据的查询操作。如果你要求查询实际数据，你必须告诉查询优化器关于这一点。必须对以前版本中对实际数据错误的编码进行评估，如果是需要的，那么必须指定ALWCPYDTA *NO或者游标SENSITIVE来消除这些数据的中间拷贝。
SQE对每一个节点的优化是独立的，但是在整个查询中使用全局化的知识，所以SQE的结果在整个查询的树型结构中是通用的。
响应和处理能力：
SQE优化器用多中方式重新改写查询语句。在决定联合的顺序，分组，数据的排序，显式查询和索引查询的时候，常规的和灵活的优化策略是独立作用的。这些策略允许优化器生成更多的选择来访问数据，这也增加了对查询最佳方案的可选性。
SQE优化器首先使用各种可能的转化技术，将树型结构的查询语句翻译成相当的更易读/易优化的查询树结构。例如，一些查询的树结构暗示了没有显式表现的条件：
SELECT...
FROM T1, T2
WHERE T1.ID = T2.ID and T1.ID >; 100
这个查询中暗示了T2.ID >;100也需要满足。明确的增加显式的谓词使得优化器能够考虑到后续添加的条件，并减少需要处理的记录数量。
另一个翻译的例子发生在跟在WHERE子句后面的ORDER BY子句中：
SELECT...
FROM T1
WHERE T1.C1 = 5
ORDER BY T1.C1.
ORDER BY子句可以去掉，因为5是从字段C1中返回的唯一的值，当查询的树型结构从逻辑的翻译的结果填充，最优化的查询结构就取代了原来的结构。通过使用优化策略，优化器深入查询的树型结构并开始在多个可能的查询结构之间执行一系列的时间花费比较，找出最优化的结构。
优化策略是如何知道要考虑哪个数据访问路径？每一个策略都只有一个特定的目标，一个排序的策略是按照查询的ORDER BY子句来确定节点中数据的顺序。如果数据访问路径满足了节点中数据排序的要求，排序策略就选择它并算出实际取出数据所要花费的时间。
每一个数据访问路径都要经过选择，时间花费的计算，然后与节点中其他的数据访问路径相比较，花费最少的路径将被选中，并依附在查询树型结构的那个节点上。
为了确保精确性，单个的数据访问花费的时间时间源自于特定的iSeries机器上SQE引擎实际的数据提取时间，一旦硬件更换了，访问花费时间也将更新，这样能使得实际该机器上剩下的数据访问时间是精确的。
SQE优化器比CQE优化器对FirstIO和AllIO环境设置的响应更快，这些设置提供了优化器关于用户实际从查询中提取出多少记录，或者少数的记录（FirstIO），或者所有的记录（AllIO）。它不会指出查询到底总共有多少记录数被返回，这部分是由优化器从统计结果中获得。这些设置是非常重要的，因为它区分了查询是否需要被优化成利用FirstIO实现最快的访问路径，或者利用AllIO实现最有效的访问路径。如果这些设置与实际使用的不一样，那么性能就不是最理想的。
尽管环境的默认设置是通过每一种SQL接口提供的，这种环境设定是通过OPTIMIZE FOR N ROWS子句显式设定的。请注意，不同的SQL接口环境的默认设置都是不一样的。
ODBC和JDBC（客户端）接口默认设置成FirstIO是不支持打包的，而AllIO则支持打包。CLI，JDBC内部和静态接口的默认设置是AllIO。如果查询要选取大量的记录，而应用只希望看到少部分的记录，那么指定OPTIMIZE FOR N ROWS子句，或者指定使用FirstIO是非常重要的。
增强效率：
如果您的系统上安装了DB2对称多处理（SMP）这个软件，那么SQE就可以通过并发处理来提高查询的性能。对于整个查询树型结构或者其子树，都可以考虑使用并发处理。如果机器上存在多个处理器（CPU），那么SQE支持在查询中使用多线程处理每一个节点或者节点组。SQE使用线程（CQE使用任务）来分割工作，因此，SMP更容易遵循作业和子系统的优先级。这样，用户可能会更乐意接受SMP来实现并发处理并提高性能。
看一下下面这个联合的例子：
SELECT COUNT(*)
FROM Cust, Trans
WHERE Cust.ID = Trans.CID and Trans.DateFld >;
'06/01/03'
假定优化器决定在表Trans上创建一个哈希表，然后与表Cust联合，那么，如果安装了SMP，哈希表的创建（使用条件Trans.DateFld >; ‘06/01/03’来减小哈希表的大小）就会被分割成多个线程并发地运行。当将表Cust联合到哈希表中的时候，也会并发地运行。在CQE中已经可以实现并发创建哈希表，但是并发处理联合对于SQE也是新的功能（参见图2）。
对Cache的计划：
一个已经优化过的查询可能再次被使用，所以那个查询的访问路径将被保存在CACHE中，CACHE中还保存了查询的信息，环境信息，以及优化过的那个查询最终使用的访问路径。
在优化一个查询之前，优化器会先在CACHE里查找，如果能找到一个相当的查询，并且其环境与当前运行环境兼容，那么优化器就会使用这个已经优化好的查询路径，避免了重复的行为。
保存并重复使用访问路径的概念对于SQE来说并不是新的，CQE也具有同样的功能。但是，与CQE不同的是，SQE的CACHE是数据库范围内的，它保存从任何SQL接口―静态的，动态的，JDBC，ODBC等等过来的查询，并且从不同借口过来的查询路径都保存在相同的CACHE中。而在从前，从不同接口过来的查询路径保存在各自不同的CACHE中，因此即使是相同的查询路径也不能跨接口被重复使用。
此外，与CQE不同的是，SQE可以保存一个查询的多个不同查询路径。这对于在查询路径依赖于用户输入，可用内存等因素的环境下，是非常灵活机动的。
对于SQE来说，真正具备潜在优势的地方在于，在将来的OS/400版本中会具备体现优化器自学习，自适应的能力。这样的查询优化器可以比较在CACHE中存储的访问路径与SQL要求的实际运行时间相比较，并自动地调整访问策略以提高查询的效率。
结论：
SQE的设计理念将以下的目标融入其中：
l 提供在更复杂查询环境中增强处理能力的功能
l 持续地并可预计地增强查询处理的性能
l 技术发展水平一体化
l 无缝地替代CQE
换句话说，使用SQE继续使用更少的工作，更好的方法将您的查询处理向前推动！ |
-
图1.gif
(16.59 KB, 下载次数: 50)
图1
-
图2.gif
(18.63 KB, 下载次数: 53)
图2
|
免费注册
发表于 2005-01-07 19:27
发表于 2005-01-07 19:39
