11g リリース1（11.1）
E05758-02
 目次 |
 索引 |
| Oracle Database アップグレード・ガイド 11g リリース1（11.1） E05758-02 |
|
この付録では、Oracle9iリリース2（9.2）、Oracle Database 10gリリース1（10.1）、Oracle Database 10gリリース2（10.2）、Oracle Database 11gリリース1（11.1）の間の重要な動作の変更点について説明します。 動作の変更によって発生する可能性がある危険性を最小限に抑えるために、DBAが詳細な情報を得て決定を行う必要がある動作の変更点に焦点を当てて説明します。 Oracle Database 11gリリース1（11.1）のすべての動作の変更または新機能については説明しません。
この付録では、次の項目について説明します。
次の各項では、Oracle Database 11gリリース1（11.1）で発生する互換性および相互運用性の問題と、これらの問題によって発生する問題を回避するための対処方法を説明します。
次の初期化パラメータはOracle Database 11gリリース1（11.1）で非推奨となりました。すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。
SQL> SELECT name FROM v$parameter WHERE isdeprecated = 'TRUE';
非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。 また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。
BACKGROUND_DUMP_DEST（DIAGNOSTIC_DESTに変更）
COMMIT_WRITE
CURSOR_SPACE_FOR_TIME
INSTANCE_GROUPS
LOG_ARCHIVE_LOCAL_FIRST
PLSQL_DEBUG（PLSQL_OPTIMIZE_LEVELに変更）
PLSQL_V2_COMPATIBILITY
REMOTE_OS_AUTHENT
RESOURCE_MANAGER_CPU_ALLOCATION
STANDBY_ARCHIVE_DEST
CQ_NOTIFICATION$_REG_INFOオブジェクトの）TRANSACTION_LAG属性
USER_DUMP_DEST（DIAGNOSTIC_DESTに変更）
次の初期化パラメータはOracle Database 11gリリース1（11.1）で廃止されました。
Oracle Database 11gリリース1（11.1）では、次の静的データ・ディクショナリ・ビューの列が削除されました。
| 静的データ・ディクショナリ・ビュー | 削除された列 |
|---|---|
|
|
|
この項では、Oracle Database 11gリリース1（11.1）で非推奨となった機能を示します。下位互換性を保持する目的で、これらの機能がこのリリースでサポートされています。 ただし、これらの非推奨となった機能は移行の対象外とすることをお薦めします。
JDK 5.0の使用をお薦めします。ただし、JDK 1.5も完全にサポートされます。
かわりにXMLIndexを使用することをお薦めします。
Oracle Database 11gリリース1（11.1）の新しいデータベース・コンポーネントである自動メンテナンス・タスク管理では、すべての自動メンテナンス・タスクがメンテナンス期間の拡張セット内にスケジュールされます。自動メンテナンス・タスク管理を使用することにより、オプティマイザ統計の収集、セグメント・アドバイザおよび自動SQLチューニング・アドバイザなどのタスクについて、メンテナンス・タスクのスケジュール作成をより細かく制御することが可能です。
自動メンテナンス・タスク管理では、既存のメンテナンス期間がすべて使用されます（たとえば、MAINTENANCE_WINDOW_GROUPの現行のメンバーである期間）。そのメンテナンス期間に関連付けられた既存のリソース・プランが使用されます。ただし、AUTOTASK_CONSUMER_GROUPは、AutoTaskリソース・サブプランによってリソース・プラン内で置換されます。
オプティマイザ統計の収集またはセグメント・アドバイザのいずれかを10gで無効にしている場合は、対応する自動メンテナンス・タスク管理機能は、Oracle Database 11gリリース1（11.1）へのアップグレード後に無効になります。
次に、メンテナンス・タスクのデフォルト設定を示します。
その他の自動メンテナンス・タスク管理クライアントはすべてデフォルトで有効です。
自動メンテナンス・タスク管理は、Oracle Database 11gリリース1（11.1）へのアップグレード時に自動的に有効になりますが、AutoTaskオンライン・バックアップは自動的に有効にはなりません。必要な場合は、データベースをアップグレードした後に、手動でオンライン・バックアップを構成する必要があります。データベースをダウングレードした場合、自動メンテナンス・タスク管理は、そのリリースでのデフォルトの動作状態に戻ります。
Oracle Database 11gリリース1（11.1）には、ASM管理タスクの実行目的に特化したSYSASM権限という新しい権限が導入されています。SYSDBA権限のかわりにSYSASM権限を使用することにより、ASMの管理職務とデータベースの管理職務を明確に区別できます。
CREATE DISKGROUP、MOUNT/DISMOUNT、ADD/DROP DISK、ONLINE/OFFLINE DISK、DROP DISKGROUPなどのディスク・グループのメンテナンス・タスクをSYSDBAで実行すると、ASMのalert.logに警告メッセージが表示されます。これらの作業はSYSDBAでは非推奨になっています。SYSASMで実行する必要があります。
OSASMは、ASM用として専用に使用される新しいオペレーティング・システム（OS）・グループです。OSASMグループのメンバーはOS認証を使用してAS SYSASMで接続が可能であり、ASMに対するすべてのアクセス権限を持ちます。
この機能の詳細は、「自動ストレージ管理（ASM）インスタンスのアップグレード」を参照してください。
Oracle Database 11gリリース1（11.1）以上では、ソフトウェア・バージョンをまたいでOracle DatabaseとASMのディスク・グループの互換性設定を拡張できます。新しい互換性属性であるcompatible.rdbmsおよびcompatible.asmを使用して、データベース用のディスク・グループおよびASM用のディスク・グループを使用するために必要な最小ソフトウェア・バージョンをそれぞれ指定できます。
この機能により、Oracle Database 10gリリース1（10.1）、Oracle Database 10gリリース2（10.2）およびOracle Database 11gリリース1（11.1）のディスク・グループで構成される異機種環境が実現します。デフォルトでは、属性は両方とも10.1に設定されます。新機能を活用するには、これらの属性を拡張する必要があります。
以前のリリースでは、ANALYZE...COMPUTE STATISTICSおよびANALYZE...ESTIMATE STATISTICS句を使用して、索引での統計の収集を開始および停止できましたが、 これらの句は廃止されました。 Oracle Database 11gリリース1（11.1）では、索引の作成中および再構築中に統計が自動的に収集されます。これらの句はすでにサポートされなくなっており、使用するとエラーが発生します。
Oracle Database 11gリリース1（11.1）へのアップグレード中に、DMSYSスキーマ・オブジェクトは大きな制約もなく、ユーザー・スキーマに存在するユーザー・モデルとともにアップグレードされます。アップグレード完了時に、マイニングのメタデータはSYSスキーマに移行されますが、ユーザー・モデルは新しいメタデータで継続して機能します。COMPATIBLE初期化パラメータを11.0.0に設定した後、DMSYSスキーマを削除することをお薦めします。また、データベース管理者は、既存のユーザーが引き続きマイニング・モデルを作成できるように、新しいCREATE MINING MODEL権限を付与する必要があります。
ユーザー・スキーマに存在するデータ・マイニング・モデルは、モデルのアップグレードの一環として自動的にアップグレードされます。これは、Oracle Databaseのアップグレード処理で欠かすことのできない部分です。データ・マイニング・モデルのエクスポートおよびインポート・ユーティリティを、データ・マイニング・モデルのリリース間アップグレードの手段として使用することもできます。
データベースのダウングレード処理中に、データ・マイニングのコンポーネントは以前のリリースにダウングレードされます。ダウングレード処理では、パッケージ、タイプおよび表オブジェクトなどのDMSYSオブジェクトがリロードされる他、ユーザー・スキーマがある場合はダウングレードするユーザー・スキーマ内のモデル・オブジェクトがリロードされます。データベースのアップグレードの一環として作成されたオブジェクトは、ダウングレード処理中にSYSスキーマから削除されます。これは透過的な処理であり、ユーザーの介入は不要です。
アップグレード後（かつ、COMPATIBLE初期化パラメータを11.0.0に設定してからDMSYSスキーマを削除した後）、Oracle Database 10gリリース1（10.1）からエクスポートされたモデルのインポート作業が多少面倒になる場合があります。これは、すでに存在していないDMSYSスキーマが参照されていることが原因です。 このような場合の対策として、Oracle Database 10gリリース1（10.1）のデータベースに存在するDMSYSのインタフェースを必要最小限に模倣するスクリプトが用意されているため、インポート処理を続行できるようになっています。モデルは時間の経過とともに古くなり、通常、ユーザーは古いモデルをインポートするよりも、モデルを作成しなおすことを望むため、このような例は一般的には発生しません。
データ・マイニングはCOMPATIBLE初期化パラメータで保護されていないことに注意してください。 データベースをOracle Database 11gリリース1（11.1）にアップグレードしても、COMPATIBLEが10.1.0または10.2.0に設定されている場合は、データ・マイニングの新機能および既存の機能はすべて動作します。 Oracle Database 11gリリース1（11.1）のみで使用できる新しいマイニング・モデルを作成し、その後Oracle Database 10gリリース2（10.2）にデータベースをダウングレードすることにした場合は、ダウングレードする前に新しいマイニング・モデルを削除することが必要になります。
Oracle Database 11gリリース1（11.1）以上では、Oracle Data Mining Scoring Engineのインストールができなくなりました。
Oracle Database 11gリリース1（11.1）では、ストアド・アウトラインの使用は非推奨となっています。かわりに、SQL計画管理機能を使用する必要があります。この機能は、オプティマイザでSQL文の実行計画履歴をメンテナンスできるようにするものです。実行計画履歴を使用することにより、SQL文の計画変更を示している新しい計画をオプティマイザで検出することができます。新しい計画がオプティマイザによって検出されると、新しい計画は保存され、パフォーマンス評価の対象としてマーキングされ、現時点で優れた計画と見なされている古い計画が使用されます。オプティマイザで新しい計画が使用されるのは、新しい計画のほうが古い計画よりもパフォーマンスが優れていることが検証された場合のみです。SQL計画ベースラインは、優れたSQL文の計画と見なされた一連の計画で構成されます。
SQLプロファイルは、Oracle Database 10gリリース1（10.1）で導入されたSQL管理オブジェクトです。これらのオブジェクトは、SYSTEM表領域内に定義されたディクショナリの一部に存在しました。SQLプロファイルが格納されるディクショナリ表は再構築され、SQL管理オブジェクトであるSQL計画ベースラインの記憶域としても使用できるようになりました。また、これらのディクショナリ表はSYSAUX表領域内に定義されています。
Oracle Database 10gリリース1（10.1）からOracle Database 11gリリース1（11.1）にアップグレードすると、既存のSQLプロファイルはデータベース・アップグレード・スクリプトによってSYSTEM表領域からSYSAUX表領域に移動されます。 したがって、Oracle Database 11gリリース1（11.1）のデータベース・インスタンスが起動していてもSYSAUX表領域がオフラインの場合は、オプティマイザでSQL管理オブジェクトにアクセスすることはできません。このことが、一部のSQLワークロードのパフォーマンスに影響する場合があります。 一方、Oracle Database 10gリリース1（10.1）の場合、SQLプロファイルはSYSTEM表領域に格納されていたため、SQLプロファイルが使用できないということはありませんでした。 SYSAUX表領域をオフラインにした状態でOracle Database 11gリリース1（11.1）を起動すると、SQLのパフォーマンスに影響が出る可能性があります。
Oracle Database 11gリリース1（11.1）では、下位互換性は次のようになっています。
SQL文に対してストアド・アウトラインが使用可能な場合、SQL計画管理機能は使用されません。ただし、別のユーザー・セッションで同じSQL文がアクティブなストアド・アウトラインなしで使用されている場合は、SQL計画管理機能が使用されます。
Oracle Database 11gリリース1（11.1）の新しいオプションであるバイナリのXML記憶域オプションは、COMPATIBLE初期化パラメータを11.0.0以上に設定した場合に使用できます。この記憶域オプションを使用して表または列を作成すると、互換性の最小要件が確認されます。最小要件は、バイナリのXMLドキュメントを直接XML DBリポジトリに格納しようとしたときにも確認されます。
データベースをOracle Database 11gリリース1（11.1）にアップグレードするときに、既存のユーザーXMLType表およびインスタンスの変更は一切行われません。アップグレードの完了後に、新しい記憶域形式を使用して既存の表を変更したり、その後で新しい表を作成することができます。 XDBの表XDB$CONFIGおよびXDB$ACLと、対応するXMLスキーマは、データベースをOracle Database 11gリリース1（11.1）にアップグレードするときに、バイナリのXML記憶域に移行されます。
次の項では、Oracle Database 11gリリース1（11.1）のPL/SQLで変更された互換性および相互運用性について説明します。
Oracle Database 11g以上では、PL/SQLネイティブ・コンパイルにCコンパイラは不要です。したがって、現在、PL/SQLネイティブ・コンパイルをサポートする目的のみでCコンパイラを使用している場合は、データベースがインストールされているマシン（およびOracle RAC構成の各ノードから）からCコンパイラを削除できます。
さらに、PL/SQLネイティブ・コンパイルの出力はファイル・システム上で実現されなくなりました。そのため、Oracle Database 10gの初期化パラメータPLSQL_Native_Library_DirおよびPLSQL_Native_Library_Subdir_Countは、Oracle Database 11gでは重要でなくなりました。これらのパラメータが示すディレクトリ、およびディレクトリの内容は、アップグレード処理の完了時に削除しても問題ありません。
また、ORACLE_HOME/plsqlディレクトリにあるSPNC_COMMANDSファイルも不要です。
PL/SQLネイティブ・コンパイルの制御用として、初期化パラメータPLSQL_Code_Typeのみが残されています。したがって、データベース管理者はPL/SQLネイティブ・コンパイルを考慮する必要はありません。
ネットワーク・ユーティリティ・パッケージに対するアクセス制御のデフォルトの動作が変更され、権限を持たないすべてのユーザーに対してネットワーク操作が許可されなくなりました。 このデフォルトの動作はこれまでのバージョンのOracle Databaseとは異なる動作であり、互換性がなくなりました。
Oracle Database 11gリリース1（11.1）にアップグレードするデータベース・ユーザーの場合、PL/SQLネットワーク・ユーティリティ・パッケージに依存するアプリケーションは問題なくコンパイルできます。ただし、権限が必要なネットワーク操作を実行しようとすると、実行時にアプリケーションで例外が受信される可能性があります。ネットワーク操作の実行に必要な権限をワイルドカードを使用してPUBLICに付与することで互換性を回復することはできますが、データベース管理者はそれぞれの状況を個別に慎重に調査し、必要な場合にのみ権限を付与することを強くお薦めします。
PL/SQLの動作を制御するOracleパラメータの一部は、Oracle Database 11gリリース1（11.1）で動作が変更されました。
PLSQL_OPTIMIZE_LEVEL <= 1の場合は、デバッグ・コードが生成されます。
PLSQL_DEBUGは非推奨です。かわりに、PLSQL_OPTIMIZE_LEVELを使用する必要があります。PLSQL_DEBUGを使用すると、非推奨であることを示す警告が発行されます。
PLSQL_OPTIMIZE_LEVEL <= 1の場合は、ネイティブ・コードが生成されません。
PLSQL_COMPILER_FLAGSは廃止されました。このパラメータは無効になっており、不正なオプションが設定されているとして、エラー・メッセージが発行されます。
PLSQL_V2_COMPATIBILITYは非推奨です。
Oracle XML DBでは、アクセス制御リスト（ACL）に基づくセキュリティ・メカニズムによって、Oracle XML DBのリソースへのアクセスが制限されます。ACLとは、アクセス制御エントリ（ACE）のリストで、指定されたリソースへのアクセス権を持っているユーザー、ロールおよびグループの特定は、このリストを基に行われます。
WebDAV ACLエントリの処理方法は変更されました。 Oracle Database 11gリリース1（11.1）より前のリリースの場合、指定されたACL内で<deny>エントリは常に<allow>エントリより優先されました。 Oracle Database 11gリリース1（11.1）以上では、ACEの順番が重要ではなくなりました。デフォルトの動作は、最初に出現した<allow>エントリまたは<deny>エントリによってのみ決定されます。つまり、プリンシパルに対する動作は最初のエントリで決定され、そのプリンシパルに設定された他のACEは効力を持ちません。
デフォルトの動作は、これまでのバージョンのOracle Databaseとは異なる動作に変更され、互換性は失われました。 Oracle Database 11gリリース1（11.1）へのアップグレード時に、必要に応じて手動でACLを並べ替えることにより、前のリリースと同様に動作させることができます。つまり、<allow>の後に<deny>が続くACLがある場合は、<deny>エントリが先に検出されるように、ACLを手動で並べ替える必要があります。
Oracle Database 10gリリース2（10.2）以上では、DBMS_OLAPパッケージ（サマリー管理内のサマリー・アドバイザ）は非推奨とされており、SQLアクセス・アドバイザに置き換えられています。
SQLアクセス・アドバイザ・リポジトリの内部構造が変更されたため、データベースをアップグレードすることにより、既存のSQLアクセス・アドバイザのタスクはすべて初期状態にリセットされます。つまり、アップグレード前に正常に実行されていたタスクに対する推奨情報は、すべて削除されます。
アップグレード後に、既存のSQLアクセス・アドバイザのタスクを再実行することにより、推奨情報を回復できます。
Standard Edition（SE）の初期データベースをアップグレードする場合、次のコンポーネントに必要なオプションがStandard Editionにはインストールされていないため、次のコンポーネントはSEサーバーでアップグレードすることはできません。
アップグレード後、これらのコンポーネントをDBA_REGISTRYビューで参照するとSTATUSの値が'OPTION OFF'と表示され、関連付けられたコンポーネント・スキーマに無効なオブジェクトが含まれます。Database Upgrade Assistant（DBUA）には、これらのコンポーネントのアップグレードが失敗したことが表示されます。
UNIXシステムでは、セグメンテーション違反などの処理できないシグナルにより、アプリケーション・プログラムがクラッシュした場合、通常、コア・ファイルが生成されます。このコア・ファイルは、coreというデフォルト名で、アプリケーションを現在実行しているディレクトリに配置されます。 Oracle Database 11gリリース1（11.1）以上では、Oracle Call Interface（OCI）を使用するアプリケーションの場合は、ora_core_process_id（process_idはクラッシュしたプロセスのUNIX ID）という名前のサブディレクトリを作成できるようになりました。この場合、coreファイルはデフォルトの位置ではなく、そのサブディレクトリに配置されます。
Oracle Database 11gリリース1（11.1）以上では、UNDO_MANAGEMENTパラメータのデフォルト値はAUTOであるため、自動UNDO管理はデフォルトで有効になっています。パラメータをMANUALに設定し、必要に応じて自動UNDO管理をオフにする必要があります。
Oracle Database 11gリリース1（11.1）以上では、LOG_ARCHIVE_DEST_nパラメータを使用して、Oracle Standard Editionを実行するデータベース・インスタンス上にローカルのアーカイブ先を指定できます。以前は、このパラメータで指定できるのはOracle Enterprise Editionを実行するデータベース・インスタンス上のみでした。
Oracle Database 10gリリース1（10.1）より前のOracle Databaseリリースで共有プールに割り当てられたメモリー量は、SHARED_POOL_SIZE初期化パラメータの値とインスタンスの起動中に計算された内部SGAのオーバーヘッドを合計した値と等しい量でした。このオーバーヘッドは、他のいくつかの初期化パラメータの値に基づいていました。
たとえば、SHARED_POOL_SIZEパラメータが64MBで内部SGAのオーバーヘッドが12MBの場合、SGA内の共有プールのサイズは実際には76MBになります。ただし、SHARED_POOL_SIZEパラメータの値は引き続き64MBと表示されます。
Oracle Database 10gリリース1（10.1）以上では、内部SGAのオーバーヘッドのサイズはSHARED_POOL_SIZEパラメータの値に含まれます。起動時に共有プールに割り当てられるメモリー量は、SHARED_POOL_SIZEパラメータの値と正確に一致します。したがってこのパラメータには、内部SGAのオーバーヘッドと共有プールとして実際に必要なサイズの両方を含んだ値を設定する必要があります。
内部SGAのオーバーヘッドが変更されていないと仮定すると、起動後に実際に共有プールとして使用できる値はSHARED_POOL_SIZEパラメータの値より12MB少ない値、つまり52MBになります。共有プールの実際のメモリー量を64MBに維持するには、このパラメータを76MBに設定します。
このリリース用の移行ユーティリティでは、アップグレード前の環境における内部SGAのオーバーヘッドの値に基づいて、SHARED_POOL_SIZEの新しい値を設定することが推奨されています。その値は、Oracle Database 11gリリース1（11.1）にアップグレードする前に次の問合せを実行することにより求めることができます。
SQL> SELECT SUM(BYTES) FROM v$sgastat WHERE pool = 'shared pool';
Oracle Database 11gリリース1（11.1）では、内部SGAのオーバーヘッド（共有プール内の起動時のオーバーヘッド）の正確な値は、新しいv$sgainfoビューにリストされます。
手動SGAモードのときに、SHARED_POOL_SIZEの値が小さすぎて内部SGAのオーバーヘッドに対応できない場合は、起動中にORA-00371エラーが発生します。このエラーでは、SHARED_POOL_SIZEパラメータの推奨値を含むエラー・メッセージが生成されます。自動共有メモリー管理を使用している場合、共有プールのサイズは自動調整されるため、ORA-00371エラーが発生することはありません。
Oracle Database 11gリリース1（11.1）以上では、JOB_QUEUE_PROCESSES初期化パラメータは基本パラメータから基本パラメータ以外に変更になりました。データベースを正しく効率的に実行するためにほとんどのデータベースで必要とされているのは、基本パラメータの設定のみです。
以前のリリースのOracle Databaseでは、DBMS_JOBおよびDBMS_SCHEDULERで同じジョブ・コーディネータが共有されており、ジョブ・コーディネータの動作はJOB_QUEUE_PROCESSESパラメータによって制御されていました。現在では、DBMS_JOBおよびDBMS_SCHEDULERは、この初期化パラメータを設定しなくても動作するようになっています。必要であればこの初期化パラメータを設定できますが、設定は必須ではありません。
JOB_QUEUE_PROCESSESのサポートされている値の範囲は、引き続き0〜1000です。 このパラメータを0に設定した場合、DBMS_SCHEDULERのジョブは実行されますが、DBMS_JOBのジョブは実行されません。 DBMS_SCHEDULERジョブに対して作成されるスレーブ・プロセスの数は、コンピュータの負荷に基づいて自動調整されます。
JOB_QUEUE_PROCESSESに設定された値が1〜1000の範囲内である場合、DBMS_JOBのジョブとDBMS_SCHEDULERのジョブの両方が実行され、これらのジョブに対して作成されるスレーブ・プロセスの数は、スレーブ・プロセスの合計数をJOB_QUEUE_PROCESSESの値以下とする制約の範囲内で自動調整されます。
アラート・ログおよびトレース・ファイルの場所は、初期化パラメータBACKGROUND_DUMP_DESTおよびUSER_DUMP_DESTによっては設定されなくなりました。 これらの場所は自動診断リポジトリ（ADR）に保持されるようになりました。自動診断リポジトリの場所は、初期化パラメータDIAGNOSTIC_DESTによって設定されます。
次の項では、Oracle Database 10gリリース2（10.2）で発生する互換性および相互運用性の問題について説明します。 Oracle Database 10gリリース2（10.2）より前のリリースからOracle Database 11gリリース1（11.1）にアップグレードする場合は、これらの問題によって発生する問題を回避するための対処方法について、次の各項を参照してください。
次の初期化パラメータはOracle Database 10gリリース2（10.2）で非推奨となりました。すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。
SQL> SELECT name FROM v$parameter WHERE isdeprecated = 'TRUE';
非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE
次の初期化パラメータはOracle Database 10gリリース2（10.2）で廃止されました。
Oracle Database 10gリリース2（10.2）では、次の静的データ・ディクショナリ・ビューの列が削除されました。
| 静的データ・ディクショナリ・ビュー | 削除された列 |
|---|---|
|
|
|
XMLファンクションで日付書式を使用した場合の動作が変更されています。XMLデータ内の日付およびタイムスタンプは、XMLスキーマ標準によって標準の書式に設定されています。 Oracle Database 10gリリース2（10.2）より前のリリースでは、XMLデータ内の日付およびタイムスタンプはこの標準に準拠していませんでした。生成されるXML内の日付およびタイムスタンプの書式はデータベースの書式によって決まりました。
Oracle Database 10gリリース2（10.2）では、Oracle XML DBのXML生成ファンクションにより、XMLスキーマ標準に従って日付およびタイムスタンプが生成されます。
Oracle Database 10gリリース2（10.2）より前のリリースからアップグレードした後は、CONNECTロールに含まれる権限はCREATE SESSIONのみになります。前のリリースでCONNECTロールに付与されていた他の権限は、アップグレード時に取り消されます。 詳細は、「非推奨のCONNECTロール」を参照してください。
Oracle Database 10gリリース2（10.2）に付属のタイムゾーン・ファイルはバージョン2からバージョン4に更新され、一部のタイムゾーン地域の変換ルールに対して行われた変更が反映されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。 詳細は、「TIMESTAMP WITH TIME ZONEデータ型」を参照してください。
Oracle Database 10gリリース2（10.2）では、DEFAULTプロファイルに対するFAILED_LOGIN_ATTEMPTSの制限は10です。Oracle Database 10gリリース2（10.2）より前のリリースでは、デフォルトはUNLIMITEDでした。
次の項では、Oracle Database 10gリリース1（10.1）で発生する互換性および相互運用性の問題について説明します。 Oracle Database 10gリリース1（10.1）より前のリリースからOracle Database 11gリリース1（11.1）にアップグレードする場合は、これらの問題によって発生する問題を回避するための対処方法について、次の各項を参照してください。
次の初期化パラメータはOracle Database 10gリリース1（10.1）で非推奨となりました。すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。
SQL> SELECT name FROM v$parameter WHERE isdeprecated = 'TRUE';
非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。
BUFFER_POOL_KEEP（DB_KEEP_CACHE_SIZEに変更）
BUFFER_POOL_RECYCLE（DB_RECYCLE_CACHE_SIZEに変更）
GLOBAL_CONTEXT_POOL_SIZE
LOCK_NAME_SPACE
LOG_ARCHIVE_START
MAX_ENABLED_ROLES
PARALLEL_AUTOMATIC_TUNING
PLSQL_COMPILER_FLAGS（PLSQL_CODE_TYPEおよびPLSQL_DEBUGに変更）
SQL_VERSION
次の初期化パラメータはOracle Database 10gリリース1（10.1）で廃止されました。
DBLINK_ENCRYPT_LOGIN
HASH_JOIN_ENABLED
LOG_PARALLELISM
MAX_ROLLBACK_SEGMENTS
MTS_CIRCUITS
MTS_DISPATCHERS
MTS_LISTENER_ADDRESS
MTS_MAX_DISPATCHERS
MTS_MAX_SERVERS
MTS_MULTIPLE_LISTENERS
MTS_SERVERS
MTS_SERVICE
MTS_SESSIONS
OPTIMIZER_MAX_PERMUTATIONS
ORACLE_TRACE_COLLECTION_NAME
ORACLE_TRACE_COLLECTION_PATH
ORACLE_TRACE_COLLECTION_SIZE
ORACLE_TRACE_ENABLE
ORACLE_TRACE_FACILITY_NAME
ORACLE_TRACE_FACILITY_PATH
PARTITION_VIEW_ENABLED
PLSQL_NATIVE_C_COMPILER
PLSQL_NATIVE_LINKER
PLSQL_NATIVE_MAKE_FILE_NAME
PLSQL_NATIVE_MAKE_UTILITY
ROW_LOCKING
SERIALIZABLE
TRANSACTION_AUDITING
UNDO_SUPPRESS_ERRORS
次の静的データ・ディクショナリ・ビューはOracle Database 10gリリース1（10.1）で非推奨となりました。
ALL_STORED_SETTINGS（ALL_PLSQL_OBJECT_SETTINGSに変更）
DBA_STORED_SETTINGS（DBA_PLSQL_OBJECT_SETTINGSに変更）
USER_STORED_SETTINGS（USER_PLSQL_OBJECT_SETTINGSに変更）
次の静的データ・ディクショナリ・ビューはOracle Database 10gリリース1（10.1）で廃止されました。
| ALLビュー | DBAビュー | USERビュー |
|---|---|---|
|
|
|
|
次の動的パフォーマンス・ビューはOracle Database 10gリリース1（10.1）で非推奨となりました。
GV$CACHE
GV$CACHE_TRANSFER
GV$CLASS_CACHE_TRANSFER（GV$INSTANCE_CACHE_TRANSFERに変更）
GV$FALSE_PING
GV$FILE_CACHE_TRANSFER（GV$INSTANCE_CACHE_TRANSFERに変更）
GV$GC_ELEMENTS_WITH_COLLISIONS
GV$LOCK_ACTIVITY
GV$TEMP_CACHE_TRANSFER（GV$INSTANCE_CACHE_TRANSFERに変更）
V$CACHE
V$CACHE_LOCK
V$CACHE_TRANSFER
V$CLASS_CACHE_TRANSFER（V$INSTANCE_CACHE_TRANSFERに変更）
V$FALSE_PING
V$FILE_CACHE_TRANSFER（V$INSTANCE_CACHE_TRANSFERに変更）
V$GC_ELEMENTS_WITH_COLLISIONS
V$LOCK_ACTIVITY
V$TEMP_CACHE_TRANSFER（V$INSTANCE_CACHE_TRANSFERに変更）
次の動的パフォーマンス・ビューはOracle Database 10gリリース1（10.1）で廃止されました。
| GV$ビュー | V$ビュー |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
この項では、Oracle Database 10gリリース1（10.1）のSQLオプティマイザに関連する互換性の問題および相互運用性の問題について説明します。
Oracle Database 10gリリース1（10.1）以上では、コストベース・オプティマイザ（CBO）がデフォルトで有効になっています。 ルールベース・オプティマイザは、Oracle Database 10gリリース1（10.1）ではサポートされなくなりました。そのため、ruleおよびchooseは、OPTIMIZER_MODE初期化パラメータの値としてサポートされません。OPTIMIZER_MODEにいずれかの値を設定すると、警告が表示されます。
現在、オプティマイザ統計の収集は、すべてのスキーマ（SYSを含む）、Oracle Database 10gリリース1（10.1）より前のリリースからアップグレードした既存のデータベース、および新規作成したデータベースに対して自動的に実行されます。無効なオブジェクトのオプティマイザ統計の収集は、メンテナンス期間中、毎日実行されるようにデフォルトでスケジュールされます。
以前のリリースでは、CREATE INDEXのCOMPUTE STATISTICS句を使用して、索引での統計の収集を開始および停止できました。 この句は非推奨となっています。 Oracle Database 10gリリース1（10.1）以上のリリースでは、索引の作成中および再構築中に統計が自動的に収集されます。この句は、下位互換性のためにサポートされているもので、エラーは発生しません。
以前のリリースでは、SKIP_UNUSABLE_INDEXESはセッション・パラメータのみでした。 Oracle Database 10gリリース1（10.1）以上のリリースでは、このパラメータは初期化パラメータであり、デフォルトはtrueです。trueに設定すると、索引のエラー・レポートおよびUNUSABLEにマークされた索引パーティションが使用不可になります。この設定を使用すると、使用できない索引または索引パーティションを使用する表で、すべての操作（挿入、削除、更新および選択）を実行できます。
Oracle Database 10gリリース1（10.1）以上では、SQLおよびPL/SQLでのCLOBとNCLOBの暗黙的な変換が可能です。
Oracle Database 10gリリース1（10.1）以上では、シノニムの名前解決が変更されています。現在、シノニムのベース・オブジェクトが存在しない場合、SQLコンパイラはPUBLIC.base_objectの検索を試行します。
Oracle Database 10gリリース1（10.1）以上では、VPDポリシーがベース・オブジェクトにではなくシノニムに付加されます。
Oracle Database 10gリリース1（10.1）以上では、シノニム（パブリックまたはプライベート）が存在しない場合または無効なオブジェクトを指している場合、アップグレード後にそのシノニムは無効になります。
現在、データベースのパフォーマンス統計は、Oracle Database 10gリリース1（10.1）より前のリリースからアップグレードされたデータベースおよび新規に作成されたデータベースの自動ワークロード・リポジトリ（AWR）のデータベース・コンポーネントによって自動的に収集されます。このデータは、SYSAUX表領域に格納され、推奨パフォーマンスを自動生成するために、データベースによって使用されます。
パフォーマンス・データの収集にStatspackを使用している場合は、AWRとの競合を回避するために、StatspackのREADME（ORACLE_HOME/rdbms/adminディレクトリにあるspdoc.txt）で、Oracle Database 10gリリース1（10.1）以上のリリースでのStatspackの使用についての説明を参照してください。
Oracle Database 10gリリース1（10.1）以上では、削除されたオブジェクトはごみ箱に移動されます。このごみ箱の領域は、必要なときにのみ再利用されます。これによって、オブジェクトは、FLASHBACK DROP機能を使用してごみ箱から戻すことができます。
Oracle Database 10gリリース1（10.1）以上では、UNDO保存の自動チューニングはデフォルトで有効になっています。UNDO_SUPPRESS_ERRORS初期化パラメータは、非推奨になりました。自動UNDO管理モードのときにロールバック・セグメント操作を実行した場合に生成されるエラーは、常に、表示されません。
Oracle Database 10gリリース1（10.1）以上では、Oracle Managed Files（OMF）のデフォルトのAUTOEXTEND NEXTサイズが大きくなります。
Oracle Database 10gリリース1（10.1）以上では、LOG_ARCHIVE_START初期化パラメータが非推奨となりました。アーカイブは、データベースをARCHIVELOGモードにすると、自動的に開始されます。
Oracle Database 10gリリース1（10.1）以上では、LOG_PARALLELISM初期化パラメータが非推奨となりました。ログ・ファイルの並列処理は、自動的に有効になります。
Oracle Database 10gリリース1（10.1）以上では、RECOVERY_PARALLELISM初期化パラメータのデフォルト値は、パラレル・リカバリの許可に設定されます。
Oracle Database 10gリリース1（10.1）以上では、ALTER DATABASE RECOVER DATABASE文のパラレル句のデフォルト値が、PARALLELに変更されています。
Oracle Database 10gリリース1（10.1）以上では、LOG_ARCHIVE_DEST_n初期化パラメータのASYNC属性のデフォルト・バッファ・サイズが、2,048ブロックから61,440ブロックに増加されています。
Oracle Database 10gリリース1（10.1）以上では、DBMS_LOGSTDBY.APPLY_SET()プロシージャで設定されるパラメータMAX_SGAおよびMAX_SERVERSのデフォルト値が変更されています。
Oracle Database 10gリリース1（10.1）以上では、Data Guard BrokerのプロパティApplyParallel、AsyncBlocksおよびLogXptModeのデフォルト値が変更されています。
Oracle Database 10gリリース1（10.1）以上では、フィジカル・スタンバイ・データベースでのSQL*PlusコマンドSTARTUP、SQL文ALTER DATABASE MOUNTおよびALTER DATABASE OPENのデフォルトの動作が変更されています。コマンドによって、データベースがフィジカル・スタンバイであることが自動的に検出されます。このため、STANDBY DATABASEおよびREAD ONLYオプションがデフォルトに設定されます。
Oracle Database 10gリリース1（10.1）以上では、バックアップからファイルをリストアするときにファイルのバックアップが存在しない場合は、Recovery Managerによって空のファイルが作成されます。アーカイブ・ログのRecovery Managerのバックアップは、最後のresetlogsの前に作成されたログを自動的にバックアップします。以前は、このようなログは無視されました。
Oracle Database 10gリリース1（10.1）以上では、Recovery Managerでエラーが発生した場合、バックアップまたはリストア・ジョブの残りの部分は継続して実行されます。対象となるバックアップの破損を検出すると、代替バックアップからのリストアを試行します。
Oracle Database 10gリリース1（10.1）以上のリリースでは、データベースの作成時またはデータベースのアップグレード時に、常にSYSAUX表領域が作成されます。SYSAUX表領域は、SYSTEM表領域の予備の表領域として機能します。SYSAUXは、Oracleの多くの機能および製品（以前は機能や製品ごとに表領域を必要としていた）のデフォルトの表領域であるため、DBAによる管理が必要な表領域の数が減少します。
Oracle Database 10gリリース1（10.1）以上では、ログ・ファイルの最小サイズおよびデフォルトのサイズが増加されています。最小サイズは4MBです。デフォルトのサイズは50MBです。ただし、Oracle Managed Files（OMF）を使用している場合、デフォルトのサイズは100MBになります。
Oracle Database 10gリリース1（10.1）では、Oracle Real Application Clustersに対して、自動化された高可用性（HA）フレームワークが提供されます。このフレームワークでは、検出、リカバリ、再起動および通知サービスが行われます。
Oracle Database 10gリリース1（10.1）以上では、一部の権限の名前が変更されています。新しい名前は、すべてのデータ・ディクショナリ・ビューに表示されます。ただし、GRANTおよびREVOKE SQL文では、以前の名前と新しい名前の両方が使用できます。
CREATE SNAPSHOTは、CREATE MATERIALIZED VIEWに変更されました
CREATE ANY SNAPSHOTは、CREATE ANY MATERIALIZED VIEWに変更されました
ALTER ANY SNAPSHOTは、ALTER ANY MATERIALIZED VIEWに変更されました
DROP ANY SNAPSHOTは、DROP ANY MATERIALIZED VIEWに変更されました
Oracle Database 10gリリース1（10.1）以上では、DBMS_CDC_SUBSCRIBEおよびDBMS_CDC_PUBLISHのインタフェースで使用されるのは、サブスクリプション・ハンドルではなくサブスクリプション名パラメータです。
Oracle Database 10gリリース1（10.1）以上では、サブスクライバ・ビューは自動的に管理されます。PREPARE_SUBSCRIBER_VIEW()およびDROP_SUBSCRIBER_VIEW()をインタフェースとするDBMS_CDC_SUBSCRIBEおよびDBMS_CDC_PUBLISHをコールする必要がなくなりました。
Oracle Database 10gリリース1（10.1）以上では、同期チェンジ・データ・キャプチャのRSID$列の計算が変更され、サブスクライバ・ビュー同士を結合して古い値と新しい値の両方を同じ行に表示することが容易になりました。同じ更新操作に関連するUO行およびUN行のRSID$の値は、等しくなります。Oracle9iの動作（同じ更新操作では、UN RSID$値はUO RSID$値に1を加えた値に等しい）に戻すには、イベント10983をレベル4に設定します。
Oracle Database 10gリリース1（10.1）以上では、リモートの宛先に対するデフォルトのアーカイブ処理が変更されています。この変更によって、プライマリ・データベースのアーカイブ処理では、リモートのスタンバイ宛先にREDOデータが転送される前に、ローカルのオンラインREDOログ・ファイルがすべて正常にアーカイブされます。 このデフォルトの動作は、LOG_ARCHIVE_LOCAL_FIRST初期化パラメータをtrueに設定した場合と同じです。これは、Oracle Database 10gリリース1（10.1）以上のリリースでの新機能でもあります。この新しいデフォルトのアーカイブ処理は、ログ転送サービスがログ・ライター・プロセス（LGWR）ではなくアーカイバ・プロセス（ARCn）を使用するように定義され、アーカイバ・プロセスがリモートの宛先に書込みを実行していて、リモートのスタンバイ宛先が必須の宛先ではない場合にのみ、有効になります。
Oracle Database 10gリリース1（10.1）より前のリリースでは、オンラインREDOログ・ファイルがローカルのオンラインREDOログ・ファイルにアーカイブされると同時に、REDOデータをスタンバイ宛先に転送するのがデフォルトの動作でした。LOG_ARCHIVE_LOCAL_FIRST初期化パラメータをfalseに設定すると、このように動作します。また、このアーカイブ処理は、ログ転送サービスがログ・ライター・プロセス（LGWR）ではなくアーカイバ・プロセス（ARCn）を使用するように定義され、アーカイバ・プロセスがリモートの宛先に書込みを実行していて、リモートのスタンバイ宛先が必須の宛先ではない場合にのみ、有効になります。
新しいデフォルトの動作の利点は、ローカルのアーカイブ、つまりプライマリ・データベースでの処理は、必須ではないリモートの宛先へのアーカイブに影響されない点です。ローカルのアーカイブとリモートのアーカイブは連動しなくなったため、プライマリ・データベースのアーカイブ済REDOログ・ファイルをバックアップ直後に削除するポリシーを設定しているサイトでは、プライマリ・データベースのアーカイブ済REDOログ・ファイルを削除する前に、スタンバイの宛先が対応するREDOデータを受信していることを確認する必要があります。V$ARCHIVED_LOGビューを問い合せて、スタンバイの宛先でREDOデータが受信されていることを確認できます。
Oracle Database 10gリリース1（10.1）以上では、NCHARデータ型（NCHAR、NVARCHAR2、NCLOBなど）は、Unicodeキャラクタ・セット・コード（UTF8およびAL16UTF16）に制限されています。
Oracle Database 10gリリース1（10.1）以上では、ネイティブ・コンパイルの初期化パラメータの構成およびコマンド設定が簡単になっています。現在の重要なパラメータは、PLSQL_NATIVE_LIBRARY_DIRとPLSQL_NATIVE_LIBRARY_SUBDIR_COUNTです。 コンパイラ、リンカーおよびmakeユーティリティに関連するパラメータは廃止されています。ネイティブ・コンパイルは、PLSQL_COMPILER_FLAGSパラメータ（現在は非推奨）のいずれかのオプションではなく、個別の初期化パラメータPLSQL_CODE_TYPEで有効または無効にします。ORACLE_HOME/plsqlディレクトリにあるspnc_commandsファイルには、makeファイルではなく、コンパイルおよびリンク用のコマンドおよびオプションが含まれています。
数値リテラルの評価方法が変更され、リテラルを使用する数値計算の場合は、定数の1つ以上で小数第1位に小数点を指定することが必要になりました。 これは、Oracle Database 10gリリース1（10.1）以上のリリースでは一部の式でINTEGER演算（有効桁は約9桁）が使用されますが、Oracle9iリリース2（9.2）ではNUMBER演算（有効桁数は約38桁）が使用されるためです。
したがって、有効桁数が9桁を超える計算結果を扱う場合、数値オーバーフローのエラーを回避するには、リテラルのうち1つが小数形式であることが必要です。 たとえば、Oracle Database 10gリリース1（10.1）では、次に示す例のv1の計算で数値オーバーフローのエラーが発生します。
DECLARE v1 NUMBER(38); BEGIN v1 := 256*256*256*256; DBMS_OUTPUT.PUT_LINE(v1); END; /
エラーが発生しないようにするには、数値リテラルの1つを次のように小数（256.0）として指定します。
DECLARE v1 NUMBER(38); BEGIN v1 := 256*256*256*256.0; DBMS_OUTPUT.PUT_LINE(v1); END; /
Oracle Database 10gリリース1（10.1）以上では、キャッシュされるカーソルの数はSESSION_CACHED_CURSORS初期化パラメータによって決定されます。 以前のリリースのOracle Databaseでは、PL/SQLでキャッシュされるSQLカーソルの数はOPEN_CURSORS初期化パラメータによって決定されました。
Oracle Database 10gリリース1（10.1）以上では、DB_BLOCK_SIZEのデフォルト値はオペレーティング・システム固有です。通常は8KB（8192バイト）です。 以前のリリースのOracle Databaseでは、デフォルト値は2KB（2048バイト）でした。 Oracle9iリリース2（9.2）からアップグレードする際にDB_BLOCK_SIZEがパラメータ・ファイルで指定されていない場合、データベースを起動しようとするとエラーが表示されます。次の行をパラメータ・ファイルに追加します。
DB_BLOCK_SIZE = 2048
DB_BLOCK_SIZEがパラメータ・ファイルで指定されている場合、Oracle Databaseはデフォルト値（8KB）ではなく指定された値を使用します。
Oracle Database 10g以上では、OPTIMIZER_MAX_PERMUTATIONS初期化パラメータは廃止されました。 Oracle9iからアップグレードして、パラメータ・ファイルでOPTIMIZER_FEATURES_ENABLEを8.1.7以下に設定し、OPTIMIZER_MAX_PERMUTATIONSを明示的に2000に設定すると、Oracle Database 11gリリース1（11.1）のデータベースの起動時にリリース8.1.7のデフォルトの80000が使用されます。
OPTIMIZER_FEATURES_ENABLEを9.0.0以上に設定すると、デフォルトが2000に設定されます。
Oracle Database 10gリリース1（10.1）以上では、COMPATIBLE初期化パラメータを10.0.0以上に設定する場合、すべてのアーカイブ・ログのファイル名が一意となるように、アーカイブ・ログのファイル名に要素%s（順序）、%t（スレッド）および%r（リセットログID）を含める必要があります。LOG_ARCHIVE_FORMAT初期化パラメータをパラメータ・ファイルに設定する場合は、パラメータ値に%s、%tおよび%r要素が含まれていることを確認します。
Oracle Database 10gリリース1（10.1）以上では、自動PGAメモリー管理がデフォルトで使用可能です（PGA_AGGREGATE_TARGETに0、またはWORKAREA_SIZE_POLICYにMANUALが明示的に設定されていない場合）。PGA_AGGREGATE_TARGETのデフォルトは、明示的に指定されていない場合はSGAのサイズの20%です。アップグレード後にPGA_AGGREGATE_TARGETの値をチューニングすることをお薦めします。
以前のリリースでは、割り当てられた共有プールのメモリーの量は、SHARED_POOL_SIZE初期化パラメータの値とインスタンスの起動中に計算された内部SGAのオーバーヘッドの量の合計でした。 Oracle Database 10gリリース1（10.1）以上では、SHARED_POOL_SIZEの値はこの共有プールのオーバーヘッドに対応する必要もあります。
Oracle Database 10gリリース1（10.1）以上では、共有サーバー・モードをオンにする場合、SHARED_SERVERSを0より大きい値に設定することをお薦めします。これは、起動時またはインスタンスの起動後に動的に設定できます。SHARED_SERVERSを0に設定して共有モードをオフにする場合、これは新しいクライアントのみに影響します（つまり、新しいクライアントは共有モードでは接続できません。すでに共有モードで接続しているクライアントは共有サーバーによって接続を継続できます）。
以前のリリースでは、共有サーバー・モードをオンにするにはDISPATCHERSを設定する方法をお薦めしていました。SHARED_SERVERSが0に変更された後も共有サーバー・クライアントが接続していた場合は、クライアントの要求はハングアップしました。
Oracle Database 10gリリース1（10.1）より前のリリースでは、次の共有サーバーのパラメータを動的に変更することはできませんでした。
Oracle Database 10gリリース1（10.1）以上では、これらの共有サーバーのパラメータを動的に変更できます。
Oracle Database 10gリリース1（10.1）以上では、DISPATCHERSのデフォルトは'(PROTOCOL=TCP)'です。値が設定されていない場合、または''が設定され、SHARED_SERVERSが1以上に設定されている場合、DISPATCHERSにこのデフォルト値が設定されます。
以前のリリースでは、DISPATCHERSのデフォルト値はありませんでした。
Oracle Database 10gリリース1（10.1）以上では、ディスパッチャの合計数が0になるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは0です。ディスパッチャの合計数が0よりも多くなるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは、以前のリリースと同様に1です。
以前のリリースでは、ディスパッチャの数が0になるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは1でした。
Oracle Database 10gリリース1（10.1）以上では、MAX_SHARED_SERVERSに対して事前に設定されたデフォルトはありません。共有サーバーの合計数は、空きプロセス・スロットの数によって異なります。MAX_SHARED_SERVERSが設定されていない場合、またはPROCESSES以上の値が設定されている場合、空きプロセス・スロットの数が2（PROCESSESが24未満の場合）または1 / 8未満のときは、既存のサーバーがデッドロック状態でないかぎり、PMONは共有サーバーを起動しません。既存のサーバーがデッドロック状態の場合、トランザクションの負荷にかかわらず、空きプロセス・スロットがないときは新しいサーバーが起動されます。
以前のリリースでは、MAX_SHARED_SERVERSがPROCESSESを超えない場合、MAX_SHARED_SERVERSのデフォルトは20またはSHARED_SERVERSの2倍（どちらか大きい方）でした。
Oracle Database 10gリリース1（10.1）以上では、サーバーの数が常にSHARED_SERVERSに設定されたレベルである場合、SHARED_SERVERSをMAX_SHARED_SERVERSより大きく設定できます。これによって、特定の順序でこれらのパラメータを変更する必要なく、SHARED_SERVERS〜MAX_SHARED_SERVERSの範囲を変更できます。
以前のリリースでは、SHARED_SERVERSをMAX_SHARED_SERVERSよりも大きく設定できませんでした。
Oracle Database 10gリリース1（10.1）以上では、SHARED_SERVER_SESSIONSに対して事前に設定されたデフォルトはありません。したがって、SHARED_SERVER_SESSIONSを指定しない場合は、セッションの制限で許可されている範囲で、必要に応じて、共有サーバー・セッションを作成できます。
以前のリリースでは、SHARED_SERVER_SESSIONSのデフォルトは、バーチャル・サーキットの最大数（CIRCUITS）またはデータベース・セッションの最大数（SESSIONS）から5を引いた数（いずれか小さい方）でした。
Oracle Database 10gリリース1（10.1）以上では、CIRCUITSに対して事前に設定されたデフォルトはありません。したがって、CIRCUITSを指定しない場合は、ディスパッチャの制約およびシステム・リソースで許可されている範囲で、必要に応じて、サーキットを作成できます。
以前のリリースでは、CIRCUITSのデフォルトは、共有サーバー・モードが有効な場合はデータベース・セッションの最大数（SESSIONS）、その他の場合は0でした。
Oracle Database 10gリリース1（10.1）以上では、MAX_DISPATCHERSに対して事前に設定されたデフォルトはありません。MAX_DISPATCHERSはディスパッチャの数を制限しません。空きプロセス・スロットおよびシステム・リソースがあるかぎりは、ユーザーはDISPATCHERSパラメータでディスパッチャの数を増加できます。
以前のリリースでは、MAX_DISPATCHERSのデフォルトは、5またはDISPATCHERSパラメータで指定したディスパッチャの合計数（いずれか大きい方）でした。
|
 Copyright © 2008 Oracle Corporation. All Rights Reserved. |
|