The database migration “journey”#
データベースの移行は、9つのステップの「ジャーニー」で構成されています。
Migration journey#
1.移行することを決定する#
最初に、組織は移行することを決定する必要があります。古いデータベースシステムにお金を費やしすぎていると判断する場合があります。現在のデータベーステクノロジーで十分にサポートされていないイニシアチブがある可能性があります。または、クラウドに移行するか、オープンソースソフトウェアを利用したいと考えている場合もあります。これらは、移行のビジネスケースにつながる可能性のある一般的な要因です。
ビジネスケースがあり、組織がそれに同意したら、組織は移行の実行にコミットする必要があります。コミットメントには、移行を実行するための資金とリソースが含まれます。
2.実現可能性と代替案を分析する#
代替案を分析し、特定のデータベースへの移行の実現可能性を検討します。
アプリケーションポートフォリオを確認して、すべてのアプリケーションを移行するかどうかを判断します#
このレビューの一部として、移行可能な古いデータベースを持つアプリケーションを確認します。移行の優先順位をIT戦略と調整して、これらが移行を検討する十分に重要なビジネスアプリケーションであることを確認します。
アプリケーションポートフォリオを確認する一環として、一部のアプリケーションをリタイアしてもよいと決定する場合があります。ポートフォリオには、移行したいが、既存のデータベースでのみサポートされているためできないアプリケーションが存在する可能性があります。
移行するアプリケーションの候補セットを特定するときは、それらを移行したいということは、移行を完了するという組織のコミットメントに対応している必要があることに注意してください。時間、リソース、予算が必要です。
各アプリケーションの移行ターゲットとしてどのデータベーステクノロジが適切な選択であるかを評価します#
多くの場合、 EDB Postgres Advanced Serverは、 Oracleに代わる理想的な選択です。ただし、一部のアプリケーションには、他のソリューションで対処したほうが良い可能性のある要件があります。
ターゲットデータベーステクノロジの適切なセットを選択した後、後続の手順は、移行がどの程度複雑になるかについてのより詳細な評価を実行することです。 EDB Postgres Advanced Serverが潜在的なターゲットである場合、 EDB移行ポータルを使用して、データベース内のOracleスキーマおよびプロシージャオブジェクトとEDB Postgres Advanced Serverとの互換性を評価できます。この情報は、旅の次のステップで重要です。
アプリケーションの優先順位付け#
大規模なアプリケーションの移行を検討している場合は、第1レベルパスを実行して、最初に移動するアプリケーションを特定します。移動する方がリスクが高いほど重要なものもありますか？また、移行の難易度を確認し、それに基づいて優先順位を付けることもできます。
移行のターゲットとするホスティング環境を決定する#
EDB Postgres Advanced Serverデータベースをホストするためのオプションの詳細については、 インフラストラクチャの考慮事項 を参照してください。現在オンプレミスで実行されていますか？オンプレミスに残りますか、クラウドに移行しますか？それとも、クラウド上にありますが、おそらくそれがうまくいかず、オンプレミスまたは別のクラウドプロバイダーに移動する必要がありますか。
潜在的な移行の問題を特定する#
ソリューションのより徹底的なレビューを実行して、旅の後半で発生する特定の互換性問題に対処しますが、この初期段階で潜在的な移行問題を特定することも重要です。 OracleからEDB Postgres Advanced Serverの移行の場合、詳細については Comparison of EDB Postgres Advanced Server with Oracle を参照してください。
このステップの主な目標は次のとおりです。
どのアプリケーションが移行の適切な候補であるかを理解します。
移行のためのさまざまなテクノロジーとベンダーオプションを分析します。
すべての移行を完了するまでの全体的なレベルの労力、時間、およびコストの全体像を理解します。
また、現在のテクノロジーとプラットフォームを使用し続ける場合と、新しいテクノロジーとプラットフォームに移行する場合のコストも検討します。
3.移行を計画する#
移行の計画には、次のプロセスが含まれます。
移行するアプリケーションの優先順位付け。移行するアプリケーションを決定したら、移行する順序に優先順位を付けます。組織は、最も困難な移行を実行できれば、他のすべての移行が簡単になると考えているため、最も困難な移行を選択することを検討することがよくあります。ただし、通常は、自分にとって中程度に重要であり、必ずしも顧客にとって最も価値のあるものではなく、最も難しいものではないものを選択することをお勧めします。このようにして、プロセスから学ぶことができます。次に、最初の移行などから学んだことに基づいて次のものを選択し、最終的に最も価値があり最も難しいものに到達します。
パフォーマンス、可用性、管理、統合などの非機能要件の特定。
移行アーキテクチャと移行後アーキテクチャの両方を含む高レベルでのソリューションの設計。たとえば、データベース、プラットフォーム、移行の種類、高可用性要件などを選択します。
移行作業の見積もり。分析から、移行の実行にどのくらいの時間とリソースが必要かがわかります。
移行環境の準備。必要なソフトウェアを入手してインストールし、サーバー間の接続を確立します。
この手順に十分な注意を払うと、成功の可能性が高まり、移行プロセスの後半での不要な予期せぬ事態の数を減らすことができます。ソースシステムのアーキテクチャと実装に関する十分な知識を持つ人を含む移行チームを編成します。
4.データベーススキーマ、コード、およびデータを移行する#
アプリケーションデータベースの移行プロジェクトに関して、これは多くの場合最初に思い浮かぶ手順です。この手順では、実際のデータベースがソースシステムからターゲットシステムに移行します。データベースを移行するには、次の手順を実行する必要があります。
スキーマを移動する#
スキーマは、データがデータベースに保存および編成される構造を提供します。そのため、最初にスキーマを移動する必要があります。
スキーマを移行する場合、通常、Oracleデータベースに存在するスキーマオブジェクトとターゲットデータベースで作成できるオブジェクトに違いがあります。 Oracle機能に対するEDB Postgres Advanced Serverの互換性のため、他のターゲットデータベースオプションでは対処できない多くの互換性の問題が自動的に対処されます。
この手順の主なタスクは、互換性がないまたは自動的に変換できないスキーマオブジェクトの回避策を実装することです。スキーマオブジェクトは、 SQLベースのデータ定義言語DDLを使用して作成されます。 EDBの移行ポータルを使用して、Oracle DDLとEDB Postgres Advanced Serverの互換性を評価できます。また、評価プロセスの一部として適用される repair handlersを介していくつかの自動変換も実行します。
移行ポータル評価を実行した後の次のステップは、 DDL移行の結果を確認し、評価レポートで特定された問題を解決することです。
データベース機能つまりデータベースプロシージャルオブジェクトを移行する#
これには、データベースが使用するアプリケーションまたはトリガーによって呼び出されるプロシージャやファンクションなど、データベースに存在するコードが含まれます。スキーマオブジェクトと同様に、データベースコードオブジェクトもDDLを使用して作成されます。さらに、コードオブジェクトはスキーマオブジェクトと密接に関連付けられ、それらを参照するか、それらによって参照されます。したがって、データベースコードオブジェクトは、通常、他のスキーマオブジェクトと同時に移行されます。
他のスキーマオブジェクトと同様に、このステップの主なアクティビティは、互換性がないまたは自動的に変換できないデータベースコードオブジェクトの回避策を特定して実装することです。 Oracleのプロシージャ言語PL/ SQLは他のデータベースネイティブビルトイン言語とは異なるため、これは多くの場合、データベースの移行で最も困難なタスクになる場合があります、特にソースデータベースに大量のコードオブジェクトが含まれている場合、またはコードオブジェクトが構成されている場合多くの行の複雑なコード。ここで、最も一般的に使用されるPL/ SQL機能の多くをネイティブに提供するEDB Postgres Advanced ServerのPL/ SQL実装が重要になります。これらの機能は、この手順を完了するために必要な労力を大幅に削減できます。移行ポータルは、他のスキーマDDLに加えてOracleデータベースコードオブジェクトを評価し、互換性のないオブジェクトを更新および再評価する機能を備えています。
データベース内のデータを移行する#
データを移行する場合、2つの基本的なオプションがあります。 1つ目は、スナップショットプロセス特定の時点でのすべてのデータのコピーを使用して、目的のすべてのデータを移動することです。このオプションは、データベースが比較的小さい場合、または運用移行の場合、移行を完了するために必要なアプリケーションのダウンタイムが許容できる場合に選択されることがよくあります。
スナップショットレプリケーションを定期的に実行して、ターゲットデータベースの内容をソースデータベースの現在の内容でリフレッシュできます。ただし、このような定期的なリフレッシュでは、通常、以前にコピーしたすべてのデータをターゲットシステムから削除し、すべてのデータを再度移行する必要があります。 2番目のオプションは、変更データキャプチャCDC技術を使用して、継続的かつ継続的にデータを移行することです。すべての変更データキャプチャプロセスの一部として、初期ロードはある種のスナップショットによって実行されます。ただし、初期スナップショットの後、変更データキャプチャメカニズムを使用して、ソースデータベースで行われたその後の変更を識別し、変更をターゲットデータベースに転送します。 CDCベースのデータ移行オプションは、通常、最小限のダウンタイムが必要で、ソースシステムで行われるデータの変更とターゲットシステムの同期を保つことが重要な場合に選択されます。
EDB Migration Toolkitを使用してスナップショットタイプのデータ移行を実行し、EDB Replication Serverを使用してOracleからPostgresへのCDCベースのデータ移行を実行できます。スナップショットベースのデータ移行とCDCベースのデータ移行は2つの主なアプローチですが、他のハイブリッドまたはカスタムアプローチを使用して、2つの主要な方法では対応できない特別なデータ移行のニーズへのソリューションを提供できます。たとえば、データベースリンクを介したクエリまたはターゲットデータベースからソースデータベースへの直接接続を介してデータを取得することが役立つ場合があります。
5.インターフェイスとアプリケーションを移行する#
新しく移行したPostgresデータベースで動作するようにアプリケーションを変換します。アプリケーションは、データベースと対話するデータベースの外部のコードです。
アプリケーションの移行には以下が含まれます。
アプリケーション接続文字列とドライバーJDBC、ODBC、OCI、.NETなどの更新。 JDBCやODBCなどのオープン標準の接続を使用するアプリケーションは、通常、データベース接続文字列とEDBドライバーの選択の変更のみが必要です。ドライバーのインストールと、 EDB Postgres Advanced Serverデータベースに接続するようにアプリケーションの構成の詳細については、次のドライバー固有のドキュメントを確認してください。
EDB OCL Connector Oracle OCIドライバーのEDBバージョン
.NETアプリケーションの場合、Oracle .NETドライバーを使用するアプリケーションを更新して、Oracleドライバー固有のクラス名の呼び出しをEDBドライバーの同等の名前に置き換える必要があります。
アプリケーション内の埋め込みSQLの変換。 SQLは、ソースデータベースで動作するように構築されている可能性があります。 Oracleがサポートしている特定の構文がPostgresでサポートされていない場合がある場合があります。この場合、Postgresで動作するようにSQLを変換する必要があります。 EDB Postgres Advanced ServerおよびEDBドライバーに組み込まれているOracle機能とEDBの互換性により、必要な変換の量が削減されます。
必要に応じてアプリケーションコードを更新します。場合によっては、アプリケーションには、Postgresドライバーでは使用できないOracleドライバー固有の呼び出しを含むコードが含まれる場合があります。このようなコードを更新して、Postgresベースの回避策を実装する必要があります。
アプリケーションの移行。移行プロジェクトによっては、実際のアプリケーションのホストされる場所とその構成の移動が発生する場合があります。ソースコードの移行とともに発生する必要があります。通常、これにより互換性の問題は発生しません。ただし、新しい環境でアプリケーションのデータベース接続、機能、およびパフォーマンスを確認することが重要です。さらに、OracleアプリケーションをPostgresに移行する場合、接続プーリングとロードバランシングのニーズに対処するためにさまざまなテクニック、ツール、および構成が必要になる場合があります。
6.レポートと管理ツールを移行する#
このフェーズでは、レポート、 DBAユーティリティ、およびスクリプトを移行します。組織は多くの場合、コアアプリケーションをサポートするためにデータベースを照会および対話するレポートメカニズムやその他の管理ツールを持っています。これらのアーティファクトの一部は、Oracleベースのプロセスをサポートするように特別に構築されているため、それらのすべてが移行後のシステムに適用されない場合、または必要とされるわけではありません。したがって、最初にレポート、ユーティリティ、スクリプト、および同様のアーティファクトのインベントリを確認して、残し、置き換え、および更新するものを決定することをお勧めします。
スクリプトまたはユーティリティの更新には、多くの場合、Oracle用に構築された互換性のないSQLをターゲットデータベースと互換性のあるものに更新することが含まれます。また、Oracleコマンドラインインターフェイスではなく、ターゲットデータベースが提供するコマンドラインインターフェイスで動作するようにそれらを更新することも含まれる場合があります。たとえば、 SQL *PlusはOracleのプライマリコマンドラインインターフェイスであり、 psqlはPostgresで提供されているものです。 SQLステートメントは両方のインターフェイスで発行できますが、それらが提供する他のサポートコマンドとキーワードは大きく異なります。多くのOracleスクリプトとユーティリティは、 SQL* Plusコマンドを使用してビルドされています。これらのスクリプトをpsqlで実行するには、代わりにpsqlコマンドを使用するように変換する必要があります。
幸いなことに、EDBはEDB *Plusを提供しています。これは、最も一般的に使用されるSQL * Plusコマンドの一部を理解するSQL *Plus作品同様のユーティリティです。この機能は、 EDB Postgres Advanced ServerのOracle機能の他のビルトイン互換性と組み合わせて、Oracle用にビルドされた多くの既存のスクリプトをEDB Postgres Advanced Serverで実行できます。 EDB Postgres Advanced Serverユーザーは、 EDB Postgres Advanced Serverに組み込まれているOracleの互換性機能と動作するように拡張されたpsqlのバージョンを使用することもできます。 psqlに慣れた後、ユーザーは多くの場合、EDB* Plusの代わりにそれを使用して、その機能を利用することにします。したがって、 SQL*Plusベースのスクリプトとユーティリティをpsqlベースのものに変換することを選択する場合があります。
Oracleが提供するもう1つの人気のあるインタフェースはSQL *Loaderで、これはOracleにデータを大量にロードするために使用されるツールです。 EDBは、 EDB Postgres Advanced Serverにデータをロードするために使用できる EDB* Loaderと呼ばれる同等のユーティリティを提供します。 EDB *Plusと同様に、 EDB* Loaderは、 EDB Postgres Advanced Serverで使用できる使い慣れたインタフェースをOracleユーザーに提供します。このツールを使用すると、既存のデータのロード手順に必要な変更が削減されます。 EDB Postgres Advanced Serverユーザーは、データをロードするためのPostgresネイティブ方法も利用できます。これらの方法を選択した場合、Oracle固有の機能に基づいてデータのロードプロセスを更新する必要があります。
他のレポートまたは管理ツールを使用して、Oracleデータベースから情報を取得する場合があります。これらのツールによって発行されたSQLクエリーを評価して、ターゲットデータベースと互換性があるかどうかを判断します。クエリが新しいシステムに適用されると仮定すると、 SQLの非互換性またはその他の操作の違いを特定した場合は、クエリを更新する必要があります。
7.移行のテスト#
移行のサイズに関係なく、移行されたアプリケーションが予想通りに動作することを検証する必要があります。ずっとテストを続けますが、ある時点で、次のことを行うための正式なテストを実行する必要があります。
データがターゲットデータベースに完全に移行され、ソースデータベースと一貫していることを検証します。 - データベースとアプリケーションの機能を確認します。 - データベースとアプリケーションのパフォーマンスが許容可能なものであることを検証します。
この手順では、データベースとアプリケーションの機能とパフォーマンスを適切にテストできるテスト環境をセットアップすることが重要です。予想される運用ワークロードをシミュレートしたワークロード、および運用環境と同様の動作環境で、実際のアプリケーションまたはアプリケーションのコピーを使用して、これらのアプリケーションとデータベースのテストを実行します。機能テストは、アプリケーションコードを実行し、通常のワークロードで使用される頻度が低いデータベースオブジェクトと対話するための十分なカバレッジを提供する必要があります。
データ検証に関しては、ソースデータベースとターゲットデータベースのデータの比較に使用されるツールとプロセスは、違いを簡単に識別できるようにする必要があります。違いが存在する場合は、分析を実行して、違いが発生した理由と、移行プロセスの変更が必要かどうかを理解する必要があります。ターゲットシステムのデータがソースシステムのデータで更新される頻度によっては、データ検証チェックを複数回実行する必要がある場合があります。進行中のCDCベースのデータ移行の場合、データを定期的に検証するための計画を確立します。
この手順では、可用性要件を満たし、バックアップとリカバリ操作を実行し、データベースを監視および管理するために使用するツールとプロセスをセットアップおよび実行することをお勧めします。これは、運用環境での使用の準備として、ツールと関連システムの操作手順または構成に必要な変更を特定するのに役立ちます。
このステップの主な目的の1つは、実稼働システムへの最終的な移行を続行する前に、対処すべき問題を特定することです。問題を見つけて修正する場合は、さらにテストを実行する必要があります。実稼働前移行テストの結果に満足したら、実稼働環境の最終準備を実行できます。
8.移行後のシステムの最適化と構成#
このフェーズでは、必要なソフトウェアがすべてインストールされていることを確認し、テストフェーズ中に特定および検証された変更で実稼働環境を更新します。また、以前のパフォーマンステスト結果から導き出された推奨事項に基づいて、システムの構成と調整も行います。データベースパラメーターとアプリケーション設定を調整して、システムが最適に実行されるように準備する必要がある場合があります。また、テストフェーズで特定および検証したクエリチューニング関連の更新も適用します。
このフェーズは、高可用性、ディザスターリカバリー、およびセキュリティ要件への対応を終了する時期でもあります。ユーザーとアプリケーションがデータベースに対して認証する方法、各アクションを実行する権限を誰に与えるかなど。必要に応じて、これらの要件が満たされていることを確認し、データベースを監視および維持するための標準操作手順SOPを更新します。
9.完全なカットオーバー/ゴーライブ#
このフェーズは次で構成されます。
運用データベースへのデータの移行の完了。 CDCベースのアプローチを使用してソースデータベースからデータを移行する場合、ソースデータベースへのさらなる変更を無効にして、新しいデータベースが古いデータベースと同期するようにします。通常、必要に応じて、ソースデータベースの読み取り専用クエリを引き続き許可できます。
ロールバックオプションの設定。古いデータベースが新しいデータベースから更新を受信し、新しいデータベースでアプリケーションの実行に問題が発生した場合にフォールバック位置として存在するように、ロールバック構成を設定します。この方法により、元のソースデータベースに対するアプリケーションの実行に戻ることができます。データをターゲットデータベースに戻すことは、多くの場合、変更データキャプチャメカニズムを介して実行されます。
新しいデータベースで移行したアプリケーションの使用を開始するようにシステムの構成。これは通常、新しいデータベースが古いデータベースからすべての最終更新を受信したことを確認した後にのみ実行されます。
続行/停止の決定が下されるまで、新しいシステムをテストします。新しいアプリケーションとデータベースを一定期間テストします。アプリケーションが新しい環境で適切にパフォーマンスしていることを確認したら、アプリケーションを完全な運用環境での使用に「go」であると宣言できます。
運用へのカットオーバーを終了します。カットオーバーが完了し、それに満足したら、通常、データの変更をターゲットデータソースデータベースに送信するフォールバック位置を削除します。その時点で、新しい実稼働システムでのみ実行されます。