The database migration “journey”¶
データベースの移行は、9つのステップから構成されます。
Migration journey¶
1.移行することを決定¶
まず、組織は移行を決定する必要があります。古いデータベース システムにお金を使いすぎていると思うかもしれません。現在のデータベース技術では十分にサポートされていないイニシアチブがあるかもしれません。または、クラウドに移行したり、オープンソース ソフトウェアを利用したりすることもできます。これらは、移行のビジネス ケースにつながる可能性のある一般的な要因です。
ビジネスケースがあり、組織がそれに同意したら、組織は移行の実行に取り組む必要があります。コミットメントには、移行を実行するための資金とリソースが含まれます。
2.実現可能性と代替案を分析する¶
代替案を分析し、特定のデータベースへの移行の実現可能性を検討します。
アプリケーションポートフォリオを確認して、すべてのアプリケーションを移行するかどうかを判断します¶
このレビューの一環として、移行可能なレガシーデータベースを持つアプリケーションを見ていきます。移行の優先順位と IT 戦略を調整して、これらが移行を検討するのに十分なほど重要なビジネス アプリケーションであることを確認します。
アプリケーション ポートフォリオを確認する一環として、一部のアプリケーションを廃止することを決定する場合があります。ポートフォリオには、既存のデータベースでのみサポートされているために移行できないアプリケーションがある場合があります。
移行するアプリケーションの候補セットを特定するときは、それらを移行することは、移行を完了するという組織のコミットメントに対応する必要があることに注意してください。時間も、リソースも、予算もかかります。
各アプリケーションの移行ターゲットとしてどのデータベーステクノロジーが正しいかを評価する¶
多くの場合、 EDB Postgres Advanced ServerはOracleを置き換える理想的な選択肢です。ただし、一部のアプリケーションには、他のソリューションでより適切に対処できる要件があります。
ターゲット データベース テクノロジの適切なセットを選択したら、次の手順として、移行がどの程度複雑になるかをより詳細に評価します。 EDB Postgres Advanced Serverが潜在的なターゲットである場合、EDBMigration Portalを使用して、データベース内の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データベースに存在するスキーマオブジェクトとターゲットデータベースで作成できるオブジェクトに違いがあります。 EDB Postgres Advanced ServerのOracle機能の互換性により、他のターゲットデータベースオプションでは対処できない多くの互換性の問題が自動的に解決されます。
この手順の主なタスクは、互換性がない、または自動的に変換できないスキーマ オブジェクトの回避策を実装することです。スキーマオブジェクトは、 SQLベースのデータ定義言語（DDL）を使用して作成されます。 EDBのMigration Portalを使用して、Oracle DDLとEDB Postgres Advanced Serverの互換性を評価できます。また、評価プロセスの一部として適用される修復ハンドラーを介していくつかの自動変換を実行します。
Migration Portalの評価を実行した後の次のステップは、 DDL移行の結果を確認し、評価レポートで特定された問題を解決することです。
データベース機能（つまり、データベースプロシージャルオブジェクト）を移行する¶
これには、アプリケーションによって呼び出されるプロシージャやファンクション、またはデータベースが使用するトリガーなど、データベースに存在するコードが含まれます。スキーマオブジェクトと同様に、データベースコードオブジェクトもDDLを使用して作成されます。さらに、コードオブジェクトはスキーマオブジェクトに密接に関連付けられており、それらを参照するか、それらによって参照されます。したがって、データベースコードオブジェクトは通常、他のスキーマオブジェクトと同時に移行されます。
他のスキーマ オブジェクトと同様に、この手順の主なアクティビティは、互換性がない、または自動的に変換できないデータベース コード オブジェクトの回避策を特定して実装することです。 Oracleの手続き言語（PL / SQL）は他のデータベースのネイティブビルトイン言語とは異なるため、特にソースデータベースに多数のコードオブジェクトが含まれている場合、またはコードオブジェクトで構成されている場合、これはデータベース移行で最も困難なタスクになる可能性があります複雑なコードの多くの行。これは、最も一般的に使用されるPL / SQL機能の多くをネイティブに提供するEDB Postgres Advanced ServerのPL / SQL実装が重要になる場所です。これらの機能により、この手順を完了するために必要な労力を大幅に削減できます。 Migration Portalは、他のスキーマ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データベースに接続するためのアプリケーションの構成の詳細については、次のドライバー固有のドキュメントを確認してください。
.NETアプリケーションの場合、Oracle .NETドライバーを使用するアプリケーションを更新して、Oracleドライバー固有のクラス名への呼び出しをEDBドライバーの同等の名前に置き換える必要があります。
アプリケーションの埋め込みSQLを変換します。 SQLは、ソースデータベースで動作するように構築されている場合があります。 Oracleがサポートしている特定の構文がPostgresでサポートされていない場合があります。この場合、Postgresで動作するようにそのSQLを変換する必要があります。 EDB 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機能の他の組み込み互換性により、 EDB Postgres Advanced ServerでOracle用に構築された多くの既存のスクリプトを実行できます。 EDB Postgres Advanced Serverユーザーは、 EDB Postgres Advanced Serverに組み込まれたOracleとの互換性機能で動作するように拡張されたpsqlのバージョンを使用することもできます。 psqlに慣れると、ユーザーは多くの場合、その機能を活用するためにEDB*Plusの代わりに使用することにします。したがって、 SQL*Plusベースのスクリプトとユーティリティをpsqlベースのものに変換することを引き続き選択できます。
Oracleが提供するもう1つの一般的なインタフェースは、 SQL*Loaderです。これは、Oracleにデータをバルクロードするために使用されるツールです。 EDBは、 EDB*Loader と呼ばれる似たユーティリティを提供し、 EDB Postgres Advanced Serverにデータをロードします。 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ベースのアプローチを使用してソースデータベースからデータを移行する場合は、ソースデータベースへのそれ以上の変更を無効にして、新しいデータベースが古いデータベースと同期するようにします。通常、必要に応じてソースデータベースの読み取り専用クエリを引き続き許可できます。
ロールバックオプションの設定。古いデータベースが新しいデータベースから更新を受信し、新しいデータベースでのアプリケーションの実行で問題が発生した場合のフォールバック位置として存在するように、ロールバック構成を設定します。このようにして、元のソースデータベースに対するアプリケーションの実行に戻ることができます。ターゲットデータベースへのデータの移動は、多くの場合、変更データキャプチャメカニズムを介して実行されます。
新しいデータベースで移行したアプリケーションの使用を開始するためのシステムの構成。これは通常、新しいデータベースが古いデータベースからすべての最終更新を受け取ったことを確認した後にのみ実行されます。
続行するかどうかが決定されるまで、新しいシステムをテストします。一定期間、新しいアプリケーションとデータベースをテストします。アプリケーションが新しい環境で適切に実行されていることを確認したら、アプリケーションが完全な実稼働用に「ゴー」であることを宣言できます。
プロダクションへのカットオーバーの仕上げ。カットオーバーを完了して満足したら、通常はデータの変更をターゲットデータソースデータベースに送信するフォールバック位置を削除します。その時点では、新しい実稼働システムでのみ実行します。
