綜述
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操作可以盡快完成時，就顯得尤為重要了。
排序性能大幅提高
ASE15避免使用工作表（worktables）來完成排序操作。這是性能上的一大提高。工作表在tempdb中生成並執行包括排序在內的許多工作。工作表 —— 從用戶表派生並倒入數據——將引發性能瓶頸。當對工作表進行讀取以獲得結果集時，將會引發其它瓶頸。總體說來，使用工作表來完成排序操作將會對性能產生影響。
但在ASE15中，采用了新的哈希技術在內存中完成排序和分組操作，從而避免了對工作表的使用。內存緩沖被用於排序操作，因此ASE的存儲過程緩沖區（procedure cache）將不再被使用。
包含ORDER BY和GROUP BY的查詢在應用中非常常見，它們經常用於生成分析報告。商業應用中經常要按某一特定順序返回信息。在ASE15中你將會看到這類復雜的查詢性能有了顯著的提高。
提高集合查詢性能
另外一種非常常見同時也非常耗時的操作是在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應用中屢見不鮮。
圖1
在ASE之前的版本中，查詢處理引擎並不針對星型關聯作特殊的查詢計劃。現在ASE 15 可以快速的識別星型關聯並采用特殊的處理過程來尋找最高效的方式執行任務。因為星型關聯在ODSS應用中廣泛存在，而ASE15可以高效地識別星型關聯並且低開銷的執行操作，因此這將大大提高其作為ODSS數據庫服務器的能力。
增強的並行查詢
你是否希望你的系統可以充分地利用設備的硬件資源？並行查詢可以幫助你充分利用硬件資源，更快地返回你希望得到的結果。在很多年前ASE就已經引入了並行機制而且效果很好；ASE15更是“青出於藍而勝於藍”！ 得益於ASE15中新的數據分區技術，並行機制可以更高效地處理海量數據集。
ASE15現在同時支持縱向和橫向並行機制。縱向並行技術可以同時利用多CPU處理查詢中的多個並行操作。橫向並行技術可以允許一個查詢的多個實例運行在位於不同分區或磁盤設備上的不同數據上。這對於需要大量數據列讀取的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，用戶僅僅通過點擊查詢計劃的操作就可以讓詳細數據展現出來。
圖2
結論
ASE 15是重大的突破。它不僅能夠讓Sybase ASE在OLTP應用中繼續提供您所希望的高性能，而且在ODSS應用環境中您也可以得到相同的性能 —— 所有這些性能將會在同一平台上實現。
ASE15的查詢處理引擎結合了最新的技術和理論，並且性能優異，而且無需很多的調優工作；還有新的分區選項；同時showplan更有了圖形界面。總而言之，ASE15不但擁有出類拔萃的高性能，還可以不斷地顯著降低系統的TCO！你還能要求什麼更多的麼？
Eric Miner是一位自由職業的技術顧問，並且對Sybase查詢處理引擎有很深的研究。他同時還是系統性能優化小組的總監 —— 世界Sybase用戶聯盟的信息管理組織。可以通過[email protected].和他聯系。
