第1回:SAPプロダクト編:SAPアップグレードのダウンタイム変動要素

 2009.10.19  リアルテックジャパン

第1回:SAPプロダクト編:SAPアップグレードのダウンタイム変動要素

BASISエキスパートの方向けにアップグレードのダウンタイムに関するブログを担当することになりました。

アップグレード処理のコアな内容になりますので、一般のBASISコンサルの方やユーザー様にとっては極めて難解な内容かつマニアックになる予定です。(笑)

まずはアップグレード作業に必要なダウンタイム(停止時間)についてなにがどのように影響するのかというお話しをしたいと思います。

第1回はSAP製品のUpgrade作業そのものです。

「theGuard! SmartChange Transport Management」 導入
SAPシステムパフォーマンス分析パック

アップグレードに関する作業要素として、prepare, sapup, アップグレード補足処理、アップグレード差分の移送、インフラチェック、システムチェックなどがあります。

各処理の時間には、サーバ能力、サポートパッケージの数、カスタマーオブジェクトの数、各作業を行うエンジニアのスキルレベルと複数の要素が絡むため、単純な計算は出来ない、というのが経験から来る意見です。

サーバ能力は、単体(コア)のCPU能力が最も影響します。メモリは経験上、あまり影響を受けないと思います。ディスクは処理によって影響があります。やはりレスポンスが良いディスク装置はCPU負荷も効率よくかかり、結果として処理時間が短くなる傾向があります。

サポートパッケージの数はsapup後半のフェーズに影響します。特にBASIS,AP,APPLは移送ファイルも大きく、スタックレベルが1個上がると数10分~数時間の処理延長があります。よって、Service Release(SR)の高いアップグレードが最初から組み込まれているサポートパッケージレベルが高いので、処理時間に有利です。

カスタマーオブジェクトは、各フェーズの処理時間を注意深く見ていないと、気がつきにくい要素ですが、アドオンのExport/Importを数か所のフェーズで実行しており、アドオンオブジェクトの数も数時間レベルで影響することもあります。よって、古いバージョンから使っているカスタマーは、古いリリース時に不足している機能をアドオンで補完していることが多いため、処理時間に楽観視はしない方が良いでしょう。

ダウンタイムの要素としては上記の他に、prepareをダウンタイムに含めるか?ということとdowntime-minimizedを使うかどうかも影響します。昨今は、当社の実績ではマイグレーションの処理時間を圧縮している関係で、マイグレーションとアップグレードを一気に行う案件が増えていため、prepareやsapupの処理は全てダウンタイムに入ってしまう傾向にあります。downtime-minimized案件はここ数年間、年に1件ペース程度になっています。ただし、Enhanced Packageの出現によりsapupの処理時間が劇的に増加したため、再びdowntime-minimizedアップグレードは増えると見ています。

各ダウンタイムの決定要素で意外に重要なのはエンジニアのスキルレベルとオペレーション時間です。スキルレベルはアップグレードツールの動きを理解しているエンジニアは、正しい判断で正確かつ効率よく処理を進めていきます。次回記述するハードウェアに関する話しでも、ハードウェアの特性を掴んでいれば最適な負荷効率で処理を実装出来るので数時間レベルの差が出てきます。また、スキルレベルや社内インフラがトラブル発生時に迅速に対応出来るかどうかが大きく変わってきます。特に初期構築時で起こる、最新のアップグレードキットやサポートパッケージの不具合はSAP Notesに一般公開されていないことが多く、テクニカルパートナーが持つコンピテンスセンターとの連携はかなり重要です。今のところ、ECC6.0 SR3アップグレードキットでは、カーネルパッチ、アップグレードキットのパッチで不具合を3件ほど経験していて、1件はコンピテンスセンターから入手した情報により1時間程度で解決しました。

ではまた

hama

SAPユーザのための 『S/4HANA』データ移行

RECENT POST「SAP情報」の最新記事


この記事が気に入ったらいいねしよう!
Archive Migration Service (アーカイブ移行リモートサービス)
オフィシャル採用ブログ『RTFrontier』はこちらから!

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング

ブログ購読のお申込み