張偉

（中國石化工程建設(shè)有限公司，北京100101）

目前很多公司應(yīng)用著各種管理信息系統(tǒng)MIS（Management Information System），大到企業(yè)級的ERP，小到部門級的出/考勤記錄程序。這些系統(tǒng)是隨著公司的信息化建設(shè)逐步建立和應(yīng)用起來的。MIS在辦公自動(dòng)化等方面為使用者提供了極大的便利，有些系統(tǒng)甚至成為管理工作中不可或缺的關(guān)鍵手段。因此，MIS的穩(wěn)定與高效已經(jīng)逐步成為各個(gè)崗位工作中至關(guān)重要的因素。

這些經(jīng)過多年開發(fā)與積累的應(yīng)用系統(tǒng)，由于各自獨(dú)立，自成一套的零散性制約著性能的發(fā)揮，同時(shí)增加了管理復(fù)雜度。系統(tǒng)過于分散也是安全風(fēng)險(xiǎn)增大的主要原因。將這些分散的應(yīng)用系統(tǒng)通過集群或是冗余的手段進(jìn)行集中，一方面可以發(fā)揮現(xiàn)有硬件的高性能，另一方面也可以集中管理系統(tǒng)，增加系統(tǒng)的穩(wěn)定性和安全性。因此，將分散的系統(tǒng)進(jìn)行整合是大勢所趨，也是提升整個(gè)公司或企業(yè)應(yīng)用水平的必然要求。

1 整合的目的與途徑

1.1 整合的目的

MIS的特點(diǎn)是緊隨公司或部門的管理模式與發(fā)展而進(jìn)行開發(fā)的，因而這些系統(tǒng)的開發(fā)與應(yīng)用是逐步積累起來的，同時(shí)隨著新部門和新業(yè)務(wù)的增加還會(huì)有新的系統(tǒng)逐漸上線。這種經(jīng)過多年積累開發(fā)的系統(tǒng)均比較獨(dú)立和分散，且系統(tǒng)的規(guī)模都不大，投入之初分配的硬件服務(wù)器都是性能較低的型號，隨著系統(tǒng)數(shù)量的逐步增加會(huì)出現(xiàn)大量的低端服務(wù)器塞滿機(jī)房的現(xiàn)象，這種現(xiàn)狀的出現(xiàn)會(huì)導(dǎo)致如下問題：硬件雖然占用數(shù)量多，但都配置落后，利用率低；系統(tǒng)分散，導(dǎo)致管理復(fù)雜度高，故障點(diǎn)多；管理賬號分散，安全風(fēng)險(xiǎn)大；沒有冗余設(shè)置，一旦系統(tǒng)出現(xiàn)問題，對工作的影響范圍較大。

為了保證每個(gè)系統(tǒng)的穩(wěn)定運(yùn)行，將上述問題引起的后果盡量降低，IT人員需要對這些系統(tǒng)進(jìn)行大量的軟硬件日常維護(hù)，盡管如此，依然會(huì)導(dǎo)致隨工作量在增加但應(yīng)用效率卻降低的現(xiàn)象出現(xiàn)。

1.2 整合的途徑

系統(tǒng)整合有兩種主要途徑：

1）完全由系統(tǒng)供應(yīng)商提供一攬子的解決方案，這些解決方案大都比較適合新開發(fā)的系統(tǒng)，而且主要針對銀行、電信等關(guān)鍵應(yīng)用部門。該種方案的特點(diǎn)：一次性資金投入量巨大，整合后的系統(tǒng)配置對管理人員的素質(zhì)和要求都極高，不符合大多數(shù)以管理系統(tǒng)為主的企業(yè)或公司的需求現(xiàn)狀。

2）各公司獨(dú)自利用已知的成熟技術(shù)和相關(guān)產(chǎn)品，在系統(tǒng)層面進(jìn)行應(yīng)用系統(tǒng)的整理和集中，實(shí)現(xiàn)初步的系統(tǒng)整合。該種整合方案雖然在技術(shù)層面不如系統(tǒng)集成商提供的方案全面，但非常貼近公司的實(shí)際，在應(yīng)用集成和業(yè)務(wù)集成的角度上更符合公司的目前需求。整合后的綜合性價(jià)比要遠(yuǎn)高于前者。

文中所描述的是第二種方案下的一種實(shí)現(xiàn)方法。

2 整合的范圍

2.1 整合范圍的選擇

系統(tǒng)整合范圍的選擇需要考慮的因素：

1）整合的目的。目的決定范圍的選擇方向。文中系統(tǒng)整合的主要任務(wù)是對上面提到的問題進(jìn)行解決，將零散的系統(tǒng)進(jìn)行合并，充分利用最新硬件資源，統(tǒng)一進(jìn)行系統(tǒng)管理，使用新技術(shù)提高系統(tǒng)的整體穩(wěn)定性。具體措施：

a）合并、優(yōu)化使用系統(tǒng)硬件，提高硬件的使用效率。

b）應(yīng)用服務(wù)器集群加Oracle的Data Guard實(shí)現(xiàn)整體提高系統(tǒng)可靠性。

c）平臺(tái)整合、集中管理，增強(qiáng)系統(tǒng)的可管理性。

2）需整合系統(tǒng)的特點(diǎn)。系統(tǒng)的特點(diǎn)決定著整合產(chǎn)品的技術(shù)方案和產(chǎn)品選擇。為了盡量將風(fēng)險(xiǎn)降低到最小，整合的范圍從滿足如下幾個(gè)條件中選擇：

a）需整合的系統(tǒng)采用的是同一或近似架構(gòu)開發(fā)的系統(tǒng)。

b）系統(tǒng)由同一家供貨商或開發(fā)商實(shí)現(xiàn)。

c）與其他系統(tǒng)的界面關(guān)系簡單。

d）進(jìn)行整合所采用的技術(shù)和產(chǎn)品成熟。

e）綜合考慮需整合系統(tǒng)的硬件利用現(xiàn)狀。

結(jié)合上述因素，有針對性地從已有的系統(tǒng)中選擇出整合的對象，見表1所列。

表1 需整合系統(tǒng)條件調(diào)查

從硬件利用狀態(tài)方面考慮范圍時(shí)的應(yīng)用示例（DB數(shù)據(jù)庫服務(wù)器，AS應(yīng)用服務(wù)器）見表2所列。

表2 需整合系統(tǒng)硬件條件調(diào)查

對通過綜合考慮選定的系統(tǒng)進(jìn)行整合可以保證系統(tǒng)的兼容性強(qiáng)，并且彼此之間的影響可以降到最低，整合實(shí)現(xiàn)的過程也會(huì)相對順利。

2.2 整合的內(nèi)容

目前大多數(shù)的MIS采用的都是B/S結(jié)構(gòu)，也就是服務(wù)器端由應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器組成，用戶只需要通過瀏覽器就能使用系統(tǒng)。該種架構(gòu)下的MIS要實(shí)現(xiàn)整體的整合，需要考慮應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器兩大部分。其內(nèi)容涉及如下三個(gè)方面：

1）將應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器從單一物理服務(wù)器分離。

2）整合數(shù)據(jù)庫服務(wù)，提高數(shù)據(jù)庫的安全性和穩(wěn)定性。

3）整合應(yīng)用服務(wù)，使資源利用高效。

3 整合的技術(shù)方案

3.1 數(shù)據(jù)庫服務(wù)器采用的方案

3.1.1 技術(shù)方案

需整合系統(tǒng)的數(shù)據(jù)庫都是采用Oracle，對Oracle進(jìn)行整合可以有三個(gè)選擇：雙機(jī)熱備、Data Guard方式以及RAC集群。表3是這三種方案的一個(gè)對比。

表3 數(shù)據(jù)庫整合方案對比

在已有軟、硬件條件下，結(jié)合MIS的使用特點(diǎn)，文中涉及系統(tǒng)的重點(diǎn)是可靠性（主要是容災(zāi)）和易管理程度，因而Data Guard方式是最適合的技術(shù)方案。

Data Guard是一款基于Oracle數(shù)據(jù)庫的熱備容災(zāi)產(chǎn)品，通過設(shè)置多臺(tái)后備數(shù)據(jù)庫服務(wù)器實(shí)現(xiàn)數(shù)據(jù)冗余來提供數(shù)據(jù)保護(hù)，并通過日志同步機(jī)制保證冗余數(shù)據(jù)和主數(shù)據(jù)之間的同步。如果是可預(yù)見因素需關(guān)閉Primary Database，比如軟硬件升級，可以把Standby Database切換為Primary Database繼續(xù)對外服務(wù)，這樣減少了服務(wù)停止時(shí)間，并且數(shù)據(jù)不會(huì)丟失。如果異常原因?qū)е翽rimary Database不可用，也可以把Standby Database強(qiáng)制切換為Primary Database繼續(xù)對外服務(wù)，從而實(shí)現(xiàn)業(yè)務(wù)高可用性，主要采用以下技術(shù)要點(diǎn)：

1）Data Guard采用物理Standby數(shù)據(jù)庫形式。

2）主庫日志發(fā)送采用LGWR進(jìn)程的ASYNC方式。

3）備庫啟用Standby Redo Log。

4）備庫日志應(yīng)用采用實(shí)時(shí)應(yīng)用（Real-time Apply）。

5）數(shù)據(jù)保護(hù)模式采用缺?。鹤罡咝阅埽∕aximum Performance）。

6）數(shù)據(jù)庫備份采用RMAN。

主庫每天進(jìn)行全庫備份（數(shù)據(jù)、控制文件、SPFILE和歸檔日志），同時(shí)刪除歸檔日志。

3.1.2 系統(tǒng)拓?fù)浣Y(jié)構(gòu)

系統(tǒng)實(shí)施整合后的拓?fù)浣Y(jié)構(gòu)如圖1所示。

3.2 應(yīng)用服務(wù)器采用的方案

3.2.1 技術(shù)方案

1）整合軟件和版本的選擇。需整合的三個(gè)系統(tǒng)都是J2EE框架，應(yīng)用服務(wù)器平臺(tái)產(chǎn)品采用的都是Web Logic，結(jié)合現(xiàn)有的硬件情況，應(yīng)用服務(wù)器的整合方案采用Web Logic集群是最佳選擇。

圖1 實(shí)施整合后的Oracle數(shù)據(jù)庫Data Guard拓?fù)浣Y(jié)構(gòu)示意

Web Logic的集群技術(shù)可以讓一組Server指向同一域名一起工作從而提供一個(gè)更強(qiáng)大、更可靠的應(yīng)用平臺(tái)。對于客戶端而言，無論集群中有幾個(gè)Server在工作，看上去都是一個(gè)。Web Logic集群提供的如下兩個(gè)主要性能非常適合MIS架構(gòu)的整合實(shí)現(xiàn)。

a）可伸縮性。集群對加入其中的Server在性能上沒有限制（如普通的PC機(jī)），為了提高性能，當(dāng)客戶端的請求大幅增加時(shí)，可以動(dòng)態(tài)地向集群中添加Server。并且集群支持當(dāng)一臺(tái)機(jī)器的資源沒有被完全利用時(shí)，可以在同一機(jī)器上啟動(dòng)多個(gè)Server。

b）高可用性。由于在集群中同一應(yīng)用在多個(gè)Server上同時(shí)存放或放在一個(gè)共享文件系統(tǒng)中，因而相同的請求可以有多個(gè)Server提供，并且Server間還可以復(fù)制狀態(tài)信息。這樣，當(dāng)其中某一Server宕機(jī)或無法響應(yīng)請求時(shí)，其他的Server會(huì)立即接管它的任務(wù)，用戶的應(yīng)用不受任何影響，從而把應(yīng)用和客戶端完全隔離開來。

2）服務(wù)器個(gè)數(shù)的確定主要是依據(jù)應(yīng)用系統(tǒng)的數(shù)量和物理服務(wù)器內(nèi)存的數(shù)量。此處的服務(wù)器是指Web Logic下的邏輯服務(wù)器，包括管理服務(wù)器、代理服務(wù)器以及被管服務(wù)器，以下所有出現(xiàn)“服務(wù)器”的地方均指這三類。硬件服務(wù)器本身將用“物理服務(wù)器”。

文中涉及的系統(tǒng)整合后將需要建立如下功能的Web Logic邏輯服務(wù)器：1臺(tái)管理服務(wù)器（Admin Server）；1臺(tái)代理服務(wù)器（Proxy Server）；4套應(yīng)用系統(tǒng)對應(yīng)Web Logic被管服務(wù)器。以每臺(tái)物理服務(wù)器的內(nèi)存為24 G，共有2臺(tái)為例：每臺(tái)物理服務(wù)器固定需要為操作系統(tǒng)預(yù)留2 G以上內(nèi)存，還需要?jiǎng)?chuàng)建Web Logic集群的管理服務(wù)器和用于集群分發(fā)的Proxy服務(wù)器，具體見表4所列。

表4 集群服務(wù)器內(nèi)存分配

表4中，每臺(tái)物理服務(wù)器為Web Logic保留可用的內(nèi)存數(shù)量約為20 G。

該方案符合WebLogic的官方要求，同時(shí)也滿足了系統(tǒng)配置靈活的要求。具體內(nèi)容：將每個(gè)被管服務(wù)器的內(nèi)存調(diào)整到2 G，根據(jù)每臺(tái)物理服務(wù)器可用的內(nèi)存數(shù)量（20 G），每臺(tái)物理服務(wù)器分別可以建立10個(gè)被管，兩臺(tái)共計(jì)20個(gè)被管服務(wù)器，考慮到預(yù)留，最終確定每臺(tái)物理服務(wù)器上創(chuàng)建8個(gè)Web Logic被管服務(wù)器用于系統(tǒng)發(fā)布，兩臺(tái)共計(jì)可創(chuàng)建16個(gè)，根據(jù)應(yīng)用的訪問特點(diǎn)分配給5個(gè)應(yīng)用系統(tǒng)。

3）應(yīng)用系統(tǒng)在服務(wù)器上的分配原則，見表5所列。

表5 應(yīng)用與被管服務(wù)器對應(yīng)關(guān)系

a）每個(gè)應(yīng)用分配2個(gè)以上被管服務(wù)器。

b）每套應(yīng)用系統(tǒng)中2個(gè)物理服務(wù)器各有副本。

c）Web Logic被管服務(wù)器按照應(yīng)用分別建立集群，之間不互相影響。

4）被管服務(wù)器命名與分配規(guī)則應(yīng)符合下列要求：

a）根據(jù)每個(gè)被管服務(wù)器分配的端口號規(guī)則。

b）所有奇數(shù)服務(wù)器分配到WEB-PRIM-SRV物理服務(wù)器上，偶數(shù)服務(wù)器分配到WEB-STANSRV物理服務(wù)器上。

5）代理服務(wù)器。整合后的系統(tǒng)是集群方式，用戶需要通過代理（Proxy）方式才能進(jìn)行訪問。代理服務(wù)器是整個(gè)網(wǎng)站系統(tǒng)的總?cè)肟?，它第一時(shí)間接受用戶的請求，通過應(yīng)用的別名轉(zhuǎn)給集群中的某個(gè)被管服務(wù)器。Proxy Server對集群的所有請求進(jìn)行負(fù)載均衡，并且當(dāng)請求失敗時(shí)會(huì)進(jìn)行恢復(fù)處理。為了系統(tǒng)穩(wěn)定，避免代理成為故障點(diǎn)，在設(shè)置Proxy時(shí)也要考慮冗余。

a）主Proxy Server。其是訪問集群應(yīng)用中的唯一入口，建議通過單獨(dú)的物理服務(wù)器實(shí)現(xiàn)。Proxy可以有硬件和軟件兩種實(shí)現(xiàn)。文中是通過安裝代理軟件，采用的是業(yè)界非常流行的配置Apache＋WLS的Apache Plugin。后期升級可以考慮通過購置專門代理硬件代替。

b）備用Proxy Server。通過在WEB-STANSRV上再單獨(dú)安裝1套Apache＋WLS-Plugin的方式作為主代理的備份，平時(shí)不需要啟動(dòng)。

3.2.2 系統(tǒng)拓?fù)浣Y(jié)構(gòu)

系統(tǒng)實(shí)施整合后的拓?fù)浣Y(jié)構(gòu)如圖2所示。

圖2 實(shí)施整合后的Web Logic集群系統(tǒng)拓?fù)浣Y(jié)構(gòu)示意

4 系統(tǒng)實(shí)現(xiàn)

技術(shù)方案確定后，在實(shí)現(xiàn)過程中有三個(gè)方面需重點(diǎn)關(guān)注：硬件的準(zhǔn)備；實(shí)施的順序；移植系統(tǒng)的調(diào)整。

4.1 硬件的準(zhǔn)備

硬件準(zhǔn)備需要結(jié)合待整合的系統(tǒng)進(jìn)行考慮：一種方法是根據(jù)軟件需求有針對性的進(jìn)行硬件配置；另一種是根據(jù)已有硬件性能盡可能多地整合已有零散系統(tǒng)。這兩種方法的目的都是為了更好地利用硬件性能，使系統(tǒng)的效率提高。文中的環(huán)境是先確定了需整合的系統(tǒng)數(shù)目，然后有針對地進(jìn)行硬件配置。

4.2 實(shí)施的順序

實(shí)施順序由簡單到復(fù)雜，由風(fēng)險(xiǎn)小到風(fēng)險(xiǎn)大的方式逐步進(jìn)行。原則上每一步都必須在上一步成功實(shí)施后才能開始。建議的整體實(shí)施順序如下：

1）數(shù)據(jù)庫系統(tǒng)整合。Data Guard實(shí)質(zhì)上是對已有數(shù)據(jù)庫系統(tǒng)進(jìn)行冗余配置，可以在不動(dòng)原有系統(tǒng)的情況下實(shí)現(xiàn)整合，在實(shí)施過程中對上線的業(yè)務(wù)幾乎沒有影響。在系統(tǒng)實(shí)現(xiàn)后，通過調(diào)整應(yīng)用服務(wù)器配置的數(shù)據(jù)庫連接池的參數(shù)，就可以直接使用，對用戶是完全透明的。

2）整合應(yīng)用服務(wù)器。主要工作是根據(jù)設(shè)計(jì)方案完成Web Logic集群系統(tǒng)的搭建。Web Logic集群軟件是一套非常成熟和應(yīng)用廣泛的系統(tǒng)。文中所采用的版本有一個(gè)相當(dāng)容易使用的配置向?qū)?，通過配置向?qū)Э梢钥焖俚赝瓿苫炯旱呐渲谩Ｔ诮⒓哼^程中需注意以下幾點(diǎn)：

a）集群中的所有物理服務(wù)器必須位于同一網(wǎng)段，并且必須是IP廣播（UDP）可到達(dá)的。

b）集群中的所有成員必須使用相同的版本，包括Service Pack。

c）集群中的物理服務(wù)器必須使用靜態(tài)IP地址。

d）集群配置后需要設(shè)置較多的代理服務(wù)器統(tǒng)一訪問。

3）依次遷移應(yīng)用系統(tǒng)。遷移應(yīng)用系統(tǒng)到集群應(yīng)該最先從框架近似、開發(fā)較晚的系統(tǒng)入手。在完成一個(gè)的基礎(chǔ)上再進(jìn)行下一個(gè)，這樣可以將問題簡單化，同時(shí)逐步積累經(jīng)驗(yàn)，避免走彎路。系統(tǒng)在遷移時(shí)需要注意以下幾點(diǎn)：

a）在集群上部署的方式。建議通過目錄的形式部署，而不是War包的形式。由于系統(tǒng)初步遷移，需要修改的地方很多，通過目錄方式可以簡化頻繁的修改和重新部署系統(tǒng)的步驟。但要注意的是，這種情況下需要手工保持不同物理主機(jī)上的目錄及其內(nèi)容的一致。

b）部署后的應(yīng)用訪問方式。單機(jī)系統(tǒng)的部署，多數(shù)情況下是直接通過根進(jìn)行訪問，但在集群下，多個(gè)系統(tǒng)通過代理服務(wù)器分發(fā)，必須通過別名。有些程序在編寫時(shí)比較嚴(yán)謹(jǐn)，代碼中都是通過規(guī)范的方式進(jìn)行引用，因而部署后通過修改配置文件可以順利通過別名進(jìn)行訪問。但有些系統(tǒng)在代碼中用到的都是絕對路徑，必須檢查源程序進(jìn)行修正以適應(yīng)集群環(huán)境下的訪問。

c）部署后的掃尾工作。系統(tǒng)遷移后需要保留一段過渡期，目的是為了系統(tǒng)測試和調(diào)整時(shí)有參照。在此期間，用戶已經(jīng)開始使用遷移后的系統(tǒng)，老系統(tǒng)主要用于IT和開發(fā)人員。系統(tǒng)過渡期內(nèi)應(yīng)在原系統(tǒng)的地址和端口上設(shè)置通知頁面（或進(jìn)行自動(dòng)跳轉(zhuǎn)），用戶可以逐步過渡到新系統(tǒng)上。

4.3 移植系統(tǒng)的調(diào)整

系統(tǒng)在整合前都是單服務(wù)器環(huán)境，整合后是多服務(wù)器的集群機(jī)制。這對于部署配置和程序的編寫有一定的特殊要求。在系統(tǒng)部署配置方面，由于采用的Web Logic集群的技術(shù)成熟，因而調(diào)整相對容易實(shí)現(xiàn)，主要是設(shè)置好Session的復(fù)制即可。但程序編寫中的調(diào)整比較耗時(shí)，需要注意以下幾個(gè)方面：

1）在單機(jī)環(huán)境中正常的功能在集群后出現(xiàn)了數(shù)據(jù)漂移，這是由程序編寫過程中出現(xiàn)的不嚴(yán)謹(jǐn)造成的，比如兩步提交就會(huì)造成數(shù)據(jù)的二義性。

2）Session復(fù)制失敗。Session復(fù)制失敗通常是由于網(wǎng)絡(luò)組播問題引起的，因而在配置組播的時(shí)候盡量避免與其他集群沖突。

3）在程序的編寫中確保Session中的數(shù)據(jù)必須是可序列化的，否則復(fù)制可能會(huì)失敗。比如不使用Http會(huì)話的Put Value和Remove Value方法，由于它們不受集群支持，并且在應(yīng)用程序中使用這些方法時(shí)，可能會(huì)出現(xiàn)會(huì)話數(shù)據(jù)復(fù)制問題，因而一致性的全部使用Http Session的Set Attribute和Remove Attribute方法。

4）靜態(tài)變量的使用以及緩存同步，EJB，Servlet，JSP同步等，在單機(jī)環(huán)境下不會(huì)發(fā)生變化的值在集群環(huán)境下有可能會(huì)發(fā)生變化。

以上對程序的調(diào)整與修改會(huì)經(jīng)歷比較長的時(shí)間，會(huì)對用戶的使用造成一定的影響。

5 結(jié)束語

系統(tǒng)整合是一項(xiàng)龐大的系統(tǒng)工程，涉及的方面遠(yuǎn)大于文中涉及的內(nèi)容。文中只是基于成熟的平臺(tái)軟件進(jìn)行系統(tǒng)集成的一種設(shè)計(jì)方案，該方案已經(jīng)在某大型工程公司的系統(tǒng)整合中使用，通過實(shí)際測試達(dá)到了預(yù)期目的，并取得了很好的效果。

［1］ GOPALAKRISHNAN K.Oracle Database 11g RAC手冊［M］.2版.賈洪峰，譯.北京：清華大學(xué)出版社，2012.

［2］ ARTIGES M.BEA Web Logic Server 8.1大全［M］.袁毅，談莉婭，宋燕紅，譯.北京：機(jī)械工業(yè)出版社，2005.

［3］ 胡利軍.Web集群服務(wù)器的負(fù)載均衡和性能優(yōu)化［D］.北京：北京郵電大學(xué)，2010.

［4］ 谷平反，趙軍.雙機(jī)環(huán)境下并行數(shù)據(jù)庫實(shí)現(xiàn)方式研究 ［J］.無線電工程，2003（09）：3-5.

［5］ 吳家祺.Web服務(wù)器集群系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［D］.南京：南京航空航天大學(xué)，2005.

［6］ 石開強(qiáng).集群Web代理服務(wù)器的設(shè)計(jì)［D］.成都：成都電子科技大學(xué)，2008.

［7］ 李俊青，周恩，符天.服務(wù)器集群及負(fù)載均衡的研究 ［J］.電腦知識與技術(shù)，2009，5（26）：4.

［8］ 碩珺.PC集群負(fù)載均衡調(diào)度策略研究［D］.北京：中國石油大學(xué)，2010.

［9］ 李長志.集群服務(wù)器系統(tǒng)負(fù)載均衡原理的分析與實(shí)現(xiàn)［J］.重慶郵電學(xué)院學(xué)報(bào)（自然科學(xué)版），2004（06）：10-11.

［10］ 朱晴.基于Oracle9i數(shù)據(jù)庫系統(tǒng)性能優(yōu)化［J］.電腦知識與技術(shù)，2007（12）：10-11.