マイグレーションのダウンタイムに関するブログ3回目は、エクスポート時間の短縮について書いていきたいと思います。
エクスポートの短縮する大前提として、「インポートの方が速い」ということが挙げられます。エクスポートとインポート処理量は、全く同じ能力のサーバならインポートはCreate indexが必要なため、２．５～３倍程度の処理が必要になります。通常、現行システムよりも新システムの方が能力は高いですが、その能力差が２．５倍以上でなければ、インポートの高速化を考えなくてはいけません。それは次回以降に書いていこうと思います。エクスポート処理はフルスキャンです。基本的にRDBMSのメモリチューニングはほとんど効かないというのが経験則です。ディスク読み込みの効率化に効くパラメータは若干効く時がありますがそれでも数％程度でしょう。
ということで最もエクスポートで重要なファクターは、並列度の決定です。
エクスポート中にかかる負荷は
・ RDBMSが消費するCPU
・ R3loadが消費するCPU
・ プライマリインデックス読み出し時のディスク読み込み
・ データ読み出し時のディスク読み込み
・ データソートに伴うディスク読み書き
・ エクスポートダンプ書き込み時のディスク書き込み
あたりが挙げられます。
エクスポートダンプの操作は、R3loadが圧縮をするため、それほど高い負荷はかかりません。しかし、極端に書き込みが遅いディスクやネットワーク回線が遅いリモートホストへの書き込みは、エクスポート時間を遅くする要因にもなり得ます。
エクスポート時間を左右するものとして、カーネル46D以下の場合、最もエクスポートに時間がかかるテーブルの存在です。例えば、BSISというテーブルだけ16時間かかって、その他全てのテーブルは12時間でエクスポートされる場合、BSISの16時間をいかに短縮するかが重要です。並列度は上げれば上げるほど、一つの処理速度は遅くなります。この場合は、並列度を下げて競合を減らし、個々の処理速度をある程度の速度で維持してあげる必要があります。逆にBSISが12時間以下ならCPUかディスクの負荷限界まで、並列度を上げた方が良いでしょう。システムに依存して、アプローチは異なります。
RDBMSの特性も考慮する必要性があります。
OracleやDB2の場合、テーブルによって格納されているテーブルスペース/コンテナは異なります。よって、同じディスクへのアクセスをなるべく減らした方が、エクスポートは速くなります。また、通常のエクスポートでは、テンポラリ領域へ高い負荷がかかるため、この対応も重要です。エクスポートする順序の調整は負荷分散の役割もあります。
SQL Serverの場合、データとインデックスが同じ場所に格納されているため、全体としてある程度ディスク本数が確保されている場合、ディスク負荷ネックになりにくくなっています。そのため、CPU負荷を考えて並列度を決定した方が良いでしょう。SAPDBも動きは似ています。Informixはブロックサイズが小さいためか、CPUが他のDBに比べると消費が激しい傾向があります。
色々と書いてしまいましたが、重要なことは、CPU/ディスクなのか、単体テーブルの処理時間がネックなのかを見極める。ここから次回エクスポートする時の対応方法が分かれます。
そして、いかに過負荷ではない、高い負荷を維持するかが重要です。普段からCPU/ディスクの動きを観察しておくと、そのヒントは良く見えます。
とりあえず、固定的な経験則を書いておきます
・ インデックスを再構築したテーブルのエクスポートは速くなる
・ FI/COのみシステムはデータが集中するのでエクスポート時間は長くなることが多い
・ クラスタテーブルとLrowを持つテーブルはスキャンが遅いことが多い。R3loadのCPU負荷が高い。そしてダンプが大きい。
・ フィールドの多い透過テーブルもスキャンが遅いことが多い。R3loadはCPU負荷のかかりが悪い。ダンプの出るスピードも悪い。
・ 適切なチューニングが行われる前提において、大概のシステムは48時間以内にマイグレーションは完了する。
これからハードウェアの進化により、新たな概念が出来ると思われます。一つの固定概念にとらわれずに取り組むことも重要だと思われます。
ではまた
hama
