翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Oracle データベース移行戦略
<a name="strategies"></a>

大まかに言うと、Oracle データベースをオンプレミスから に移行するには AWS クラウド、Oracle にとどまる (*同種移行*) か、Oracle から移行する (*異種移行*) の 2 つのオプションがあります。同種移行では、データベースエンジンは変更しません (つまり、移行先のデータベースもオラクルデータベースである)。異種移行では、MySQL、PostgreSQL、MariaDB などのオープンソースデータベースエンジンに切り替えるか、Amazon Aurora、Amazon DynamoDB、Amazon RedShift などの AWS クラウドネイティブデータベースに切り替えます。 

Oracle データベースを に移行するための一般的な戦略は、 AWSリホスト、リプラットフォーム、リアーキテクト (リファクタリング) の 3 つです。これらは[アプリケーション移行戦略の 7 R](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/planning-phase.html) の一部であり、以下の表で説明されています。


|  |  |  |  | 
| --- |--- |--- |--- |
| **方針** | **タイプ** | **いつ選択するか** | **例** | 
| **リホスト** | 同種 | オペレーティングシステム、データベースソフトウェア、または構成の変更の有無にかかわらず、オラクルデータベースをそのまま移行したいです。 | オラクル・データベースから Amazon EC2 へ | 
| **リプラットフォーム** | 同種 | データベース・アズ・ア・サービス (DBaaS) を利用することで、データベース・インスタンスの管理に費やす時間を短縮したいです。 | オラクル・データベースから Amazon RDS for Oracle へ | 
| **リアーキテクト (リファクタリング) ** | 異種 | オープンソースおよびクラウドネイティブのデータベース特徴量を活用するために、データベースとアプリケーションを再構築、再書き込み、リアーキテクトしたいと考えています。 | Oracle データベースから Amazon Aurora PostgreSQL、MySQL、または MariaDB へ | 

## 適切な移行戦略を選択する
<a name="choose-strategy"></a>

正しい戦略の選択は、ビジネス要件、リソースの制約、移行のタイムフレーム、コストの考慮によって決まります。次の図は、6 つの戦略を含む移行に関わる労力と複雑さを示しています。 

 ![\[Comparison of Oracle Database migration strategies\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-oracle-database/images/migration-strategy-comparison.png) 

Oracle データベースをリファクタリングし、Amazon Aurora PostgreSQL 互換エディションや Amazon Aurora MySQL 互換エディションなどのオープンソースまたは AWS クラウドネイティブデータベースに移行すると、データベースのモダナイズと最適化に役立ちます。オープンソースのデータベースに移行することで、高価なライセンス (結果的にコスト削減につながる) 、ベンダーのロックイン期間、監査を避けることができ、新機能のために追加料金を支払う必要もなくなります。しかし、ワークロードの複雑さによっては、オラクルデータベースのリファクタリングは、複雑で時間がかかり、リソースを大量に消費する作業となる可能性があります。 

複雑さを軽減するために、データベースの移行を一度に行うのではなく、段階的なアプローチを検討するとよいでしょう。最初の段階では、データベースのコア機能に集中することができます。次のフェーズでは、追加の AWS サービスをクラウド環境に統合してコストを削減し、パフォーマンス、生産性、コンプライアンスを最適化できます。例えば、オンプレミスのOracle データベースを Aurora PostgreSQL 互換に置き換えることが目的であれば、最初のフェーズでは Amazon EC2 上でデータベースをリホストするか、Amazon RDS for Oracle 上でデータベースをリプラットフォームし、その後のフェーズで Aurora PostgreSQL 互換にリファクタリングすることを検討するかもしれません。このアプローチは、移行フェーズではコスト、リソース、リスクを削減するのに役立ち、第 2 フェーズでは最適化とモダナイズに重点を置きます。

## オンラインとオフラインの移行
<a name="online-offline"></a>

移行タイムラインと許容できるダウンタイムに基づいて、Oracle Database をオンプレミス環境から AWS クラウドに移行するには、オンライン移行とオフライン移行の 2 つの方法を使用できます。
+ **オフライン移行：**この方法は、アプリケーションに計画的なダウンタイムを許容できる場合に使用されます。オフライン移行では、移行期間中はソースデータベースがオフラインになります。ソースデータベースがオフラインのときは、ターゲットデータベースに移行されます AWS。移行が完了すると、確認と検証のチェックが行われ、ソースデータベースとのデータ整合性が確保されます。データベースがすべての検証チェックに合格したら、アプリケーションをターゲットデータベースに接続 AWS してカットオーバーを実行します AWS。
+ **オンライン移行：**この方法は、アプリケーションのダウンタイムをゼロに近いか最小限に抑える必要がある場合に使用されます。オンライン移行では、ソースデータベースは複数のステップで移行されます AWS。最初のステップでは、ソースデータベースがまだ稼働している間に、ソースデータベース内のデータがターゲットデータベースにコピーされます。以降のステップでは、ソースデータベースからのすべての変更がターゲットデータベースに反映されます。ソースデータベースとターゲットデータベースが同期すると、カットオーバーの準備が整います。カットオーバー中、アプリケーションはターゲットデータベースへの接続を切り替え AWS、ソースデータベースへの接続を残しません。 AWS Database Migration Service (AWS DMS)、Oracle GoldenGate、Quest SharePlex、または から利用可能なツール [AWS Marketplace](https://aws.amazon.com/marketplace/) (Attunity など) を使用して、ソースデータベースとターゲットデータベースを同期できます。