開發人員升級至ASE 15.0的10大理由（五）

以下的簡略模式是一種可行的實現。

圖2 針對不同病人的對象類規范化的物理模式例子

應用程序開發人員的問題是病人信息很可能使用不同的應用程序輸入，或同一應用程序中不同的屏幕因為需要不同的工作流程來完全錄入必要的病人信息。作為對象模型，開發人員更容易從“patient”父類中抽取出住院或門診病人，等到將數據保存至數據庫時，住院或門診病人對象在中間層被集成至一個單獨的實體中。對象—關系映射需要在某點發生，通常是在中間層。但是在一些情況下，開發人員會使用像Hibernate這樣的數據庫抽取層，它在介于中間層邏輯和數據庫本身的數據庫接口層進行對象—關系映射。該層中的對象—關系映射操作常常很麻煩而且效率不高。上例中偽操作可能是：

（1）Get new patient id.

（2）Insert patient information.

（3）If outpatient, insert outpatient information.

（4）If inpatient, insert inpatient information.

這可能會導致抽取層的多次網絡交互。有許多抽取層（包括Hibernate）高度依賴于替代觸發器來實現最終的數據語義模式分解。該邏輯(從抽取層的角度)被簡化為對視圖的一個單獨插入，如下：

（1）Insert all patient information into patient view.

（2）Instead of trigger fires with following logic.

a.Get new patient id.

b.Insert patient data into patient table.

c.If outpatient, insert outpatient information.

d.If inpatient, insert inpatient information.

這不僅能加快開發速度，還能在應用程序和數據庫模式之間提供一個常常需要的抽取層。通過該方法，對任一方的小改動都有可能無需更改對方。

5.2.2 手工數據分區

替代觸發器的另一用途就是提供了普通的統一接口來進行手工表分區，以便對應用程序或最終用戶隱藏分區。考慮一個至少要將數據在線保留7年的財務應用軟件。如果都存在一張表中，則表的大小會以極大的比例增長。常見的技術（尤其在DSS應用程序中）是用單獨的物理表來實現每月或每年的數據，如tran_hist_2005、tran_hist_2006、tran_hist_2007、tran_hist_2008……創建一個統一的“transaction_history”視圖用來連接單獨的表，例如：

create view transaction_history as

select * from tran _hist _2009 union all

select * from tran _hist _2008 union all

select * from tran _hist _2007 union all

select * from tran _hist _2006 union all

select * from tran _hist _2005

…

“分區”隨著時間的改變可有不同的權限。例如，去年，一個用戶插入(或更新)tran_hist_2008表中的數據。今年，可廢除大部分用戶的插入、更新和刪除權限，防止意外數據修改。ASE中的語義分區不支持不同分區、不同權限。

“分區”可擁有不同的索引。例如，由于更有可能是OLTP或混合負載處理，最近的交易記錄與常見的查詢有不同的查詢參數。較早的“分區”可能需要不同的索引來支持更復雜的DSS類型查詢。ASE的語義分區不支持不同分區、不同索引。

“分區”可與單獨的命名緩存綁定。例如，較早的數據和索引可能會沖刷緩存中較多當前的數據。通過使用單獨的物理表，較早的數據能與較小的命名緩存綁定，在緩存中最大程度保留當前的數據操作。

每個“分區”本身還可以是語義分區表。例如，如果表是按年進行物理分區的，單獨的表可根據月份來進行語義分區，進一步改善維護時間。或者語義分區可在不同的鍵上完成， 例如客戶/交易類型，或者甚至用另一種分區類型（哈希而非范圍）。ASE中的語義分區不支持多層級分區。

這些是額外的表分區優勢，諸如隔離維護每個分區的行動。但是，它存在一個大問題每當一個時間段趨近結束時，不僅需要創建一個新的分區，而且涵蓋了分區的視圖必須更改，加入新表并移除舊表。雖然修改視圖定義并不需要花一秒鐘時間，但必須在無人使用該視圖時完成，所以必須在行動時強制暫停。另外，真正完整的改變需要以下內容：

（1）創建新的“當前”分區表、索引和用戶權限。

（2）更新視圖定義，刪除并重建的同時修改替代觸發器和用戶權限。

（3）去除最近的“當前”分區的權限。

（4）從最近的“當前”分區中支持OLTP的索引。

（5）在最近的“當前”分區中增加支持DSS查詢的索引。

為了改變視圖定義而造成的維護和縮短服務時間要求是本方法的劣勢之一，還可能由于改變了對象ID而對預編譯對象（例如存儲過程）造成不確定的影響。另一個明確的考慮就是因為優化器并不知道每個分區與什么查詢語義相關，結果就可能常常出現對所有數據的訪問，頻繁創建包含任意謂詞結果的工作表，并將工作表用于查詢處理中。若是語義分區，則優化器了解分區鍵，能避免中間的工作表并能執行分區消除。雖然表的分區是像上述那樣離散的集合，而同樣的鍵將觸發優化器去了解沒有可用的結果，并且可縮短union all查詢的周期。

6 可配置的DSS查詢優化

關于ASE 15，經常被問到的問題之一是對開發人員都有哪些特性？贊成開源系統的人們傾向那些產品所吹捧的“開發人員”特性，并抱怨主流的RDBMS系統長時間關注DBA，已經忽略了開發人員。那些產品中的一個嚴峻缺陷就是查詢優化，查詢優化器100%的是完全關注開發人員的特性。畢竟，日常運營的DBA通常不會關心查詢優化器運行得如何，只要系統性能在可接受的資源消耗范圍內。正是開發人員才去考慮該產品是否支持星型連接等。

如果考慮它，企業級DBMS產品的大部分精髓都被賦予了查詢優化，一定程度地重寫查詢優化器將會耗費博士研發團隊多年的辛勤工作。毫無疑問，在ASE 15.0中最大的改變正是它—完全重寫的查詢優化器。

重寫優化器需要滿足不斷增長的混合負載、OLAP和甚至是DSS應用程序的需求，由于要滿足實時報表或普通應用程序擴展以利用數據保持力的改變來滿足業務需求，諸如市場、趨勢分析或其他源于歷史數據的信息，如客戶波動。考慮以下OLTP與DSS應用程序的趨勢變遷描繪圖：

圖3 OLTP 和 DSS 應用程序趨勢

注意OLTP與DSS系統的變遷，為了填補它們之間的空缺而產生了兩類新的需求—實時報表和實時分析。為了支持實時報表復雜查詢處理的變化，ASE完全重寫了查詢優化器，增加了新的典型DSS/報表優化特性，例如：DSS連接技術，諸如合并連接（merge join）、哈希連接（hash join）、N陣嵌套循環連接（n-ary nested loop join）和對星型模型的支持；支持聚合、聯合和去重的更快算法；改進了對并行查詢的支持，包括導向/矢量連接以減少資源使用。

非常有用的也是比較復雜的特性之一是優化目標和標準。對優化器工程師來說，關鍵需要考慮開發出的優化器能在最快的時間內能找到優化的執行計劃，因為優化時間很容易超過執行時間。例如，一個12向的連接涉及12張相對大的表（每個表在10萬至1 000萬行），需要10 min優化但僅需30 s去執行。因此，如果優化器了解應用程序的本質，它就能避免在優化階段的前期找到一個查詢計劃后，又竭盡全力去尋找可能不會比該計劃更快的查詢計劃。ASE 15.0實施了3個特性以達此目的—優化目標、超時和標準，見表10。

表10 不同優化目標和一些關鍵查詢技術之間的高層級關系

雖然allrows_dss能運行所有內容看起來很誘人，但是請記住前面關于優化時間超出執行時間的討論。一個關鍵的原因是合并與哈希連接被認為是DSS類型的操作，因為它們假定連接不會被索引完全覆蓋，通常可能并不是即席報表查詢的情況。因此，這樣的連接條件通常會因數據排序而受益，要么是物理地要么是內存哈希表，與連接排序的連接列。較嚴厲的OLTP系統應用索引來強制主外鍵。

雖然“容量規劃”常常被包含在開發周期中，而“負載管理”卻常被忽略。不幸的是，業務用戶通常讓硬件/軟件來自動執行負載均衡，還需要考慮業務優先權，簡直就是不可能的任務。事實是不同的應用程序常常會有不同的優化需求，使用錯誤的技術同時支持所有的需求將造成失敗。請認真考慮，如何去滿足沖突的需求：高速插入/最小化優化；復雜查詢與更長時間的優化需求。在不斷改變的現實中，日趨快速的 CPU，大量廉價的內存。現在更傾向于用更多的CPU和內存來執行密集算法么？四核=低價的大型SMP。它不僅帶來了第2階段的應用程序整合，它增加了復雜度，還在更低的價格點上提供了并行策略的CPU資源。在從未如此擴展的領域中，更大的數據量和更大的使用人群。

好的方法是通過會話級別和查詢相關的優化控制，讓開發人員來控制優化。因此，ASE 15不僅增加了DSS優化技術，它還令其可配置并通過優化目標提供了3個初始的優化情形。開發人員必須考慮應用程序組件的本質并與DBA一道工作，為不同的應用程序實施“優化情形”，然后這些可以根據應用程序名稱或其它特質來通過登錄觸發器實現。通過這些特性，OLTP應用程序能避免不適合OLTP的長時間優化或復雜優化算法，而報表應用程序則可利用諸如索引聯合、濃密連接等的新功能。使用支持表來存儲優化情形的登錄觸發器例子如下：

-- created in master to allow prevent login failures in case the server needs to

-- be booted with traceflag to recover master database only

use master

go

create table optimization_profile (

appnamevarchar(30) not null,

opt_goalvarchar(20) not null,

parallel _deg tinyintnot null,

use_stmtcache bit not null,

use _mergejoin bit not null,

use _hashjoin bit not null,

use _idxunion bit not null,

delayed _commitbit not null,

primary key (appname)

)

go

exec sp_logintrigger 'drop' go

if exists (select 1 from sysobjects

where name= ' sp_optimization_profile' and type='P' and uid=user_id()) drop procedure sp_optimization_profile

go

print "...creating procedure: 'sp_optimization_profile'" go

create procedure sp_optimization_profile as begin

declare @appnamevarchar(30),

@opt _goal varchar(20),

@use_stmtcachebit,

@use_mergejoinbit,

@use_hashjoinbit,

@use_idxunionbit,

@delayed_commitbit

if suser_name()='sa' return 0

if has _role('sa _role',0)=1 return 0 select @appname= (case

when clientapplname is not null then clientapplname else program_name

end)

from master.. sysprocesses

where spid=@@spid

set export on

if exists (select appname

from master. . optimization_profile where appname= @ appn ame)

begin

select @opt _goal=opt _goal,

@use_stmtcache=use_stmtcache from master. . optimization_profile

where appname= @ appname

if @opt_goal="allrows_oltp" set plan optgoal allrows_oltp if @opt_goal="allrows _mix" set plan optgoal allrows _mix if@opt_goal="allrows_dss" set plan optgoal allrows_dss

if @use_stmtcache=1

begin

set statement_cache on set literal _autoparam on

end else begin

set statement_cache off

end

if @delayed_commit=1 set delayed _commit on ...

end

return 0

end

go

grant exec on sp _optimization_profile to public go

exec sp_logintrigger 'master. .sp_optimization_profile' go

如果一個單獨的服務器試圖支持不同類型的應用程序(OLTP和DSS)，則強烈推薦使用該技術，因其支持應用程序開發人員控制每個應用程序必要的優化配置，而無需在應用程序中進行硬編碼配置。除了優化情形外，開發人員也必須考慮臨時表和應用程序相關tempdb的負載管理。當一個服務器與DSS用戶共享時，這將改善需要支持混合負載的OLTP應用程序響應度。當大型的DSS查詢充滿tempdb時，通過避免tempdb掛起問題，它也能改善OLTP應用程序的可用性。