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

關鍵詞： 異構數(shù)據(jù)庫； 整合運維； 預防性； 效率

中圖分類號：TP391 文獻標志碼：A 文章編號：1006-8228（2013）10-06-04

0 引言

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

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

⑴ 數(shù)據(jù)庫的產品種類不同，導致運維標準缺乏統(tǒng)一性；

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

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

1 平臺體系架構

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

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

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

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

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

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

數(shù)據(jù)收集層 用于從數(shù)據(jù)源層實時收集數(shù)據(jù)庫的各類運維指標數(shù)據(jù)。

數(shù)據(jù)中轉層 對收集到的原始指標數(shù)據(jù)進行過濾和格式轉換，將原始指標數(shù)據(jù)轉換成符合運維度量平臺庫表所定義的存儲格式，并將指標數(shù)據(jù)導入到平臺的存儲數(shù)據(jù)庫中。

數(shù)據(jù)存儲層 定義了存儲和分析異構數(shù)據(jù)庫運維指標所需的庫表結構，存放經過數(shù)據(jù)中轉層過濾和轉換后的各類數(shù)據(jù)庫運維指標值，以及運維度量分析平臺自身正常運行所需要的元數(shù)據(jù)，用于提供給更高層進行展示、分析、監(jiān)控。

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

數(shù)據(jù)展示層 生成數(shù)據(jù)庫自動巡檢結果和日常檢查報表。

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

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

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

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

2 異構數(shù)據(jù)庫整合運維策略

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

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

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

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

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

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

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

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

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

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

從圖4可以看出，異構整合后的平臺具有如下優(yōu)點。

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

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

在解決了異構數(shù)據(jù)庫管理后，另一個關鍵技術就是如何實現(xiàn)主動性的數(shù)據(jù)庫運維。

我們認為，主動性的數(shù)據(jù)庫運維必須同時滿足如下三點。

⑴ 自動化：自動生成數(shù)據(jù)庫巡檢結果和日常檢查報表。

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

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

通過編寫SQL語句，并結合GRID CONTROL自身的報表展現(xiàn)和事件告警功能，本平臺實現(xiàn)了以上三個功能點。在日常運維中，本平臺的主要應用范圍如下。

⑴ 每日定時自動發(fā)送數(shù)據(jù)庫產品運行指標狀態(tài)檢查報告。

⑵ 每日定時自動發(fā)送生產系統(tǒng)數(shù)據(jù)庫巡檢報告。

⑶ 每周定時自動發(fā)送數(shù)據(jù)庫產品容量增長趨勢評估郵件。

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

3 應用效果分析

本平臺投產至今，已實現(xiàn)了超過100套異構數(shù)據(jù)庫的集中管理。經評估，本平臺的主要應用效果如下。

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

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

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

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

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

4 結束語

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

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

參考文獻：

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

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

[3] 馬德云，俞時權，胡浩民.異構數(shù)據(jù)庫的集成[J].計算機工程，2002.28（10）：283

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

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

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

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