SESSION_EXIT_ON_PACKAGE_STATE_ERROR indique le traitement d'un package PL/SQL avec conservation de statut exécuté dans une session. Lorsqu'un package de ce type fait l'objet d'une modification, par exemple lors d'une maintenance planifiée pour des objets fournis par Oracle, les sessions qui ont une instanciation active du package reçoivent l'erreur suivante lorsqu'elles tentent d'exécuter le package :

ORA-4068 existing state of package has been discarded

Cependant, le code d'application qui reçoit l'erreur ORA-4068 peut ne pas être équipé pour gérer cette erreur avec sa logique de nouvelle tentative.

La définition de SESSION_EXIT_ON_PACKAGE_STATE_ERROR sur TRUE fournit un traitement différent pour ce cas. Lorsque SESSION_EXIT_ON_PACKAGE_STATE_ERROR est défini sur TRUE, au lieu de simplement générer l'erreur ORA-4068 lorsque l'état du package est rejeté, la session se ferme immédiatement. Cela peut être avantageux car de nombreuses applications peuvent gérer la terminaison de la session en rétablissant automatiquement et de manière transparente la connexion.

Fuseau horaire d'Autonomous Database par défaut

Le fuseau horaire d'Autonomous Database par défaut est le temps universel coordonné (UTC). Par défaut, les appels vers SYSDATE et SYSTIMESTAMP retournent la date et l'heure dans UTC.

Pour modifier le fuseau horaire de la base de données, vous pouvez exécuter l'instruction suivante.

Cet exemple définit le fuseau horaire de la base de données sur UTC-5.

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

Cet exemple définit le fuseau horaire de la base de données pour la côte est des Etats-Unis : America/New_York et l'heure est automatiquement ajustée au niveau des commutateurs d'heure d'été :

ALTER DATABASE SET TIME_ZONE='America/New_York';

Une fois que vous avez défini le fuseau horaire de la base de données, par défaut, SYSDATE et SYSTIMESTAMP continuent à renvoyer la date et l'heure au format UTC (SYSDATE_AT_DBTIMEZONE est défini sur FALSE par défaut). Si vous définissez SYSDATE_AT_DBTIMEZONE sur TRUE dans une session, SYSDATE et SYSTIMESTAMP retournent le fuseau horaire de la base de données.

Pour plus d'informations sur l'utilisation de la clause SET TIME_ZONE avec ALTER DATABASE, reportez-vous à Définition du fuseau horaire de la base de données dans Oracle Database 19c ou Oracle Database 23ai.

Utilisation de SYSDATE_AT_DBTIMEZONE dans une session

Lorsque SYSDATE_AT_DBTIMEZONE est défini sur FALSE dans une session, les appels vers SYSDATE et SYSTIMESTAMP retournent des valeurs en fonction du fuseau horaire d'Autonomous Database par défaut, le temps universel coordonné (UTC).

Lorsque SYSDATE_AT_DBTIMEZONE est défini sur TRUE dans une session, les appels vers SYSDATE ou SYSTIMESTAMP retournent la date et l'heure en fonction du fuseau horaire de la base de données.

Exemple

L'exemple suivant renvoie les dates et heures pour deux fuseaux horaires différents, en fonction de la valeur du paramètre SYSDATE_AT_DBTIMEZONE :

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

Le paramètre CLIENT_PREFETCH_ROWS peut être défini avec ALTER SESSION ou ALTER SYSTEM. Si la valeur du paramètre change à l'aide de ALTER SESSION, la nouvelle valeur prend effet pour cette session spécifique lors des extractions d'ensemble de résultats suivantes. Si la valeur du paramètre change à l'aide de ALTER SYSTEM, la nouvelle valeur prend effet pour les instructions exécutées sur les connexions créées après la commande ALTER SYSTEM.

Par exemple, si CLIENT_PREFETCH_ROWS est défini sur 100 et qu'une application client demande d'extraire 10 lignes, un total de 110 lignes est renvoyé au pilote client. Les 10 premières lignes sur les 110 lignes sont données à l'application et le pilote client met en mémoire tampon en interne les 100 lignes restantes. Les 10 lignes suivantes sont extraites de l'application client, chacune avec 10 lignes par itération d'extraction pouvant être exécutée à partir des 100 lignes mises en mémoire tampon en interne par le pilote client. Ce processus réduit le nombre d'aller-retours réseau requis depuis et vers la base de données. Dans cet exemple, lors de la 11e extraction, un nouvel aller-retour réseau est engagé et la base de données renvoie le lot suivant de 110 lignes, tant que l'ensemble de résultats n'est pas épuisé et que le cycle se répète.

Remarques relatives à la définition de CLIENT_PREFETCH_ROWS :

• Lorsque CLIENT_PREFETCH_ROWS est défini sur une valeur différente de zéro, sa valeur est prioritaire sur la valeur OCI_ATTR_PREFETCH_ROWS par défaut pour le nombre de lignes de pré-extraction.

• Si la valeur OCI_ATTR_PREFETCH_ROWS est définie sur une valeur autre que celle par défaut, la valeur CLIENT_PREFETCH_ROWS est ignorée pour le nombre de lignes de pré-extraction.

• Utilisation de CLIENT_PREFETCH_ROWS avec OCIAttrSet() :

  OCI_ATTR_PREFETCH_ROWS définit le nombre de lignes de niveau supérieur à pré-extraire. La valeur par défaut est 1 ligne. Toutefois, si CLIENT_PREFETCH_ROWS est défini, le nombre de lignes de niveau supérieur à pré-extraire est déterminé par la priorité suivante :

  1. Si vous définissez l'attribut OCI_ATTR_PREFETCH_ROWS à l'aide de la fonction OCIAttrSet() ou de oraaccess.xml en tant que valeur '1', la valeur du paramètre d'initialisation de base de données CLIENT_PREFETCH_ROWS est prioritaire et détermine le nombre de lignes de niveau supérieur à pré-extraire.

  2. Si vous définissez l'attribut OCI_ATTR_PREFETCH_ROWS à l'aide de la fonction OCIAttrSet() ou de oraaccess.xml en tant que valeur 'x' autre que 1, le nombre de lignes de niveau supérieur 'x' sera pré-extrait et le paramètre d'initialisation de base de données CLIENT_PREFETCH_ROWS sera ignoré.

  3. Si vous ne définissez pas de valeur OCI_ATTR_PREFETCH_ROWS à l'aide de OCIAttrSet() ou oraaccess.xml, la valeur du paramètre d'initialisation de base de données CLIENT_PREFETCH_ROWS est prioritaire et détermine le nombre de lignes de niveau supérieur à pré-extraire.

• Utilisation de CLIENT_PREFETCH_ROWS avec OCIAttrGet() :

  La fonction OCIAttrGet() renvoie la valeur de ligne de pré-extraction effective définie à partir de OCI_ATTR_PREFETCH_ROWS, oraaccess.xml et le paramètre d'initialisation de base de données CLIENT_PREFETCH_ROWS. Si la valeur OCI_ATTR_PREFETCH_MEMORY est définie, la valeur renvoyée par OCIAttrGet() peut ne pas être la valeur de ligne de pré-extraction finale et peut être limitée au nombre maximal de lignes autorisé par la valeur de mémoire indiquée par l'attribut OCI_ATTR_PREFETCH_MEMORY.

Les valeurs par défaut et maximales pour JOB_QUEUE_PROCESSES diffèrent en fonction du modèle de calcul que vous utilisez. Pour plus d'informations, reportez-vous à Modèles de calcul dans Autonomous Database.

Le coordinateur de travaux et les processus de travail Oracle Scheduler sont contrôlés par le paramètre JOB_QUEUE_PROCESSES. Le nombre réel de processus actifs créés pour les travaux Oracle Scheduler est réglé automatiquement par le planificateur en fonction de plusieurs facteurs, notamment les ressources disponibles, les paramètres Resource Manager et les travaux en cours d'exécution.

La valeur par défaut de JOB_QUEUE_PROCESSES fournit un compromis entre la qualité de service des applications et l'utilisation raisonnable des ressources système. Cependant, il est possible que la valeur par défaut ne corresponde pas à tous les environnements.

La définition de la valeur de JOB_QUEUE_PROCESSES sur 0 désactive les travaux du planificateur non fournis par Oracle. Lorsque JOB_QUEUE_PROCESSES est défini sur 0, cela ne désactive aucun travail interne pour les utilisateurs fournis par Oracle (les travaux liés au service exécutés par les utilisateurs fournis par Oracle continuent d'être programmés).

Les utilisateurs fournis par Oracle sont des utilisateurs marqués comme ORACLE_MAINTAINED avec la valeur Y. Les utilisateurs non fournis par Oracle sont des utilisateurs marqués comme ORACLE_MAINTAINED avec la valeur N.

Pour plus d'informations, reportez-vous à ALL_USERS.

Autonomous Database utilise des profils de verrouillage pour restreindre certaines fonctionnalités et fonctionnalités de base de données. Par défaut, la base de données génère une erreur chaque fois que vous tentez d'exécuter une commande SQL restreinte par le profil de verrouillage Autonomous Database. Le paramètre LOCKDOWN_ERRORS vous permet de supprimer les erreurs de profil de verrouillage. De plus, lorsque LOCKDOWN_ERRORS est défini sur la valeur IGNORE, en ignorant une erreur, la base de données consigne les détails relatifs à l'instruction SQL, à l'utilisateur et à l'horodatage de la commande.

Vous pouvez utiliser la vue DBA_LOCKDOWN_ERRORS pour obtenir des informations sur les erreurs de profil de verrouillage. Pour plus d'informations, reportez-vous à Vue Erreurs de verrouillage.

Valeurs

• ENFORCED : quel que soit le paramètre RESULT_CACHE_MODE ou les conseils indiqués, seules les structures déterministes sont éligibles à la mise en cache des résultats. Par exemple, les requêtes utilisant des fonctions PL/SQL qui ne sont pas déclarées comme déterministes ne sont jamais mises en mémoire cache (sauf si les fonctions sont déclarées comme déterministes, les résultats de requête avec ces fonctions ne sont pas mis en mémoire cache).

• TRUSTED : la base de données respecte le paramètre RESULT_CACHE_MODE et les conseils spécifiés, et prend en compte les requêtes utilisant éventuellement des structures non déterministes comme candidats à la mise en cache des résultats. Par exemple, les requêtes utilisant des fonctions PL/SQL qui ne sont pas déclarées comme déterministes peuvent être mises en mémoire cache. Toutefois, les résultats connus comme non déterministes ne sont pas mis en mémoire cache (par exemple, SYSDATE ou des structures impliquant SYSDATE).

Pour plus d'informations, reportez-vous à RESULT_CACHE_MODE.