鐵路中央主機系統遷移總體方案

杜 巍

（中國鐵路信息技術中心 信息工程部，北京 100844）

鐵路中央主機系統遷移總體方案

杜 巍

（中國鐵路信息技術中心 信息工程部，北京 100844）

通過對鐵路主機系統現狀分析，對開放平臺的架構設計、系統邏輯設計、應用移植技術、數據庫調優和系統實施運行等方面的研究，提出了系統遷移的總體方案。實現對鐵路中央主機系統的平臺架構、數據庫、數據和應用程序的完整、高效、安全的遷移。

遷移；主機；開放平臺；Oracle；數據遷移；并行

鐵路中央主機系統是TMIS的核心設備，運行著十多個重要的應用，保存了全路完整的貨票、確報、車號和集裝箱等主要信息。系統由3臺IBM大型機構成均為早年采購，至今已運行多年。IBM S/390系列主機為IBM第2代產品，早在2000年就退出銷售市場，在 2005年廠家就停止了市場保修服務。隨著時間的推移，主機系統日益老化，系統軟件已不能升級，設備備件沒有保障。整個主機系統的可靠性已經不能滿足當前運輸生產對信息保障需求，存在嚴重的安全生產隱患。為確保鐵路信息系統安全穩定運行，更好地為運輸生產經營服務，提高鐵路信息系統的可用性，對不能滿足應用需求的中央主機系統進行更新改造勢在必行。

1 系統分析與遷移目標

1.1 現狀分析

鐵路中央主機系統環境由主處理機、前置處理機、Web服務器等組成：主處理機負責運行數據庫、進行信息處理并為各種查詢請求提供服務；前置系統負責對來自全路各基層站段的各種運輸信息進行校驗和預處理，然后轉主機系統入庫處理，同時負責單項業務信息的收集、預處理和轉發；Web服務器接收來自終端用戶的各種業務查詢請求。

主處理機全部運行OS/390操作系統。系統應用全部基于DB2數據庫、C語言開發，主機上的應用程序對數據庫訪問基本上都是通過嵌入式C語言編程，存在少量的存儲過程；鐵路局到鐵路總公司中央系統、中央主機和前置系統之間的數據傳輸采用MQ中間件；B/S、C/S模式的應用，均通過DB2客戶端直連方式訪問數據庫；應用前置處理的開發主要基于C語言進行編程，Web應用有Java、ASP、.NET等編程語言實現。

1.2 遷移目標范圍

1.2.1 數據遷移

歷史數據遷移：主機歷史數據以文本文件形式保存在主機系統的虛擬磁帶庫中，實現指定數據從主機DB2到UNIX平臺Oracle數據庫的遷移。

聯機數據遷移：根據用戶要求，實現指定數據從主機DB2到UNIX平臺Oracle數據庫的無損遷移。根據Oracle數據庫特性，實現DB2到Oracle的數據類型轉換。

對遷移后的數據進行驗證，確保數據的一致性和完整性。

1.2.2 應用移植

完成目前運行于中央主機上基于DB2數據庫C語言研發的多個應用到UNIX平臺基于Oracle的C語言應用完整移植。

完成所有中央主機DB2數據庫客戶端應用(B/S、C/S)向Oracle的移植。

在確保應用功能一致的前提下，優化應用結構，提高應用性能。

2 技術方案設計

2.1 開放平臺架構

中央主機系統更新改造后，系統應采用4層模式（客戶端+Web服務器+應用處理層+數據庫層）。系統資源劃分為4個不同的層次，如圖1所示。

圖1 開放平臺架構圖

（1）數據庫層：保證應用數據庫的可靠性和可恢復性，保證為其用戶提供準確、唯一的數據和快速的數據訪問。（2）應用服務層：根據業務的需要建立相應的應用程序，處理業務邏輯和更改數據庫的數據。（3）接入訪問層：提供用戶接入和數據瀏覽的接口，客戶通過接入訪問層可以方便輕松的獲得其所需的信息。（4）客戶端：是客戶的數據操作層，該層主要是提供業務系統和使用者之間的接口。

2.2 系統邏輯架構

系統邏輯結構如圖2所示。

圖2 系統邏輯結構圖

（1）Web服務器群：利用多個刀片服務器作為應用前端Web服務器使用，根據性能和并發用戶聯接的需求，建立負載均衡服務器集群機制，保障性能和可靠性。 （2）應用服務器群：采用UNIX服務器作為應用和MQ通信服務器，每臺服務器建議配置32核CPU和128 GB內存，在每臺服務器上劃分多個分區，提供給貨票、確報、車號、集裝箱等系統的后端應用和MQ通信使用，通過HA集群技術實現高可用性，保障性能和可靠性。 （3）數據庫服務器群：采用2臺高端UNIX服務器作為數據庫服務器，每臺物理服務器建議配置64核CPU和512 GB內存，每臺物理服務器可劃分為多個分區。服務器通過2臺萬兆網絡交換機建立數據庫專用高速網絡，實現數據庫服務器之間的內部數據高速交換。分區服務器構成多節點的RAC，建立負載均衡服務器集群機制，提供高效、不間斷的數據庫服務。（4）存儲系統：配置2臺128口光纖交換機、2臺高端磁盤陣列、1臺虛擬磁帶庫，1臺高速磁帶庫，構建存儲網絡實現數據的高速訪問、可靠存儲。

2.3 移植技術分析

2.3.1 前期分析和計劃

分析需要移植的系統應用包括外部連接方式、內部所有模塊的功能、模塊間的關聯關系、模塊之間的數據流向和各模塊采取的技術實現方式；明確整個系統中采用的軟件及其版本信息，確定每個子系統（模塊）的規模、開發方式等。

基于上述調研分析后，制定移植計劃，明確相關參與人員和具體工作內容，各個階段的里程碑。

2.3.2 移植方法過程

（1）確認移植工作范圍和計劃，明確開發/移植規范，包括編程規范和版本管理等，明確各相關部門負責人/接口人；（2）準備移植環境，包括軟件和編譯環境的安裝，對數據庫需要建立好庫表結構，開發用戶的建立，待移植的源代碼準備就緒；（3）修改源代碼，創建編譯源代碼的makefile文件；（4）編譯源代碼，并修改編譯錯誤或警告的代碼；（5）對編譯后的代碼單元測試； （6）模塊測試和集成測試。

2.4 系統遷移測試

為了保證新舊系統切換的成功和業務的過渡，有必要對所要切換的系統及其關聯系統進行充分的測試，測試是保證切換后業務系統能夠正常運行的重要手段。其目的如下：（1）從業務目標的角度評估IT集成架構合理性；（2）從業務需求的角度對新系統的功能特性進行充分的驗證；（3）從業務運維的角度對新系統非功能特性（性能、壓力）得到充分的驗證。

通過測試，對新系統可能存在的缺陷、性能瓶頸進行及時發現和建議。遷移測試主要包含業務功能測試、性能和可用性保證測試。

2.5 系統試運行

數據和應用遷移完成以后，新舊兩套系統應并行運行，各鐵路局所有發往舊系統的數據同時發往新系統，新舊系統的數據接收以及分解入庫的程序同時工作。

用戶接入新系統，使用新系統的功能。并行一段時間后，如果通過檢驗發現新系統中所有的業務系統的運行良好，則表明切換成功，系統進入試運行階段。

3 系統遷移詳細方案

3.1 系統軟硬件配置

3.1.1 系統硬件配置

（1）數據庫服務器。中央主機系統遷移工程的數據庫服務器，負責原中央主機系統上所有應用的數據存取和訪問控制。數據庫服務器提供數據管理服務和數據集成分析服務，存放所有應用的靜態和動態數據信息。數據庫服務器采用2臺高性能小型機。每臺服務器配置不低于：64核CPU，512 GB內存，24×300 GB內置硬盤，24個千兆雙口網卡，24個萬兆光口網卡，24個HBA光纖通道卡。劃分11個服務器分區，部署Oracle數據庫、MQ傳輸、NBU備份等應用，以及預留分區。2臺小型機數據庫服務器上相應的服務器分區以集群方式工作，以保證系統高可靠性。

（2）應用服務器。中央主機系統遷移工程的應用服務器，負責原中央主機系統上所有應用的后臺邏輯處理功能。應用服務器采用2臺高性能小型機。每臺服務器配置不低于：48 CPU，256 GB內存，24×300 GB內置硬盤，24個千兆雙口網卡，16個萬兆光口網卡，24個HBA光纖通道卡。劃分6個服務器分區，分別部署后臺應用程序，以及預留分區。2臺應用服務器上相應的服務器分區以集群方式工作，以保證系統高可靠性。

（3）存儲及備份設備。中央主機系統遷移工程的存儲及備份設備，負責所有應用當前和歷史數據的存儲。存儲系統采用2臺高端磁盤陣列。每臺磁盤陣列配置不低于：40 TB有效容量， 512 GB Cache。磁帶庫采用1臺高端的虛擬磁帶庫，配置不低于：48 TB容量，4個8 GB FC接口，2個萬兆光口，2個千兆電口。

3.1.2 系統軟件配置

數據庫軟件：采用Oracle RAC，部署在2臺高性能的數據庫服務器上，用于提供應用數據的存取及訪問控制。

應用中間件：采用Oracle Weblogic，主要部署在UNIX刀片服務器上，用于提供應用程序的部署及訪問。

磁盤鏡像軟件：采用Symantec Storage Foundation，部署在所有UNIX服務器上。該軟件主要實現備份恢復功能。

備份恢復軟件：采用Symantec NBU，服務器端部署在一臺獨立的NBU Server上，客戶端部署在每臺要做備份的服務器上。

3.2 遷移組織和計劃

3.2.1 組織結構

系統遷移和實施按照質量管理體系的相關流程，采用項目制管理方式。組織結構由公司領導統一指揮，組建各相關部門、集成供應商、應用負責人和技術人員共同參與的項目團隊，制定全面的技術方案以及風險應對措施，并按應用制定詳細執行計劃。

遷移實施過程中，實行應用與維護等技術人員值守制度，保證24 h實時監控，出現問題及時解決，并對運行性能進行實時監測和優化調整，應用通過新老環境的并行運行實現過渡。組織架構如圖3所示。

圖3 組織架構

3.2.2 遷移計劃

遷移計劃內容見表1。

3.3 系統遷移關鍵技術要點

3.3.1 數據遷移的技術要點

（1）數據結構的移植。主機數據庫對象定義移植；View，Triggers等在數據遷移好之后針對應用需求和SQL執行性能要求添加；遷移重點在Table級別,重新規劃TABLESPACE的空間和結構；考慮業務需求及新系統的變化,修改數據結構；存儲的規劃和重新部署。

DB2和Oracle在某些數據類型的定義上有一定差異性，要考慮各種數據類型的匹配關系。例如：DB2日期類型為DATE和TIME兩種分別存放日期和時間，Oracle中日期類型為DATE統一存放日期和時間，可將日期和時間字段合并遷移。DB2中數值類型可統一轉換為Oracle中NUMBER類型，DB2中CHAR類型可統一轉換為Oracle中VARCHAR2類型等。

表1 遷移計劃內容表

（2）數據的移植方法。SQL*Loader將文本數據裝入Oracle數據庫中；Oracle Transparent Gateway for DB2在DB2數據庫和Oracle 數據庫之間建立連接，通過Oracle的數據庫鏈接(Database Link)技術將DB2數據Copy到Oracle數據庫中；用C編程方式簡單地實現動態轉換。

（3）系統并行的數據遷移要點。需要對數據庫的表進行全面分析，盡量優化遷移方案，減少遷移時間和所需的停機時間；需要規劃出合理的遷移時間窗口和遷移時間點，同時規劃系統遷移所需的應用停機時間和相應的數據保留方案；數據庫系統中數據量很大且7×24 h服務，無法進行長時間停機來進行數據遷移，只能在業務運行過程中根據應用修改數據庫的情況進行數據遷移。

3.3.2 數據遷移策略

假設2014.07.01系統遷移開始試運行。

3.3.2.1 表結構遷移和應用部署

（1）在07.01前完成所有的DB2數據庫結構到Oracle數據庫的遷移。（2）完成開放系統數據庫和應用的部署，應用功能與原主機生產系統完全一致，但開放系統暫不接收任何生產數據。

3.3.2.2 數據遷移

（1）將07.01前有時間戳以及沒有數據修改的表中的數據卸載，遷移到Oracle開放系統。假如歷時15天。（2）07.16某時間點停止現主機系統應用和數據傳輸，保證現系統不再進入新數據，將07.01以來15天有時間戳的數據卸載并遷移到Oracle開放系統(保證1天完成)。（3）啟動現主機系統的應用和遷移后開放系統的應用，MQ分別將數據發往新、舊系統，開始同步更新數據。

由于應用訪問的數據暫時用不到歷史，可以在系統正式切換后，根據一定的策略，逐步遷移到開放系統中。

3.3.3 應用移植技術要點

（1）應用分析過程：分析總結內部所有模塊的功能、模塊間的關聯關系、模塊之間的數據流向、各模塊采取的技術實現方式、明確整個系統中采用的軟件及版本信息、確定每個子模塊的規模和開發方式、明確相關人員負責的具體內容。（2）應用移植過程：明確開發/移植規范(編程規范和版本管理等)、明確各應用程序負責人和接口方式、準備移植環境(軟件和編譯環境的安裝，建立數據庫表結構，測試數據)、開發用戶建立、修改源代碼、做好單元測試和模塊功能測試。

3.3.4 應用移植技術方法

DB2 CLI程序的遷移：DB2為 CLI （Call Level Interface），Oracle中為OCI，可以將這些C程序中的CLI調用直接轉換成Oracle的OCI函數調用，在改動源碼最少的情況下達到移植目的。

DB2 C語言的遷移：可改成Oracle 的PRO*C實現，過程化語言中Oracle的函數是DB2函數的超集。DB2中絕大部分的函數在Oracle中都是支持的，只有少量需要做一些修改。特別注意對DB2和Oracle中SQLCODE異常處理結果的轉換，注意DB2和Oracle中日期字段的變量定義、格式轉換和編程技巧的區別。

DB2 存儲過程的遷移：可將這些存儲過程改成相應的Oracle PL/SQL存儲過程，這樣對前臺的應用的改動影響最少。

Oracle數據庫和DB2中很多數據類型的匹配、SQL語句的寫法等有一定差異，需要熟悉掌握相關編程技術。

3.3.5 性能優化技術要點

Oracle表空間的合理規劃和重新劃分；關鍵表和大數據量表建成各類分區表,在移植前Oracle數據庫的建立、表空間的劃分、具體數據的“落腳點”（如將關聯性大的表和Index等隔離在不同的存儲空間中），對關鍵性大表建成Partitioning方式，移植過程中的SQL優化和移植后的數據庫內存，參數調整等方面提前進行規劃，設計性能調優步驟，更好地發揮系統硬軟件的潛力；鑒于系統的壓力和數據的處理計算量非常大，建議對于一些大的數據表采取Oracle的Partitioning方式將其分成若干個小表，并盡量分布在不同的I/O通道上，以期達到I/O均衡和較少查詢量。在移植過程中，可改良相關的SQL寫法，如盡量減少全表掃描、盡量減少大表的Join操作等。對于一些View中有很多的Join操作，并訪問非常頻繁，不妨建成Oracle的物化視圖方式Materialize View，以存儲空間來保證查詢性能。

3.3.6 系統試運行和并行的策略

（1）試運行：應用移植在測試環境下完成后，逐步向生產環境中遷移。在生產環境下進行系統測試、負載測試、性能優化工作。主要數據接收處理應用在新舊兩套系統中同時傳輸，應用同時處理。（2）并行運行：數據和應用遷移完成以后，新舊兩套系統并行運行，所有發往中央系統的數據在新舊系統中同時接收，分解入庫程序、數據處理程序等同時工作。用戶接入新系統，使用新系統的功能。如果通過檢驗發現新系統中所有的業務系統的運行良好，經過一段時間的考驗，可認為切換成功。（3）并行中應急回退策略：新老系統需并行，直到新的系統完全穩定為止，一旦發現新系統運行問題，馬上切換回老的系統。制定應急預案，預先規定應急回退的條件，一旦上線過程中達到應急回退的條件，馬上回退。將回退的工作編寫成完整腳本，并規定回退腳本的執行順序。進行回退演練，需要回退時，按照預先演練好的順序執行相關修改，盡可能縮短應急回退的時間。

4 結束語

在領導小組的高度重視和大力支持下，各工作組全力配合，密切協作，鐵路中央主機系統已完整、安全、高效地遷移到開房平臺中，系統數據完整同步、應用功能一致運行平穩，受到了鐵路總公司業務部門的充分肯定。總結如下：

（1）開放平臺架構設計是主機系統遷移到開放平臺的前提條件，對遷移后的開放平臺硬件、軟件資源和系統架構進行總體的規劃設計，為系統遷移提供穩定、高效的系統軟、硬件平臺。（2）對系統遷移組織架構、職責、人員和計劃流程進行全面的規劃，組建由各相關部門、集成供應商、應用負責人和技術人員共同參與的項目團隊，為遷移工作順利進行提供了強大的組織保障。（3）分析數據和應用遷移的技術方法，遷移工作的核心是數據遷移和應用代碼遷移，重點研究數據遷移技術、方法和策略，應用代碼移植的方法和技術，對DB2和Oracle數據庫的數據結構、應用程序移植等技術進行深入的分析和研究，為系統遷移提供了切實可行的技術支撐。

[1]谷曉明，劉衛國.鐵路信息系統建設和應用有關問題研究[J].鐵路計算機應用，2010，19（4）：1-3.

[2]趙 靜,史天運,李 平.鐵路信息共享平臺中共享數據庫結構和關鍵技術研究[J].鐵路計算機應用，2010，19（9）.[3]戴國華,董寶田,李明輝,等.鐵路數據資源整合的分析與設計[J].鐵路計算機應用，2009，18（11）：7-10.

[4]孫遠運.TMIS總體架構設計研究[J].鐵路計算機應用，2005，16（7）：11-14.

[5]李伏欣.鐵路信息共享平臺技術初探[J].中國鐵道科學，2002（5）：31-38.

[6]阿 杳.大機來襲—IBM推出面向中小企業的z9新品[J].微電腦世界，2006（7）：151.

[7]朱蔚恒,周 偉,龍 舜.開放平臺解決方案及其安全策略研究[J].計算機工程，2012（6）：12.

[8]樊新華.關系數據庫的查詢優化技術[J].計算機與數字工程，2009（12）：188-192.

[9]謝 鵬.DB2通用數據庫的訪問技術[J].微機發展， 2004（2）：55-56.

[10]史曉磊.DB2數據庫在軟件中的應用技巧[J].電腦與電信，2008（11）：72-73.

[11]王 雷,曾蘊波,王 璐.Oracle數據庫的性能調整與優化方法探析[J].航天器工程，2008（6）：129-133.

[12]鐘文龍,陳 磊.DB2與Oracle的數據倉庫技術關鍵能力對比研究[J].電腦知識與技術， 2005（26）：9-11.

[13]張幸亞,張遵連.Pro*C開發的幾點經驗[J].電腦知識與技術，2005（12）：6-8.

[14]肖 偉,趙嵩正.異構環境下Oracle數據移植問題研究[J].微型電腦應用，2004（2）：63-64.

[15]段衛國,李俊春 Oracle數據庫數據遷移技術研究[J].信息技術 ，2015（8）：35-39.

[16]李永良.數據遷移在新舊系統中切換[J].中國計算機用戶，2003（Z2）：45-46.

責任編輯 徐侃春

Migrating plan for Railway Central System

DU Wei
( Department of Information Engineering,China Railway Information Technology Center, Beijing 100844,China)

This article analyzed the current status of Railway Central System,studied on the open platform,design of logical architecture,technology of application transplantation,database optimization,system implementation and operation,etc.,proposed the migrating plan of the System.The migration for platform architecture,database,data and applications program of the System was implemented safely,effciently and perfectly.

migrating;Central System;open platform;Oracle;data migrating; parallel

U29∶TP39

A

1005-8451（2016）02-0027-06

2015-06-11

杜 巍，工程師。