文/劉傳堯
現(xiàn)在從國家到學(xué)校都非常重視“信息孤島”問題,并相繼投入了大量的人力和財(cái)力,本文作者在學(xué)校實(shí)施教學(xué)改革和開展數(shù)字校園建設(shè)的過程中,通過建設(shè)與部署“本科生創(chuàng)新網(wǎng)”、“國家級虛擬仿真實(shí)驗(yàn)中心”、“課程中心平臺(tái)”等幾個(gè)校級的系統(tǒng),也確切感覺到“數(shù)據(jù)孤島”給數(shù)字化校園建設(shè)帶來的問題。目前主要解決的辦法有兩種:一種是推翻原有系統(tǒng),建立校級數(shù)據(jù)中心,由學(xué)校重新規(guī)劃建設(shè)各部門信息系統(tǒng);一種是對原有的系統(tǒng)進(jìn)行升級改造,然后實(shí)現(xiàn)跨部門之間的實(shí)時(shí)數(shù)據(jù)同步,讓“數(shù)據(jù)孤島”之間的基礎(chǔ)數(shù)據(jù)有效共享、合并冗余數(shù)據(jù) 。
隨著信息技術(shù)的快速發(fā)展,“信息孤島”(Information Isolated Island)所帶來的管理與技術(shù)問題在高校數(shù)字校園建設(shè)中普遍存在,所謂“信息孤島”指的是相對獨(dú)立的不同類型的資源信息系統(tǒng),由于各系統(tǒng)間相互封閉、無法進(jìn)行順暢的信息交流,猶如一個(gè)個(gè)分散、獨(dú)立的島嶼。其本質(zhì)的問題就是這些獨(dú)立的系統(tǒng)之間所生成的數(shù)據(jù)無法相互共享、數(shù)據(jù)不一致,這不僅導(dǎo)致了不同的系統(tǒng)因獨(dú)立管理而產(chǎn)生大量冗余數(shù)據(jù),而且由于系統(tǒng)與系統(tǒng)之間無法進(jìn)行數(shù)據(jù)關(guān)聯(lián),特別在大數(shù)據(jù)時(shí)代無法對數(shù)據(jù)進(jìn)行科學(xué)分析,學(xué)校無法通過這些數(shù)據(jù)進(jìn)行科學(xué)的管理與決策。信息孤島的產(chǎn)生不是一開始就存在的,它是高校在信息化推進(jìn)的過程中逐漸產(chǎn)生的一種必然現(xiàn)象。其產(chǎn)生的原因主要是高校在信息化建設(shè)初期,在認(rèn)識上,沒有充分理解信息化內(nèi)涵,過于注重技術(shù)而忽略應(yīng)用;在管理上,缺少統(tǒng)一規(guī)劃,多個(gè)部門各自為陣;在技術(shù)上,只注重硬件投入,而忽略軟件資源的建設(shè)。
“信息孤島”的存在很大程度上制約了校園信息化的進(jìn)程,已經(jīng)成為各高校急待解決的問題。查閱文獻(xiàn)發(fā)現(xiàn),目前在關(guān)于解決“信息孤島”問題上,主要還是從政策理論上去避免“信息孤島”的產(chǎn)生,通過技術(shù)來解決現(xiàn)存的“信息孤島”的方案相關(guān)文獻(xiàn)比較缺乏,特別是針對高校這種特殊的情況。目前也有專家提出基于信息交換平臺(tái)的實(shí)現(xiàn)方法,比如,李杰玲,雷軍程提出基于XML消除高校信息孤島,郭向陽提出基于數(shù)據(jù)庫復(fù)制技術(shù)的數(shù)據(jù)交換平臺(tái)研究與實(shí)現(xiàn)等。本文提出的是一種基于日志解析數(shù)據(jù)同步的“數(shù)據(jù)孤島”解決方案。該方案在許多方面都有其不可替代的優(yōu)勢,這主要體現(xiàn)在:操作方便,適合遠(yuǎn)程同步操作;實(shí)現(xiàn)記錄級數(shù)據(jù)同步;實(shí)現(xiàn)表一級數(shù)據(jù)同步;實(shí)現(xiàn)異構(gòu)表間的數(shù)據(jù)同步等。進(jìn)而讓遠(yuǎn)程目標(biāo)數(shù)據(jù)庫執(zhí)行同樣語句實(shí)現(xiàn)數(shù)據(jù)同步。要解決的主要問題是對Oracle數(shù)據(jù)庫歸檔日志的提取和分析,以及分析結(jié)果的SQL語句重構(gòu)問題。
Oracle數(shù)據(jù)庫的所有更改都記錄在日志中,但是原始的日志信息我們根本無法看懂,而從目前來看,分析Oracle日志的較好的方法就是使用Oracle公司提供的LogMiner工具來進(jìn)行。LogMiner工具是Oracle8i版本以后新增加的功能。通過LogMiner工具,可以進(jìn)行日志分析,分析在線日志、離線日志以及數(shù)據(jù)庫的重作日志文件。
在分布式環(huán)境下開發(fā)數(shù)據(jù)交換系統(tǒng),面對的主要瓶頸還是增量數(shù)據(jù)如何同步以及數(shù)據(jù)同步的效率問題。分布式環(huán)境下不能采用集中環(huán)境中那種靜態(tài)數(shù)據(jù)備份技術(shù),這種技術(shù)傳輸文件大,并且效率很低。因此增量數(shù)據(jù)同步成為唯一可行的方案。在基于Oracle數(shù)據(jù)庫的環(huán)境下,增量數(shù)據(jù)同步就必須解決數(shù)據(jù)庫日志的解析以及增量數(shù)據(jù)在目標(biāo)計(jì)算機(jī)快速入庫的問題。
系統(tǒng)總體設(shè)計(jì)由三大模塊構(gòu)成,分別
本文提出的數(shù)字校園的數(shù)據(jù)同步方案,主要依靠分析Oracle數(shù)據(jù)庫歸檔日志文件,解析日志中的SQL語句,為數(shù)據(jù)源端、目的端和控制端。數(shù)據(jù)源端和目的端以服務(wù)的方式運(yùn)行,控制端為一個(gè)在Windows下運(yùn)行的GUI應(yīng)用程序。數(shù)據(jù)源端根據(jù)控制端發(fā)送的要求,操縱地方各局?jǐn)?shù)據(jù)庫,然后提供系統(tǒng)所需的源數(shù)據(jù)。目的端根據(jù)用戶在控制端的設(shè)置,在規(guī)定的時(shí)間內(nèi),抽取數(shù)據(jù)源端的數(shù)據(jù),并進(jìn)行轉(zhuǎn)換入庫??刂贫瞬倏v數(shù)據(jù)源端和目的端服務(wù)運(yùn)行,并提供GUI界面供用戶設(shè)置系統(tǒng)運(yùn)行所需配置信息。系統(tǒng)各模塊具體定義如表1所示。源端的實(shí)現(xiàn)
表1 系統(tǒng)模塊定義
源數(shù)據(jù)端運(yùn)行存儲(chǔ)過程DBXS_LOGDUMP將Oracle數(shù)據(jù)庫最新自動(dòng)歸檔的Redo日志文件利用Oracle日志分析工具LOGMINER進(jìn)行解析,并將結(jié)果存入歸檔日志文件同名的表中,然后源數(shù)據(jù)端程序(DBXSd)將讀取存入數(shù)據(jù)庫的解析結(jié)果,并將相關(guān)數(shù)據(jù)庫的DML語句按照在控制端配置的數(shù)據(jù)映射關(guān)系進(jìn)行轉(zhuǎn)換,并以XML文件的格式進(jìn)行保存,在數(shù)據(jù)交換時(shí)間到達(dá)時(shí)以FTP方式上傳目標(biāo)數(shù)據(jù)端。源端用例關(guān)系如圖1所示。
源數(shù)據(jù)端主要功能包括:SQL語句分析,通過Flex編寫詞法解析器,解析并重構(gòu)符合OTL接口標(biāo)準(zhǔn)的SQL語句;創(chuàng)建XML文件,將構(gòu)造好的SQL語句依據(jù)控制端的表項(xiàng)映射倒入到一個(gè)XML文件中;Oracle數(shù)據(jù)庫訪問,訪問Oracle數(shù)據(jù)庫,從控制端讀取同步參數(shù)(包括握手參數(shù)、時(shí)間參數(shù)和回滾參數(shù)等);客戶端功能,向目標(biāo)端上傳構(gòu)造好的含有SQL語句的XML文件。
圖1 源端用例關(guān)系
源數(shù)據(jù)端數(shù)據(jù)庫存儲(chǔ)過程包括:自動(dòng)歸檔Redo日志和調(diào)用LogMiner解析最新歸檔的Redo日志。源端的輸入為經(jīng)過LOGMINER所解析的歸檔日志,表的字段為:SCN,TIMESTAMP,SEG_OWNER,SEG_NAME,ROW_ID,SQL_REDO。表名稱同其對應(yīng)的歸檔日志名稱同名。DBXSd將從Redo日志解析中獲取的結(jié)果,根據(jù)控制端配置的表映射信息進(jìn)行轉(zhuǎn)換,將轉(zhuǎn)換結(jié)果以XML文件的形式輸出。
文件中的SQL語句按照其SCN號從小到大依次排列:
例:
源端流程邏輯即DBXS_LOGDUMP存儲(chǔ)過程如圖2所示,其過程如下:首先讀取DBXS.OM表,獲取系統(tǒng)執(zhí)行數(shù)據(jù)交換起始時(shí)間。判斷系統(tǒng)時(shí)間是否大于數(shù)據(jù)交換起始時(shí)間,如果不大于則等待。當(dāng)系統(tǒng)時(shí)間大于數(shù)據(jù)交換起始時(shí)間時(shí)讀取DBXS.ARCHIVED_FILE表,判斷從數(shù)據(jù)交換起始時(shí)間到系統(tǒng)時(shí)間段日志是否已經(jīng)被解析。如果未被解析,檢索V$Archived_log視圖,獲取從數(shù)據(jù)交換起始時(shí)間到系統(tǒng)時(shí)間的所有歸檔日志。調(diào)用LOGMINER將歸檔日志解析,存入歸檔日志同名表中,并將表名稱和相關(guān)數(shù)據(jù)結(jié)果存入DBXS.DBXS_ARCHIVED_FILE中。如果已經(jīng)被解析,判斷是否有新的歸檔日志產(chǎn)生。新的歸檔日志產(chǎn)生時(shí)繼續(xù)執(zhí)行前面的LOGMINER日志解析步驟的內(nèi)容進(jìn)行日志解析。判斷是否已經(jīng)到了系統(tǒng)數(shù)據(jù)交換執(zhí)行時(shí)間,或數(shù)據(jù)立即交換標(biāo)志生效,如果滿足以上兩條件之一,則運(yùn)行Archive log switch強(qiáng)行生成歸檔日志。
圖3 源端程序流程
圖4 目標(biāo)端用例關(guān)系
圖5 目標(biāo)端流程邏輯
DBXS程序流程如圖3,其過程如下:如果DBXS.DUMP_FILE中內(nèi)容為空,則獲取DBXS.OM中的系統(tǒng)執(zhí)行數(shù)據(jù)交換起始時(shí)間,將DBXS.ARCHIVED_FILE中所有BEGIN_TIME大于數(shù)據(jù)交換起始時(shí)間的歸檔日志記錄進(jìn)行抽取映射轉(zhuǎn)換,并存為XML文件。如果DBXS.DUMP_FILE中內(nèi)容不為空,獲取DBXS.DUMP_FILE中最大的END_SCN,然后將DBXS.ARCHIVED_FILE中,BEGIN_SCN大于END_SCN的歸檔日志記錄進(jìn)行抽取映射轉(zhuǎn)換,并存為XML文件。如果DBXS.OM表中MAP_ID發(fā)生轉(zhuǎn)變,則清空DBXS.DUMP_FILE中該ID對應(yīng)的時(shí)間不小于數(shù)據(jù)交換起始時(shí)間記錄,并刪除相應(yīng)文件,然后將DBXS.ARCHIVED_FILE中從數(shù)據(jù)交換起始時(shí)間到當(dāng)前時(shí)間的記錄進(jìn)行轉(zhuǎn)換。數(shù)據(jù)交換執(zhí)行時(shí)間到達(dá)時(shí)或數(shù)據(jù)交換立即執(zhí)行命令下發(fā)后,將DBXS.DUMP_FILE表中記錄從數(shù)據(jù)交換起始時(shí)間到執(zhí)行時(shí)間的XML文件和歸檔文件上傳到指定的FTP目錄,并在上傳完成后,將上傳的文件路徑寫入DBXD.UPLOAD表中,并將DBXS.OM表中的EXCHANGE_START_TIME設(shè)置為此次交換起始時(shí)間,EXCHANGE_EXE_TIME設(shè)為下次交換起始時(shí)間。SQL語句的轉(zhuǎn)換時(shí),對于insert語句要增加對BUREAU_ID和ROW_ID字段的插入,對于update和delete語句要加入判斷BUREAU_ID和ROW_ID這兩個(gè)字段的判斷,且要將其轉(zhuǎn)換為帶參數(shù)的SQL語句。目標(biāo)端的實(shí)現(xiàn)
目標(biāo)數(shù)據(jù)端主要負(fù)責(zé)在數(shù)據(jù)交換時(shí)間到達(dá)時(shí),讀取源端程序上傳的XML文件,將其反向解析為SQL語句,并執(zhí)行入庫。目標(biāo)端用例關(guān)系圖,如圖4所示。
目標(biāo)端的主要功能包括:創(chuàng)建DBXD數(shù)據(jù)庫,解析XML文件和入庫操作。目標(biāo)端(DBXDd)輸入項(xiàng)為DBXSd程序上傳的XML文件。目標(biāo)端流程邏輯如圖5所示。程序初始運(yùn)行時(shí),判斷UPLOAD表是否為空,如果不為空,將里面剩余數(shù)據(jù)分析完畢。在數(shù)據(jù)交換時(shí)間到達(dá)時(shí),訪問UPLOAD表,獲取源數(shù)據(jù)端上傳的XML文件,進(jìn)行解析入庫,在解析入庫前將OM表SYS_STATUS字段置為DBX_SYS_STATUS_EXCHANGING,入庫完成后將字段重新置為DBX_SYS_STATUS_IDLE,并將EXCHANGE_EXEC_TIME置為下次數(shù)據(jù)交換時(shí)間??刂贫说膶?shí)現(xiàn)
控制端程序主要負(fù)責(zé)提供圖形化的數(shù)據(jù)映射關(guān)系增刪改操作界面(由于源端與目標(biāo)端對應(yīng)表的字段可能不一致,需要手工確定映射關(guān)系)??刂贫擞美P(guān)系圖如圖6所示。
控制端的流程邏輯包括:程序運(yùn)行時(shí),通過用戶輸入獲取目標(biāo)端數(shù)據(jù)庫的信息后,連接目標(biāo)端數(shù)據(jù)庫,讀取DBXD.SOURCE表獲取源數(shù)據(jù)庫的信息。通過DBXD.SOURCE表獲取源數(shù)據(jù)庫的信息可以訪問各個(gè)源數(shù)據(jù)庫DBXS.MAP_TABLE和DBXS.MAP_FIELD獲取已經(jīng)配置的映射信息。
控制端所需操作的表和字段說明如下:
圖6 控制端用例
圖7 數(shù)據(jù)同步系統(tǒng)部署
(1) 數(shù)據(jù)交換時(shí)間設(shè)置:用戶設(shè)置數(shù)據(jù)交換時(shí)間后,控制端需要將DBXS.OM和DBXD.OM的EXCHANGE_EXEC_TIME填入用戶設(shè)置數(shù)據(jù)交換時(shí)間。
(2) 數(shù)據(jù)立即交換觸發(fā):用戶觸發(fā)界面上數(shù)據(jù)立即交換按鈕后,控制端需要將DBXS.OM和DBXD.OM的EXCHANGE_EXEC_IMMEDIATE置位,并將EXCHANGE_EXEC_IMM_TIME字段設(shè)置上控制端當(dāng)前時(shí)間。
(3) 源數(shù)據(jù)端配置:用戶添加源數(shù)據(jù)端后,需將相關(guān)信息填入DBXD.SOURCE數(shù)據(jù)庫,和DBXS.OM的DEST_IP、DEST_USER、DEST_PASSWORD、FTP_USER、FTP_PASSWORD字段。
(4) 映射信息增刪改:用戶在控制端進(jìn)行映射信息的增刪改操作時(shí),將結(jié)果寫入DBXS.MAP_TABLE和DBXS.MAP_FIELD,并且將DBXS.OM表中的MAP_ID值修改。
(5) 日志顯示:通過讀取DBXS.OM和DBXD.OM可以獲取當(dāng)前系統(tǒng)運(yùn)行的日志信息。
(6) 同步控制:通過判斷DBXD.OM的SYS_STATUS字段可以判斷系統(tǒng)當(dāng)前是否正在進(jìn)行同步。
數(shù)據(jù)同步系統(tǒng)部署圖,如圖7所示,系統(tǒng)中主要包含用于實(shí)現(xiàn)控制的控制端及其數(shù)據(jù)庫、源端程序及數(shù)據(jù)庫、目標(biāo)端程序及數(shù)據(jù)庫。
本次數(shù)據(jù)交換系統(tǒng)源端與目標(biāo)端程序均采用服務(wù)進(jìn)程的方式運(yùn)行于系統(tǒng)后臺(tái),控制端程序負(fù)責(zé)遠(yuǎn)程初始化源端程序的數(shù)據(jù)交換時(shí)間、交換數(shù)據(jù)表的映射關(guān)系設(shè)置和交換數(shù)據(jù)的有效起始時(shí)間等參數(shù)。數(shù)據(jù)交換系統(tǒng)的實(shí)驗(yàn)結(jié)果如表2所示。
表2 數(shù)據(jù)交換系統(tǒng)實(shí)驗(yàn)結(jié)果
為了提高系統(tǒng)運(yùn)行效率和性能,系統(tǒng)對數(shù)據(jù)抽取和轉(zhuǎn)換不是通過數(shù)據(jù)表復(fù)制來實(shí)現(xiàn),而是通過在數(shù)據(jù)源端每小時(shí)調(diào)用一次LOGMINER日志解析該時(shí)段的在線REDO日志,然后將解析結(jié)果入庫,入庫結(jié)果再按照用戶在控制端設(shè)置,將語句中相關(guān)字段和數(shù)據(jù)進(jìn)行轉(zhuǎn)換,以XML文件保存,在用戶指定數(shù)據(jù)同步時(shí)間到達(dá)時(shí)(通過控制端設(shè)置),將XML文件上傳。目的端程序?qū)ML文件中的操作內(nèi)容存入Oracle數(shù)據(jù)庫指定表中,數(shù)據(jù)源端再提取日志存放表中原子操作內(nèi)容(即SQL語句)執(zhí)行,達(dá)到數(shù)據(jù)抽取和轉(zhuǎn)換的目的。
實(shí)驗(yàn)結(jié)果顯示日志文件規(guī)模直接影響到了數(shù)據(jù)交換系統(tǒng)的交換頻率和交換時(shí)間長度。日志文件規(guī)模較小時(shí),交換頻率偏高會(huì)影響到服務(wù)器日常工作(LogMiner的運(yùn)行會(huì)影響數(shù)據(jù)庫效率),但是日志文件規(guī)模設(shè)置較大時(shí),又會(huì)導(dǎo)致數(shù)據(jù)交換時(shí)間過長(必須在晚上非工作時(shí)間運(yùn)行)。根據(jù)實(shí)驗(yàn)結(jié)果,日志文件設(shè)置為50MB左右是比較合理而且頻率和交換時(shí)間都處在可以接受的水平。
在數(shù)據(jù)校園原有多重?cái)?shù)據(jù)孤島環(huán)境下開發(fā)數(shù)據(jù)交換系統(tǒng),面對的主要問題還是增量數(shù)據(jù)如何同步以及數(shù)據(jù)同步的效率問題。大校園環(huán)境下由于有多個(gè)校區(qū)存在,不能采用集中環(huán)境中那種靜態(tài)數(shù)據(jù)備份技術(shù),這種技術(shù)傳輸文件大,并且效率很低。因此增量數(shù)據(jù)同步成為唯一可行的方案。在基于Oracle數(shù)據(jù)庫系統(tǒng)中,增量數(shù)據(jù)同步就必須解決數(shù)據(jù)庫日志的解析以及增量數(shù)據(jù)在目標(biāo)計(jì)算機(jī)快速入庫的問題。利用LogMiner解析Oracle系統(tǒng)日志是實(shí)現(xiàn)分布式數(shù)據(jù)交換系統(tǒng)所要解決前提之一。對LogMiner解析出的日志進(jìn)行SQL語句分析重構(gòu)(針對目標(biāo)數(shù)據(jù)庫的快速入庫接口重構(gòu))是實(shí)現(xiàn)分布式數(shù)據(jù)同步系統(tǒng)要解決的前提之二。本文實(shí)現(xiàn)了數(shù)字校園網(wǎng)數(shù)據(jù)同步系統(tǒng)的技術(shù)問題及系統(tǒng)架構(gòu)問題,并給出了系統(tǒng)實(shí)現(xiàn)方案。