Oracle Database 18cアップグレード計画の対象となる機能変更

これらの機能変更を参考にして、Oracle Database 18cのアップグレード計画に含める変更に対する準備を整えてください。

トピック:

64文字を超えるJSONキー名の索引付けのサポート

JSONキーを使用すると、長いキー名を使用してHASH MAP形式の構造から生成されたJSONドキュメントの検索効率が向上します。

JSON検索索引で索引付けできるJSONキー名の上限が引き上げられています。Oracle Database 12cリリース2 (12.2.0.2)以降のリリースでのJSONキー名の上限は、255バイトです。以前のリリースで作成されたJSON検索索引では、64バイトを超えるキー名は索引付けされませんでした。

既存のデータベースのアップグレードにかわるイメージ・インストール

Oracle Database 18c以上では、既存のサービスはインストールで移行されなくなりました。Database Upgrade Assistant (DBUA)を使用してサービスを移行します。

既存のOracle Databaseで使用されているサービスを移行する必要がある場合は、Oracleホームに新しいリリースのOracle Databaseソフトウェアをインストールしてから、DBUAを起動する必要があります。

Windowsの場合、Microsoft Transaction Serviceを新しいOracleホームに移行するには、コマンド%ORACLE_HOME%\bin\oramtsctl.exe -newも実行する必要があります

RPMベースのOracle Databaseインストール

Linuxシステムでは、RPMイメージ・インストールを使用してOracle Database 18cをインストールできます。

Oracle Database 18cでは、Oracle Preinstallation RPMおよびrpm -ivhコマンドを使用して、RPMベースのOracle Databaseインストールを実行できます。RPMベースのインストールは、Oracle Linuxシステム上の単一インスタンスのOracle Databaseに対してのみサポートされています。

Oracle Text索引のトークン制限

Oracle Databaseリリース18c以上では、索引付けされたトークンの最大サイズがシングルバイト文字セットで255文字まで拡張されています。

Oracle Databaseリリース18cより前では、SDATAセクションを除くすべてのOracle Text索引タイプで、VARCHAR2 (64 BYTE)型の表列にトークンが格納されていました。Oracle Databaseリリース18c以上では、CTXCATおよびCTXRULE索引を除くすべてのOracle Text索引タイプで、VARCHAR2 (255 BYTE)型の表列にトークンが格納されます。この変更では、索引付けされたトークンの最大サイズがシングルバイト文字セットで255文字まで拡張されています。サイズの拡張は、マルチバイト文字セットや可変長文字セットではこれより短くなります。255バイトより長いトークンは切り捨てられます。トークンが切り捨てられたとしても、トークン文字列全体の検索が妨げられることはありません。ただし、システムでは最初の255バイトが同じ2つのトークンを区別できません。

ノート:

Oracle Databaseリリース18cより前では、64バイトを超えるトークンは64バイトに切り捨てられていました。Oracle Databaseリリース18cにアップグレードすると、トークン表が64バイトから255バイトに拡張されます。検索トークン(つまり、検索文字列の1語)が64バイトを超える検索では、64バイトに切り捨てられたトークンを見つけることができません。この問題を回避するには、索引を再構築します。64バイトを超える検索トークンを使用しない場合は、索引を再構築する必要はありません。

SDATAセクションでは、VARCHAR2 (249 BYTE)型の表列にトークンが格納されます。CTXCATおよびCTXRULE索引では、VARCHAR2 (64 BYTE)型の表列にトークンが格納されます。

/ALL/USER/DBA_ユーザー・ビューおよびPL/SQL外部ライブラリの変更

Oracle Database 18c以上では、/USER/ALL/DBA_ARGUMENTSビューと/USER/ALL/DBA_IDENTIFIERSビュー、およびPDBでのLIBRARYオブジェクトの作成方法が変更されています。

作業に影響する可能性のある変更を確認してください。

ALL/USER/DBA_ARGUMENTSユーザー・ビューの変更点

ARGUMENTSビュー内の行数が減りました。具体的には、最上位(DATA_LEVEL=0)の項目のみがARGUMENTSビューに格納されます。

以前のOracle Databaseリリースでは、PL/SQLコンパイラにより、PL/SQLデータ型のネストされたすべてのタイプに関するメタデータが収集されていました。DATA_LEVELは、タイプのネスト・レベルを表していました。Oracle Database 18c以上では、最上位のタイプのメタデータ(DATA_LEVEL=0)のみがARGUMENTSビューに格納されます。

例として、create-or-replaceパッケージNestedTypesExampleの変更点に注目します。

Type Level2Record is RECORD (Field1 NUMBER);
Type Level1Collection is TABLE of Level2Record index by binary_integer;
Type Level0Record is RECORD (Field1 Level1Collection);
Procedure NestedTypesProc (Param1 Level0Record);

以前のOracle Databaseリリースでは、NestedTypeProcプロシージャの最上位のタイプ(パラメータParam1、Level0Record)とともに、Level0Record内のネストされたすべてのタイプの詳細な説明が返されます。次に例を示します。

SQL> select argument_name,type_subname,position,sequence,data_level from user_arguments where object_name='NESTEDTYPESPROC';
ARGUMENT_NAME   TYPE_SUBNAME      POSITION   SEQUENCE  DATA_LEVEL 
--------------- ----------------- ---------- ---------- --------- 
PARAM1          LEVEL0RECORD             1          1           0
FIELD1          LEVEL1COLLECTION         1          2           1 
                LEVEL2RECORD             1          3           2
FIELD1                                   1          4           3

それに対し、18.1データベースで同じ問合せを使用した場合は、次の結果が返されます。

ARGUMENT_NAME   TYPE_SUBNAME      POSITION   SEQUENCE  DATA_LEVEL 
--------------- ----------------- ---------- ---------- --------- 
PARAM1          LEVEL0RECORD             1          1           0

Oracle Database 12c (12.1)より前のリリースでは、PL/SQLパッケージ・タイプの説明的なメタデータには、最上位のオブジェクト・タイプのメタデータにアクセスする場合と同じ方法ではアクセスできませんでした。最上位のオブジェクト・タイプとコレクションについては、ALL_TYPESに加え、関連するユーザー・ビューALL_TYPE_ATTRSおよびALL_COLL_TYPESを問い合せて、タイプのメタデータを取得できます。一方、Oracle Database 12.1より前では、レコードやパッケージ化されたコレクションなど、PL/SQLパッケージ・タイプのメタデータを取得できませんでした。関数またはプロシージャのパラメータでこれらのPL/SQLパッケージ・タイプを参照していた場合は、ARGUMENTSビューでこれらのタイプ(ネストされたタイプを含む)に関するすべてのメタデータが公開されていました。

このアプローチの問題は、深くネストされたタイプがSYS表領域で大量のメモリーを消費する可能性があることです。また、ARGUMENTSビューでタイプのメタデータを共有する方法がないため、深くネストされたタイプを持つ各パラメータには、タイプのメタデータの冗長コピーがそれぞれ個別に必要でした。ARGUMENTSビューおよびSYS表領域内のメタデータの量によっては、PL/SQLコンパイラのパフォーマンス低下など、様々な問題を生じる可能性があります。パフォーマンス低下の原因は、PL/SQLが基礎となるディクショナリ表の行を更新するのに多くの時間を要することです。

Oracle Database 12.1リリースでは、PL/SQLでのパッケージ・タイプに対するサポートが拡張され、新しいユーザー・ビューALL_PLSQL_TYPESALL_PLSQL_TYPE_ATTRSおよびALL_PLSQL_COLL_TYPESが追加されています。これらのビューは、名前が示すとおり、ALL_TYPESビュー・ファミリに類似しています。ただし、拡張されたPL/SQLタイプ・ビューを使用して、最上位のオブジェクト・タイプおよびコレクション・タイプのかわりに、PL/SQLパッケージ・タイプに関するメタデータを問い合せることができます。

Oracle Database 12.1ではパッケージ・タイプが追加されているため、説明的なメタデータを大量にARGUMENTSビューに挿入する必要がなくなりました。各パラメータ・タイプについてARGUMENTSビューで必要になるのは、タイプ名を含む1行のメタデータのみです。PL/SQLタイプ・ビューおよびネストされたタイプに対する問合せでは、タイプ名の完全な説明を取得できます。

OCIDescribeAny()は、ARGUMENTSビューで使用されるものと同じメタデータに基づきます。また、OCIDescribeAny()では、各パラメータ・タイプについてそれぞれ1行のみが返されます(Oracle Database 12.1で変更されるまでは一般に複数の行が返されていました)。

ALL/DBA/USER_ARGUMENTSには、新しい列タイプTYPE_OBJECT_TYPEが含まれています。TYPE_OWNERTYPE_NAMEおよびTYPE_SUBNAMEで表されるタイプのタイプを調べるには、TYPE_OBJECT_TYPE列を使用します。候補となる値は、TABLEVIEWPACKAGEおよびTYPEです。

ARGUMENTSビューで引き続きALL_TYPESとそれに関連するユーザー・ビュー(ALL_TYPE_ATTRSおよびALL_COLL_TYPES)を収集する場合は、イベントをevents='10946, level 65536'に設定できます。このイベントを設定すると、ARGUMENTSビューが12.1より前のOracle Databaseリリースの動作に戻ります。つまり、DATA_LEVELを0より大きくすることができ、タイプおよびネストされたタイプに関する説明的なメタデータがビューに含まれます。このように変更する場合は、イベントを設定した後で、影響を受けるパッケージを再コンパイルする必要があります。影響を受けるパッケージの再コンパイル時には、コンパイラによって追加のメタデータが再収集されます。また、このイベントを設定すると、OCIDescribeAny()が12.1より前のOracle Databaseリリースの動作に戻ります。

Oracle Database 12cリリース1 (12.1.0.2)以上では、引数なしでプロシージャを入力すると、ARGUMENTSビューに行は含まれません。この変更は、ARGUMENTSビューの行削減とは別に加えられたものです。Oracle Database 12.1.0.2より前では、引数なしのプロシージャもARGUMENTSビューに1行として表示されていました。

USER/ALL/DBA_IDENTIFIERSユーザー・ビューの変更点

Oracle Database 18c以上では、PL/Scopeが拡張され、PL/SQLコード内のユーザー識別子に関する追加情報が取得されるようになりました。追加情報には、識別子に適用されている制約、関数がPL/SQLのSQLビルトインであることを示すインジケータなどが含まれます。

次の列は、Oracle Database 18cのUSER/ALL/DBA_IDENTIFIERSビューに新規に追加されました。

  • CHARACTER_SET: この列には、列が変数識別子宣言で使用されている場合に文字セット句の値が格納されます。候補となる値は、CHAR_CSNCHAR_CSおよびIDENTIFIER (文字セットが別の変数識別子から派生している場合)です。

  • ATTRIBUTE: この列には、%attributeが変数宣言で使用されている場合に属性値が格納されます。候補となる値は、ROWTYPETYPEおよびCHARSETです。

  • CHAR_USED: この列には、制約が文字列長制約宣言で使用されている場合に長さ制約のタイプが格納されます。候補となる値は、CHARおよびBYTEです。

  • LENGTH: この列には、文字列長制約宣言の長さ制約の値が格納されます。

  • PRECISION: この列には、数値精度が変数宣言で使用されている場合にその精度が格納されます。

  • PRECISION2: この列には、変数宣言で使用されている第2精度値(間隔タイプなど)が格納されます。

  • SCALE: この列には、変数宣言で使用されているスケール値が格納されます。

  • LOWER_RANGE: この列には、範囲制約付きの変数宣言で使用されている範囲の下限値が格納されます。

  • UPPER_RANGE: この列には、範囲制約付きの変数宣言で使用されている範囲の上限値が格納されます。

  • NULL_CONSTRAINT: この列は、NULL制約が変数宣言で使用されている場合に設定されます。候補となる値は、NULLまたはNOT NULLです。

  • SQL_BUILTIN: PL/SQLから発行されたSQL文で使用されるSQLビルトインを識別子としている場合、この列はYESに設定されます。識別子がSQLビルトインでない場合、列はNOに設定されます。

PL/SQL外部ライブラリの変更点

Oracle Database 18c以上では、PATH_PREFIXが事前定義されたOracle Database 18c PDBにLIBRARYオブジェクトを作成する方法が変更されています。

  • PATH_PREFIXが事前定義されたPDBに新しいLIBRARYオブジェクトを作成する場合、LIBRARYDIRECTORYオブジェクトを使用する必要があります。DIRECTORYオブジェクトにより、LIBRARYオブジェクトに対してPATH_PREFIXのルールが適用されます。LIBRARYオブジェクトでDIRECTORYオブジェクトを使用しないと、PLS-1919コンパイル時エラーが発生します。

  • PATH_PREFIXが事前定義されたPDBとしてデータベースをCDBに接続する場合に、DIRECTORYオブジェクトを使用していないLIBRARYオブジェクトを使用しようとすると、ORA-65394ランタイム・エラーが発生します。LIBRARYオブジェクトは無効化されません。ただし、(ランタイム・エラーが常に発行されるのとは対照的に) LIBRARYを有効に活用するには、DIRECTORYオブジェクトを使用するようにLIBRARYオブジェクトを再作成する必要があります。

このように変更すると、ファイル・システムにおけるLIBRARYダイナミック・リンク・ライブラリ(DLL)の場所を示すPATH_PREFIXの値が考慮されるようになり、PDBでのLIBRARYオブジェクトのセキュリティと管理性が向上します。また、DIRECTORYオブジェクトを使用すると、管理者はDLLディレクトリへのアクセスを許可するユーザーを指定できます。

シンボリック・リンクおよびUTL_FILE

シンボリック・リンクでUTL_FILEを使用することはできません。かわりに、ディレクトリ・オブジェクトを使用してください。

アップグレード後、アプリケーションでUTL_FILEを介したシンボリック・リンクを使用してデータベースのアドレスを指定すると、これらのリンクは失敗します。ディレクトリ・オブジェクトを使用することをお薦めします。必要に応じて、UTL_FILE内のファイル名のターゲットとなる実際のファイルを作成できます。

例8-1 UTL_FILEおよびシンボリック・リンクによるエラー・メッセージの例

UTL_FILEのアドレスを指定するシンボリック・リンクを使用するアプリケーションで、エラーが発生しました。たとえば、次のようなシンボリック・リンクを作成しようとするとします。Ia.cはシンボリック・リンク・ファイルです。

create or replace directory TEMP as '/home/PLSQL/TEMP';

declare
f utl_file.file_type;
begin
f := utl_file.fopen('TEMP','la.c','r');
end;
/

このコマンドは、次のエラーが発生して失敗します。

ERROR at line 1: 
ORA-29283: invalid file operation 
ORA-06512: at "SYS.UTL_FILE", line 536 
ORA-29283: invalid file operation 
ORA-06512: at line 4

DBCAを使用したリスナーの直接登録の非推奨

Database Configuration Assistant (DBCA)を使用したOracle DatabaseのOracle Internet Directory (OID)への登録は、Oracle Database 18cで非推奨になりました。

アップグレード時に、DBCAを使用してデータベース・ホームにリスナーを移行または登録するかわりに、Net Configuration AssistantまたはNet Managerを使用して、新しいリリースのOracleホームにLISTENER.ORAファイルを作成してからこのリスナーを起動します。DBCAを使用してリスナーを登録解除し、OIDに再び登録することもできます。