Factors to consider when migrating

移行を分析および計画するときは、次の要因について考えます。

  • スキーマ

  • データ

  • インフラストラクチャ

  • アプリケーション

  • オペレーション

スキーマの移行考慮事項

スキーマは、データベースの構造を定義します。スキーマには、テーブルと、シーケンス、インデックス、制約、ビューなどの他の構造の定義が含まれます。 Postgresがこれらのオブジェクトを作成するために提供する構文は、多くの場合Oracleの構文と似ていますが、移行時に対処する必要がある違いがあります。 OracleとPostgresでは、理解することが重要なスキーマオブジェクトを編成および保存する方法にも違いがあります。

データ型は、テーブルおよびデータベースで使用される他のオブジェクトで使用されます。移行、 Oracleのデータ型がPostgresのデータ型にどのように対応するかを考える必要があります。

データベーススキーマには、データベースに直接記述されたパッケージ、プロシージャ、ファンクション、トリガーなどのコードオブジェクトも含まれています。 Oracle では、コードオブジェクトは Oracle の PL/ SQL言語で記述されます。 PostgreSQLには、Oracleと互換性のない独自のビルトインプログラミング言語があります。ただし、 EDB Postgres Advanced Serverは、SPLと呼ばれるPL / SQLのビルトイン実装を提供します。 EDBのSPLは、最も一般的に使用されるOracle PL / SQLコンストラクトの大部分をカバーしていますが、Oracleコンストラクトの完全なセットを実装していません。その結果、 EDB Postgres Advanced Serverで動作するように一部のOracleコードオブジェクトを変換する必要がある場合があります。

多くの場合、ソースデータベースとターゲットデータベースがデータと対話する方法には構文の違いがあります。 Oracleには、Postgresでサポートされていない情報の選択、挿入、更新、および削除のためにそのバージョンの構造化照会言語（SQL）で使用する特定の規則とキーワードがあります。

データ移行の考慮事項

スキーマは構造を提供しますが、データはデータベースのコンテンツです。考慮する必要があるのは、データをターゲットデータベースに移動する方法です。この方法は、移動する必要があるデータの量と、許容できるダウンタイムによって異なります。バルクロードが適切かどうかを判断する必要があります。つまり、ソースシステムからデータのスナップショットを取得し、ターゲットシステムに転送し、そこから先に進みます。または、データをターゲットデータベースに移行している間、ソースアプリケーションとデータベースを稼働し続けなければならない場合があります。ソースデータベースはまだ更新を受け取っているため、そのデータを引き続きターゲットデータベースに移動できるようにします。

フォールバックは別の考慮事項です。移行プロセスを進めるうちに、最終的に移行が完了します。移行したシステムのテストを終了するときは、移行が完全に成功しなかった場合に備えて、フォールバックのポジションが必要になることがよくあります。移行されたシステムで運用を開始した後、移行されたデータベースに適用されるデータ変更とレガシーデータベースが同期されている場合、元のソースデータベースとソースアプリケーションに簡単にフォールバックできます。フォールバック計画では、移行したデータベースに入力された新しいデータをタイムリーに元のソースデータベースに戻す必要があります。

データの移行には、ソースデータベースからターゲットデータベースにデータをプッシュするために提供するコアツールに加えて、より複雑な抽出、変換、ロード（ETL）のニーズなど、より高度なデータ移行シナリオをサポートするツールを使用することもできます。これらのツールは、ソースデータベースからデータをプルし、変換して、ターゲットデータベースにロードします。

データをターゲットシステムに配置したら、ターゲットシステムに配置したデータがソースシステムのデータと一致することを検証します。

インフラストラクチャーの考慮事項

データベースはインフラストラクチャ上にあるため、ソースデータベースのホスティング環境と、ターゲット環境を検討する必要があります。たとえば、現在のデータベースがオンプレミスにデプロイされている場合、同様にオンプレミスで実行されている別のデータベースに移行することを決定できます。ただし、データベースのオンプレミス展開からクラウドベースの展開への移行を検討している組織が増えています。クラウドベースの展開が最終的な目標である場合、オンプレミスで実行されているデータベースからクラウドで実行されているデータベースに直接移行することを決定できます。または、最初にデータベースをオンプレミスで実行されているデータベースに移行してから、移行したデータベースをクラウドに移動する場合があります。

最終状態として、またはクラウドへの踏み台としてオンプレミスデータベースに移行する場合、移行を実行およびテストし、オペレーションデータベースと関連ツールをホストするためのサーバーリソースがあることを確認する必要があります。クラウドに移行する場合もニーズは似ていますが、移行プロセスをサポートするために必要に応じてサーバーをより柔軟に追加および削除できます。

考慮すべきもう 1 つの要因は、多くのレガシ アプリケーション データベースが専用のハードウェアとオペレーティング システムに展開されたことです。サーバーオプションをターゲットにする可能性が高い場合、この要因は移行に使用されるツールとアプローチの種類に影響を与える可能性があります。使用する予定のツールがこれらのシステムに展開できること、またはアクセスして移行する情報を取得できることを確認する必要があります。

オンプレミスリソースへの移行を検討する場合、 EDB Postgres Advanced Serverで使用可能なデプロイオプションは次のとおりです。

  • 物理サーバー

  • 仮想マシン

  • KubernetesのクラウドネイティブPostgresコンテナ

  • プライベートクラウドインスタンス

従来、データベースはパフォーマンスを最適化するために物理サーバーにインストールされました。時間が経つにつれて、仮想化テクノロジーが向上するにつれて、データベースを仮想マシンにインストールすることがより一般的になりました。ここ数年、コンテナはデータベース展開の実行可能なオプションとして浮上し始めています。 。

クラウドへの移行の場合、 EDB Postgres Advanced Serverの展開オプションは次のとおりです。

  • BigAnimalクラスター

  • クラウドベースのサーバーインスタンスにインストールされた自己管理のEDB Postgres Advanced Server

  • クラウドネイティブPostgreSQL（CNP）

ますます多くの組織が、マネージドデータベースサービス (DBaaSとしても知られる) に移行して、このサービスがビジネスにもたらすメリットを活用しています。 BigAnimalは、主要な商用クラウドで利用可能なEDB Postgres DBaaSオファリングで、PostgreSQLまたはEDB Postgres Advanced Serverデータベースクラスターを簡単に展開するオプションを提供します。クラウドに移行したいが、データベースインスタンスと基になるサーバーの管理をより細かく制御したい場合は、クラウドベースのサーバーインスタンスに自分でEDB Postgres Advanced Serverをインストールして管理できます。 EDBのクラウドネイティブPostgreSQL（CNP）を使用すると、KubernetesオーケストレーションコンテナにPostgreSQLまたはEDB Postgres Advanced Serverクラスターをデプロイして管理できます。データベース用のコンテナの普及はまだ初期段階です。ただし、アプリケーションがマイクロサービスに移行するにつれて、データベース用のコンテナーの使用が増加しています。 Kubernetesクラスターはクラウド内に立てることができます。実際、主要なクラウドプロバイダーもマネージドKubernetesサービスを提供しています。

異なるソースインフラストラクチャとターゲットインフラストラクチャがある場合、インフラストラクチャに基づいてソースシステムを最適化した可能性があることを考慮してください。ターゲットシステムに移行するときは、同様の最適化を異なる手法を使用して行う必要があります。

アプリケーションの移行考慮事項

アプリケーションはデータベースに情報を送信し、データベースから情報を取得します。 OracleやPostgresなどのリレーショナルデータベース管理システム（RDBMS）バックエンドを使用するほとんどのアプリケーションは、構造化照会言語（SQL）でデータベースクエリを発行します。 SQL標準の重要なコンポーネントは、すべての主要なリレーショナルデータベースで採用されました。ただし、それぞれには標準から逸脱し、互いに異なる機能があります。そのため、移行作業の一環として、アプリケーションコードに埋め込まれたSQLコードの変換が静的または動的に生成される可能性があります。

さらに、アプリケーションは通常、レガシーデータベースシステムおよびオペレーティング環境で適切に動作するように調整および構成されています。古いシステムから新しいシステムに移行する場合、新しいデータベースとオペレーティング環境で適切に実行できるようにアプリケーションに変更を加える必要があります。

運用上の考慮事項

古いデータベースを新しいデータベーステクノロジに移行すると、新しいデータベースを操作するための運用プロセスとツールを更新する必要があります。 OracleからPostgresへの移行の場合、使用されているOracle固有のツールをPostgres固有のツールに置き換える必要があります。考慮すべき運用上の主な側面には、高可用性、バックアップとリカバリ、監視と管理、セキュリティ、暗号化などがあります。

また、古いデータベースが古い専用のハードウェアとオペレーティングシステムで実行されている場合、データベースの移行では、基になるホストシステムを最新のプラットフォームとオペレーティングシステムに移行する必要があります。オンプレミスの移行の場合、これにより、新しいサーバープラットフォームとオペレーティングシステムで動作するように運用とメンテナンスの手順とツールを変更する必要が生じる場合があります。クラウドへの移行の場合、運用とメンテナンスのアクティビティの一部はクラウドサービスプロバイダーによって処理されますが、その他は引き続きお客様の責任となります。おそらく、これらのアクティビティには、現在使用しているものとは異なるツールと手順が必要です。

ベストプラクティスの考慮事項

以下は、OracleからPostgresへのデータベースアプリケーションの移行を計画する際に考慮すべきいくつかのベストプラクティスです。

  • 移行の手順をスキップしたり、ざっと読んだりしないでください。 -計画を立ててください。 - 機能要件と非機能要件を特定して理解する。 - ソリューション設計を早期に完了して、ITリソースのニーズを理解する。

  • 開発環境とテスト環境を使用して、運用環境に移行する前に移行の問題を特定および解決します。

  • アプリケーション開発者とシステム管理者を移行の旅の早い段階でデータベース チームと連携させます。

  • 運用環境と使用法に近い方法で、データベースを使用してアプリケーションをテストできる環境を設定します。

  • データベーススキーマを移行する場合、データの移行後までインデックスと制約のロードを延期します。

  • より複雑な移行については、移行の専門家とPostgreSQLの専門家の助けを借ります。

  • 移行後の操作の前に、運用担当者が新しいシステムについてトレーニングされていることを確認します。