性能測試報告數(shù)據(jù)倉庫參考架構(gòu)包含結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)PB級數(shù)據(jù)倉庫使用Solaris?10OS,Sybase?IQ與BMMsoftDataFusion?應(yīng)Sun公司的邀請，InfoSizing于2007年7月對Sun數(shù)據(jù)倉庫參考架構(gòu)的加載及性能進(jìn)行了驗證，Sun數(shù)據(jù)倉庫參考架構(gòu)使用Solaris10操作系統(tǒng)、SybaseIQ、BMMsoftDataFushion，搭建于加州MenloPark，Sun企業(yè)技術(shù)中心（ETC），我們定義并檢測了一組基準(zhǔn)測試。該數(shù)據(jù)庫的裝載容量達(dá)到了破記錄的1PB原始數(shù)據(jù)，它總共包含6萬億行交易數(shù)據(jù)，超過1億8千5百萬文本查詢類文檔，比如電子郵件、報表、電子表格以及其他多媒體對象。本次基準(zhǔn)測試使用了容量空前的交易數(shù)據(jù)，描述了一個真實世界的場景——全球金融交易網(wǎng)絡(luò)中所產(chǎn)生的交易。將這些交易數(shù)據(jù)與相應(yīng)的代表50萬金融交易人之間電子通訊的多媒體文檔進(jìn)行合并。本次基準(zhǔn)測試環(huán)境的配置，數(shù)據(jù)倉庫的裝載以及性能測試的執(zhí)行均由InfoSizing獨立驗證，并對測試結(jié)果進(jìn)行收集與分析。所附報告是一份關(guān)于此次測試的容量與性能結(jié)果的獨立證明。此致總裁性能測試報告Sun數(shù)據(jù)倉庫參考架構(gòu)使用Solaris10操作系統(tǒng)，SybaseIQ，BMMsoftDataFusion執(zhí)行摘要Sun數(shù)據(jù)倉庫參考架構(gòu)，使用Solaris10操作系統(tǒng)，SybaseIQ分析型服務(wù)器以及BMMsoftDataFusion，配置了一臺SunSPARC技術(shù)的EnterpriseM9000服務(wù)器，帶有三個SunStorageTek6540陣列，取得了如下具有重要意義的成就：■加載了1PB的原始數(shù)據(jù)（6萬億行股票交易記錄），存于一個全面索引化的星型模型中；建立了一個全新的經(jīng)獨立驗證的全球最大的數(shù)據(jù)倉庫記錄。■達(dá)到了每天2850億行的加載速度（每秒300萬行），整個數(shù)據(jù)裝載過程持續(xù)了3周多的時間。■僅僅需要不到2秒的數(shù)據(jù)就緒時間，新加載的數(shù)據(jù)即可被數(shù)據(jù)倉庫使用。■用超過72TB的EDM數(shù)據(jù)（Email/電子郵件，Documents/文本，Multimedia/多媒體）替代一半的T（交易）數(shù)據(jù)，建立一個裝載有572TB原始“EDMT”數(shù)據(jù)的數(shù)據(jù)倉庫。■當(dāng)使用1億8千5百萬文檔（電子郵件，附件與其他非結(jié)構(gòu)化文檔）裝載數(shù)據(jù)倉庫時，加載速度達(dá)到每天26TB。■電子郵件加載速率達(dá)到每小時2百萬封，文檔加載速率達(dá)到每小時6百萬份，僅僅消耗不到7％的CPU，而M9000其余93％的CPU可用作他途。■顯著減少所需存儲磁盤空間，將其直接轉(zhuǎn)換為CO2排放量，則在由Solaris10操作系統(tǒng)、SybaseIQ、BMMsoftDataFushion構(gòu)建的數(shù)據(jù)倉庫參考架構(gòu)之生命期內(nèi)，可減少CO2排放量高達(dá)90％以上。配置說明Sun數(shù)據(jù)倉庫參考架構(gòu)所使用的“生產(chǎn)級”的環(huán)境包括：一個單節(jié)點的SunSPARC技術(shù)EnterpriseM9000服務(wù)器，運行Solaris10操作系統(tǒng)，與3臺SunStorageTek6540存儲陣列相連，使用光纖通道，并使用SybaseIQ12.7作為數(shù)據(jù)庫平臺。下圖顯示了該參考架構(gòu)平臺的具體配置：內(nèi)存分配■SybaseIQ寫節(jié)點運行于64核之上（總共128個線程），分配有大約100GB的主內(nèi)存。■大約45GB的主內(nèi)存用于SybaseIQ加載過程，作為數(shù)據(jù)庫裝載期間輸入數(shù)據(jù)文件的緩沖。■BMMsoftDataFushion加載服務(wù)器運行于64核之上（總共128個線程），分配有大約90GB內(nèi)存，其中50GB用于對SybaseIQ的支持，40GB由DataFushion單獨使用。■大約20GB主內(nèi)存分配給Solaris10，用于優(yōu)化交換（Swapping）與頁面（paging）增長到1PB創(chuàng)建數(shù)據(jù)庫Sun數(shù)據(jù)倉庫參考架構(gòu)使用一個星型模型建立，大約100個事實表，裝載有真實的描述股票交易狀況的T（交易）數(shù)據(jù)。6個維表被裝載，提供一個寬范圍的表基數(shù)（從5行到接近400萬行）。下表列出了維表的裝載情況。維表行數(shù)維表行數(shù)裝載事實表在SybaseIQ中，創(chuàng)建了100個事實表。每個表大約裝載了120多個加載單元，如下表所示：加載單元___________________________________輸入數(shù)據(jù)文件原始文件大小字節(jié)102,814,873,296記錄數(shù)百萬508記錄寬度列18分隔符大小（SizeofDelimiters）字節(jié)9,146,722,464帶分隔符的大小（SizewithDelimiters）GB95.8純數(shù)據(jù)大小GB87.2一組真實世界的交易數(shù)據(jù)被當(dāng)作模板，用以在每個加載單元里合成性的創(chuàng)建數(shù)據(jù)。保證生成的數(shù)據(jù)倉庫的分配、基數(shù)、數(shù)據(jù)相關(guān)性能夠代表一個真實世界的生產(chǎn)環(huán)境。實現(xiàn)PB級規(guī)模的里程碑100個事實表的裝載大約用了6周的時間，其中一半的時間用于系統(tǒng)的配置與調(diào)優(yōu)，其余時間（大約3周）用于將數(shù)據(jù)加載到數(shù)據(jù)庫表中。平均而言，這些表的數(shù)據(jù)加載速率為每小時1.8TB原始數(shù)據(jù)，每天加載超過2500億行數(shù)據(jù)。總體而言，超過1PB的純原始數(shù)據(jù)（也就是說，不包含實際數(shù)據(jù)的字節(jié)并沒有計算在其中）被加載到表中。在本例中，純原始數(shù)據(jù)不包含任何用于列之間分割的字節(jié)。而數(shù)據(jù)庫是從1130TB的包含分隔符的輸入文件裝載的，這些文件大約包含1029TB的純原始數(shù)據(jù)（即去掉列分隔符）。除了股票交易記錄之外，128GB的電子郵件、文本、多媒體文檔也通過DataFusion被加載到數(shù)據(jù)倉庫中。下表顯示了Sun數(shù)據(jù)倉庫參考架構(gòu)1PB的記錄集的裝載情況:PB級數(shù)據(jù)加載________________________________________________原始輸入數(shù)據(jù)加載單元數(shù)數(shù)據(jù)文件12081股票報價記錄數(shù)萬億6.1原始數(shù)據(jù)大小（含分隔符）TB1,130純數(shù)據(jù)大小（不含分隔符）TB1,029純輸入數(shù)據(jù)大小PB1.01_______________________________________________________平均文本大小KB670非結(jié)構(gòu)化文本數(shù)量百萬0.2非結(jié)構(gòu)化數(shù)據(jù)大小GB128________________________________________________總數(shù)據(jù)大小TB1,157PB1.13SybaseIQ存儲T數(shù)據(jù)與索引空間GB162,639TB159壓縮84.57%在上述裝載完成只后，定義了一個全視角的視圖以形成對100個事實表的“UNIONALL”，建立一個對全部加載的6萬億行數(shù)據(jù)的單一的訪問點。然后對這個PB級的企業(yè)數(shù)據(jù)倉庫執(zhí)行一組性能評估測試。這些測試結(jié)果將在隨后介紹。PB級性能評估查詢執(zhí)行時間 通過執(zhí)行多表查詢進(jìn)行驗證，牽涉到全事實表視圖以及一些維表。這些查詢主要驗證該企業(yè)數(shù)據(jù)倉庫的可操作性及其響應(yīng)時間是否保持在可接受的范圍。 共有6條不同的查詢被執(zhí)行，同時不斷增加并發(fā)數(shù)（從1到50）。這些查詢包括： ●“Active”與“Sector”查詢：簡單查詢，基于T數(shù)據(jù) ●“Short”與“Growth”查詢：復(fù)雜查詢，基于T數(shù)據(jù) ●“Secret”與“Popular”查詢：復(fù)雜查詢，基于混合的“EDMT”數(shù)據(jù)下圖描述了基于這個PB級數(shù)據(jù)倉庫運行這6個查詢所發(fā)生的響應(yīng)時間：新數(shù)據(jù)的就緒時間在一個新數(shù)據(jù)不斷實時生成的環(huán)境中，新數(shù)據(jù)加載到數(shù)據(jù)倉庫以及能被查詢所見的速度是一個關(guān)鍵的指標(biāo)。一段新的數(shù)據(jù)實時生成與它可被查詢所見之間的時間間隔稱為“就緒時間”。簡單查詢的響應(yīng)時間——在我們重點考察就緒時間的同時，也必須提到另外一個指標(biāo)，那就是對那些基于這個PB級數(shù)據(jù)庫的交易、電子郵件或者文檔進(jìn)行的“Pin-Point”查詢的響應(yīng)時間，它應(yīng)該保持在秒以內(nèi)。在執(zhí)行這些查詢之時，新的電子郵件消息同時產(chǎn)生，并由DataFusion捕獲，然后傳送到SybaseIQ中以供數(shù)據(jù)倉庫使用。新郵件生成到其可被查詢訪問之間的時間間隔（就緒時間）將會被評估。該測試驗證了Sun數(shù)據(jù)倉庫參考架構(gòu)如何獲得在新郵件消息生成到可被查詢訪問之間最小的時間延遲。這是首次基于該PB級數(shù)據(jù)庫執(zhí)行的對郵件消息的就緒時間進(jìn)行評估。下圖描述了測試結(jié)構(gòu)：經(jīng)測試，該PB級數(shù)據(jù)庫的電子郵件的平均就緒時間不到2秒。事實上，最長的就緒時間也不到4秒。新股票交易數(shù)據(jù)的就緒時間——新的復(fù)雜的股票交易數(shù)據(jù)的就緒時間也將被評估。不斷增加并發(fā)數(shù)量（從3到50），執(zhí)行相應(yīng)的查詢。每個查詢針對特定股票的現(xiàn)有報價。在這些查詢執(zhí)行之時，新的股票交易也不斷完成，記錄也將傳送到SybaseIQ中。本測試驗證了Sun數(shù)據(jù)倉庫參考架構(gòu)如何使用Solaris10操作系統(tǒng)、SybaseIQ、BMMsoftDataFusion實現(xiàn)了在反映新交易的新記錄生成到它可被查詢訪問之間的最小的時間延遲。新的交易記錄從生成到可被查詢訪問之間的時間（就緒時間）基于EDMT數(shù)據(jù)倉庫進(jìn)行評估。下圖描述了測試結(jié)果：

基于該PB級數(shù)據(jù)庫，新交易數(shù)據(jù)的平均響應(yīng)時間不超過5秒。裝載非架構(gòu)化數(shù)據(jù)隨后，50％的T（交易）數(shù)據(jù)從數(shù)據(jù)倉庫中卸載，以騰出空間用于加載另外的更有意義的“EDM”數(shù)據(jù)（電子郵件、文本與多媒體）。“EDM”數(shù)據(jù)由三種類型的非結(jié)構(gòu)化數(shù)據(jù)對象組成：電子郵件、小型文檔（比如純文本）以及大型文檔（比如視頻片斷、圖形圖像以及格式化文本）。具體的非結(jié)構(gòu)化數(shù)據(jù)加載顯示如下：總數(shù)電子郵件小型文檔大型文檔平均對象大小KB0.3432.47203,205加載的對象百萬18559.01250.374加載的原始大小GB72,72119.329572,406加載速度MB/秒0.1894317對象/小時新的“EDM”數(shù)據(jù)在加載期間僅僅占用了7%的CPU使用率，也就是說僅僅使用了64顆芯片中的大約6顆。混合的“EDMT”數(shù)據(jù)加上剩余的T數(shù)據(jù)，該PB級數(shù)據(jù)倉庫的最新加載情況如下圖所示：混合EDMT數(shù)據(jù)裝載原始輸入數(shù)據(jù)加載單元數(shù)數(shù)據(jù)文件5476股票交易記錄數(shù)萬億2.8純T（交易）數(shù)據(jù)大小TB467EDM文檔數(shù)百萬185純EDM（非結(jié)構(gòu)化）數(shù)據(jù)大小TB71.02混合（EDM+T）數(shù)據(jù)大小TB537.5非結(jié)構(gòu)化“EDM”對象通過DataFusion存儲到SybaseIQ中。某些文檔是各種不同格式和內(nèi)容的獨立文件，而有些文檔是電子郵件消息，其中80％帶有附件。在通過DataFusion傳送電子郵件消息時，每個附件同其主體郵件分開成為兩個獨立的文檔。這兩個獨立的文檔與充分的元數(shù)據(jù)一道被存儲以捕獲郵件主體與其附件之間的關(guān)聯(lián)。EDMT性能評估新郵件的就緒時間 基于混合的EDMT數(shù)據(jù)倉庫對新郵件消息的就緒時間進(jìn)行評估。下表描述了評估測試結(jié)果：基于混合的EDMT數(shù)據(jù)倉庫，新郵件的平均就緒時間小于3秒。事實上，在新裝載了1.85億新的文檔后，新郵件的平均就緒時間的增加幾乎可以忽略不計，僅僅約5％。基于混合的EDMT數(shù)據(jù)庫，交易數(shù)據(jù)的平均就緒時間小于5秒。事實上，在裝載了1.85億新的文檔后，其平均交易就緒時間也僅僅增加了約5％。減少CO2的排量從數(shù)據(jù)壓縮到CO2排量 數(shù)據(jù)倉庫運轉(zhuǎn)所需電力的減少可以直接轉(zhuǎn)化為全球CO2排量的減少。若能評估使用Solaris10操作系統(tǒng)、SybaseIQ、BMMsoftDataFusion所構(gòu)建的Sun數(shù)據(jù)倉庫參考架構(gòu)的數(shù)據(jù)壓縮，則相應(yīng)的CO2排量的減少可被計算。其他傳統(tǒng)型數(shù)據(jù)倉庫解決方案所需的存儲空間一般來說都會大于裝載的原始數(shù)據(jù)的大小。使用附加索引的“行存儲”模型在存儲需求方面通常會導(dǎo)致幾倍于原始數(shù)據(jù)的容量。與此形成鮮明對比的是，Sun數(shù)據(jù)倉庫參考架構(gòu)顯示了高達(dá)85％的數(shù)據(jù)壓縮。由于高度的數(shù)據(jù)壓縮，Sun數(shù)據(jù)倉庫參考架構(gòu)所需的電力僅僅是其他傳統(tǒng)型解決方案的10％。同樣的，在此參考架構(gòu)中，所需的物理空間，存儲設(shè)備的大小和重量也減少至少90％。計算CO2排量的減少 根據(jù)其技術(shù)說明，其50％的電力用于冷卻，用于測試的各種配置的電力消耗為90KW，一年的運營需要約780MWh。而傳統(tǒng)的相同容量的數(shù)據(jù)倉庫，所需存儲設(shè)備大約是其10倍，電量消耗每年約7800MWh。 根據(jù)普遍接受的“污染因子”認(rèn)識，每KWh產(chǎn)生1.34磅CO2，Sun數(shù)據(jù)倉庫參考架構(gòu)在其3年運行期內(nèi)可減少CO2排量14000噸。 到其生命周期結(jié)束，使用Solaris10操作系統(tǒng)、SybaseIQ、BMMsoftDataFusion構(gòu)建的Sun數(shù)據(jù)倉庫參考架構(gòu)預(yù)計可比傳統(tǒng)的同等數(shù)據(jù)容量與性能水平的解決方案減少污染物排放高達(dá)90％。同時，預(yù)計可減少生命周期結(jié)束時所需拋棄的存儲設(shè)備重達(dá)26噸。結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)的相關(guān)性 交易型與非結(jié)構(gòu)化數(shù)據(jù)通過使用BMMsoftDataFusion可以互相關(guān)聯(lián)。非結(jié)構(gòu)化對象在插入到數(shù)據(jù)倉庫時可進(jìn)行實時分析，每個對象生成的元數(shù)據(jù)也存儲到數(shù)據(jù)倉庫中。 下面的拷屏圖描述了用來組織電子郵件、附件和其他非結(jié)構(gòu)化對象的Projectfolders（本例中為“MuellerSpoelmann”）是如何被建立的。這些folders自動基于預(yù)定義和用戶自定義的規(guī)則進(jìn)行裝載。范圍很廣的用于關(guān)系型和全文搜索的字符與數(shù)字參數(shù)，以及統(tǒng)一數(shù)據(jù)的相關(guān)性可由屏幕右邊輸入。復(fù)雜的EDMT分析結(jié)果以統(tǒng)一的EDMT數(shù)據(jù)視圖顯示。電子郵件、文本、交易可以實時地?zé)o縫地被分析，集成的結(jié)果可被顯示或輸出到文件中。下面的截屏圖描述了潛在的欺詐性股票交易、內(nèi)幕交易或其他目標(biāo)事件是如何被實時捕捉的。滿足監(jiān)管所要求的數(shù)據(jù)保存要求帶WORM-FS功能的SunStorageTekQFS軟件被配置為用于測試該PB級數(shù)據(jù)倉庫的平臺的一部分。目的是證明DataFusion可以使用外部WORM存儲子系統(tǒng)滿足監(jiān)管對數(shù)據(jù)保存的需求（比如，SOXNASD,SEC17a-4,HIPAA,GLBH以及其他）。上面的截屏圖描述了DataFusion如何被配置為自動存儲外部WORM設(shè)備中、存儲服務(wù)器（如SybaseIQ）中的新數(shù)據(jù)（如電子郵件、附件或其他非結(jié)構(gòu)化文檔），或者兩者同時進(jìn)行。查詢集 用于性能測試的查詢集由以下6個查詢組成：“Active”查詢 查詢所有交易中特定日期前10名最活躍的股票，按交易量排序。SELECT

TOP10TRADING_SYMBOL,

SUM(BID_SIZE)ASTRADESIZE,

DENSE_RANKOVER(ORDERBYSUM(BID_SIZE)DESC)ASRANKING

FROM

STOCK_QUOTE_VIEW

WHERE

QUOTE_DATE='2007-07-04'

GROUPBY

TRADING_SYMBOL

ORDERBY

SUM(BID_SIZE)DESC;“Sector”查詢 查找當(dāng)前“計算機(jī)”行業(yè)最活躍的股票。 SELECT

ST.TRADING_SYMBOL,

SUM(BID_SIZE)TRADESIZE,

DENSE_RANK()OVER(ORDERBYSUM(BID_SIZE)DESC)ASRANKING

FROM

STOCK_INNERJOIN

INSTRUMENTIION

II.TRADING_SYMBOL=ST.TRADING_SYMBOL

INNERJOIN

SCND_IDST_CLSSCON

II.SCND_IDST_CLS_ID=SC.SCND_IDST_CLS_IDAND

SC.SIC_NAME='COMPUTERS'

WHERE

ST.QUOTE_DATE='2007-07-04'

GROUPBY

ST.TRADING_SYMBOL;

“Secret”查詢查詢在股票競價（BIDS）與有泄密之嫌的電子郵件之間是否有關(guān)聯(lián)。SELECT

TRADING_SYMBOL,

QUOTE_DATE,

SUM(BID_SIZE)

FROM

STOCK_QUOTE_VIEW,

BMM_MESSAGEHEADER,

BMM_MESSAGELONGTEXT

WHERE

TEXTTYP='P'AND

MESSAGETEXTLIKE'%SECRET%'AND

MESSAGE_ID=MESSAGE_IDAND

SUBJECT=TRADING_SYMBOLAND

QUOTE_DATE='2007-07-04'

GROUPBY

TRADING_SYMBOL,

QUOTE_DATE;

“Popular”查詢查詢某天在電子郵件通訊中被討論最多的股票。SELECT

COUNT(*),

BM.MESSAGE_TIME,

SQ.TRADING_SYMBOL,

SUM(SQ.BID_SIZE)ASTRADESIZE,

DENSE_RANK()OVER

(ORDERBYSUM(SQ.BID_SIZE)DESC)ASRANKING

FROM

STOCK_QUOTE_VIEWSQ,

BMM_MESSAGEHEADERBM

WHERE

SQ.QUOTE_DATE='2007-07-04'AND

BM.SUBJECT=SQ.TRADING_SYMBOL

GROUPBY

BM.MESSAGE_TIME,

SQ.TRADING_SYMBOL

ORDERBY

SUM(SQ.BID_SIZE)DESC;

“Short”查詢查詢某交易所特定日損失最大的前10名，按照損失百分比排序。損失的計算按照前一日的最后交易價格的百分比計算。SELECT

TOP10INSTRUMENT_ID,

TRADING_SYMBOL,

TRADE_PRICE,

TRADE_DATE

INTO#TEMP_TICK3A

FROM

DBA.STOCK_TRADEST,

(SELECT

INSTRUMENT_IDASIDX,

MAX(TRADE_TIME)ASMAXTIME

FROM

DBA.STOCK_TRADE

WHERE

TRADE_DATE='2005-11-14'

GROUPBY

INSTRUMENT_ID

)Y

WHERE

ST.TRADE_DATE='2005-11-14'AND

ST.TRADE_TIME=MAXTIMEAND

IDX=ST.INSTRUMENT_ID;

CREATEVARIABLEPREV_DAYDATE;

SETPREV_DAY=(SELECTMAX(TRADE_DATE)

FROMSTOCK_TRADE

WHERETRADE_DATE<'2005-11-14');

SELECT

INSTRUMENT_ID,

TRADING_SYMBOL,

TRADE_PRICE,

TRADE_DATE

INTO#TEMP_TICK3B

FROM

DBA.STOCK_TRADEST,

(SELECT

INSTRUMENT_IDASIDX,

MAX(TRADE_TIME)ASMAXTIME

FROM

DBA.STOCK_TRADE

WHERE

TRADE_DATE=PREV_DAY

GROUPBY

INSTRUMENT_ID

)Y

WHERE

ST.TRADE_DATE=PREV_DAYAND

ST.TRADE_TIME=MAXTIMEAND

IDX=ST.INSTRUMENT_ID;

DROPVARIABLEPREV_DAY;

SELECT

INSTRUMENT_ID,

TRADING_SYMBOL,

PER_LOSER,

LOSER_RANK

FROM

(SELECT

INSTRUMENT_ID,

TRADING_SYMBOL,

PER_LOSER,

RANK()OVER(ORDERBYPER_LOSERASC)

LOSER_RANK

FROM

(SELECT

T.INSTRUMENT_ID,

T.TRADING_SYMBOL,

(T.MTP-Y.MTP)*100/Y.MTPPER_LOSER

FROM

(SELECT

INSTRUMENT_ID,

TRADING_SYMBOL,

TRADE_PRICEMTP

FROM

#TEMP_TICK3A)T,

(SELECT

INSTRUMENT_ID,

TRADING_SYMBOL,

TRADE_PRICEMTP

FROM

#TEMP_TICK3B

)Y

WHERET.INSTRUMENT_ID=Y.INSTRUMENT_ID

)A

)B

WHEREPER_LOSER<0;

“Growth”查詢 查詢目前$100,000的價值，假設(shè)一年前投資了等值的10支股票（比如每支股票為$10,000）。交易策略遵循如下規(guī)則：如果20天平均漲跌高于5個月平均漲跌值，則置為投資；如果20天平均漲跌低于5個月平均漲跌值，則置為出售。TRUNCATETABLEHIST_TEMP;

TRUNCATETABLEHIST7_TEMP;

COMMIT;

INSERTHIST_TEMPSELECT

NUMBER(),

B.INSTRUMENT_ID,

B.TRADING_SYMBOL,

B.TRADE_DATE,B.CLOSE_PRICE,

IFNULL(SUM(A.SPLIT_FACTOR),1,SUM(A.SPLIT_FACTOR)

)

FROM

STOCK_HISTORYASB

LEFTOUTERJOIN

SPLIT_EVENTASAON

B.INSTRUMENT_ID=A.INSTRUMENT_IDAND

B.TRADE_DATE<A.EFFECTIVE_DATE

WHERE

B.INSTRUMENT_IDBETWEEN11AND20AND

B.TRADE_DATE>=DATEADD(DAY,-160,'2012-06-01')AND

B.TRADE_DATE<='2012-12-01'

GROUPBY

B.INSTRUMENT_ID,

B.TRADING_SYMBOL,

B.TRADE_DATE,

B.CLOSE_PRICE

ORDERBY

B.INSTRUMENT_ID,

B.TRADE_DATE;

INSERTHIST7_TEMPSELECT

NUMBER(),

X.INSTRUMENT_ID,

X.TRADE_DATE,

AVG_5MTH,

AVG_21DAY

FROM

(SELECT

B.INSTRUMENT_ID,

B.TRADE_DATE,

AVG(C.CLOSE_PRICE*B.SPLIT_FACTOR)AVG_5MTH

FROM

HIST_TEMPASB

LEFTOUTERJOIN

HIST_TEMPASCON

B.INSTRUMENT_ID=C.INSTRUMENT_IDAND

C.ROW_NBRBETWEENB.ROW_NBR-160AND

B.ROW_NBR

GROUPBY

B.INSTRUMENT_ID,

B.TRADE_DATE

)X,

(SELECT

B.INSTRUMENT_ID,

B.TRADE_DATE,

AVG(C.CLOSE_PRICE*B.SPLIT_FACTOR)AVG_21DAY

FROM

HIST_TEMPASB

LEFTOUTERJOIN

HIST_TEMPASCON

B.INSTRUMENT_ID=C.INSTRUMENT_IDAND

C.ROW_NBRBETWEENB.ROW_NBR-21ANDB.ROW_NBR

GROUPBY

B.INSTRUMENT_ID,

B.TRADE_DATE

)Y

WHERE

X.INSTRUMENT_ID=Y.INSTRUMENT_IDAND

X.TRADE_DATE=Y.TRADE_DATE

ORDERBY

X