2年ぶりにブログを書くことになりました。
OS/DBのMigration件数も一時期に比べると少し落ち着きを取り戻している感じです。
最近では5年位前にMigrationしたお客様から新しいシステムへ入れ替える案件なども対応させて頂くことも多くなり、今回はOS/DB Migrationに限らずExport/Importによるシステムコピーも含めています。
またR/3 4.6C以下のMigrationは非常に希なケースとなり、BASIS 620/640ベースのR/3 4.7やBW 3.5や70xベースが主流になった結果、最近はR3taを使ってTable Splitterを使うことも出てきました。
今回は、Table Splitter（R3ta）を取り上げたいと思います。
R3ta．．．難しいですね。というのも、Table Splitterを使うと、相対的なディスク負荷が上昇するからです。昨年SQL ServerでTB越のシステムコピーをExport/Importで実施しました。初回構築はサイズ上位テーブルを5～11に分割して18並列でExportしたところ、ソート有りで14時間余りかかりました。
初回構築で観察していたとき、どう見てもCPUが張り付く前にディスクが過負荷だったので、リハーサルでは並列度を12に下げました。13時間弱に短縮されました。ディスクが過負荷な状態で並列度を上げるとかえって遅くなるといういい例です。それでもダンプの出るスピードに波があったので、これはまだディスクが過負荷だと思いました。そこで、本番ではTable Splitterを一切やめたところ、11時間ちょっとで終わりました。エクスポート開始後6時間あたりでインポートが追い付かなくなるので、後半は小さなダンプは後回しにして、時間がかかる大きなテーブルのインポートを先に入れて、負荷調整的に小さなダンプを投入したので、Table Splitterをかけてもかけなくてもインポート終了は変わらずという結果で終わりました。この時の旧本番機はお客さんから「ディスク遅いよ。」とは聞いていたので、この時はTable Splitterを使わない方が早くなった例ですが、他の案件では逆に短縮出来た案件もあるので、ストレージ能力とお客さんのシステムを見極めて計算することが大事だということです。
次はSQLServer のデータベース圧縮を取り上げたいと思います。
ではまた。
hama
