第1回:序章:SAPマイグレーションのダウンタイム変動要素

 2009.12.28  リアルテックジャパン

今回から何回かにわけてマイグレーションのダウンタイムに関するエキスパート向けブログを始めることになりました。

エキスパート向けに書いていますので、かなり難解なところがでてくるかもと思いつつ、作業に直接携わるエキスパートの方にとっては有益な情報になると思います。

 マイグレーションと言っても定義はベンダーによって異なり、ここでの定義は、

      ・基本的にはSAPのR3loadを使ってエクスポートとインポートを実施する

      ・OSまたはDBまたはその両方が変更になる

になります。

今回のブログではOS/DB未変更でも、エクスポートとインポートを行うのであれば多少の参考になるのではないかと思われます。

まず、何から話しましょうか・・・

SAPシステムパフォーマンス分析パック
導入事例:日本マタイ株式会社

ダウンタイムを短縮するには、色々なノウハウが存在します。

そして、その効果は大小様々であり、いかにそのプロジェクトでノウハウを詰め込めるかで、最終的なダウンタイムは決まってきます

      ・不必要な処理はダウンタイム外で処理を行う

      ・エクスポートを速くする

      ・インポートを速くする

      ・補足処理を早く終わらせる

しかし、ダウンタイムを短くする前に、最も重要なことはデータベースの整合性を保つことです。ツールの効果を見切る前に、ツールの特性を見抜く必要があります。SAPのマイグレーションに関するNotesが非常に保守的な原因は、ツールの活用に失敗して、システム不整合を招いているケースが多いからだと思われます。

例えば、エクスポートが中断したときSAPは、SAP*.TOC,SAP*.nnn(001などの数字),SAP*.logを全て削除してから、エクスポートを再実行して下さい、とあります。この原因は、SAP*.TOCへテーブルとダンプの情報が書かれたあと、SAP*.nnnへダンプを書き込む、という順番で書き込むこと原因です。SAP*.TOCへ書いたあと、SAP*.nnnへダンプを書き込む前にR3loadが止まってしまうと、あたかもそのテーブルのエクスポートが成功したように見えて、ダンプが正常に書き込まれていないことがあります。

このとき、エクスポートは再実行によってログ上は成功していますが、インポート時にダンプの不整合で失敗します。

このあたりをいかに未然に対処し、また起こった場合にいかに迅速な対応できるかというところはマイグレーション・コンサルタントの経験と力量次第になることはいうまでもありません。

次回から各フェーズでダウンタイムを短くするための概念をお話しようかと思います。

ではまた

 hama

導入事例:日本航空株式会社

RECENT POST「データ移行」の最新記事


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

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング

ブログ購読のお申込み