データベースサーバリプレイスの考え方：ゼロからのリレーショナルデータベース入門（12）（3/3 ページ）

» 2021年05月31日 05時00分公開

[佐瀬力，株式会社アシスト]

データ移行手段の選択

　新環境構築にめどを付けたら、次に考えなければならないポイントが「データ移行作業」です。これは、現行環境のデータベースを新環境に移植するための作業です。当然のことながら、データベースとして整合性の取れた状態として移植する必要があります。

　最初にデータベースのデータ規模とシステムの停止可能な時間について検討します。

　データ移行作業では通常、純正機能の「Exportユーティリティ」（以下、expdp）／「Importユーティリティ」（以下、impdp）が用いられます。この方法には、製品バージョン間の差異やOS種別の差異を吸収してくれることに加え、ディスク領域の断片化を解消するといった効果があります。その半面、実行時間がデータ量に比例して長くなるという問題もあります。

　このため、移行方式の検討フェーズでexpdp／impdpコマンドを実行し、それぞれの実行時間がシステムの停止時間内に収まるかどうかの検証が必要です。

　データ移行方式の検討フェーズでは、図4のようにデータ移行作業だけではなく、稼働しているシステムの停止などの事前準備、作業後のデータ整合性チェックやアプリケーションの動作確認なども含めて考えなければなりません。

図4　データ移行によるシステム停止時間

　expdp／impdpコマンドでの移行方式を検討した結果、不運にもシステム停止時間をオーバーしてしまうケースがあります。その場合には、代替となるデータ移行手段を探すことになります。

　例えば、データベースのバージョンやOS種別が現行環境と新環境で全く同一の場合、データファイルなどのデータベースを構成する物理ファイルをそのままコピーしてしまう方法があります。この方法ではコールドバックアップとして取得したバックアップセット一式を別のサーバに移植するため、余分な処理を介さず作業時間を短縮できます。また、製品純正機能ではトランスポータブル表領域という機能もあります。こちらも利用に当たっては幾つかの前提条件がありますが、それらをクリアしている場合には、expdp／impdpを用いた場合よりも作業時間を短縮できる場合があります。

図5　データの移行手段


データ移行手段	概要	メリット	考慮点
Export／Import	expdp／impdpユーティリティを用いた移行手段。データベース全体を対象とするモードの他に、スキーマやオブジェクト単位での実行も可能	Oracle Databaseのバージョン差異や、OS環境の差異などを吸収する他に、断片化解消も可能	作業時間がデータ量に比例して長くなる
データベース構成ファイルのコールドコピー	正常終了した状態で取得したデータベース構成ファイルを新環境にコピーし移植する手段	シンプルな作業手順で実施できる。新／旧環境での移行後の整合性チェックが最小限で済む	新／旧の環境を完全に一致させるなど、採用できるケースは限られる
トランスポータブル表領域	「RMAN」（Recovery Manager）を利用して取得した表領域のメタデータとともに、データファイル単位で新環境にコピーし移植する手段	ストレージ機器の筐体間コピー機能などを併用することで、データコピーにかかる時間を短縮可能	未使用領域もコピーの対象となり、断片化状態もそのまま移植されてしまう
「DBLINK」経由でのダイレクトロードインサート	新／旧データベース間に作成したDBLINK経由で接続し、ダイレクトロードインサートを用いて旧環境から新環境にデータをコピーする手段	中間ファイルを生成せずにデータをコピーでき、条件によっては簡易な作業で高速化を実現可能	作業時間が利用するネットワークの回線速度に依存してしまう。
アンロードツール（csv出力）と、「SQL*Loader」の利用	専用ツールを用いてデータベースのデータをcsv出力させ、それを新環境にコピーしてSQL*Loaderなどでロードする手段	専用ツールによるアンロードの高速性と、ロードの並列処理による作業時間短縮が見込まれる	外部参照などオブジェクト間の依存関係を作業者が考慮する必要がある
データ同期製品の利用	「Oracle GoldenGate」などのデータ同期製品を利用して新環境にデータを移行する手段	事前にデータが同期されている状況を作ることができるため、切り替え時間が非常に短い	同期中の正常性確認が必要となる。また、サポートされていない処理やオブジェクトがないかどうかを事前に確認する必要がある
表1　データ移行手段の特徴

作業に問題が発生したときの切り戻し計画

　今回「データベースサーバリプレースの考え方」と題して、リプレースに際して検討すべき事項の基本的な考え方を説明しました。新環境の構築では、そのハードウェアやOSの選定からサイジング、データベースのバージョン選定や構成の検討など、将来の安定運用に関わる重要事項の決定が次々に待ち構えています。

　最後に、リプレース作業を計画するに当たって最も重要な、リプレース作業に問題が生じた際の切り戻し、および復旧方法について触れておきます。

　リプレース作業において最も大事なことは、時間内に作業を完了し、予定通りシステムを再開させることです。そして、リプレース作業が完遂できない事態に陥った場合にも、システム再開の期限は必ず守られなければなりません。そのための準備が、問題発生時の切り戻し、復旧手順の確立、そして作業工程表への「切り戻し最終期限」の組み込みです。

　例えば、切り戻し先を現行環境（旧環境）とする場合で考えてみます。

　まず、実施したデータ移行作業をロールバックして、再び旧環境を正常稼働させるために必要な時間を見積もります。それを基に、サービス再開の予定時刻から逆算した「確実に旧環境に戻せる時刻」を切り戻し最終期限としてマイルストーンを設定します。そして、そのマイルストーンまでにリプレース作業の全工程が完了していない場合には無条件に旧環境への切り戻しを実施する、といったルールを設定します。これによって、システム再開の期限を確実に守ることができます。

　実際には作業を仕切り直した場合のコストなども考慮し、作業の進行状況を都度確認しながら「ここまで進んでいれば本番稼働に影響はない」といった現場レベルの判断も必要になりますが、基本となるルールがあいまいな状態では適切な判断はできません。客観的な判断基準を備えた、マイルストーンの設定を心掛けてください。

　今回をもって、「ゼロからのリレーショナルデータベース入門」（2018年度版）を一区切りとさせていただきます。ご高覧いただきました読者の皆さま、誠にありがとうございました。

　本連載では、リレーショナルデータベースの基本構造の解説からスタートし、耐障害性やセキュリティなどの非機能要件を含めて、データベースを取り扱う際に必要となるトピックをできるだけ実業務に近い目線で幅広く取り扱ってきたつもりです。その1つでも、皆様の日々の業務に役立つことができれば幸いです。