第4回:Import最適化:SAPマイグレーションのダウンタイム変動要素

 2010.01.23  リアルテックジャパン

マイグレーションのダウンタイムに関するブログ4回目は、インポート時間の短縮について書いていきたいと思います。

前回(第3回)でも触れましたがインポートのチューニングをするのは、エクスポートよりもインポートに時間がかかるという前提がありますので、まずはインポートの負荷特性を押さえることが必要です。
なお、R3load 4.6D以下と620以降でデフォルトの動作は異なり、DDL*.TPLを変更することで動作を変えることは可能です。

R3load 4.6D以下:

 Create Table → ダンプの読み出とInsert → Create Index(プライマリインデックス) → Create Index(セカンダリインデックス)

 R3load 620以降:

Create Table  → Create Index(プライマリインデックス) → ダンプの読み出しとInsert → Create Index(セカンダリインデックス)

処理時間で言えばInsertが終わってからプライマリインデックスを生成する4.6D以前よりも620以降の方が短くなります。ただしロック数が増えるので大規模システムでは注意が必要です。


次に各フェーズでのシステム負荷特性を説明します。

・Create Table → 一瞬で終了

・Insert → テーブルの大きさに依存。

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

R3loadで1プロセスとRDBMSに1プロセス(スレッド)分のCPU負荷がかかります。

Insert中はエクスポートダンプのDBログに書き込み負荷がかかります。(例外としてInformixはNoLogというモードで打ち込むため、Logに負荷はかかりません。)

Commit時にデータファイルへ書き込みが発生します。

これを延々と繰り返します。ダンプの負荷はよほど遅いディスクでなければ気にする必要はありません。Insertで注意すべきことは、ある程度以上の並列数でInsertを実行すると、Log用のディスクに書き込みが集中して過負荷になります。基本的にシーケンシャルアクセスなので、ストレージが過負荷になるというより、RDBMSのLog書き込みスレッドが一つしかないことで、限界に達すると思われます。Oracleはロールバックのために、PSAPUNDOが使われますが、この処理では気にする必要はないでしょう。メモリは大量に消費しません。

・Create Indexはフェーズによって異なります。

フルスキャン→ソート→データ格納という順序で動作します。フルスキャンでは全データの読み込み動作をしますので、大変高いディスク読込負荷がデータファイルにかかります。ソートはRDBMSによって使う場所が異なります。
メモリはテーブルサイズに依存して大量消費します。そして足らない分を、OracleはPSAPTEMP、SQL Serverは(TEMPDBではなく)データファイルの一時領域を消費します。最後にデータ格納を行いますが、Logとデータファイルに書き込み負荷がかかりますがそれほど高い負荷ではありません。2次インデックスも基本的に同じ動作をします。
そして、上記の動作はインデックスやRDBMSのバッファ状況によって、使われ方が異なることも分かっています。基本的にCreate Indexの生成時間を短縮するために、インポート中は物理メモリをRDBMSに振り分けて下さい。R3loadがセッションを張るためのメモリが無くなってしまうような限界チューニングはしないで下さい。そして、Create Indexの処理でディスク負荷やメモリ消費に競合が起こらないように時間差をつけて投入すると、全体の処理時間短縮につながります。ただし、これを完璧にするのは大変難しいことです。


インポートを実施するときの配慮点として方針は下記の通りです。

・ メモリ/CPU/ディスク負荷バランスの均衡
システムリソースは一箇所で渋滞が起こると、プロセスの進捗が滞って、別のリソースも使われなくなります。そして、全体の処理時間がいたずらに伸びます。Insertは比較的、安定した負荷でメモリ消費も少なく動作しますが、Create Indexは極端な負荷がかかりがちなので、分散するように配慮しています。例えば、大規模テーブルを複数個同時にCreate Indexをかけないようにスケジューリングします。

・ 如何に早くインポートを始めるか
エクスポート順序を大きなテーブル順で実行してしまうと、エクスポートが終了するテーブルがなかなか出現せず、インポート出来ない状況が生まれます。そのため、時間的にネックとなるテーブルと中小の早くエクスポート終わるを最初にエクスポートさせて、中小のテーブルでインポート側を早い段階で高負荷に持って行けば、全体の時間圧縮につながります。

なお、実際のプロジェクトでは初回構築テスト時にエクスポートやインポートの処理時間が分かるので、その実績データをもとに次回の処理スケジュールを組むのがオーソドックスな進め方になります。


最後に固定的な法則を書いておきます。

・ 可変長テーブルはインポートが速い。R3loadのCPU負荷も高い。Create Indexも早く終る。2次インデックスも無いので、後半でのエクスポート/インポート向き。

・ フィールドの多い透過テーブルはエクスポートが遅いが、インポートも遅い。

・ 大規模システムの場合、チューニングにより追加インデックス(~Z01など)が多いので、インポートは大変になることが多い。

・ CPUが数秒間負荷0になるのはディスク能力がCPUに負けているサイン。頻繁なら並列度を落とすべきである。

ではまた

hama


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


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

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング

ブログ購読のお申込み