董偉　黃饒生　楊佳熠　張小全

摘要：隨著信息技術(shù)的日新月異，x86架構(gòu)的CPU（中央處理器）算力的加強(qiáng)，以及虛擬化技術(shù)（VT）的應(yīng)用，原有基于小型機(jī)的SAP（ERP軟件）系統(tǒng)硬件架構(gòu)已逐漸露出諸多弊病，其中最重要的性價比已無法與x86服務(wù)器相比。而如何將SAP系統(tǒng)從老舊的小型機(jī)遷架構(gòu)移到x86架構(gòu)服務(wù)器是如今很多SAP用戶面臨的迫切問題。經(jīng)過與SAP用戶實際項目為技術(shù)應(yīng)用對象，本文主要講述了基于Oracle的SAP系統(tǒng)異構(gòu)遷移技術(shù)的成功應(yīng)用與研究，在保證數(shù)據(jù)完整性的前提下，為各信息終端用戶提供持續(xù)的應(yīng)用平臺，并為其他SAP用戶做異構(gòu)遷移提供了參考依據(jù)。同時SAP系統(tǒng)運維人員通過虛擬化技術(shù)管理x86服務(wù)器能更加高效的利用硬件資源，降低了硬件設(shè)備故障的風(fēng)險，減輕了運維人員的工作量，最終為SAP用戶節(jié)約了成本，創(chuàng)造了價值。

關(guān)鍵詞：SAP系統(tǒng)異構(gòu)遷移? 小型機(jī)遷移? 虛擬化服務(wù)器應(yīng)用

一、引言

隨著時間的推移，基于小型機(jī)的SAP系統(tǒng)硬件逐年老化，存在的隱患對日常經(jīng)營管理形成極大風(fēng)險。同時對于SAP應(yīng)用系統(tǒng)運維人員（BASIS人員）和網(wǎng)絡(luò)服務(wù)器運維人員來說，老舊的硬件設(shè)備需要更多的精力和時間關(guān)注性能和可用性，甚至將絕大多數(shù)時間花在硬件故障的維修上，而將小型機(jī)遷移至基于x86架構(gòu)的服務(wù)器便是以上一系列問題最便捷的解決方案。

二、小型機(jī)與x86服務(wù)器技術(shù)的優(yōu)劣對比

2.1 小型機(jī)的技術(shù)優(yōu)勢

小型機(jī)采用RISC指令集，比x86服務(wù)器的響應(yīng)時間要快，多任務(wù)處理性能要好，并發(fā)用戶數(shù)量要多。同時小型機(jī)大多采用冗余和高可用技術(shù)，可靠性也比x86服務(wù)器要好，小型機(jī)在大數(shù)據(jù)和批量處理上占有不少優(yōu)勢。綜合系統(tǒng)響應(yīng)時間、多任務(wù)處理、終端用戶支持?jǐn)?shù)量、可靠性等因素考慮，在一些關(guān)鍵業(yè)務(wù)應(yīng)用上，小型機(jī)優(yōu)勢還是非常明顯。但小型機(jī)都采用專有技術(shù)，硬件價格比x86服務(wù)器高，且操作系統(tǒng)也都采用專有的UNIX操作系統(tǒng)，運行維護(hù)和售后費用高昂。隨著x86服務(wù)器綜合性能上的提升，小型機(jī)已步入晚年期，后續(xù)機(jī)型從各個方面都無絕對優(yōu)勢。

2.2 x86服務(wù)器的技術(shù)優(yōu)勢

近年來隨著x86服務(wù)器性能的逐年提升，雖然單臺服務(wù)器仍然無法與小型機(jī)進(jìn)行對比，但隨著虛擬化技術(shù)的加持，將多臺x86服務(wù)器組合成一個大硬件資源池，重新將硬件資源分配給一臺或多臺虛擬服務(wù)器，x86服務(wù)器與虛擬化的組合已在性能的各方面趕超小型機(jī)。部分電商企業(yè)如亞馬遜、阿里云、騰訊云等x86服務(wù)器運行的虛擬服務(wù)器已上萬臺。而且x86服務(wù)器運維方便，能運行Linux或Windows等各種操作系統(tǒng)，價格便宜，易于維護(hù)，技術(shù)成熟度也越來越高。如圖1列舉了各架構(gòu)服務(wù)器性能對比。

三、基于Oracle的SAP系統(tǒng)異構(gòu)遷移的技術(shù)難點分析

Oracle提供多種工具進(jìn)行遷移，其中以O(shè)racle DataGuard性能最為優(yōu)秀。DataGuard僅支持異構(gòu)平臺、跨版本數(shù)據(jù)庫遷移，同時還支持在線異構(gòu)平臺數(shù)據(jù)庫遷移。但我們在此需要說明的是基于Oracle的SAP系統(tǒng)異構(gòu)遷移，不能將Oracle數(shù)據(jù)庫和SAP應(yīng)用系統(tǒng)割裂后單獨遷移。Oracle在此為SAP底層數(shù)據(jù)庫，脫離SAP單獨遷移Oracle對SAP應(yīng)用系統(tǒng)來說無意義。圖2所示為SAP系統(tǒng)遷移路徑。

3.1 源平臺的技術(shù)需求及難點分析

3.1.1 源操作系統(tǒng)的技術(shù)需求及難點分析

SAP應(yīng)用系統(tǒng)多數(shù)情況采用高可用技術(shù)（HA），即SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫系統(tǒng)安裝兩臺服務(wù)器上同時提供負(fù)載均衡服務(wù)，并通過心跳線連接，保證單臺服務(wù)器故障后另外一臺服務(wù)器能提供持續(xù)的服務(wù)。高可用的兩臺服務(wù)器底層操作系統(tǒng)是一致的，以保證兩臺服務(wù)器上運行的SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫系統(tǒng)能兩邊自由切換。源操作系統(tǒng)遷移的技術(shù)難點在于是否支持SAP遷移工具所要求的最低版本要求和插件要求。以惠普的Superdome小型機(jī)操作系統(tǒng)HP-UX為例，最低HP-UX版本要求為11.31且至少安裝PHSS_43741 aC++ Runtime （IA： A.06.28，PA： A.03.90）或更新版本 。

3.1.2 源Oracle系統(tǒng)的技術(shù)需求與難點分析

Oracle數(shù)據(jù)庫遷移前后的版本是一致的。但在實際進(jìn)行SAP系統(tǒng)異構(gòu)遷移時，需要根據(jù)SAP要求確定是否需要升級Oracle版本。SAP針對Oracle9、Oracle10、Oracle11推出了專用于系統(tǒng)遷移的補(bǔ)丁，SAP用戶需在遷移前期檢查Oracle版本是否滿足SAP系統(tǒng)遷移前置條件。

3.2 目的平臺的技術(shù)要求及難點分析

3.2.1目的操作系統(tǒng)的技術(shù)需求及難點分析

目的操作系統(tǒng)硬件資源不能小于源系統(tǒng)的硬件資源數(shù)量。硬件資源在保證滿足業(yè)務(wù)并發(fā)需求的情況下，同時考慮遷移所需硬件性能是否滿足。使用虛擬化技術(shù)后，目的操作系統(tǒng)底層硬件資源擴(kuò)展方便，x86服務(wù)器能非常便捷的擴(kuò)展到虛擬化資源池中，只要前期充分調(diào)研，一般不需要擔(dān)心目的操作系統(tǒng)資源不夠的情況。

目的操作系統(tǒng)通常采用最新發(fā)布版本降一版本號的穩(wěn)定版本，同時兼顧SAP與Oracle官方資料，保證不要因系統(tǒng)版本太新而遇到棘手的漏洞。

3.2.2目的Oracle系統(tǒng)的技術(shù)需求與難點分析

遷移前可根據(jù)實際情況做Oracle升級。一旦開始遷移，目的Oracle系統(tǒng)版本只能保持與遷移前版本一致。如遷移在驗證階段不成功，后續(xù)根據(jù)實際需求情況再做Oracle版本升級。

3.3 保證數(shù)據(jù)一致性的難點分析

SAP系統(tǒng)龐大，涉及業(yè)務(wù)模塊眾多。如果通過業(yè)務(wù)崗位人員逐一驗證遷移是否成功，將會是一個耗時且繁雜的工作。在做業(yè)務(wù)崗位數(shù)據(jù)驗證前，BASIS運維人員可通過SAP自帶的數(shù)據(jù)庫工具和Oracle數(shù)據(jù)庫管理工具驗證遷移前后數(shù)據(jù)容量、表字段、表數(shù)量、單一表條目數(shù)等是否一致，再提交業(yè)務(wù)崗位進(jìn)行抽查驗證。一旦業(yè)務(wù)崗位人員驗證通過，此SAP系統(tǒng)遷移即成功完成。

四、SAP系統(tǒng)遷移的應(yīng)用與實施

4.1 SAP源系統(tǒng)導(dǎo)出

SAP源系統(tǒng)導(dǎo)出分為導(dǎo)出準(zhǔn)備、Kernel準(zhǔn)備、表分割準(zhǔn)備和數(shù)據(jù)實例導(dǎo)出四個步驟，如圖3所示。

通過SAP的SWPM（Software Provisioning Manager）工具進(jìn)行SAP源系統(tǒng)導(dǎo)出，SWPM提供了詳細(xì)的操作向?qū)?。遷移人員按需填入源操作系統(tǒng)、SAP應(yīng)用和Oracle數(shù)據(jù)庫相關(guān)參數(shù)信息即可實現(xiàn)四個步驟的導(dǎo)出作業(yè)，遷移人員只需關(guān)注SWPM日志并處理異常。

Oracle數(shù)據(jù)庫表的如果大于1G將被拆分并自動編號。數(shù)據(jù)導(dǎo)出過程比較慢，導(dǎo)出過程可以通過R3load進(jìn)程實時監(jiān)控。

4.2 SAP目的系統(tǒng)安裝及Oracle數(shù)據(jù)庫導(dǎo)入

SAP目的操作系統(tǒng)在前期準(zhǔn)備階段已經(jīng)準(zhǔn)備完成，因此在遷移執(zhí)行階段直接在目的操作系統(tǒng)中安裝SAP并導(dǎo)入Oracle數(shù)據(jù)庫。安裝和導(dǎo)入同樣使用SAP的SWPM工具，并在工具中通過向?qū)У姆绞较葓?zhí)行安裝SAP，再在安裝過程中選擇需要導(dǎo)入數(shù)據(jù)庫存檔并執(zhí)行。

SAP目的系統(tǒng)將根據(jù)實際應(yīng)用模塊情況選擇安裝ABAP、JAVA等實例，如生產(chǎn)系統(tǒng)使用高可用，還需安裝ASCS服務(wù)器，DI服務(wù)器。

4.3后續(xù)配置

后續(xù)配置為正常的SAP應(yīng)用系統(tǒng)和Oracle數(shù)據(jù)庫后安裝配置，包括軟件激活，開發(fā)、測試、生產(chǎn)系統(tǒng)連接，數(shù)據(jù)庫零時表清空，后臺作業(yè)釋放，參數(shù)調(diào)整等步驟。

4.4 系統(tǒng)驗證

系統(tǒng)驗證是保證數(shù)據(jù)一致性的關(guān)鍵步驟。3.3章節(jié)中已經(jīng)指出可以通過SAP自帶的數(shù)據(jù)庫工具和Oracle數(shù)據(jù)庫管理工具驗證遷移前后數(shù)據(jù)容量、表字段、表數(shù)量、單一表條目數(shù)量是否一致，再提交業(yè)務(wù)崗位進(jìn)行抽查驗證。

SAP系統(tǒng)遷移實施前期工作一定要準(zhǔn)備充分。特別是遷移人員必須清楚遷移前后操作系統(tǒng)、數(shù)據(jù)庫版本、SAP應(yīng)用系統(tǒng)是否需要升級，目的系統(tǒng)硬件資源情況，目的操作系統(tǒng)是否提前已交付等。一旦遷移開始，系統(tǒng)停機(jī)時間將非常寶貴。因此生產(chǎn)系統(tǒng)的遷移要在開發(fā)系統(tǒng)遷移驗證成功后進(jìn)行。

五、SAP系統(tǒng)遷移的技術(shù)路線

SAP系統(tǒng)遷移看似SAP系統(tǒng)的重新部署，實際確有著長期的技術(shù)發(fā)展路線。在虛擬化和云計算大行其道的今天，果斷將技術(shù)路線切換到虛擬化和云計算的方向才能順應(yīng)市場變革。SAP公司為保證其軟件應(yīng)用產(chǎn)品的持續(xù)發(fā)展和延續(xù)性，將基于老舊技術(shù)架構(gòu)的SAP系統(tǒng)遷移至虛擬化、云產(chǎn)品、內(nèi)存計算服務(wù)器，將是未來SAP系統(tǒng)遷移的技術(shù)路線圖，為用戶提供硬件更新、系統(tǒng)遷移和產(chǎn)品升級退出更好的遷移產(chǎn)品，做好技術(shù)支持將是其持續(xù)的發(fā)展策略。

六、總結(jié)

越來越多的SAP用戶已經(jīng)意識到虛擬化技術(shù)的優(yōu)勢，都在考慮如何將SAP應(yīng)用系統(tǒng)從笨重的小型機(jī)遷移到基于x86服務(wù)器的虛擬機(jī)上。同時，隨著x86服務(wù)器性能的持續(xù)發(fā)展，虛擬化技術(shù)的成熟，SAP也將更加注重客戶SAP系統(tǒng)遷移的需求。而各種異構(gòu)平臺的數(shù)據(jù)遷移技術(shù)及應(yīng)用的研究還將持續(xù)，為客戶提供更加好用的應(yīng)用平臺。

參考文獻(xiàn)：

[1]Edward Whalen，Jim Czuprynski 著，許向東，林緒嘉，劉炳林譯。Oracle數(shù)據(jù)庫升級、遷移和轉(zhuǎn)換最佳實踐。清華大學(xué)出版社，2017年5月第一版。

[2]李明，姚振，方銳，吳躍，劉海苗 著，ERP系統(tǒng)X86架構(gòu)遷移關(guān)鍵技術(shù)研究，無線互聯(lián)科技，2020（21）：79-80。

[3]吳天宇，馮蕊，楊翠 著，Oracle數(shù)據(jù)庫批量數(shù)據(jù)無損遷移技術(shù)，電子技術(shù)與軟件工程，2021（8）：204-205。

作者簡介：

董偉，男，漢，1979年8月生，湖北潛江人，本科，高級工程師，研究方向：計算機(jī)硬件及應(yīng)用。

楊佳熠，男，漢，1987年4月生，云南昭通人，本科，工程師，研究方向：信息系統(tǒng)集成。

張小全，男，漢，1984年8月生，河南英文人，本科，助理工程師，研究方向：云原生技術(shù)應(yīng)用。

黃繞生，男，漢，1979年8月生，云南石林人，本科，工程師，研究方向：計算機(jī)信息管理。