技術記事

ダウンタイム最適化コンバージョンをやってみた①(概要編) ~Downtime Optimized Conversion~

  • S/4HANA移行
  • SAP
  • S/4HANA

ダウンタイム最適化コンバージョンをやってみた①(概要編) ~Downtime Optimized Conversion~

目次

ブログ内容
①概要編ダウンタイム最適化手法の仕組み、制約 ※当ブログ
実施編ダウンタイム最適化手法の実施手順
検証編ダウンタイム比較、考察

はじめに

SAP S/4HANAへの移行において、ダウンタイムは非常に重要なポイントです。

ECCからS/4HANAへの移行の方式は、コンバージョン、再構築、選択データ的移行の大きく3つに分類されますが、一番シンプルなコンバージョンは、他の方法と比較して長いダウンタイムが必要となります。

データ量が多いシステムでは、標準的なコンバージョン方式ではダウンタイム要件を満たす事が難しく、コンバージョンのハードルを上げている要因となっています。

SUM(Software Update Manager)によるダウンタイム短縮の方法として、ダウンタイム最適化手法のシナリオはSAP社から以前よりリリースされていましたが、以前まではSAP社メンバーによるサポートが必要などの実施条件がありました。
直近においては、その実施条件が緩和されて一般利用が可能となりましたので、ダウンタイム最適化手法によるコンバージョンの検証を実施しました。

現在、SUMを使用したコンバージョンで選択可能なダウンタイム最適化手法のシナリオは以下の2つです。

  • Downtime-Optimized DMO(以下DO-DMOと記載)
  • Downtime-Optimized conversion(以下DO-Convと記載)

今回は上記の2つと標準方式のコンバージョン(Standard Conversion、以下標準Convと記載)を実施して比較を行います。

ブログは概要編(このブログ)でダウンタイム最適化手法の概要に触れ、実施編(次のブログ)で実施時のポイント、検証編で各コンバージョン手法のダウンタイム比較などについて触れていきます。

ダウンタイム最適化手法の仕組み

1.概要

ダウンタイム最適化手法は、標準Convではダウンタイム中に実施する移行処理の一部をアップタイム中に実施する事でダウンタイムを短縮する手法です。

そのため、エンドユーザが利用中でデータ追加も可能なアップタイム中からSUMを実行し移行処理を行う事になります。

SUMで移行処理実施中にデータ追加しても整合性のあるデータ移行ができるのかという疑問がでてきますが、その仕組みについても後続で簡単に記載していきます。

2.SUMでの処理内容

ダウンタイム最適化手法を理解するために、SUMでの処理内容について簡単に説明します。

S/4HANAコンバージョンの時にSUMでの実施内容を単純化してみると、以下の4つのステップで構成されていると考えることができます。

 「リポジトリの作成」・・・ターゲットDBにS/4HANAのデータ構造となる器の作成
 「データ移行」・・・ソースDBからターゲットDBへのデータベースコンテンツの転送
 「データ変換」・・・S/4HANAのデータ構造に応じたデータ変換
 「FINデータ変換」・・・会計データの「データ変換」、事前にカスタマイズが必要。標準ConvではSUMが終わった後の後処理で実施される

簡単に説明すると新しいデータベースの入れ物を用意して、元のデータベースからデータを移動し、さらに新しいデータベースのルールに従ってデータを変換するというイメージです。

この4つのステップの実施タイミング(ダウンタイム・アップタイム)を調整することでダウンタイムを短縮する仕組みがダウンタイム最適化手法(Downtime-Optimized)です。

コンバージョン時のシステム遷移のイメージ

3.標準方式とダウンタイム最適化手法の実施タイミングの違い

標準Convでは全データの「データ移行」「データ変換」「FINデータ変換」をダウンタイムで実施します。
DO-DMOでは移行可能データの「データ移行」をアップタイムで実施します。
DO-Convでは、「データ移行」に加え、そのデータの「データ変換」「FINデータ変換」をアップタイム中に実施します。

アップタイム中に処理できなかったデータを⊿(デルタ)処理として、ダウンタイムの最初に実施します。図のように、アップタイム中に処理を移すことで、ダウンタイムを短くすることができ、一方でアップタイムは長くなることがイメージできます。

実際にコンバージョンのPoCを行うことでダウンタイムおよびアップタイムを把握できます。本番移行のスケジュールを立てるために重要な情報となります。

4.アップタイム中のデータ追加の挙動

「データ移行・変換」のステップがSUMのアップタイムに移動したときに、アップタイム中に追加されるデータがどのように 処理されるかについても簡単にまとめてみます。

「データ移行・変換」のステップは下図のように「初回データ移行・変換」と「差分データ移行」に分けられます。初回データ移行が始まる前に静止点が取られ、それまでに登録されているデータに対し「初回データ移行・変換」が行われます。

静止点以降に登録されたデータは「初回データ移行・変換」が終わった後に、「差分データ移行」として随時「データ移行」のみが行われます。「差分データ移行」についてはTCR(Transactional Consistent Replication)という仕組みでソース環境での変更データがもれなくターゲット環境に転送される仕組みとなっており、進行状況をCRRコントロールというツールでモニタリングできます。

ダウンタイムに入るとソース環境へのデータ変更は止まりますが、「差分データ移行」中に発生した追加のデータ変更も含め、移行が終わっていないデータの移行(⊿データ移行)が行われます。

これで、全てのデータの移行が行われたことになります。

また、「データ変換」は差分(随時)では行われないため、「差分データ移行」中に発生したデータの分もまとめて⊿データ変換として実行されます。

「FINデータ変換」もデータ変換と同じタイミングで実施されます。エラーがある場合はターゲットシステムにログインして対応します。

上記はDO-Convを例に記載していますが、DO-DMOの場合は「初回データ移行」「差分データ移行」のみがアップタイム中に行われることになります。

制約事項

1.前提条件

標準方式でのコンバージョンの前提条件(ユニコードシステムであることやECC6.0以上など)を満たすことは当然ですが、ソースデータベースの条件には特に注意する必要があります。DO-DMOでは多くのデータベースが可能となっていますが対象となるバージョンにも注意が必要です。DO-Convでは「MS SQL」や「SAP ASE」などが対象外となっており、今後のバージョンアップで対象とされることが期待されます。

また、アップタイム中にデータを移行する仕組み上、システムムーブオプションは使用できません。その他にも細かい前提条件がありますのでノートやガイドを確認することをお奨めします。

  • Downtime-optimized DMO
ソース製品ECC6.0以上
ユニコードユニコードシステム
MFLE 品目マスタ項目長の拡張を有効化している場合はサポート外
ソースデータベース

Oracle (at least on Oracle 12)
IBM Db2 for Linux, Unix, and Windows (DB6)
MS SQL (with SUM 2.0 SP 07 and higher)
IBM Db2 for z/OS (with SUM 2.0 SP 08 and higher)
SAP ASE (with SUM 2.0 SP 10 and higher)
※ソースDBがHANAの場合はnZDMのアプローチとなる

システムムーブ不可
  • Downtime-optimized Conversion
    Downtime-optimized DMOの前提条件を満たし、以下の条件も満たす必要があります。
ソースデータベース    

SAP HANA
Oracle
IBM Db2 for Linux, Unix, and Windows (DB6)
IBM Db2 z / OS

トレーニングと評価トレーニング(ADM329 )、評価(ADM329k)に合格、OSSからパスワードを取得
アプリケーション固有の制限    ソースデータベースSAPHANAの場合、勘定ベースのCO-PA(収益性分析)をソースシステムで使用してはなりません。
ソース製品SAP Simple Finance1503およびSAPS / 4HANA Finance 1605はサポート外
MFLE / DIMP-LAMAMFLE / DIMP-LAMAがアクティブなソースシステムはサポート外

2.アップタイム中の制約事項

ダウンタイム最適化手法ではSUMのアップタイム中に以下の処理を実施しないよう記載されています。実施が避けられない作業をリストアップし、制約事項を考慮してスケジュールを立てる必要があります。

  • 残高繰り越し
  • アーカイブの実行
  • カスタマイジングの変更
  • リポジトリの変更
  • 旧資産の処理
  • 会計年度の変更
  • 原価計算実行
  • 品目マスタの基本数量単位の変更

ダウンタイムとビジネスの制限
https://help.sap.com/viewer/a882504353b1407da13a271cf9dfcaf5/docsum20.12/en-US/36a957a36be84cfb8ae65f81ac153966.html

カスタマイズの凍結
https://help.sap.com/viewer/a882504353b1407da13a271cf9dfcaf5/docsum20.12/en-US/1f04d85a0fb7420c954d2365634ec883.html

おわりに

概要編ではダウンタイム最適化の手法の概要・制約についてまとめてみました。
弊社にて検証した際の具体的な手順・動作やダウンタイムの結果については実施編検証編へ。

<参考Note>
Downtime-optimized DMO
2547309 - Downtime-optimized DMO with SUM 2.0

Downtime-optimized Conversion
3074543 - Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 12


BeeXでは、ECCからS/4HANAへの移行を検討中のお客様向けのロードマップ作成、アセスメント、PoCなどのSAP S/4HANAコンバージョン関連サービスを実施しています。
BeeX Migration Factoryを利用する事で、お客様データでのPoCにてダウンタイム時間確認もスピーディに対応可能です。

S/4HANAへの移行でお悩みのお客様は是非、お気軽にご相談ください。

BeeXサービス紹介はこちらから

カテゴリー
タグ

この記事を書いたメンバー

Omura
Omura

このメンバーの記事一覧

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関してお気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)

  • TOP
  • ブログ
  • ダウンタイム最適化コンバージョンをやってみた①(概要編) ~Downtime Optimized Conversion~