第3回:SPDD編:SAPアップグレードのダウンタイム変動要素

 2009.10.20  リアルテックジャパン

第3回:SPDD編:SAPアップグレードのダウンタイム変動要素

今回はSPDDの調整によるダウンタイムの影響について書きます。

SPDDはフェーズACT_700で実施されるモディフィケーション調整です。

モディフィケーションの調整は主に、SAP標準へリセットする、SAPの推奨に従う(Accept Proposal)、削除する、その都度調整という4パターンが存在します。

Upgrade_3.jpg

SAP標準へリセットするパターンでは、現行リリースでNotes適用をしたとき、新しいリリースでは対応している可能性が大なので、Notes適用はほとんどのケースでリセットになります。

また、アプリケーションサイドの判断で、新しいリリースの機能へ移管してアドオンを消したり、標準へいったん戻してから、アップグレード後に再度調整するパターンも見受けられます。

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

SAPの推奨に従う(Accept Proposal)と、現状のモディフィケーションを保持しながら、新しいリリースで追加されるオブジェクトが追加されます。

アップグレードキットの判断で、新しいリリースでは使われそうもないオブジェクトは削除対象になります。ここはアプリケーションサイドの判断が必要です。

その都度調整は、ほぼアプリケーションサイドでの仕様変更に依存します。

SPDDの調整が最もダウンタイムに影響を与えるのは、フェーズPARCONV_UPGです。

PARCONV_UPGはオブジェクトの順番が変更されると、透過テーブルの場合、一時テーブル(QCM<テーブル名>を作成→元のテーブルから読み出して、一時テーブルへ変換→元のテーブルを削除→QCM<テーブル名>を<テーブル名>に変更(QCMという名前を落とす)→インデックスの再作成という手順を踏みます。クラスタテーブルの場合は、QCM<テーブル名>という一時“透過”テーブルを作成→一時テーブルへ変換→元のテーブルを削除→元のテーブルを再作成→一時テーブルから再作成したテーブルへ変換→インデックス作成→一時テーブルを削除という手順を踏みます。ちなみにインデックスは再作成という手順を踏みます。

上記の処理はSAP標準へのリセットやその都度調整したとき、テーブルやインデックスの順番が変わってしまうと発生します。BASIS系のテーブルは幾つか構造が変化するため、必ず変換の対象になります。

ただし、これは大きなテーブルではないため、処理時間も10~20分程度で終了します。

ちなみに、並列で複数のR3transが同時進行します。

この変換対象が100万件も無い小さなテーブルだった場合、数分程度で処理が終わりますが、トランザクション系の巨大テーブルだった時に、長時間の処理に及ぶことがあります。インデックスの場合、アップグレード中はとりあえず現状を保持したまま処理を行ってしまい、アップグレード後の他の処理を行っている間にインデックスを再作成すると、アップグレード全体のダウンタイムを圧縮することも可能です。

開発機には大概トランザクション系のデータは少ないので、気づきづらいですが、テスト機や本番機で、驚くほど処理時間が延長することがあるので注意が必要です。

ではまた

hama

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

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


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

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング

ブログ購読のお申込み