Oracle DBアップグレードの実践的手法〜パッチ適用、データ移行、ダウンタイム短縮の手法：データベース運用管理をクラウド化する方法（2）（3/5 ページ）

データベースをプライベートクラウドの構築に最適なOracle Database 12cに移行する際には、アップグレード作業をいかに円滑に行うかが重要なポイントとなる。また、高い安定性を確保するためのパッチ適用も忘れてはならない。今回は、Oracle Databaseの最新アップグレード手法とパッチ適用のベストプラクティスを紹介する。[プライベートクラウド/データベース統合][Oracle Database 12c][Oracle Multitenant]

[PR／＠IT]

データベース移行の極意

　ここからは、アップグレード作業に伴うデータベース移行、データ移行の方法を見ていこう。

データベース移行ツール「Data Pump」とは？

　アップグレードでは、既存のデータベースを別の環境に移す作業がしばしば発生する。最も多いケースは、現行サーバーの保守切れに伴う新規サーバーへの移行だ。この作業では、主に次のような手段を使うことができる。

• export/import
• Data Pump
• トランスポータブル表領域
• フルトランスポータブルExport/import
• Oracle GoldenGate

　export/importは、Oracle Databaseで古くから提供されている手法であり、移行元のデータベースをダンプファイルとして出力し、それを移行先のデータベースに取り込むというものだ。ただし、Oracle Database 11g以降ではexportコマンドをサポートしていない（ユーティリティとしてインストールはされる）。また、パフォーマンスも後述のData Pumpに比べて大きく劣る。古いバージョンのOracle Databaseを最新バージョンに移行するといった場合以外では、export/importを使うケースはないだろう。

　Oracle Database 10g以降では、export/importに代わるツールとしてData Pumpが提供されている。これはexport/importと似たツールだが、パラレル処理をサポートするなど高速化されているほか、APIによる呼び出し、ジョブ管理／状況監視、停止／再開といった操作が可能となっている。なお、export/importとの間に互換性はなく、exportで出力した旧バージョンのメタデータをData Pumpで読み込むといったことはできないので注意されたい。

　Data Pumpの便利な機能に、移行元のデータベースを直接読み込める「Network Link」がある。同機能を使えばエクスポート処理が不要となるため、作業時間を短縮できる。特に大きなデータベースで有効な機能であり、ネットワークの帯域幅を十分に確保でき、移行先ハードウエアのCPUが高速な場合には検討する価値があるだろう。

「トランスポータブル表領域」による移行では追加オブジェクトの作成が必要

　Oracle Database間で表領域を移動させる「トランスポータブル表領域」を使う方法もある。具体的な手順としては、まず表領域のメタデータを出力し、それとデータファイルを移行先データベースに転送する。次にメタデータをインポートしてデータファイルを読み込み、さらに追加オブジェクトを作成するといった具合になる。

　Data Pumpの場合、ダンプファイルのサイズはデータ量に依存するが、トランスポータブル表領域ではファイルサイズはデータベースのデータファイルそのものであり、データの転送時間を高い精度で予測できる。このことは、停止計画を立案する際に非常に有用である。

　トランスポータブル表領域を使う場合に肝となるのは、追加オブジェクトの作成だ。シノニムやシーケンス、PL/SQLのパッケージなどのオブジェクトはトランスポータブル表領域では移行できないため、追加オブジェクトとして作らなければならない。したがって、これらのオブジェクトが大量にあるデータベースでは、作業量が増える上に抜けや漏れのリスクが大きくなる。

　なお、エンディアンが異なる環境にトランスポータブル表領域でデータベースを移行する場合は、当然ながらエンディアンの変換が必要となる。その際に有効なのが、Oracle Databaseの標準バックアップツール「RMAN」だ。同ツールで移行するデータファイルの変換処理を行った後、メタデータをインポートし、エンディアンを変換したデータファイルを読み込むという流れになる。エンディアンの変換処理には長時間（条件次第だが、おおよそバックアップと同程度の時間）を要するので留意されたい。

　増分バックアップを使い、データファイルの転送とエンディアンの変換にかかる時間を短縮するというテクニックもある。この場合は、まずフルバックアップを転送／変換する。その後は日々のバックアップで取得した増分バックアップを転送し、移行先の環境でエンディアンを変換して適用するという作業を数日間、繰り返す。そして、移行のタイミングでメタデータと最後の増分バックアップを転送し、メタデータのインポートと追加オブジェクトの作成を行った上でデータベースを切り替える。

　このようにして、データファイルの転送とエンディアン変換処理を事前に行っておくことで、移行にかかる時間を短縮するわけである。まだ実績の少ない方法だが、トランスポータブル表領域を使って短時間で移行したいという場合には検討する価値があるだろう。