教你们用Sybase ASE 15的查询处理引擎(QPE)为混合工作负载环境中的应用提供高性能(1)

下面小编跟你们来看看这个问题，让我们一起很愉快的学习吧。

综述
ASE已经在OLTP (on-line transaction processing，关系型数据库联机事务处理) 系统中成为高性能的领先者。但用户现在需要的不仅仅是高交易处理性能，他们还需要分析当前活动的事务数据，而且这样的分析还要在原来的平台上实时（real-time）地进行。
实际上，现在超大型数据库经常被用来作数据挖掘和分析以获取商业智能。这种分析对于公司来说是至关重要的——帮助公司辨明趋势，并且为公司的长远决策提供系统的支持。随着对数据进行分析的查询越来越复杂，数据服务器的设计已经从单纯的交易型（OLTP）服务器转而为决策支持系统(DSS) 提供平台—— 或者说是，操作性决策支持系统，即ODSS。
近年来，数据量呈爆炸性增长。生产交易系统中的数据量以每年125%的速度快速增长。众所周知，数据库中的数据量越大，对运行其上的应用性能影响也越大。当运行类似于数据挖掘和分析的查询操作时，很容易使生产交易系统的性能几乎陷于停顿。通常而言，我们可以转储历史数据到一个独立的数据仓库进行分析操作，从而减少这种对性能的影响。这将有效地减少在生产交易数据库中的数据量，缓解对数据库整体性能的压力。
现在，数据仓库系统通常运行在大量的静态数据基础之上。绝大多数数据仓库系**立于日常生产交易系统并专注于查询和分析操作。这些系统一般为DSS工作环境专门配置数据库服务器和硬件设施。其管理的历史数据通常以大批量的方式定时加载到系统中。在决策支持系统中使用的绝大多数查询都包含了复杂的聚集操作、大量的数据分类和多表关联操作。和通常在OLTP系统中运行的查询相比，复杂程度可谓天壤之别。
因此数据库服务器现在必须可以保证在混合工作负载的ODSS 环境中的高性能，OLTP操作和DSS 可以在同一平台上同时运行。用户对这种灵活性的要求是出于控制拥有总成本（TOC，total cost of ownership）的需要。

                                                                                                         
影响TCO的重要因素之一是性能调优工作——通常由数据库管理员（DBA）负责。ASE15增强的性能和稳定性意味着数据库管理员无需象以前那样经常对系统进行调整，这正是降低TCO的关键因素。而且，在使用ASE15的过程中，数据库管理员不用频繁地宕机和重启动。
Sybase ASE 15可以提供新的特性和功能来满足用户对性能和经济性的巨大需求。这篇文章将讨论ASE15如何在各种数据平台上提供优异的ODSS性能，从小数据量到海量数据存储，同时控制你的开销。
ASE 15如何实现操作型决策分析处理
在DSS分析中使用的查询语句通常比在OLTP中的查询要复杂很多倍。查询处理引擎（query processing engine ，QPE）决定了如何以最有效的方式查询所需数据。查询处理引擎的优化器将产生包含一系列指令的查询计划来确定如何运行查询。运行引擎将负责执行查询计划并返回结果集。
在ASE15中的查询处理引擎性能有了很大提高，这包含了非常高效的优化技术。ASE15内置在其查询处理引擎中的优化组件使用了非常成熟先进的技术。ASE15 比以前的版本提供了更多的选项和方式，来进行自动的分析及选择高性能的查询计划，从而高效地提高了性能。
基于目标的优化 
ASE15在执行应用中所有的查询时都表现了高性能。如果你希望ASE15在ODSS环境中有最好的运行性能，你无须提前调整查询处理引擎。当系统需要升级到ASE15时，这会帮你节省很多系统管理时间。
应用常常对查询处理引擎有不同的需求，这些需求和这些应用的功能和运行方式有关。例如对于股票交易系统，系统需要在标准的OLTP环境（交易查询为简单或中等复杂程度）中提供最佳的性能。其它，例如在线订单系统可能需要非常迅速地返回结果集的头几行数据。或者又如销售系统可能既需要在ODSS环境中对简单或中等复杂程度的交易查询可以快速做出反应，同时亦要求可以处理高复杂程度的DSS类型查询操作。
在ASE15中提供优化目标（Optimization Goals）使得查询优化工作可以完全适应应用的需求。数据库系统优化目标是一组内置的优化条件，它将全面地影响查询处理引擎中的优化器组件的运行方式。每一个目标（Goal）都被设计成为指导优化器利用各种特性和功能去寻找最优的查询计划。
这里共有三种优化目标。第一个目标被设计为允许查询处理引擎使用所有可能的技术，包括新特性和功能去寻找和实施最优的查询计划。这个目标对整个结果集进行优化并平衡OLTP和DSS类型的不同查询。这也是默认设置。
第二个优化目标将使得查询处理引擎采用针对单纯OLTP查询最适合的技术来获取最优查询计划。查询处理引擎将不仅仅使用原有的针对OLTP操作的优化技术，同时还采用了在ASE15中提供的一些新的与性能相关的特性和功能。例如，在这种方式下只使用嵌套—循环关联（nested-loop join）技术，因为这种技术对于OLTP查询最为有效。同时，也将尽量减少分类(sort)操作。当你的应用只运行交易工作而无任何ODSS操作需求时可以采用这个优化目标。这个优化目标将极大地提高ASE在OLTP环境中简单查询的性能。
第三个优化目标被设计成为可以生成尽快返回查询结果集前几行数据的查询计划。这个优化目标为基于游标或Web方式的应用提供了极高的性能。
这些优化目标可以在服务器级别设定。出于测试需要在会话或查询级别也可以设定。一旦被设定，在选定的运行环境中就不需要进一步调整优化目标的运行方式。
在查询中提高索引的利用率
ASE15可以胜任基于多索引的数据访问。数据类型和索引使用的不兼容问题将不复存在。
ASE15新的哈希(hashing)技术可以提供更多的使用索引的方式。在一个查询中可以同时利用同一张表的多个索引。这尤其对于包含OR或星型关联命令的查询更为重要。在包含OR子句的复杂关联（Join）操作中索引的利用率得到了极大地提高。
尽可能多地利用索引对于任何应用的性能提高都是很重要的。而当你要求运行在新的交易数据上的ODSS操作可以尽快完成时，就显得尤为重要了。
排序性能大幅提高
wellASE15避免使用工作表（worktables）来完成排序操作。这是性能上的一大提高。工作表在tempdb中生成并执行包括排序在内的许多工作。工作表 —— 从用户表派生并倒入数据——将引发性能瓶颈。当对工作表进行读取以获得结果集时，将会引发其它瓶颈。总体说来，使用工作表来完成排序操作将会对性能产生影响。
但在ASE15中，采用了新的哈希技术在内存中完成排序和分组操作，从而避免了对工作表的使用。内存缓冲被用于排序操作，因此ASE的存储过程缓冲区（procedure cache）将不再被使用。
包含ORDER BY和GROUP BY的查询在应用中非常常见，它们经常用于生成分析报告。商业应用中经常要按某一特定顺序返回信息。在ASE15中你将会看到这类复杂的查询性能有了显著的提高。well

提高集合查询性能
另外一种非常常见同时也非常耗时的操作是在ODSS应用中运行集合操作（aggregates），例如：counts, sums, averages 和其它数学计算功能；不幸的是，以往这些操作都需要在工作表中作大量的处理。然而现在，在ASE15中用于避免在工作表中运行排序操作的哈希技术同样也可以用于集合操作。这种性能上的提高对于经常进行依赖于集合的汇总报告操作是非常重要的。
包含大量表关联（Join）操作的查询性能有了质的提高
在数据分析中对多张表进行关联操作是非常常见的，不象在OLTP环境中大多数的关联操作只包含少量的表。在ASE15中，查询处理引擎负责测试（交互式遍历，permutes through）不同的查询计划，其功能得到了很大提高。在新的ASE15的搜索引擎中有两项重要的改进，它们可以改善对查询计划进行交互式遍历的工作。
首先，搜索引擎将很快地“去除”查询计划中高开销的部分，以便于在将来的测试中不再涉及。通过该处理可以在操作中尽早地获得低开销的查询计划，然后将其与其它查询计划进行对比，如果没有找到更低开销的查询计划，那么第一个低开销的查询计划将被确定下来。这对于包含ODSS任务的应用来说是非常重要的——在大量的报表操作中尽快地对查询进行优化。
其次，在查询处理引擎中包含一个“超时”机制。当达到超时极限点（timeout threshold）的时候，优化将会被自动停止，在该时间点之前得到的开销最低的查询计划将被确定下来并具体负责实现查询操作。超时机制可以使得查询优化的时间不至于超过查询真正运行的时间。如果需要，数据库管理人员可以方便地在ASE15中设置超时极限点。这项改进对于运行ODSS任务的应用来说是非常重要的，它可以帮助你尽快地获得高效的查询计划、尽快地运行查询操作、尽快地返回结果集、然后尽快地切换到下一个查询操作。
新的增强的Join技术
在ASE15之前的版本中，几乎所有的join操作都是嵌套循环（nested-loop）关联。这项技术对于OLTP类型的查询是如此的高效以至于在大多数早期的版本中是唯一可利用的技术。在ASE12中首次引入了分类组合关联（sort merge join）技术。

                                                   
ASE15中的分类组合关联功能得到了极大地提高。当然，在关联列是在被分类排序的情况下，例如：通过索引，分类组合关联的效率最高。 当索引被设计成为可以利用该项技术时，这些在报表操作中的查询效率将得到很大提高。需要注意的是，当分类操作仅仅在一个或两个关联列上运行的时候，分类组合关联的效率较低。
因此ASE15引入了哈希关联（hash joins）。哈希关联在运行时需要更多的资源，但在关联列没有可用的索引或需针对大量数据进行关联时是非常高效的。有的时候需要临时运行一些报表操作来产生特定的结果，在这种情况下没有时间重新设计索引，哈希关联将大显身手。哈希关联还可以大大减少对重格式化（reformatting）的需求。重格式化是一个进程，当在一个关联操作中没有有效的聚簇索引（clustered index）时，该进程将会被触发。在工作表中将生成一份关联列的拷备同时在这个工作表上建立聚簇索引。而这将导致在关联操作中使用工作表。这需要大量耗时的排序工作，最终将极大地影响性能。
借助于ASE15的查询处理引擎，所有的关联操作性能都得到了大幅提高。当一个关联操作被优化时，在内存中会根据关联的列产生柱状图（histogram，一组统计分布值）并用来估算关联操作的开销。然后统计数据将利用关联操作中实际涉及到的数据具体估算关联操作的开销。这将显著提高ODSS和OLTP 操作的性能。
星型关联（Star Join）支持
星型关联对于在大数据量环境中产生报表是尤为关键的，无论是针对当前数据还是历史数据。星型关联需要一张数据量较大的表（事实表）和一些相关的数据量较小的表（维表）。让我们做一个假设，你的事实表中存放着日常的销售记录，你的维表中存储着一些相关的细节数据如客户代码、零件代码、供应商、价格和发货类型等等。报告系统中的查询操作会高效地将这些表关联起来产生需要的结果。相比而言，将一些小表关联到一张大表上比许多大表关联在一起的性能会好一些。这种设计在数据仓库和ODSS应用中屡见不鲜。

在ASE之前的版本中，查询处理引擎并不针对星型关联作特殊的查询计划。现在ASE 15 可以快速的识别星型关联并采用特殊的处理过程来寻找最高效的方式执行任务。因为星型关联在ODSS应用中广泛存在，而ASE15可以高效地识别星型关联并且低开销的执行操作，因此这将大大提高其作为ODSS数据库服务器的能力。
增强的并行查询
你是否希望你的系统可以充分地利用设备的硬件资源？并行查询可以帮助你充分利用硬件资源，更快地返回你希望得到的结果。在很多年前ASE就已经引入了并行机制而且效果很好；ASE15更是“青出于蓝而胜于蓝”！ 得益于ASE15中新的数据分区技术，并行机制可以更高效地处理海量数据集。
ASE15现在同时支持纵向和横向并行机制。纵向并行技术可以同时利用多CPU处理查询中的多个并行操作。 Oracle数据库技术横向并行技术可以允许一个查询的多个实例运行在位于不同分区或磁盘设备上的不同数据上。这对于需要大量数据列读取的ODSS应用来说是特别有效的。ASE15 同样可以支持“管道（Pipelined）”并行机制。这是一种纵向并行机制， 中间结果集可以传送到查询计划的其它操作中，这样使得多个操作可以并行地在同一数据集上运行，进一步提高了效率。

“Partition Aware”查询处理引擎
ASE15引入了新的数据分区技术。这样数据库管理员可以将大块数据分割成易于管理的小数据块，并且任意地将这些小数据块存储在独立的设备上。
这里有四种方式进行数据分区。该功能对于超大型数据库尤为有用。如果你是用了“范围（range）” 分区方式，数据将根据不同范围存储在指定的分区上。当你的数据是关于时间/日期纪录，那么一个分区可以被用来管理最近的交易记录，而其它分区可以管理历史数据；因此如果你仅仅需要一份昨天交易的报表，那么其它分区的数据将根本不会被读取。
ASE15的查询处理引擎全面支持分区对象（partitioned objects），如表和索引。于是数据何时被分区、数据分布在哪些分区上等信息就一目了然了。当分区中没有包含有用的数据时，查询处理引擎将使用“分区排除技术（partition elimination）”来避免读取不需要的分区。这意味着仅仅读取包含所需数据的分区。
在ASE15运行过程中，一些维护任务可以有选择的在特定分区执行，这样可以进一步降低你的TCO。例如：当数据库管理员需要运行维护任务——如更新查询处理引擎所用到的统计数据——可以仅仅在需要的分区上执行，这样将大大节省时间和精力。
借助ASE15新的“partition aware”功能，系统的性能得到了大幅度的提高。这对于在海量数据集上高效运行ODSS查询来说无疑具有重大意义。新的数据分区技术可以和查询处理引擎携手从功能上提高并行查询的性能。
进一步降低ASE15已经很低的TCO
长久以来，如何进行有效的性能调优对于数据库管理员来说变得有点可望而不可及，这是因为需要特殊的技术、经验和合适的工具才可以有效地完成工作。 这种技能不仅需要数据库管理员们长时间的经验积累和沉淀， 而且在隔离和调整低效率的查询时难免顾此失彼，从而影响其它正在运行的应用的性能。尤其在对数据库服务器进行升级时尤为如此。
但在ASE15中，这个烦恼已经一去不复返了！我们以前讨论过的许多涉及到提高系统效率降低TCO的特性和功能已经可以自动进行调优而无需特殊操作。因此用了ASE15，数据库管理员就不需要象过去那样必须要进行调优了。当然，如果有必要，有些默认的功能和改进选项同样可以被调整，通过优化目标或单独使用SET命令的新的扩展选项即可打开或关闭参数。这为系统测试提供了更灵活的控制。
增强的查询处理引擎监测工具
当数据库管理员需要定位和调整偶尔出现的低效率查询时，好工具可以快速地确定和解决问题。
在ASE以前的版本中**的用于监控查询优化和运行的诊断工具功能尚可，但有时比较抽象和难以使用，而且仅对系统管理员开放权限。ASE15提供了一系列新的诊断工具，非常易用并且不需要特定的权限。这些工具可以向数据库管理员提供信息，帮助他们了解诸如ASE如何运行、需要做哪些调整来提高性能。
自从ASE提供了showplan诊断工具，它就被系统管理员广为使用。Showplan通过一系列“简明语言（plain language）”按实际运行的顺序再现了查询操作。在ASE15中，showplan的易用性和可读性得到了很大提高。
在早期版本中用于得到诊断信息的DBCC跟踪功能可以满足需求，但有一点晦涩难懂，并且也需要特殊的授权许可。新设计的SET命令的扩展选项将可以被用来提供更为详尽的信息并且不需要特殊的授权。
查询处理矩阵
如果你的业务关键应用突然停止运行，当务之急是快速地使其恢复运行。然而你仍然需要知道是什么操作导致了这一事故的发生？是不是由于正在运行的报表操作？还是由于当前正在处理的日常交易？作为系统管理员，你如何定位问题并且修复它们？
随着定制应用的不断普及，系统管理员很难深入SQL语句挖掘低效率查询的成因。由于几乎不可能得到有问题的操作语句，问题的瓶颈有时候很难被定位。有时候系统管理员要用远多于解决问题的时间来隔离问题，所以降低判断问题范围的时间对于性能调优至关重要。

                                                                                         
ASE的查询处理矩阵，或者叫QP矩阵，可以让系统管理员捕捉正在运行的操作的性能数据，甚至包括每一查询的SQL语句。QP 矩阵提供的信息包括：
◆查询语句
◆该查询的查询计划
◆CPU运行时间
◆运行总时间（运行查询需要的总时间）
◆逻辑I/O  – 在内存中命中页面的次数
◆物理I/O  –从硬盘中读取页面的次数
◆查询运行的次数
系统管理员可以利用批量查询运行时收集的数据来确定哪个查询运行效率最低，从而需要进一步的调优。QP 矩阵是一个强大的工具，不仅可以使性能调优工作变得简单，而且加快了实施的进度。
图形化Showplan输出
正像前面提到过的，Showplan是那些系统管理员过去熟知的性能诊断工具。现在Showplan可以以图形化的方式展现出来。利用图形化的Showplan，用户仅仅通过点击查询计划的操作就可以让详细数据展现出来。

ASE 15是重大的突破。它不仅能够让Sybase ASE在OLTP应用中继续提供您所希望的高性能，而且在ODSS应用环境中您也可以得到相同的性能 —— 所有这些性能将会在同一平台上实现。
ASE15的查询处理引擎结合了最新的技术和理论，并且性能优异，而且无需很多的调优工作；还有新的分区选项；同时showplan更有了图形界面。总而言之，ASE15不但拥有出类拔萃的高性能，还可以不断地显著降低系统的TCO！你还能要求什么更多的么？
Eric Miner是一位自由职业的技术顾问，并且对Sybase查询处理引擎有很深的研究。他同时还是系统性能优化小组的总监 —— 世界Sybase用户联盟的信息管理组织。可以通过eminer1254@yahoo.com.和他联系。
不知道小伙伴们对于这个问题有没有看懂，就让我们在课课家的网站里尽情的练习吧。