今回から何回かにわけてマイグレーションのダウンタイムに関するエキスパート向けブログを始めることになりました。
エキスパート向けに書いていますので、かなり難解なところがでてくるかもと思いつつ、作業に直接携わるエキスパートの方にとっては有益な情報になると思います。
マイグレーションと言っても定義はベンダーによって異なり、ここでの定義は、
・基本的にはSAPのR3loadを使ってエクスポートとインポートを実施する
・OSまたはDBまたはその両方が変更になる
になります。
今回のブログではOS/DB未変更でも、エクスポートとインポートを行うのであれば多少の参考になるのではないかと思われます。
まず、何から話しましょうか・・・
ダウンタイムを短縮するには、色々なノウハウが存在します。
そして、その効果は大小様々であり、いかにそのプロジェクトでノウハウを詰め込めるかで、最終的なダウンタイムは決まってきます
・不必要な処理はダウンタイム外で処理を行う
・エクスポートを速くする
・インポートを速くする
・補足処理を早く終わらせる
しかし、ダウンタイムを短くする前に、最も重要なことはデータベースの整合性を保つことです。ツールの効果を見切る前に、ツールの特性を見抜く必要があります。SAPのマイグレーションに関するNotesが非常に保守的な原因は、ツールの活用に失敗して、システム不整合を招いているケースが多いからだと思われます。
例えば、エクスポートが中断したときSAPは、SAP*.TOC,SAP*.nnn(001などの数字),SAP*.logを全て削除してから、エクスポートを再実行して下さい、とあります。この原因は、SAP*.TOCへテーブルとダンプの情報が書かれたあと、SAP*.nnnへダンプを書き込む、という順番で書き込むこと原因です。SAP*.TOCへ書いたあと、SAP*.nnnへダンプを書き込む前にR3loadが止まってしまうと、あたかもそのテーブルのエクスポートが成功したように見えて、ダンプが正常に書き込まれていないことがあります。
このとき、エクスポートは再実行によってログ上は成功していますが、インポート時にダンプの不整合で失敗します。
このあたりをいかに未然に対処し、また起こった場合にいかに迅速な対応できるかというところはマイグレーション・コンサルタントの経験と力量次第になることはいうまでもありません。
次回から各フェーズでダウンタイムを短くするための概念をお話しようかと思います。
ではまた
hama
