SESSION_EXIT_ON_PACKAGE_STATE_ERRORは、セッションで実行されているステートフルPL/SQLパッケージの処理を指定します。このようなパッケージが変更された場合(Oracle提供オブジェクトの計画メンテナンス中など)、パッケージのアクティブなインスタンス化があるセッションは、パッケージを実行しようとすると次のエラーを受け取ります:

ORA-4068 existing state of package has been discarded

ただし、ORA-4068エラーを受信するアプリケーション・コードでは、その再試行ロジックでこのエラーを処理できない場合があります。

SESSION_EXIT_ON_PACKAGE_STATE_ERRORをTRUEに設定すると、このケースで異なる処理が行われます。SESSION_EXIT_ON_PACKAGE_STATE_ERRORがTRUEの場合、パッケージ状態が破棄されると、ORA-4068エラーが発生するのみでなく、セッションもすぐに終了します。多くのアプリケーションが自動的かつ透過的に接続を再確立することによってセッションの終了を処理できるため、これは有益である可能性があります。

デフォルトのAutonomous Databaseタイムゾーン

デフォルトのAutonomous Databaseタイム・ゾーンは、Coordinated Universal Time (UTC)であり、デフォルトではSYSDATEおよびSYSTIMESTAMPをコールすると、日付と時刻がUTCで返されます。

データベースのタイム・ゾーンを変更するには、次の文を実行します。

この例では、データベース・タイム・ゾーンをUTC-5に設定します。

ALTER DATABASE SET TIME_ZONE='-05:00';

この例では、米国東海岸のデータベース・タイムゾーン(America/New_York)を設定し、時間をDSTスイッチで自動的に調整します。

ALTER DATABASE SET TIME_ZONE='America/New_York';

データベースのタイム・ゾーンの設定後、デフォルトでは、SYSDATEおよびSYSTIMESTAMPは引き続きUTCで日時を返します(SYSDATE_AT_DBTIMEZONEはデフォルトでFALSEです)。セッションでSYSDATE_AT_DBTIMEZONEをTRUEに設定すると、SYSDATEおよびSYSTIMESTAMPはデータベースのタイム・ゾーンを返します。

ALTER DATABASEでSET TIME_ZONE句を使用する方法の詳細は、Oracle Database 19cまたはOracle Database 23aiのデータベース・タイムゾーンの設定を参照してください。

セッションでのSYSDATE_AT_DBTIMEZONEの使用

セッションでSYSDATE_AT_DBTIMEZONEがFALSEの場合、SYSDATEおよびSYSTIMESTAMPをコールすると、デフォルトのAutonomous Databaseタイム・ゾーンであるCoordinated Universal Time (UTC)に基づいて値が返されます。

セッションでSYSDATE_AT_DBTIMEZONEがTRUEの場合、SYSDATEまたはSYSTIMESTAMPをコールすると、データベースのタイム・ゾーンに基づいて日付と時刻が返されます。

例

次の例では、SYSDATE_AT_DBTIMEZONEパラメータ値に基づいて、2つの異なるタイム・ゾーンの日時が返されます:

SQL> SELECT DBTIMEZONE FROM DUAL;

DBTIMEZONE
_____________
-05:00

SQL> ALTER SESSION SET SYSDATE_AT_DBTIMEZONE=FALSE;

Session altered.

SQL> SELECT SYSTIMESTAMP FROM DUAL;

SYSTIMESTAMP
______________________________________
27-JAN-22 06.59.45.708082000 PM GMT

SQL> ALTER SESSION SET SYSDATE_AT_DBTIMEZONE=TRUE;

Session altered.

SQL> SELECT SYSTIMESTAMP FROM DUAL;

SYSTIMESTAMP
_________________________________________
27-JAN-22 02.14.47.578946000 PM -05:00 

SQL> SELECT TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD"T"HH24:MI:SS TZH":"TZM') FROM DUAL;

TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD"T"HH24:MI:SSTZH":"TZM')
___________________________________________________________
2022-01-27T14:15:00 -05:00

CLIENT_PREFETCH_ROWSパラメータは、ALTER SESSIONまたはALTER SYSTEMで設定できます。ALTER SESSIONを使用してパラメータ値が変更されると、後続の結果セット・フェッチでその特定のセッションに対して新しい値が有効になります。ALTER SYSTEMを使用してパラメータ値が変更された場合、新しい値は、ALTER SYSTEMコマンドの後に作成された接続で実行される文に対して有効になります。

たとえば、CLIENT_PREFETCH_ROWSが100に設定され、クライアント・アプリケーションが10行のフェッチを要求した場合、合計110行がクライアント・ドライバに返されます。110行中の最初の10行がアプリケーションに与えられ、クライアント・ドライバは残りの100行を内部的にバッファリングします。クライアント・アプリケーションから次の10行がフェッチされ、フェッチ反復ごとに10行がそれぞれ、クライアント・ドライバによって内部的にバッファされる100行から処理できます。このプロセスにより、データベースとの間の必要なネットワーク・ラウンドトリップの数が削減されます。この例では、11番目のフェッチで、新しいネットワーク・ラウンドトリップが発生し、結果セットが使い果たされておらず、サイクルが繰り返されているかぎり、データベースは110行の次のバッチを返します。

CLIENT_PREFETCH_ROWSの設定に関するノート:

• CLIENT_PREFETCH_ROWSがゼロ以外の値に設定されている場合、その値はプリフェッチ行数のデフォルトのOCI_ATTR_PREFETCH_ROWS値よりも優先されます。

• OCI_ATTR_PREFETCH_ROWS値がデフォルト以外の値に設定されている場合、プリフェッチ行数のCLIENT_PREFETCH_ROWS値は無視されます。

• OCIAttrSet()でCLIENT_PREFETCH_ROWSを使用する場合:

  OCI_ATTR_PREFETCH_ROWSは、プリフェッチされるトップレベル行の数を設定します。デフォルトは1行です。ただし、CLIENT_PREFETCH_ROWSが設定されている場合、プリフェッチされる最上位行の数は、次の優先順位によって決定されます。

  1. OCIAttrSet()関数またはoraaccess.xmlを値'1'として使用してOCI_ATTR_PREFETCH_ROWS属性を設定すると、データベース初期化パラメータのCLIENT_PREFETCH_ROWS値が優先され、プリフェッチされる最上位行の数が決定されます。

  2. OCIAttrSet()関数またはoraaccess.xmlを1以外の値'x'として使用してOCI_ATTR_PREFETCH_ROWS属性を設定すると、最上位行数の'x'がプリフェッチされ、データベース初期化パラメータCLIENT_PREFETCH_ROWSは無視されます。

  3. OCIAttrSet()またはoraaccess.xmlを使用してOCI_ATTR_PREFETCH_ROWS値を設定しない場合、データベース初期化パラメータのCLIENT_PREFETCH_ROWS値が優先され、プリフェッチされる最上位行の数が決定されます。

• OCIAttrGet()でCLIENT_PREFETCH_ROWSを使用する場合:

  ファンクションOCIAttrGet()は、OCI_ATTR_PREFETCH_ROWS、oraaccess.xmlおよびデータベース初期化パラメータCLIENT_PREFETCH_ROWSから設定された有効なプリフェッチ行値を返します。OCI_ATTR_PREFETCH_MEMORY値が設定されている場合、OCIAttrGet()によって返される値は、最終的なプリフェッチ行の値ではない可能性があり、OCI_ATTR_PREFETCH_MEMORY属性で指定されたメモリー値で許可される最大行数に制限される場合があります。

JOB_QUEUE_PROCESSESのデフォルト値と最大値は、使用するコンピュート・モデルによって異なります。詳細は、Autonomous Databaseのコンピュート・モデルを参照してください。

Oracle Schedulerのジョブ・コーディネータおよびジョブ・ワーカーは、JOB_QUEUE_PROCESSESパラメータによって制御されます。Oracle Schedulerジョブ用に作成されるジョブ・ワーカーの数は、使用可能なリソース、リソース・マネージャ設定、現在実行中のジョブなどの複数のファクタに応じて、スケジューラにより自動チューニングされます。

JOB_QUEUE_PROCESSESのデフォルト値では、アプリケーションのサービス品質とシステム・リソースの適切な使用の両立を図っています。ただし、すべての環境にデフォルト値が適合するとはかぎりません。

JOB_QUEUE_PROCESSESの値を0に設定すると、Oracle提供でないスケジューラ・ジョブが無効になります。JOB_QUEUE_PROCESSESが0に設定されている場合、Oracle提供ユーザーの内部ジョブは無効化されません(Oracle提供ユーザーが実行するサービス関連ジョブは引き続きスケジュールされます)。

Oracle提供のユーザーは、値がYのORACLE_MAINTAINEDとしてマークされたユーザーです。Oracle提供以外のユーザーは、値がNのORACLE_MAINTAINEDとしてマークされたユーザーです。

詳細は、ALL_USERSを参照してください。

Autonomous Databaseは、ロックダウン・プロファイルを使用して、特定のデータベース機能および機能を制限します。デフォルトでは、Autonomous Databaseロックダウン・プロファイルによって制限されているSQLコマンドを実行しようとすると、データベースによってエラーが発生します。LOCKDOWN_ERRORSパラメータを使用すると、ロックダウン・プロファイル・エラーを抑制できます。また、LOCKDOWN_ERRORSが値IGNOREに設定されている場合、エラーを無視すると、データベースのSQL文、ユーザーおよびコマンド・タイムスタンプに関する詳細が記録されます。

DBA_LOCKDOWN_ERRORSビューを使用して、ロックダウン・プロファイル・エラーに関する情報を取得できます。詳細は、ロックダウン・エラー・ビューを参照してください。

値

• ENFORCED: RESULT_CACHE_MODEまたは指定されたヒントの設定に関係なく、結果キャッシュの対象となるのは決定論的な構成のみです。たとえば、決定論的として宣言されていないPL/SQLファンクションを使用する問合せはキャッシュされません(ファンクションが決定論的として宣言されていないかぎり、そのようなファンクションを使用した問合せ結果はキャッシュされません)。

• TRUSTED: データベースは、RESULT_CACHE_MODEおよび指定されたヒントの設定を尊重し、結果キャッシュの候補として決定的でない可能性のある構造を使用する問合せを検討します。たとえば、決定論的として宣言されていないPL/SQLファンクションを使用する問合せはキャッシュできます。ただし、非決定的であることがわかっている結果はキャッシュされません(たとえば、SYSDATEまたはSYSDATEを含むコンストラクト)。

詳細は、RESULT_CACHE_MODEを参照してください。