第3回:SPDD編:SAPアップグレードのダウンタイム変動要素
今回はSPDDの調整によるダウンタイムの影響について書きます。
SPDDはフェーズACT_700で実施されるモディフィケーション調整です。
モディフィケーションの調整は主に、SAP標準へリセットする、SAPの推奨に従う(Accept Proposal)、削除する、その都度調整という4パターンが存在します。
SAP標準へリセットするパターンでは、現行リリースでNotes適用をしたとき、新しいリリースでは対応している可能性が大なので、Notes適用はほとんどのケースでリセットになります。
また、アプリケーションサイドの判断で、新しいリリースの機能へ移管してアドオンを消したり、標準へいったん戻してから、アップグレード後に再度調整するパターンも見受けられます。
SAPの推奨に従う(Accept Proposal)と、現状のモディフィケーションを保持しながら、新しいリリースで追加されるオブジェクトが追加されます。
アップグレードキットの判断で、新しいリリースでは使われそうもないオブジェクトは削除対象になります。ここはアプリケーションサイドの判断が必要です。
その都度調整は、ほぼアプリケーションサイドでの仕様変更に依存します。
SPDDの調整が最もダウンタイムに影響を与えるのは、フェーズPARCONV_UPGです。
PARCONV_UPGはオブジェクトの順番が変更されると、透過テーブルの場合、一時テーブル(QCM<テーブル名>を作成→元のテーブルから読み出して、一時テーブルへ変換→元のテーブルを削除→QCM<テーブル名>を<テーブル名>に変更(QCMという名前を落とす)→インデックスの再作成という手順を踏みます。クラスタテーブルの場合は、QCM<テーブル名>という一時“透過”テーブルを作成→一時テーブルへ変換→元のテーブルを削除→元のテーブルを再作成→一時テーブルから再作成したテーブルへ変換→インデックス作成→一時テーブルを削除という手順を踏みます。ちなみにインデックスは再作成という手順を踏みます。
上記の処理はSAP標準へのリセットやその都度調整したとき、テーブルやインデックスの順番が変わってしまうと発生します。BASIS系のテーブルは幾つか構造が変化するため、必ず変換の対象になります。
ただし、これは大きなテーブルではないため、処理時間も10~20分程度で終了します。
ちなみに、並列で複数のR3transが同時進行します。
この変換対象が100万件も無い小さなテーブルだった場合、数分程度で処理が終わりますが、トランザクション系の巨大テーブルだった時に、長時間の処理に及ぶことがあります。インデックスの場合、アップグレード中はとりあえず現状を保持したまま処理を行ってしまい、アップグレード後の他の処理を行っている間にインデックスを再作成すると、アップグレード全体のダウンタイムを圧縮することも可能です。
開発機には大概トランザクション系のデータは少ないので、気づきづらいですが、テスト機や本番機で、驚くほど処理時間が延長することがあるので注意が必要です。
ではまた
hama
- カテゴリ: SAP情報