SAPマイグレーションのダウンタイム変動要素に関するブログ2回目は、ダウンタイム期間内に実行が不要な処理に関して書いていきたいと思います。
マイグレーションの作業順序を書いてゆくと、まず現行システムで行う処理として
・ マイグレーションキットのインストール
・ 統計情報更新(DB依存)
・ R3ldctl実行
- STRファイル(テーブル構造)取得
- DDL(テーブルとインデックス作成テンプレート)ファイル生成
- テーブルDDLOADD内容生成
- STRリストファイル生成
・ EXTファイル(テーブルサイズ)取得
・ STRファイルの分割
・ テーブルスプリッタ用ファイルの生成(カーネル640以降)
・ エクスポート領域のフォルダ作成
・ エクスポート領域へのSTR, ファイルコピー
・ JAVAインストール(必要時)
・ Migration Monitor, Distribution Monitorの設定(必要時)
・ エクスポート実施
・ DBSIZE.TPL(カーネル4.6Dまで)、DBSIZE.XML(カーネル620以降)生成
上記の作業でダウンタイムに行わなければならないものは、エクスポートの実施のみです。
言い換えれば個々の処理の内容を技術的に見切る（=この処理は何を目的としていて、アウトプットは何か、それはいるのかいらないのか、そしてそれはいつ実行可能なのかを理解する）ことで、必要ダウンタイムの短縮を実現することが可能です。
Migration先の新システムで行う処理としては
・ RDBMSのインストールとパッチ適用
・ セントラルインスタンスのインストール
・ セントラルインスタンスのクラスタ化(カーネル640まで)
・ メッセージサーバのクラスタ化(カーネル700以降)
・ OSユーザの作成
・ DB作成
・ インポート実施
・ ビュー作成
・ R3SETUP, sapinstの後処理実施
・ RDBMSのクラスタ化(必要時)
・ マイグレーションの補足処理
上記でダウンタイムに実施が必要な処理は、インポート実施以降になります。
このあたりも個別の作業を技術的に細かく見切ることで、旧システムで行ったのと同様にダウンタイムの短縮を実現することが可能です。
REALTECHがマイグレーションを実施するとなぜ早く終わるのかの理由の一端を垣間見て頂けましたでしょうか？
実は細かいチューニング作業の積み重ねで実現していますので、端から見るとかなり地味です。
私的にはかなり派手と思うのですが；）
ではまた
hama
