4 以前のリリースのAPEXからのアップグレード

Oracle APEXをアップグレードすると、新しいスキーマに新しいデータベース・オブジェクトが作成され、アプリケーションのメタデータが新しいリリースに移行されます。

APEXリリース22.1以前をご使用の場合は、このマニュアルに記載されているどのインストール・シナリオに従っても、APEXインスタンスは新しいリリースにアップグレードされ、新しいスキーマにAPEX 22.2のデータベース・オブジェクトが作成され、アプリケーションのメタデータが新しいリリースに移行されます。

4.1 リリース番号の規則について

Oracle APEXの新規リリースは、カレンダ年に対応しています。

2018年のリリース18.1および18.2以降では、APEXのリリース番号はカレンダ年に対応しています。

また、APEXは完全リリースのみが提供されるようになり、パッチ・セット・リリース(5.1.1など)は提供されなくなりました。パッチ・セットのリリースを消去すると、既存のインストールを更新する際の停止時間が短縮されます。APEXアーキテクチャでは、必要に応じて開発者がリリースを元に戻すこともできます。

大きい欠陥については、今後もパッチ・セットの例外(PSE)が提供される場合があります。PSEの詳細は、Oracle APEX 22.2の既知の問題ページまたは以前のリリースの以前のリリースのアーカイブを参照してください。

4.2 サンプル・アップグレード・シナリオ

以前のリリースからのアップグレードやOracle DatabaseリリースにOracle APEXが含まれている場合のアップグレードなど、一般的なアップグレード・シナリオを確認します。

表4-1に、一般的なアップグレード・シナリオを示します。

表4-1 サンプル・アップグレード・シナリオ

アップグレード・シナリオ アクション

以前のOracle APEXリリースからのアップグレード

Oracle APEXダウンロード・ページから最新のZIPファイルをダウンロードし、スクリプトを実行して最新リリースにアップグレードします。

詳細は、「APEXのインストール」を参照してください。

Oracle APEXを含むOracle Databaseをインストールします。

Oracle APEXダウンロード・ページから最新のZIPファイルをダウンロードし、スクリプトを実行して最新リリースにアップグレードします。

詳細は、「APEXのインストール」を参照してください。

4.3 APEXのリリース番号の表示

ワークスペースのホームページまたはAPEXについてページでOracle APEXのリリース番号を表示します。

ワークスペースのホームページまたはAPEXについてページでAPEXのリリース番号を表示できます。
  • ワークスペース・ホームページ:
    • APEXにサインインします。

      「ワークスペース」ホームページで、右下隅に現在のリリース番号が表示されます。

  • APEXについてページ:
    • APEXにサインインします。

    • 右上にある「ヘルプ」メニューをクリックし、「情報」を選択します。

      APEXについてページでは、「製品のバージョン情報」の隣にリリース番号が表示されます。

4.4 Oracle REST Data Servicesのリリース番号の表示

Oracle APEXについて」ページでOracle REST Data Servicesのリリース番号を表示します。

Oracle APEXは、Webサーバー(Oracle REST Data Services (ORDS) 20.x以降)へのアクセスを必要とします。

Oracle REST Data Servicesのリリース番号を表示するには:

  1. Oracle APEXにサインインします。
  2. 右上にある「ヘルプ」メニューをクリックし、「情報」を選択します。
  3. 「CGI環境」セクションの下でAPEX_LISTENER_VERSIONを見つけます。

4.5 Oracle Databaseに付属のAPEXリリースのインストールについて

どのOracle DatabaseリリースにOracle APEXが含まれているかと、最新のAPEXリリースに更新することの重要性について説明します。

APEXは、次のOracle Databaseリリースに付属しています。

  • Oracle Database 19c: Oracle Application Expressリリース18.1。
  • Oracle Database 18c: Oracle Application Expressリリース5.1。
  • Oracle Database 12cリリース2 (12.2): Oracle Application Expressリリース5.0。
  • Oracle Database 12cリリース1 (12.1): Oracle Application Expressリリース4.2。
  • Oracle Database 11gリリース2 (11.2): Oracle Application Expressリリース3.2。
  • Oracle Database 11gリリース1 (11.1): Oracle Application Expressリリース3.0。

Oracle DatabaseAPEXよりリリース頻度が少ないため、入手可能な最新のAPEXリリースに更新することをお薦めします。詳細は、「APEXのダウンロードとインストール」を参照してください。

ノート:

APEXをデータベースに付属のリリースからアップグレードする場合は、Oracleホーム・ディレクトリ(たとえば、/u01/app/oracle/product/18.0.0/dbhome_1/apex)内のどのAPEXファイルも変更しないでください。

4.6 既存のアプリケーションのアップグレードについて

Oracle APEXの新しいリリースをインストールすると、既存のアプリケーションが最新リリースに更新されますが、アプリケーション・ユーザー・インタフェースまたはアプリケーション・コンポーネントは変更されません。

Oracle APEXインスタンスを以前のリリースからアップグレードすると、既存のアプリケーションは変更なしで機能します。ただし、アプリケーションを保守可能で最新の状態に保ち、新しい機能を活用するためには、開発者は『Oracle APEXアプリケーション・ビルダー・ユーザーズ・ガイド』APEXアプリケーションのアップグレードに関する項に記載されている手順を実行する必要があります。

4.7 テスト要件について

Oracle APEXアップグレード時の、適切な回帰テストの量の判定は、アップグレードするアプリケーションの複雑さ、サイズおよび数に依存します。

複雑なページ、特に大きなJavaScriptや、広範なPL/SQLの計算またはプロセスを統合しているページの大部分を含める必要があります。開発者は、「アプリケーションのアップグレード」または「アドバイザ」に基づいて手動で更新するページが回帰テストにも含まれていることを確認する必要があります。残りのページをすべて回帰テストに含める必要はありません。レポート、チャートおよびフォームを含む様々なページ・タイプを適切に代表する内容を含めることをお薦めします。アプリケーションの互換性モードがアップグレード後に変更された場合は、必ず回帰テストに含める必要があります。

エンド・ユーザーが中断されるリスクを最小にするにはアップグレードされたアプリケーションの回帰テストは必須ですが、長期間かからないようにすることが重要です。一般原則:

  • ステップ1: 先に開発環境をアップグレードします。開発者がアプリケーションを検討して、必要に応じて初期更新できるようにします。

  • ステップ2: QA/テスト環境をアップグレードします。

  • ステップ3: アプリケーションを、この環境に組み込まれた開発からアップグレードします。

  • ステップ4: 本番環境をアップグレードします。

  • ステップ5: アップグレードされたアプリケーションをこの環境に組み込みます。

4.8 環境のクリーンアップについて

すべての環境で最新リリースへのOracle APEXのアップグレードが成功したら、環境をクリーン・アップする必要があります。

新しいリリースでの開発を開始したら、以前のリリースに関連付けられたOracle APEXスキーマは削除できます。以前のリリースが別の表領域にインストールされた場合、固有の表領域を単純に削除できます。以前のOracle APEXスキーマは、数週間残してから、開発、テストおよび本番環境から削除することをお薦めします。このクリーンアップ・プロセスによりディスク領域が解放され、SQL DeveloperやSQL*Plusなどのツールを使用して古いスキーマにアクセスするユーザーをゼロにできます。

4.9 元のリリースに戻す

Oracle APEXの元のリリースに戻すことができます。

Oracle APEXは各メジャー・リリースに対して新しいスキーマを作成するため、元のリリースに戻すのは比較的単純なプロセスです。以前のリリースに戻る場合、現在のOracle APEXインスタンスで行われた変更はすべて失われます。主要なタスクは、パブリック・シノニムと権限付与を、新しいスキーマでなく以前のスキーマを参照するように切り替えることです。