銀行系統(tǒng)異構(gòu)數(shù)據(jù)庫(kù)的整合運(yùn)維研究

摘 要： 銀行系統(tǒng)中使用的數(shù)據(jù)庫(kù)類型和數(shù)量逐漸增多，這對(duì)銀行系統(tǒng)的數(shù)據(jù)庫(kù)運(yùn)維提出了更高的要求。通過研究建立統(tǒng)一的數(shù)據(jù)庫(kù)集中運(yùn)維管理平臺(tái)，實(shí)現(xiàn)了異構(gòu)數(shù)據(jù)庫(kù)的整合運(yùn)維，節(jié)約了數(shù)據(jù)庫(kù)運(yùn)維管理的人力投入和廠商資源成本，達(dá)到了主動(dòng)和預(yù)防性的數(shù)據(jù)庫(kù)運(yùn)維模式，提高了數(shù)據(jù)庫(kù)運(yùn)維管理的效率及事件處理的時(shí)效性，提升了銀行系統(tǒng)的穩(wěn)定性。

關(guān)鍵詞： 異構(gòu)數(shù)據(jù)庫(kù)； 整合運(yùn)維； 預(yù)防性； 效率

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2013）10-06-04

0 引言

在現(xiàn)代銀行系統(tǒng)中，由于業(yè)務(wù)模式的類型不斷擴(kuò)張，使用的數(shù)據(jù)庫(kù)產(chǎn)品種類也越來越多，已有的主流數(shù)據(jù)庫(kù)產(chǎn)品有Informix、Sybase、Sqlserver、Oracle。隨著數(shù)據(jù)庫(kù)類型和數(shù)量越來越多，對(duì)數(shù)據(jù)庫(kù)的運(yùn)維質(zhì)量要求[1]也越來越高。由于缺乏有效的運(yùn)行監(jiān)控、自動(dòng)化巡檢、趨勢(shì)預(yù)測(cè)、隱患排查的方法和工具，導(dǎo)致運(yùn)維成本不斷增加，數(shù)據(jù)庫(kù)管理工作面臨嚴(yán)峻的考驗(yàn)。因此，對(duì)于不同類型的異構(gòu)數(shù)據(jù)庫(kù)的整合運(yùn)維[2-4]是現(xiàn)代金融企業(yè)IT科技必須研究的一個(gè)重要課題。

目前，異構(gòu)數(shù)據(jù)庫(kù)的整合運(yùn)維存在兩大問題：

⑴ 數(shù)據(jù)庫(kù)的產(chǎn)品種類不同，導(dǎo)致運(yùn)維標(biāo)準(zhǔn)缺乏統(tǒng)一性；

⑵ 當(dāng)前主流的數(shù)據(jù)庫(kù)運(yùn)維工具側(cè)重于“事中”和“事后”監(jiān)控[5-7]等被動(dòng)模式，缺乏主動(dòng)性運(yùn)維模式。

為解決上述問題，本文通過研究建立異構(gòu)數(shù)據(jù)庫(kù)的集中運(yùn)維管理平臺(tái)，改變數(shù)據(jù)庫(kù)運(yùn)維中存在的效率低、管理方式被動(dòng)等不足，同時(shí)通過實(shí)現(xiàn)主動(dòng)和預(yù)防性的數(shù)據(jù)庫(kù)運(yùn)維模式，提高數(shù)據(jù)庫(kù)運(yùn)維效率。

1 平臺(tái)體系架構(gòu)

經(jīng)調(diào)研發(fā)現(xiàn)，目前業(yè)界尚沒有一款產(chǎn)品可以完全覆蓋四種異構(gòu)數(shù)據(jù)庫(kù)的指標(biāo)監(jiān)控，往往僅支持一種或兩種數(shù)據(jù)庫(kù)。在經(jīng)過對(duì)幾款主流數(shù)據(jù)庫(kù)監(jiān)控平臺(tái)POC測(cè)試的基礎(chǔ)上，我們最終選用ORACLE公司的GRID CONTROL，作為我行異構(gòu)數(shù)據(jù)庫(kù)整合運(yùn)維度量分析平臺(tái)的基礎(chǔ)框架，其物理架構(gòu)如圖1所示。

如圖1所示，數(shù)據(jù)庫(kù)運(yùn)維度量平臺(tái)共包括四臺(tái)服務(wù)器，分別為一臺(tái)應(yīng)用服務(wù)器、一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器和兩臺(tái)中轉(zhuǎn)服務(wù)器。其中，應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器互為熱備，通過SAN網(wǎng)絡(luò)連接到共享存儲(chǔ)，兩臺(tái)中轉(zhuǎn)服務(wù)器互為冷備。因此，總體來說，本平臺(tái)可滿足高可用性。

四臺(tái)服務(wù)器上都安裝了SUSE LINUX操作系統(tǒng)。其中，應(yīng)用服務(wù)器安裝了Weblogic中間件，數(shù)據(jù)庫(kù)服務(wù)器和兩臺(tái)中轉(zhuǎn)服務(wù)器都安裝了Oracle數(shù)據(jù)庫(kù)。此外，數(shù)據(jù)庫(kù)服務(wù)器上安裝了GRID CONTROL產(chǎn)品，作為異構(gòu)數(shù)據(jù)庫(kù)監(jiān)控分析的平臺(tái)；而中轉(zhuǎn)服務(wù)器則作為接收和存放報(bào)表數(shù)據(jù)的平臺(tái)。

本平臺(tái)的系統(tǒng)邏輯架構(gòu)圖如圖2所示。其邏輯結(jié)構(gòu)從下往上依次為：數(shù)據(jù)源層、數(shù)據(jù)收集層、數(shù)據(jù)中轉(zhuǎn)層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)處理層、數(shù)據(jù)展示層、數(shù)據(jù)分析層和事件通知層。

通過分層架構(gòu)模式，本平臺(tái)細(xì)化并明確了各層次的專有功能，極大地降低了各層次間的耦合程度。各層次的組成和作用說明如下。

數(shù)據(jù)源層 處于整個(gè)邏輯架構(gòu)的最底層，是數(shù)據(jù)庫(kù)運(yùn)維指標(biāo)的原始數(shù)據(jù)來源，由生產(chǎn)系統(tǒng)的各類數(shù)據(jù)庫(kù)和其中的數(shù)據(jù)組成，包括Informix、Sybase、Oracle、Sqlserver數(shù)據(jù)庫(kù)。

數(shù)據(jù)收集層 用于從數(shù)據(jù)源層實(shí)時(shí)收集數(shù)據(jù)庫(kù)的各類運(yùn)維指標(biāo)數(shù)據(jù)。

數(shù)據(jù)中轉(zhuǎn)層 對(duì)收集到的原始指標(biāo)數(shù)據(jù)進(jìn)行過濾和格式轉(zhuǎn)換，將原始指標(biāo)數(shù)據(jù)轉(zhuǎn)換成符合運(yùn)維度量平臺(tái)庫(kù)表所定義的存儲(chǔ)格式，并將指標(biāo)數(shù)據(jù)導(dǎo)入到平臺(tái)的存儲(chǔ)數(shù)據(jù)庫(kù)中。

數(shù)據(jù)存儲(chǔ)層 定義了存儲(chǔ)和分析異構(gòu)數(shù)據(jù)庫(kù)運(yùn)維指標(biāo)所需的庫(kù)表結(jié)構(gòu)，存放經(jīng)過數(shù)據(jù)中轉(zhuǎn)層過濾和轉(zhuǎn)換后的各類數(shù)據(jù)庫(kù)運(yùn)維指標(biāo)值，以及運(yùn)維度量分析平臺(tái)自身正常運(yùn)行所需要的元數(shù)據(jù)，用于提供給更高層進(jìn)行展示、分析、監(jiān)控。

數(shù)據(jù)處理層 通過數(shù)據(jù)處理引擎，計(jì)算出各項(xiàng)數(shù)據(jù)庫(kù)運(yùn)維指標(biāo)的基線，以滿足更高層對(duì)數(shù)據(jù)庫(kù)進(jìn)行自動(dòng)化巡檢、趨勢(shì)預(yù)測(cè)、運(yùn)維指標(biāo)監(jiān)控的需要。

數(shù)據(jù)展示層 生成數(shù)據(jù)庫(kù)自動(dòng)巡檢結(jié)果和日常檢查報(bào)表。

數(shù)據(jù)分析層 通過趨勢(shì)分析，提前預(yù)警數(shù)據(jù)庫(kù)未來可能發(fā)生的問題，并幫助數(shù)據(jù)庫(kù)管理員做好隱患排查和解決的準(zhǔn)備工作。

事件通知層 通過和郵件系統(tǒng)、HP Openview事件監(jiān)控平臺(tái)結(jié)合，進(jìn)行告警。

其中，Oracle Grid Control產(chǎn)品的實(shí)現(xiàn)功能為：Oracle數(shù)據(jù)庫(kù)所有運(yùn)行指標(biāo)、Sybase、Sqlserver數(shù)據(jù)庫(kù)部分運(yùn)行指標(biāo)的數(shù)據(jù)采集功能和數(shù)據(jù)展示、事件通知功能。

我們的創(chuàng)新點(diǎn)為：通過自定義數(shù)據(jù)收集層、數(shù)據(jù)中轉(zhuǎn)層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)處理層，實(shí)現(xiàn)了所有非Oracle數(shù)據(jù)庫(kù)（Informix、Sybase、Sqlserver等）運(yùn)行指標(biāo)的數(shù)據(jù)采集功能，并通過特定的策略算法，對(duì)數(shù)據(jù)庫(kù)指標(biāo)進(jìn)行了趨勢(shì)分析和自動(dòng)化等主動(dòng)性運(yùn)維。

2 異構(gòu)數(shù)據(jù)庫(kù)整合運(yùn)維策略

本平臺(tái)的第一個(gè)關(guān)鍵技術(shù)特點(diǎn)是如何實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫(kù)的統(tǒng)一管理。在沒有實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫(kù)集中化管理前，數(shù)據(jù)庫(kù)管理員將會(huì)面對(duì)不同的數(shù)據(jù)庫(kù)管理視圖，具體如圖3所示。

從圖3可以發(fā)現(xiàn)，分散管理數(shù)據(jù)庫(kù)的模式存在如下缺點(diǎn)。

⑴ 每種數(shù)據(jù)庫(kù)分別使用不同的管理工具，缺乏良好的擴(kuò)展性。如果以后新增一個(gè)數(shù)據(jù)庫(kù)種類，就需再搭建一套獨(dú)立的管理工具，相應(yīng)增加投資成本和維護(hù)成本，造成資源的浪費(fèi)。

⑵ 每種數(shù)據(jù)庫(kù)使用不同的管理工具，缺少統(tǒng)一的視圖、界面和使用方法，管理員需要去熟悉不同工具的使用，造成技術(shù)管理壁壘。

⑶ 每種數(shù)據(jù)庫(kù)使用不同的管理工具，使得數(shù)據(jù)庫(kù)的各類運(yùn)行指標(biāo)數(shù)據(jù)分散存放，不利于管理員對(duì)這些數(shù)據(jù)進(jìn)行統(tǒng)一的管理和使用。

以上缺點(diǎn)啟發(fā)了我們對(duì)異構(gòu)數(shù)據(jù)庫(kù)進(jìn)行統(tǒng)一管理，具體的整合運(yùn)維策略及步驟如下。

⑴ 首先，設(shè)計(jì)適用于所有主流數(shù)據(jù)庫(kù)通用的數(shù)據(jù)表和視圖，用來存放收集到的各類運(yùn)行指標(biāo)數(shù)據(jù)，并形成數(shù)據(jù)存儲(chǔ)層。

⑵ 其次，在數(shù)據(jù)收集層通過數(shù)據(jù)獲取引擎收集數(shù)據(jù)庫(kù)運(yùn)行數(shù)據(jù)，建立獨(dú)特的數(shù)據(jù)傳輸鏈路，將運(yùn)行數(shù)據(jù)傳輸?shù)街修D(zhuǎn)服務(wù)器。

⑶ 最后，在數(shù)據(jù)中轉(zhuǎn)層通過中轉(zhuǎn)服務(wù)器上的數(shù)據(jù)中轉(zhuǎn)引擎，對(duì)運(yùn)行數(shù)據(jù)進(jìn)行過濾、格式轉(zhuǎn)換，形成統(tǒng)一的格式后將數(shù)據(jù)導(dǎo)入平臺(tái)的庫(kù)表中。

在數(shù)據(jù)庫(kù)集中管理下的統(tǒng)一視圖，如圖4所示。

從圖4可以看出，異構(gòu)整合后的平臺(tái)具有如下優(yōu)點(diǎn)。

⑴ 只搭建一個(gè)系統(tǒng)，就能實(shí)現(xiàn)對(duì)所有數(shù)據(jù)庫(kù)運(yùn)維指標(biāo)的收集、管理、使用、保存，有利于節(jié)約投資。

⑵ 統(tǒng)一的功能、界面和操作模式，使數(shù)據(jù)庫(kù)管理員只需要掌握一種方法，就能管理所有異構(gòu)數(shù)據(jù)庫(kù)得日常運(yùn)維工作，消除了技術(shù)壁壘。

在解決了異構(gòu)數(shù)據(jù)庫(kù)管理后，另一個(gè)關(guān)鍵技術(shù)就是如何實(shí)現(xiàn)主動(dòng)性的數(shù)據(jù)庫(kù)運(yùn)維。

我們認(rèn)為，主動(dòng)性的數(shù)據(jù)庫(kù)運(yùn)維必須同時(shí)滿足如下三點(diǎn)。

⑴ 自動(dòng)化：自動(dòng)生成數(shù)據(jù)庫(kù)巡檢結(jié)果和日常檢查報(bào)表。

⑵ 趨勢(shì)分析：通過深層次的指標(biāo)監(jiān)控，幫助數(shù)據(jù)庫(kù)管理員提前預(yù)警數(shù)據(jù)庫(kù)未來可能發(fā)生的問題，做好隱患排查和解決的準(zhǔn)備工作。

⑶ 事件通知：將隱患和告警，第一時(shí)間自動(dòng)通知數(shù)據(jù)庫(kù)管理員。

通過編寫SQL語句，并結(jié)合GRID CONTROL自身的報(bào)表展現(xiàn)和事件告警功能，本平臺(tái)實(shí)現(xiàn)了以上三個(gè)功能點(diǎn)。在日常運(yùn)維中，本平臺(tái)的主要應(yīng)用范圍如下。

⑴ 每日定時(shí)自動(dòng)發(fā)送數(shù)據(jù)庫(kù)產(chǎn)品運(yùn)行指標(biāo)狀態(tài)檢查報(bào)告。

⑵ 每日定時(shí)自動(dòng)發(fā)送生產(chǎn)系統(tǒng)數(shù)據(jù)庫(kù)巡檢報(bào)告。

⑶ 每周定時(shí)自動(dòng)發(fā)送數(shù)據(jù)庫(kù)產(chǎn)品容量增長(zhǎng)趨勢(shì)評(píng)估郵件。

具體的展示分別如圖5、圖6所示。

3 應(yīng)用效果分析

本平臺(tái)投產(chǎn)至今，已實(shí)現(xiàn)了超過100套異構(gòu)數(shù)據(jù)庫(kù)的集中管理。經(jīng)評(píng)估，本平臺(tái)的主要應(yīng)用效果如下。

⑴ 節(jié)約成本，帶來經(jīng)濟(jì)效益：四種數(shù)據(jù)庫(kù)，每個(gè)數(shù)據(jù)庫(kù)管理平臺(tái)建設(shè)需投入約100萬，共400萬；而本平臺(tái)建設(shè)需投入100萬，共節(jié)省約300萬；

⑵ 降低運(yùn)維人力成本，提升工作效率：100套數(shù)據(jù)庫(kù)，每套檢查需20分鐘，即每天節(jié)省2000分鐘，相當(dāng)于4人天，合計(jì)880人天/年；

⑶ 節(jié)約數(shù)據(jù)庫(kù)廠商的定期巡檢成本：100套數(shù)據(jù)庫(kù)，每季度的每套數(shù)據(jù)庫(kù)巡檢從1小時(shí)縮減到30分鐘，共節(jié)省3000分鐘，相當(dāng)于6人天， 合計(jì)24人天/年；

⑷ 實(shí)現(xiàn)了主動(dòng)、預(yù)防性的數(shù)據(jù)庫(kù)運(yùn)維模式；

⑸ 消除數(shù)據(jù)庫(kù)管理員的技術(shù)壁壘。

4 結(jié)束語

本平臺(tái)通過建立統(tǒng)一的異構(gòu)數(shù)據(jù)庫(kù)運(yùn)維監(jiān)控體系，將多種不同類型的數(shù)據(jù)庫(kù)管理進(jìn)行整合，解決了異構(gòu)數(shù)據(jù)庫(kù)運(yùn)維方法不統(tǒng)一、日常檢查和監(jiān)控效率低等問題。同時(shí)，本平臺(tái)通過對(duì)數(shù)據(jù)庫(kù)的性能分析、自動(dòng)化巡檢、運(yùn)行趨勢(shì)預(yù)測(cè)等功能，實(shí)現(xiàn)了主動(dòng)式、預(yù)防性的數(shù)據(jù)庫(kù)運(yùn)維模式。

通過本平臺(tái)的投入使用，降低了銀行系統(tǒng)數(shù)據(jù)庫(kù)故障的發(fā)生率，提高了數(shù)據(jù)庫(kù)的可用性，節(jié)約了人力和財(cái)力成本，為數(shù)據(jù)庫(kù)管理員提供了有效的支持和幫助。

參考文獻(xiàn)：

[1] Joel Siegel， Jae Shim.數(shù)據(jù)庫(kù)管理系統(tǒng)：管理人員必讀[M].清華大學(xué)出版社，2004.

[2] 呂品，夏紅霞，李明.異構(gòu)數(shù)據(jù)庫(kù)互操作平臺(tái)的開發(fā)研究[J].武漢理工大學(xué)學(xué)報(bào)，2003.25（1）：35

[3] 馬德云，俞時(shí)權(quán)，胡浩民.異構(gòu)數(shù)據(jù)庫(kù)的集成[J].計(jì)算機(jī)工程，2002.28（10）：283

[4] 王成杰，唐愛平.SQL SERVER管理異構(gòu)數(shù)據(jù)庫(kù)[J].電腦開發(fā)與應(yīng)用，2007.20（10）：78

[5] 李治強(qiáng)，苗放.多源異構(gòu)數(shù)據(jù)整合在信用系統(tǒng)中的應(yīng)用研究[J].計(jì)算機(jī)技術(shù)與發(fā)展，2007.17（2）：172

[6] 陳小武，潘章晟，趙沁平.網(wǎng)格環(huán)境下模式復(fù)用的異構(gòu)數(shù)據(jù)庫(kù)訪問和集成方法[J].軟件學(xué)報(bào)，2006.17（11）：2225

[7] 蔡延峰，蔡啟明.異構(gòu)數(shù)據(jù)庫(kù)間的數(shù)據(jù)轉(zhuǎn)換[J].計(jì)算機(jī)與現(xiàn)代化，2002.1（10）：41