李 明 建

(瓦斯災(zāi)害監(jiān)控與應(yīng)急技術(shù)國家重點實驗室　重慶 400037)(中煤科工集團重慶研究院有限公司　重慶 400037)

0　引　言

隨著煤礦信息化、自動化水平的提高，特別是煤礦井下無線通信系統(tǒng)的推廣應(yīng)用，以智能手機為核心的礦用防爆手機在井下數(shù)據(jù)采集領(lǐng)域得到迅猛發(fā)展。當(dāng)前，礦用防爆手機的硬件技術(shù)已經(jīng)比較成熟，基于礦用防爆手機開發(fā)的應(yīng)用程序因其具體應(yīng)用場景不同而在功能需求上千差萬別，但都面臨一個共性問題：防爆手機應(yīng)用程序怎么與部署于地面的安全監(jiān)控系統(tǒng)、業(yè)務(wù)管理系統(tǒng)進行數(shù)據(jù)交換，既能在井下查詢地面存儲管理的已有信息，也能在井下采集上傳新信息。研發(fā)適用于以偶爾連接為特征的礦用防爆手機數(shù)據(jù)同步組件，降低專業(yè)應(yīng)用程序開發(fā)技術(shù)難度、減少開發(fā)工作量，因而具有較高的工程研究和應(yīng)用價值。

基于防爆手機的數(shù)據(jù)同步組件，至少應(yīng)滿足兩個基本要求：適應(yīng)偶爾連接的網(wǎng)絡(luò)環(huán)境；適應(yīng)受限本機硬件資源環(huán)境。筆者所在單位研發(fā)的瓦斯災(zāi)害監(jiān)控預(yù)警系統(tǒng)(以下簡稱監(jiān)控預(yù)警系統(tǒng))中多類信息通過礦用防爆手機采集。監(jiān)控預(yù)警系統(tǒng)以安全監(jiān)控系統(tǒng)提供的在線監(jiān)測信息、檢測裝備測定的離線檢測信息、防爆手機在井下采集的日常預(yù)測及觀測信息為基礎(chǔ)，以預(yù)警指標(biāo)和預(yù)警模型為核心，計算分析井下特定區(qū)域瓦斯災(zāi)害危險度，進而實現(xiàn)瓦斯災(zāi)害超前預(yù)警[1]。其中基于防爆手機的各類應(yīng)用程序，一般設(shè)計為偶爾連接網(wǎng)絡(luò)，因為在煤礦井下采掘工作面很少能有無線信號覆蓋，僅在主要大巷、變電所、井底車場等位置可以連接到井下通信環(huán)網(wǎng)，進而訪問位于地面的監(jiān)控預(yù)警服務(wù)器。近年來隨著無線通信技術(shù)的飛速發(fā)展，防爆手機雖然在存儲、計算、網(wǎng)絡(luò)帶寬及系統(tǒng)可靠性等方面有了長足的發(fā)展，但與臺式電腦、筆記本甚至普通智能手機相比，仍然有較大的差距。同時由于防爆檢測、安標(biāo)檢測費用較高、周期較長，防爆手機一旦定型后硬件升級改進成本較高，導(dǎo)致其硬件配置水平遠低于主流普通智能手機，因此在設(shè)計基于防爆手機的數(shù)據(jù)同步組件時，必須充分考慮其存儲能力、計算能力、網(wǎng)絡(luò)傳輸速率等關(guān)鍵指標(biāo)。

1　數(shù)據(jù)同步概述

1.1　數(shù)據(jù)同步原理及方法

數(shù)據(jù)同步在理論上比較簡單: 它是在適當(dāng)時間在兩個或更多參與者之間復(fù)制正確的數(shù)據(jù)集的過程[1]。但在軟件實現(xiàn)過程中仍然存在眾多技術(shù)難點，特別是分布式異構(gòu)數(shù)據(jù)同步場景，包括：集成不同類型的數(shù)據(jù)；與能力不盡相同或者要求數(shù)據(jù)的不同子集的參與者合作；適應(yīng)不可靠網(wǎng)絡(luò)等。數(shù)據(jù)同步首先需要解決數(shù)據(jù)變化捕獲問題，目前常用的數(shù)據(jù)變化捕獲有快照法、觸發(fā)器法、日志法、API法、影子表法、時間戳法、變更軌跡法。這些變化捕獲方法雖各有優(yōu)點，但都有一定的局限性[2]。

分布式數(shù)據(jù)庫是利用計算機網(wǎng)絡(luò)、分布式計算、同步技術(shù)等將物理上分散的多個數(shù)據(jù)庫連接起來組成一個邏輯上統(tǒng)一的數(shù)據(jù)庫。其基本特點包括：物理分散性、邏輯整體性、節(jié)點自治性、數(shù)據(jù)透明性等[3]。當(dāng)前實現(xiàn)分布式異構(gòu)數(shù)據(jù)庫同步的方法主要有三種：(1) 內(nèi)置同步法，使用數(shù)據(jù)庫內(nèi)置同步功能，部署簡單，可靠性高，但一般不支持不同類型和不同版本數(shù)據(jù)庫之間的同步，不能二次開發(fā)，個性化定制需求難以實現(xiàn)；(2) 中心同步法，中心數(shù)據(jù)庫存儲所有分布數(shù)據(jù)庫的數(shù)據(jù)總和，各分布數(shù)據(jù)庫通過中心數(shù)據(jù)庫中轉(zhuǎn)同步，但中心數(shù)據(jù)庫龐大，邏輯復(fù)雜，效率較低；(3) 對等同步法，任意數(shù)據(jù)庫之間是對等關(guān)系，通過使用SOAP、XML或者一些成熟的數(shù)據(jù)同步框架進行數(shù)據(jù)交互，實現(xiàn)異構(gòu)數(shù)據(jù)庫之間同步[4]。本文重點研究偶爾連接環(huán)境下防爆手機與地面SQL Server數(shù)據(jù)同步，采用基于數(shù)據(jù)同步框架的中心同步法是合適的。

1.2　典型數(shù)據(jù)同步框架

(1) SyncML(Synchronization Markup Language)是一種基于XML、平臺無關(guān)的數(shù)據(jù)同步協(xié)議，最早由SyncML initiative發(fā)布，后來該組織融入到開放移動聯(lián)盟OMA(Open Mobile Alliance)，成為其下設(shè)的數(shù)據(jù)同步工作組(Data Synchronization Working Group)，繼續(xù)負(fù)責(zé)SyncML數(shù)據(jù)同步的標(biāo)準(zhǔn)化工作。2011年OMA發(fā)布OMA Data Synchronization V2.0標(biāo)準(zhǔn)。

(2) Microsoft Sync Framework(微軟同步框架，簡稱Sync Framework)是微軟公司研發(fā)的數(shù)據(jù)同步組件，用于SQL Server與SQL Server、SQL Server Express、SQL Server Compact、SQLite等數(shù)據(jù)庫同步，并可以開發(fā)自定義數(shù)據(jù)同步提供程序，以IIS或Windows 應(yīng)用程序為宿主，通過數(shù)據(jù)同步服務(wù)接口與其他數(shù)據(jù)源進行同步。Sync Framework具有結(jié)構(gòu)合理、配置靈活、適應(yīng)能力強、可擴展性好、持續(xù)技術(shù)支持等特點，現(xiàn)已成為SQL Server內(nèi)置數(shù)據(jù)同步組件的核心，得到廣泛應(yīng)用。

Sync Framework可擴展性強，具有良好的程序接口，且可選擇使用二進制方式傳輸同步消息，傳輸效率較使用XML方式的SyncML高，通過ADO.NET可快速擴展至Windows客戶端SQLite、SQL Server Express與SQL Server數(shù)據(jù)同步，符合監(jiān)控預(yù)警數(shù)據(jù)同步擴展需求，因此本文基于Sync Framework研發(fā)Android防爆手機數(shù)據(jù)同步組件。

2　數(shù)據(jù)同步框架簡介

2.1　SQL Server數(shù)據(jù)同步

微軟公司為以SQL Server為中心的數(shù)據(jù)同步提供了多種方案，如快照復(fù)制、合并復(fù)制、事務(wù)復(fù)制、對等事務(wù)復(fù)制[5]。其中適用于數(shù)據(jù)庫與數(shù)據(jù)庫間雙向同步的有兩種：(1) SQL Server對等事務(wù)復(fù)制同步，要求參與方必須為SQL Server企業(yè)版，而標(biāo)準(zhǔn)版、商業(yè)智能版及Web版均不具備此功能，同時要求參與方必須位于固定網(wǎng)絡(luò)環(huán)境，不適用于公網(wǎng)上一臺服務(wù)器與一臺運行于內(nèi)網(wǎng)的不可尋址的服務(wù)器間數(shù)據(jù)庫同步；(2) SQL Server合并復(fù)制同步，對服務(wù)器端SQL Server版本沒有限制，客戶端也可以是SQL Server、SQL Server Compact，但對于Android這樣的非SQL Server客戶端則必須借助微軟公司開發(fā)的Sync Framework才能實現(xiàn)數(shù)據(jù)同步。

礦用防爆手機一般使用開源的Android操作系統(tǒng)，在此基礎(chǔ)上開發(fā)的數(shù)據(jù)采集應(yīng)用程序普遍使用SQLite數(shù)據(jù)庫，且數(shù)據(jù)結(jié)構(gòu)與SQL Server主數(shù)據(jù)庫也可能不盡相同。以不同平臺、不同結(jié)構(gòu)為特征的異構(gòu)數(shù)據(jù)庫同步，對具有較強計算能力、固定網(wǎng)絡(luò)環(huán)境的服務(wù)器而言不是問題，但對于計算及存儲能力有限、偶爾連接網(wǎng)絡(luò)且使用Android系統(tǒng)的防爆手機來說，確實是一個挑戰(zhàn)。

SQL Server自2008版本開始，引入了兩種變更數(shù)據(jù)捕獲方案：更改跟蹤CT(Change Tracking)和變更數(shù)據(jù)捕獲CDC(Changing Data Capture)。這兩種方案均不需要修改用戶表結(jié)構(gòu)、自定義觸發(fā)器，也不需要增加影子表，即可記錄用戶對數(shù)據(jù)表的所有更改。雖然更改跟蹤只能記錄刪除行的主鍵而不是備份刪除行，但與變更數(shù)據(jù)捕獲相比，更改跟蹤并不限于SQL Server企業(yè)版，并能與Sync Framework結(jié)合，開發(fā)自定義同步提供程序，可以更高效地實現(xiàn)數(shù)據(jù)同步[6]。

2.2　Sync Framework實現(xiàn)原理與部署方式

Sync Framework最新版本為2.1，它既可以同步以SQL Server為中心的數(shù)據(jù)庫、同步文件系統(tǒng)，也可以自定義同步提供者實現(xiàn)非SQL Server數(shù)據(jù)庫間的數(shù)據(jù)同步，還可以通過Web數(shù)據(jù)服務(wù)方式實現(xiàn)Windows平臺Web數(shù)據(jù)同步。但上述同步模式需要服務(wù)器端和客戶端均有同步框架相應(yīng)版本組件的支持，這對于Windows電腦客戶端甚至基于Windows Phone的智能手機來說是可行的，但對于當(dāng)前占主流的Android、IOS操作系統(tǒng)移動設(shè)備來說，則因缺少相應(yīng)同步客戶端組件支持而變得困難。為了解決Android、IOS系統(tǒng)客戶端的跨平臺數(shù)據(jù)同步問題，微軟公司在Sync Framework基礎(chǔ)上，研發(fā)了用以支持非對稱同步交換的Sync Framework Toolkit 4.0，將所有同步處理邏輯移至服務(wù)器端，客戶端通過簡單的HTTP調(diào)用即可實現(xiàn)數(shù)據(jù)同步。

Sync Framework數(shù)據(jù)同步實現(xiàn)過程為：首先由數(shù)據(jù)接收方發(fā)起同步會話請求，并建立起網(wǎng)絡(luò)連接；數(shù)據(jù)提供方接收到會話請求后，查找自身副本所儲存的元數(shù)據(jù)，然后將元數(shù)據(jù)傳送給數(shù)據(jù)接收方；數(shù)據(jù)接收方對比本地元數(shù)據(jù)和提供方元數(shù)據(jù)，確定需要更新的數(shù)據(jù)，并將其發(fā)送到數(shù)據(jù)提供方；提供方收到需要更新的數(shù)據(jù)后，將對應(yīng)元數(shù)據(jù)信息發(fā)送給數(shù)據(jù)接收方進行比較是否有數(shù)據(jù)沖突；經(jīng)沖突檢測后，數(shù)據(jù)接收方正式請求接收更新數(shù)據(jù)，數(shù)據(jù)提供方接收請求并發(fā)送數(shù)據(jù)至接收端，接收端接收到數(shù)據(jù)并更新至數(shù)據(jù)庫，從而完成同步會話[8]。

從部署角度來說，Sync Framework支持脫機模式和協(xié)作模式，如圖1所示。中心同步方案：在客戶端-服務(wù)器拓?fù)渲?，多個客戶端連接到一個中心服務(wù)器，以便在連接可用時同步數(shù)據(jù)。對等同步方案：多個數(shù)據(jù)庫可以通過對等方式進行同步，而無需通過中心服務(wù)器，前提條件是所有參與方必須處于固定網(wǎng)絡(luò)環(huán)境。

圖1　Sync Framework兩種部署模式

3　數(shù)據(jù)同步設(shè)計與實現(xiàn)

3.1　數(shù)據(jù)同步總體方案

監(jiān)控預(yù)警系統(tǒng)由多個子系統(tǒng)組成，其中防突動態(tài)管理是其中采集離線數(shù)據(jù)較多的子系統(tǒng)。防突動態(tài)管理子系統(tǒng)主要通過防爆手機采集防突工作面執(zhí)行防突措施、局部預(yù)測、效果檢驗過程中所能人工觀測、儀器測量的各種信息，在井下或地面有WIFI信號時與監(jiān)控預(yù)警服務(wù)器進行數(shù)據(jù)同步；同時防突動態(tài)管理電腦客戶端也會修改數(shù)據(jù)庫信息，例如：防突工作面基礎(chǔ)信息、區(qū)域措施效果檢驗信息、局部措施設(shè)計信息等。因此防爆手機上的防突信息采集數(shù)據(jù)庫與服務(wù)器數(shù)據(jù)庫間存在雙向同步的需求。

根據(jù)上述業(yè)務(wù)場景分析，防突動態(tài)信息數(shù)據(jù)同步總體方案如下：在服務(wù)器端數(shù)據(jù)庫中，啟用SQL Server 2012的更改跟蹤以記錄服務(wù)器數(shù)據(jù)更改；在防爆手機SQLite數(shù)據(jù)庫中，使用觸發(fā)器及影子表記錄客戶端所有數(shù)據(jù)更改，在網(wǎng)絡(luò)可用時通過無線基站發(fā)起同步請求；同步服務(wù)器端使用WCF開發(fā)數(shù)據(jù)同步服務(wù)，接收來自防突信息采集App的數(shù)據(jù)同步請求，并與服務(wù)器端數(shù)據(jù)庫進行同步，返回防突信息采集App。數(shù)據(jù)同步總體流程如圖2所示。

圖2　防爆手機數(shù)據(jù)同步總體流程圖

3.2　服務(wù)器端變更數(shù)據(jù)捕獲方案

根據(jù)前面對SQL Server更改跟蹤和變更數(shù)據(jù)捕獲兩種技術(shù)比較，結(jié)合瓦斯災(zāi)害監(jiān)控預(yù)警系統(tǒng)中離線數(shù)據(jù)采集環(huán)境特征，本文選用更改跟蹤來記錄SQL Ser-ver主數(shù)據(jù)庫的增量數(shù)據(jù)更改。雖然更改跟蹤只能記錄哪些數(shù)據(jù)行已被修改，而不能記錄修改過程軌跡，但對于防爆手機這樣的偶爾連接參與者的同步要求已經(jīng)足夠。對用戶表啟用更改跟蹤主要腳本如下：首先對數(shù)據(jù)庫啟用更改跟蹤；其次對需要同步的數(shù)據(jù)表，啟用更改跟蹤；在需要查詢更改行時，使用更改跟蹤函數(shù)獲取更改。

現(xiàn)以防突動態(tài)信息數(shù)據(jù)庫OIMSJMYM2015及其中的工作面信息表MOBI_WorkFace為例(其結(jié)構(gòu)如表1所示)說明使用更改跟蹤獲取變更數(shù)據(jù)的過程。

表1　MOBI_WorkFace表結(jié)構(gòu)

(1) 啟動并配置更改跟蹤

?對數(shù)據(jù)庫啟用更改跟蹤，開啟自動清理，數(shù)據(jù)保存期為兩天。

ALTER DATABASE OIMSJMYM2015 SET CHANGE_TRACKING = ON

(AUTO_CLEANUP = ON, CHANGE_RETENTION = 2 DAYS);

?對表啟用更改跟蹤，跟蹤列更新。

USE OIMSJMYM2015;

ALTER TABLE dbo. MOBI_WorkFace ENABLE CHANGE_TRACKING

WITH (TRACK_COLUMNS_UPDATED = ON);

(2) 獲取變更數(shù)據(jù)行

?通過SQL Server內(nèi)置的CHANGETABLE函數(shù)獲取更改數(shù)據(jù)記錄表，從中查詢本表自上次同步以來的所有更改數(shù)據(jù)行。

DECLARE @last_sync_version BIGINT;

SET @last_sync_version = CHANGE_TRACKING_MIN_VALID_VERSION (OBJECT_ID (′dbo.MOBI_WorkFace′));

SELECT CT.UID,WF.FaceName,WF.FaceType,

CHANGE_TRACKING_IS_COLUMN_IN_MASK (

COLUMNPROPERTY (OBJECT_ID (′dbo.MOBI_WorkFace′),′FaceName′,′ColumnId′),

CT.SYS_CHANGE_COLUMNS

) AS NameIsChanged,

CHANGE_TRACKING_IS_COLUMN_IN_MASK (

COLUMNPROPERTY (OBJECT_ID (′dbo.MOBI_WorkFace′),′FaceType′,′ColumnId′),

CT.SYS_CHANGE_COLUMNS

) AS TypeIsChanged,

CT.SYS_CHANGE_VERSION,

CT.SYS_CHANGE_OPERATION,

CT.SYS_CHANGE_COLUMNS

FROM dbo.MOBI_WorkFace AS WF, CHANGETABLE (CHANGES dbo.MOBI_WorkFace, @last_sync_version) AS CT

WHERE WF.UID = CT.UID

上述SQL語句運行結(jié)果如圖3所示，其中：NameIsChanged記錄源表FaceName字段是否更新；TypeIsChanged記錄源表FaceType字段是否更新；SYS_CHANGE_VERSION記錄操作版本號；SYS_CHANGE_OPERATION有三種取值: I、U、D，對應(yīng)的DML操作為INSERT、UPDATE和DELETE；SYS_CHANGE_COLUMNS為受UPDATE操作影響的字段編碼[9]。

圖3　MOBI_WorkFace更改行查詢結(jié)果

3.3　防爆手機端SQLite變更數(shù)據(jù)捕獲方案

SQLite是基于C語言開發(fā)的輕量級進程內(nèi)嵌入式數(shù)據(jù)庫引擎，完全遵守ACID準(zhǔn)則，具有開源免費、單一文件、零配置、資源占用率低、可移植性好、開發(fā)接口豐富等特點[10]。自2000年發(fā)布以來，在各類嵌入式設(shè)備中得到廣泛應(yīng)用，現(xiàn)已發(fā)布SQLite 3版本。適用于SQLite數(shù)據(jù)庫的更改跟蹤方法有“觸發(fā)器+控制表”法和附加API法捕獲待提交事務(wù)，但后者實現(xiàn)均在應(yīng)用程序內(nèi)部，導(dǎo)致數(shù)據(jù)庫可移植性差，且無法捕獲不經(jīng)過應(yīng)用程序執(zhí)行的數(shù)據(jù)更改，因此本文采用“觸發(fā)器+控制表”法捕獲SQLite數(shù)據(jù)更改，具體實現(xiàn)如下：

(1) 在SQLite數(shù)據(jù)庫新建一張ScopeInfoTable表，用以記錄同步域名稱、同步服務(wù)地址、最后同步時間以及需要同步的用戶表名稱。

(2) 為每張需要同步的用戶表創(chuàng)建三個觸發(fā)器，分別在After Insert、After Delete、After Update時點記錄對用戶表的所有更改操作，并保存于與用戶表對應(yīng)的更改控制表中。但更改控制表并非記錄更改數(shù)據(jù)行的所有字段，而僅記錄更改數(shù)據(jù)行的主鍵、更改操作類型、最后修改時間等信息，其結(jié)構(gòu)如表2所示。

表2　SQLite更改控制表結(jié)構(gòu)

3.4　防爆手機端與服務(wù)器交換更改數(shù)據(jù)

防爆手機端與服務(wù)器交換更改數(shù)據(jù)有兩種模式。第一種慢同步方案：首先在同步服務(wù)器生成SQLite數(shù)據(jù)庫構(gòu)架，后續(xù)同步過程中，通過Web Service傳遞更改數(shù)據(jù)集、通過Web Service傳遞壓縮后的SQLite數(shù)據(jù)庫(壓縮率可達90%以上，同時SQLite數(shù)據(jù)庫存儲密度非常高)至服務(wù)器執(zhí)行同步，再將同步后的數(shù)據(jù)庫下載至防爆手機端覆蓋工作數(shù)據(jù)庫，從而實現(xiàn)同步。第二種增量同步方案：初始化SQLite數(shù)據(jù)庫構(gòu)架在服務(wù)器端，防爆手機端從服務(wù)器下載數(shù)據(jù)庫以后，在同步時直接通過HTTP請求，以O(shè)Data的JSON格式上傳更新、下載更新、協(xié)調(diào)沖突。第一種方案可以簡單有效對應(yīng)質(zhì)量較差的網(wǎng)絡(luò)環(huán)境，但同步效率有待不高，而第二種方案雖然實現(xiàn)復(fù)雜，但僅上傳下載增量數(shù)據(jù)，在地面局域網(wǎng)環(huán)境下可以提高同步效率。

考慮井下通過無線基站接入通信環(huán)網(wǎng)穩(wěn)定性較差、SQLite數(shù)據(jù)庫存儲密度較高等因素，本文采用第一種慢同步方案，在完成SQLite數(shù)據(jù)庫初次下載以后，一次同步分為三個步驟：壓縮并通過Web Service上傳SQLite數(shù)據(jù)庫、在同步服務(wù)器上執(zhí)行SQLite數(shù)據(jù)庫與SQL Server數(shù)據(jù)庫同步、下載SQLite數(shù)據(jù)庫并解壓還原至工作數(shù)據(jù)庫位置。同步服務(wù)器根據(jù)SQL Server主數(shù)據(jù)庫的同步配置，創(chuàng)建SQLite數(shù)據(jù)庫構(gòu)架的流程如圖4所示。

圖4　同步服務(wù)器初始化SQLite數(shù)據(jù)庫構(gòu)架流程

3.5　同步提供者及同步服務(wù)程序?qū)崿F(xiàn)

Sync Framework同步框架自動生成對象關(guān)系模型實現(xiàn)需要同步數(shù)據(jù)表到實體類的映射，并由一個實體管理類KJEPOIMSDB_OfflineEntities進行整合，實體管理類以屬性字段方式記錄需要同步的數(shù)據(jù)表實體類。用戶自定義的數(shù)據(jù)同步服務(wù)類KJEPOIMSDB_SyncService 派生于抽象類Microsoft.Synchronization.Services.SyncService，并以實體管理類KJEPOIMSDB_OfflineEntities作為泛型模板參數(shù)，從而實現(xiàn)同步實體類的注入，并以靜態(tài)方法InitializeService初始化數(shù)據(jù)同步服務(wù)。在同步過程中通過OData生成REST風(fēng)格Http響應(yīng)，格式既可以選用JSON，也可以選用Atom?；诼椒桨傅姆辣謾C端App數(shù)據(jù)同步過程如圖5所示。其中初始化同步服務(wù)的主要代碼如下：

// 設(shè)置數(shù)據(jù)庫連接字符串，設(shè)置數(shù)據(jù)庫同步域及同步對象

//所有者

config.ServerConnectionString = ConfigurationManager.ConnectionStrings[″OIMSConn″].ConnectionString;

config.SetEnableScope(″DefaultScope″);

config.SetSyncObjectSchema(″dbo″);

// 設(shè)置沖突解決策略，是否允許跟蹤

config.SetConflictResolutionPolicy(ConflictResolutionPolicy.ServerWins);

config.EnableDiagnosticPage = true;

// 設(shè)置同步序列化格式為JSON，同步過程中批量下載最

//大為2M

config.SetDefaultSyncSerializationFormat(

SyncSerializationFormat.ODataJson);

config.SetDownloadBatchSize(20 * 2048);

圖5　防突信息采集App數(shù)據(jù)同步實驗效果圖

4　現(xiàn)場應(yīng)用

河南能化集團焦煤演馬莊礦使用鉆孔瓦斯涌出初速度q，鉆屑量S作為防突日常預(yù)測指標(biāo)，并輔以噴孔、頂鉆、夾鉆等現(xiàn)場觀測信息。上述日常預(yù)測、觀測信息由防突技術(shù)員在井下工作面通過防爆手機錄入；執(zhí)行突出危險性預(yù)測后，將防爆手機攜帶至采區(qū)變電所附近，通過其內(nèi)的WIFI無線通信基站接入井下通信環(huán)網(wǎng)，執(zhí)行防突信息采集App的數(shù)據(jù)同步，將日常預(yù)測和觀測信息上傳至地面的防突信息采集工作站，進入運行于監(jiān)控預(yù)警服務(wù)器上的防突動態(tài)信息數(shù)據(jù)庫；運行于局域網(wǎng)上的防突動態(tài)信息管理系統(tǒng)讀取加載上述信息，生成日常預(yù)測表單，打印后供相關(guān)技術(shù)領(lǐng)導(dǎo)簽字存檔。

根據(jù)2015年4月演馬莊礦現(xiàn)場實驗，對防突信息采集App增量同步模式和慢同步模式進行了對比分析(數(shù)據(jù)見表3實驗中初始化構(gòu)架階段使用的原始數(shù)據(jù)庫為635 KB，GZip壓縮后為72 KB)。結(jié)論如下：在初始化構(gòu)架階段均采用GZip壓縮技術(shù)，下載數(shù)據(jù)量相同，因此不存在顯著效率差異；在后續(xù)同步階段，慢同步模式仍然可以采用GZip壓縮技術(shù)，雖然每次同步均需要將整個數(shù)據(jù)庫壓縮后上傳下載，在數(shù)據(jù)量增長受限前提下(同步服務(wù)器端在生成防爆手機端數(shù)據(jù)庫時，可過濾過期數(shù)據(jù))，數(shù)據(jù)同步耗時比增量同步模式增加16.3%，但同步處理速度比增量同步模式高93.2%，分析原因得益于大粒度事務(wù)傳輸，開銷較低。演馬莊礦現(xiàn)場試實驗防突信息采集App運行效果如圖5所示。

5　結(jié)　語

本文基于Sync Framework設(shè)計開發(fā)了適用于Android防爆手機的數(shù)據(jù)同步組件，實現(xiàn)防突信息采集App與地面防突動態(tài)信息數(shù)據(jù)庫按需同步，與傳統(tǒng)直接編程實現(xiàn)數(shù)據(jù)上傳下載方式相比，具有以下優(yōu)勢：首先，SQLite數(shù)據(jù)庫由同步服務(wù)器根據(jù)SQL Server主數(shù)據(jù)庫的同步配置自動生成，簡化了SQLite數(shù)據(jù)表輔助字段、輔助表設(shè)計和維護工作量；其次，本方案與直接編碼實現(xiàn)上傳下載方式相比，數(shù)據(jù)同步事務(wù)粒度更大，具有受網(wǎng)絡(luò)質(zhì)量影響小、網(wǎng)絡(luò)異常后處理代價低等特點；最后，本方案將數(shù)據(jù)同步組件與業(yè)務(wù)數(shù)據(jù)庫解耦，實現(xiàn)數(shù)據(jù)同步組件復(fù)用，降低業(yè)務(wù)軟件開發(fā)工作量，符合軟件工程思想，可以推廣至基于防爆手機乃至普通Android手機數(shù)據(jù)采集App與SQL Server數(shù)據(jù)同步領(lǐng)域，具有比較廣泛的工程應(yīng)用前景。當(dāng)然，本文采用的慢同步方案會隨著SQLite數(shù)據(jù)庫容量增大而同步效率降低，如何提高同步效率尚有待進一步研究。

[1] 寧小亮. 煤與瓦斯突出災(zāi)害監(jiān)控預(yù)警技術(shù)[J]. 中國安全生產(chǎn), 2016(9): 50-51.

[2] 者敬. 開放式異構(gòu)數(shù)據(jù)庫復(fù)制框架的研究與實現(xiàn)[D].北京:中國科學(xué)院軟件研究所,2002:19-23.

[3] 申德榮,于戈. 分布式數(shù)據(jù)庫系統(tǒng)原理與應(yīng)用[M].北京:機械工業(yè)出版社,2011.

[4] 林源，陳志泊. 分布式異構(gòu)數(shù)據(jù)庫系統(tǒng)的研究與應(yīng)用[J]. 計算機工程與設(shè)計，2010，31( 24) 5278-5281.

[5] SQL Server Replication [EB/OL]. Microsoft MSDN library,2011 [2011-02-11]. https://msdn.microsoft.com/zh-cn/library/ms151198(v=sql.110).aspx#.

[6] Tracking Data Changes [EB/OL]. Microsoft MSDN library,2016 [2016-08-26].https://msdn.microsoft.com/en-us/library/bb933994.aspx#.

[7] 王麗君,李萌,徐卓然,等. 變化數(shù)據(jù)捕獲研究及基于SQL SERVER的開發(fā)與應(yīng)用[J]. 南華大學(xué)學(xué)報(自然科學(xué)版), 2011, 25(3): 78-82.

[8] 陳什,耿浩,朱巖. 基于MSF的數(shù)據(jù)庫同步技術(shù)在監(jiān)控系統(tǒng)中的應(yīng)用[J]. 微計算機應(yīng)用, 2011, 32(8): 57-61.

[9] CHANGETABLE [EB/OL]. Microsoft MSDN library, 2016 [2016-08-26]. https://msdn.microsoft.com/en-us/library/bb934145.aspx#.

[10] About SQLite [EB/OL]. SQLite Home, [2016-12-20]. https://www.sqlite.org/about.html.