銀行數據大集中之後，業務部門越來越迫切地希望能從現有的數據中找到對開展業務有價值的信息，提供更多的輔助功能。在此背景下，出現了各種各樣的分析系統，有的銀行正在規劃數據倉庫（ＤＷ）的開發，有些銀行已開發了客戶關係管理（ＣＲＭ）系統。
ＤＷ與ＣＲＭ都以數據分析爲基礎，有的稱之爲決策支持系統（ＤＳＳ），有的稱之爲商務智能（ＢＩ）。但無論是ＣＲＭ還是ＤＷ，都不容易實現，即便在歐美發達國家已經有了成功的實踐經驗，國有四大商業銀行的賬務數據量之大和客戶數之多可能是歐美任何一家大銀行都無法相比的。在歐美，如果銀行的客戶數或賬戶數超過一千萬就是大型銀行了，與我國四大國有商業銀行的一些省級分行的數據量相當。
要在四大國有商業銀行實施數據分析系統，即使使用最先進的計算機設備，最先進的應用系統，最科學的算法，都不得不面臨一個共同的問題——性能調整。
一、數據分析系統與聯機交易系統性能的度量區別
數據分析系統對響應速度的要求雖然沒有聯機交易系統高，但也有一定的業務要求，每天增量的數據轉換、裝載、抽取、更新等必須在規定許可的時間內處理完。
響應時間和吞吐量仍是數據分析系統最爲關注的兩個問題，與傳統的ＯＬＴＰ系統不同的是：
１．ＯＬＴＰ系統重在聯機事務處理的響應速度、吞吐量；數據分析系統重在查詢，只有少量的聯機事務處理，其吞吐量主要表現爲單位時間內允許的查詢數。
２．ＯＬＴＰ系統的查詢交易一般僅返回一條或很少的記錄；數據分析系統的查詢有兩個響應 http://www.csai.cn ①從提交查詢的時刻到第一條記錄返回給最終用戶時刻之間的時間，②從查詢提交到返回所有記錄之間的時間。
二、數據分析系統性能調整的過程
１．首先建立並定義性能指標。在系統正式投入生產之前就有明確的性能需求，數據量與要求實現的功能決定了要採用的系統平臺。
２．制定並實施性能監控方案。如什麼時候監控，監控的週期，並及時記錄監控的結果（包括各應用程序運行時各類資源的佔用情況、響應速度、各數據表的數據量及訪問頻率等）。
３．根據監控記錄分析各度量元素（響應速度、吞吐量、ＣＰＵ、內存、Ｉ/Ｏ等）是否滿足預期定義的指標。
４．確定主要約束是ＣＰＵ、內存、網絡，還是Ｉ/Ｏ，如ＣＰＵ已達到或超過８５％的利用率等。
５．確定可以調整的資源。瞭解哪些方面可負擔得起性能改進，哪些資源可承受附加的負荷。
６．調整數據庫配置。每次更改一個，最好不要同時更改多個參數。
７．如果調整數據庫配置不起作用，則應調整操作系統或硬件配置。
以上是一個重複的過程。
三、應用設計
性能調整不僅是系統管理員的事，更需要應用開發人員的配合。不好的應用設計會吞噬掉機器的性能。
１．使用存儲過程
爲了提高處理性能，應儘可能採用存儲過程而不採用嵌入ＳＱＬ。存儲過程主要有以下優點：
（１）同發出單一的ＳＱＬ語句或發送整塊的ＰＬ/ＳＱＬ文本到服務器相比，信息只需發送一次，減少了交互，通過網絡傳送的信息量較少。
（２）存儲過程經創建、分析、認證、編譯等處理後，存放在數據庫管理系統（ＤＢＭＳ）服務器，ＳＱＬ語句是靜態的，可以即時調用，執行時不需要再編譯。如果存儲過程已經在共享內存中，就不需要從磁盤中讀取，可以立即執行。
（３）減少對內存的需求。多個用戶執行時，只需將過程的單個拷貝即可，多用戶共享同樣的代碼。
（４）連續的執行以較小的開銷實現，從而改善性能。動態ＳＱＬ每次運行都需要較大的預處理開銷。與表和索引一樣，系統可以收集存儲過程的統計信息，優化器可以創建最合適的訪問計劃。
有數據表明，實現同一個功能，採用存儲過程只需採用嵌入ＳＱＬ的２０％的時間。
使用存儲過程還比較安全，存儲過程的執行需要有該存儲過程定義者或所有者的權力，這樣就限制了用戶能夠執行的數據庫操作。同時，使用存儲過程還能提高軟件開發的生產率，可以把存儲過程看成面向對象設計中的經過封裝的類，其他存儲過程或應用程序爲完成某個功能，可以繼承該存儲過程而不需要重寫ＳＱＬ語句。如果需要修改該存儲過程功能，也不必對所有繼承該存儲過程的應用進行修改，可使修改的工作量降到最小，保證了應用程序的完整性與一致性。另外，存儲過程也是可重用的單元，對提高可靠性也有所幫助。
２．使用Ｃ程序設計語言作爲補充
不要使用Ｃ＋＋程序設計語言處理數據，更不要使用Ｊａｖａ程序設計語言。在所有的高級程序設計語言中，Ｃ程序設計語言的運行效率是公認的，可以使用Ｃ程序設計語言作爲補充。存儲過程有自身的缺陷，如編程語言ＳＱＬ功能較差，與編程環境集成不夠，移植性差，能提供的內部功能函數有限，執行過程中能提供的信息有限，不便調試等，對於一些特定的業務需求目標和數據的具體情況，可能用嵌Ｃ更好。
３．建立索引
建索引是提高數據訪問效率的重要途徑，但建索引有時並不一定能起到作用，索引不能滿足未知需求，有時會適得其反，降低系統性能。關於索引，可歸納出以下幾點：
（１）索引數儘量少。當要在一個合理的時間內結束查詢時，應避免添加索引。過多的索引會降低更新操作的速度並消耗額外的空間，使磁盤有效使用率降低，增加系統的複雜性和管理成本。低速查詢不一定表示數據庫或索引有問題，很可能是程序有問題。
（２）基數較大的列很適合用來做索引。如果索引的惟一值有限（如＜１００），則不宜使用索引。
（３）最好不選擇大的列作索引。
（４）考慮到管理上的開銷，應避免在索引中使用多於 ５ 個的列，避免覆蓋多個查詢的大型索引。
（５）對於多列索引，將查詢中引用最多的列放在定義的前面。
（６）添加與已有索引相似的索引會給優化器帶來更多的工作，降低更新操作的速度。如果需要，可以修改已有的索引，使其包含附加的列。
（７）在經常進行連接，但沒有指定爲外鍵的列上建立索引。
（８）在頻繁進行排序或分組的列上建立索引。
（９）在需要時建羣集索引。羣集索引允許對數據頁採用更線性的訪問模式，允許更有效的預取，並且有助於避免排序。這樣查詢操作會更快，但插入操作會慢。適合插入更新頻率不高的表。
（１０）確保最優的索引使用。
４．優化查詢
優化查詢的出發點是如何減少查詢的資源利用：減少Ｉ/Ｏ，減少運算量。可以用Ｓｅｔ Ｅｘｐｌａｉｎ命令分析各種查詢語句的效率。
（１）把頻繁使用的小表放在內存或高速緩存中，可以明顯減少Ｉ/Ｏ。
（２）減少所讀的行數和所讀或更新的列。如，僅讀取滿足條件的第一條記錄，僅讀取或更新必須的列。
（３）用臨時表縮小查詢範圍。
（４）儘量避免子查詢和明確關聯的子查詢。
（５）避免複雜規則表達式。
（６）儘量使用數據庫引擎提供的函數，如：ｓｕｍ，ａｖｇ，ｍｉｎ，ｍａｘ。
（７）儘量使用連接而不用嵌套循環，避免連接長字符串。
（８）儘量用Ｗｈｅｒｅ縮小連接範圍。
（９）避免不必要的大表的全表搜索。
５．數據結構與算法設計
（１）儘量採用整數類型
整數是最常用的數據類型，在運算字符串變量時計算機先把字符串中的每一個字符逐一轉換爲整數，然後再對每一個整數分別進行運算。計算機軟件處理整數的效率要比處理字符串快２ｎ倍，其中ｎ是字符串中字符的個數。
所以，在設計表結構時，一些計算時頻繁用到的字段，如分支機構代碼、系統用戶代碼、客戶代碼等，應儘量採用整數類型。
（２）少用可變長字符串
對少於或等於３０個字節的字段，應避免使用可變長字符串（ＶＡＲＣＨＡＲ）數據類型。在這種情況下，ＶＡＲＣＨＡＲ類型通常會浪費空間，所以建議使用ＣＨＡＲ 類型。如果數據量很大，空間的浪費往往會對查詢時間造成影響。
（３）數據模型
爲了減少數據冗餘，數據建模時一般都需要規格化達到第三範式，如果需要冗餘也是因爲外鍵關係和數據引用完整性的需要。適當的非規格化雖然需要佔用更多的空間，但通過減少頻繁的連接、聚集和推導可以提高數據查詢的性能。例如，客戶經理號與客戶經理名，客戶經理名依賴客戶經理號，如果在客戶經理業績表中僅有客戶經理號，在查詢客戶經理業績時就需要做表的關聯，從而降低查詢響應速度。非規格化以數據更新和數據空間的損失爲代價換取數據訪問的優化。一般的非規格化形式有：列複製，創建數據陣列，預連接表，預聚集數據。
（４）算法設計
良好的算法，對提高性能有很大的幫助。對於一個業務功能，可以用多種算法去實現，因此應該評估每種算法的執行效率，從而選擇最優算法。
這裏說一下排序。是排序，就要耗費資源，所以應儘量減少排序，避免不必要的排序，簡化排序。可以將數據放在臨時表中以避免排序，減少所需排序的行數，用簡單關鍵字排序，排序較少或較小的列，以簡化排序。
如果要排序應儘量使用內排序，避免使用外排序。外排序和內排序相比較要慢很多，而且磁盤排序會消耗臨時表空間中的資源。
四、數據庫系統參數調整
ＯＬＴＰ系統爲了達到更新交易吞吐量的最大化，一般使用緩衝日誌，增加物理日誌長度，最大化寫入緩衝百分比。爲防止任何ＤＳＳ類型的查詢佔用系統資源，可通過將相關並行查詢參數配置設爲較小值以限制並行查詢的資源（如Ｉｎｆｏｒｍｉｘ的ＰＤＱＰＲＩＯＲＩＴＹ、Ｏｒａｃｌｅ的ＰＱＯ並行查詢選項、ＤＢ２的ＩＮＴＲＡ＿ＰＡＲＡＬＬＥＬ、ＣＵＲＲＥＮＴ ＤＥＧＲＥＥ等）。
要使查詢引擎處理的查詢數最大化（吞吐量），以Ｉｎｆｏｒｍｉｘ爲例，可以將相關的並行查詢參數設爲ＰＤＱＰＲＩＯＲＩＴＹ≤２５％。
要使單個查詢的處理時間最小化（響應速度），可設置ＰＤＱＰＲＩＯＲＩＴＹ＝５０％，最好採用快速ＣＰＵ多處理器。
以上看起來似乎有些矛盾，但應根據實際情況平衡優先級。在不同的運行時間或針對不同的執行任務，使用不同的設置。例如，日常工作時間用戶數較多時，將ＰＤＱＰＲＩＯＲＩＴＹ設置爲較低，同時限制一些大數據量的查詢，大數據量的查詢可以放在非工作時間做，可設置較高的ＰＤＱＰＲＩＯＲＩＴＹ。
一些數據庫管理系統允許用戶設置頁面大小，如ＤＢ２，對於ＯＬＴＰ應用程序採用較小的頁面更爲可取，這樣消耗的緩衝池中的空間更少。對ＯＬＡＰ應用程序，通常使用較大頁面，可以減少在讀取特定數量的行時發出的Ｉ/Ｏ請求的數量。較大的頁面還可以減少索引中的層數。但是，如果行長度小於頁面大小的１/２５５，則每頁中都將存在浪費的空間，因爲每頁最多只能有２５５行（對於索引數據頁不適用）。在這種情況下，採用較小的頁面大小或許更合適一些。
ＤＢ２、Ｉｎｆｏｒｍｉｘ、Ｏｒａｃｌｅ都有許多參數可以調整，這裏不一一敘述。
五、硬件系統方面的考慮
對於數據分析系統而言，由於系統用戶較少，網絡一般不會成爲瓶頸。所以系統方面主要考慮處理器、內存和磁盤，原則是並行性相較於速度而言對提高性能更有效。
對於大型分塊表，使用多ＣＰＵ可以並行搜索每個分塊。增加ＣＰＵ個數可以支持更多的用戶數並增加並行性。ＣＰＵ越快，越能支持複雜查詢和大型數據庫。處理器的緩衝區越多就越快，多層緩衝可以幫助平衡處理器負荷。
一般來說，處理器、內存越多越好，但在現實環境中，數據處理的瓶頸常在輸入/輸出上，存儲器與計算機間的數據傳輸速度比計算機運算速度一般慢２～３個數量級，磁盤速度的提高遠遠落後於ＣＰＵ。我們在多個數據分析系統中發現存在Ｉ/Ｏ瓶頸。
系統中磁盤利用率一般不應超過４５％。磁盤除了考慮磁盤機速度、控制器與通道速度外，還要考慮當前和最大驅動器數（磁盤多多益善，多些小驅動器比少些大驅動器好，新驅動器較快但較大）。
如果爲了提高可靠性使用了ＲＡＩＤ磁盤設備，爲提高Ｉ/Ｏ性能，最好採用ＲＡＩＤ１０而不是ＲＡＩＤ５。在ＤＢ２中可以用ＤＢ２＿ＰＡＲＡＬＬＥＬ＿ＩＯ註冊表變量，強制對由多個物理磁盤組成的單個ＲＡＩＤ容器表空間執行並行Ｉ/Ｏ。
使用裸設備、對存儲空間分塊可以顯著提高系統性能。
１．使用裸設備
Ｉ/Ｏ操作有兩種方式：文件系統或ｃｏｏｋｉｅｄ ｆｉｌｅ（熟文件）和裸設備Ｒａｗ Ｉ/Ｏ（或原始設備、生設備）。
文件系統又分爲緩衝（Ｂｕｆｆｅｒｅｄ）Ｉ/Ｏ、內存映射（Ｍｅｍｏｒｙ Ｍａｐｐｅｄ）Ｉ/Ｏ、ＤＩＯ、ＣＩＯ。以往最常用的文件系統爲Ｍｅｍｏｒｙ Ｍａｐｐｅｄ Ｉ/Ｏ、Ｂｕｆｆｅｒｅｄ Ｉ/Ｏ。ＤＩＯ可以在文件系統級越過ｃａｃｈｉｎｇ，減少ＣＰＵ負載。２００３年ＩＢＭ在ＡＩＸ ５Ｌ ｖｅｒｓｉｏｎ ５．２．１０文件系統ＪＦＳ２推出了ＣＩＯ，包含了ＤＩＯ的優點，多線程可以同時讀寫共享的文件，但性能仍比裸設備Ｒａｗ Ｉ/Ｏ低。
與文件系統相比，裸設備有以下優點：
（１）空間是物理連接的，由一大塊相鄰磁盤空間構成，數據庫管理引擎不需要跳過磁盤尋找數據時，能大大提高性能。熟文件的磁盤空間可能由多個Ｕｎｉｘ文件共享。連續的磁盤空間是設計表格與索引的重要因素。
（２）數據直接在共享內存與磁盤之間傳輸，不需要操作系統緩衝過程，從而加快了響應速度。數據庫管理引擎對數據庫操作優化Ｉ/Ｏ，避免其他涉及操作系統的步驟，而文件系統的實現要通過ｃａｃｈｉｎｇ和鎖機制。
（３）利用裸設備能更好地保證系統出現故障時恢復數據。
當然，文件系統使用比較方便，Ｒａｗ Ｉ/Ｏ對存儲管理要求比較高。Ｉ/Ｏ按性能速度從高到低爲Ｒａｗ Ｉ/Ｏ、ＣＩＯ、ＤＩＯ、Ｍｅｍｏｒｙ Ｍａｐｐｅｄ Ｉ/Ｏ、Ｂｕｆｆｅｒｅｄ Ｉ/Ｏ。有許多測試表明，裸設備比熟文件快１５％～２５％。
２．磁盤分區
ＤＢ２、Ｉｎｆｏｒｍｉｘ、Ｏｒａｃｌｅ建表時都可以確定Ｅｘｔｅｎｔ初始值。Ｉｎｆｏｒｍｉｘ建議Ｅｘｔｅｎｔ不超過３３個。ＤＢ２對Ｅｘｔｅｎｔ Ｓｉｚｅ的建議爲估計空間大小/４ｋ×１６Ｍ。Ｏｒａｃｌｅ Ｅｘｔｅｎｔ的管理很靈活，除了操作系統自身的限制外，可以指定Ｅｘｔｅｎｔ數量的最大和最小值。
數據分析系統包含了當前和歷史的數據，一般數據量都很大，需要分佈存放。一些數據庫管理系統有限制：如在一個分區上的總頁數不能超過１６Ｍ頁，如果超過這個限制，爲了提高性能則需採用分佈存儲方式，把數據存放在不同的物理設備上，通過並行讀寫可以有效利用多磁盤的Ｉ/Ｏ帶寬，實現真正的數據分佈併發處理。如果存在磁盤瓶頸，應確保表空間分佈在所有可用磁盤上。如果磁盤利用率仍然很高，可能需要更多的磁盤。
數據分塊的方法有範圍分割法、哈希分割法、循環分割法、表達式分割法等，哈希分割法普遍使用於數據倉庫。如：對於交易數據可以按交易日期存放，對賬戶數據可以按所屬分支機構存放。各數據庫管理系統可以採用的分割法可能不同。
給數據對象分配空間時應注意：
（１）把頻繁訪問的表儘量放置到不同的表空間中。
（２）把索引和表數據分開放置到不同的表空間中。
（３）高增長表不要放到同一個表空間中。
（４）把經常使用的表存放在磁盤中間。
數據分佈存放的另一個好處是，可以提高數據的安全性，某個表空間損壞不至於影響到其他表空間。
六、運行規劃
數據分析系統必須每天裝載、更新生產交易系統下傳的數據。系統從初始化開始正常運行後，數據會隨着業務的增長而增長，分析功能及用戶也會隨之增長。每天在生產交易系統下傳數據到達後，需在規定的有限時間裏完成這些任務。所以做好運行設計，不但要考慮現在每天的任務安排，還要考慮未來的增長情況。
運行規劃包括以下幾個部分：
（１）首先確定批處理系統可用時間窗口和終端用戶可用時間窗口。例如，每天早晨三點收到總行數據中心的數據，終端用戶在上午九點就要查看到最新數據，這之間有六個小時可以用來做批處理。
（２）確定任務完成窗口。估算數據抽取、清理/轉換、裝載需要的時間，估算彙總統計、更新等正常業務功能處理需要的時間，各種查詢的響應時間，各種任務的執行週期等。確定哪些必須在終端用戶工作時間之前完成，哪些可以在終端用戶工作時完成，哪些可以在終端用戶工作時間之後完成。
（３）計劃性維護。確定何時維護及維護的內容。隨着時間的推移、用戶需求的改變，有的數據會過時，應將其定期歸檔，把長時間不用的數據轉移到其他設備中予以存儲，刪除休眠數據，清理髒數據。還要考慮備份，包括備份的數據量，備份所需時間，備份的級別，何時備份，備份的週期等。
定期更新數據表的統計信息是計劃性維護中一個很重要的任務，如運行ＤＢ２的ｒｕｎｓｔａｔｓ ｏｎ命令、Ｉｎｆｏｒｍｉｘ的ｕｐｄａｔｅ ｓｔａｔｉｓｔｉｃｓ ｆｏｒ命令等，這些統計信息直接影響查詢的執行計劃。ＤＢ２有一個實用程序ＲＥＯＲＧＣＨＫ，如果運行ＲＵＮＳＴＡＴＳ後仍不能改進性能，ＲＥＯＲＧ實用程序可以選擇根據指定的索引將數據重新排列成一個物理序列。對有大量更新的表，如果統計信息後性能提高不明顯，可以刪除和重建索引。
（４）糾正性維護。包括允許維護的時間，允許多少故障時間和恢復時間。
一般情況下，銀行購買產品後很少做參數調整、程序優化等方面的工作。針對機器出現的性能方面的問題，生產廠商也往往是推出系統升級方案。而銀行數據分析系統同交易系統不同，由於其需求不斷增加，沒有確定的邊界，因此，性能調整也是一個沒有結束的過程，若要最終達到資源極限，則需要升級硬件。