Paramètres d'initialisation

Autonomous AI Database configure automatiquement les paramètres d'initialisation de base de données lorsque vous provisionnez une base de données. Il n'est pas nécessaire de définir des paramètres d'initialisation pour pouvoir commencer à utiliser votre service. Toutefois, vous pouvez modifier certains paramètres, si nécessaire.

Paramètres d'initialisation modifiables

Le tableau suivant présente les paramètres d'initialisation qui ne peuvent être modifiés qu'avec ALTER SESSION.

Le tableau suivant présente les paramètres d'initialisation qui ne peuvent être modifiés qu'avec ALTER SYSTEM.

Le tableau suivant présente les paramètres d'initialisation modifiables avec ALTER SESSION ou ALTER SYSTEM.

Pour plus d'informations sur les paramètres d'initialisation, voir Oracle AI Database Référence.

CLIENT_PREFETCH_ROWS

Définissez le paramètre CLIENT_PREFETCH_ROWS pour permettre aux clients de réduire le nombre d'allers-retours requis lors de l'extraction des rangées d'un jeu de résultats d'interrogation.

CLIENT_PREFETCH_ROWS indique le nombre de rangées à préextraire par le pilote de client Oracle, sans apporter de modification à l'application client. Le pilote client met en mémoire tampon les lignes prédéfinies après chaque exécution d'interrogation réussie et pour chaque demande d'extraction ultérieure envoyée à la base de données.

Ce paramètre s'applique uniquement aux clients qui utilisent Oracle Call Interface (OCI) pour se connecter à la base de données.

Ce paramètre s'applique uniquement à Oracle Instant Client/Oracle Database Client 19.17 (ou version ultérieure) et 21.8 (ou version ultérieure) pour toutes les plates-formes.

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 entre en vigueur pour cette session spécifique lors des extractions de jeu de résultats suivantes. Si la valeur du paramètre change à l'aide de ALTER SYSTEM, la nouvelle valeur prend effet pour les énoncés qui s'exécutent sur les connexions créées après la commande ALTER SYSTEM.

Par exemple, si CLIENT_PREFETCH_ROWS est réglé à 100 et qu'une application client demande d'extraire 10 rangées, un total de 110 rangées sont retournées au pilote client. Les 10 premières lignes sur les 110 sont données à l'application et le pilote client met en mémoire tampon en interne les 100 lignes restantes. Les 10 prochaines lignes extraites de l'application client, chacune avec 10 lignes par itération d'extraction, peuvent être exécutées à partir des 100 lignes mises en mémoire tampon en interne par le pilote client. Ce processus réduit le nombre d'allers-retours réseau requis vers et depuis 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 retourne le lot suivant de 110 lignes, à condition que le jeu de résultats ne soit pas épuisé et que le cycle se répète.

Notes pour définir CLIENT_PREFETCH_ROWS :

• Lorsque CLIENT_PREFETCH_ROWS est réglé à 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 rangées de préextraction.

• Si la valeur OCI_ATTR_PREFETCH_ROWS est réglée à une valeur autre que par défaut, la valeur CLIENT_PREFETCH_ROWS est ignorée pour le nombre de rangées de préextraction.

• Utilisation de CLIENT_PREFETCH_ROWS avec OCIAttrSet() :

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

  1. Si vous définissez l'attribut OCI_ATTR_PREFETCH_ROWS en utilisant la fonction OCIAttrSet() ou oraaccess.xml comme 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 rangées 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 comme valeur 'x' autre que 1, le nombre de rangées 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 CLIENT_PREFETCH_ROWS du paramètre d'initialisation de la base de données est prioritaire et détermine le nombre de rangées de niveau supérieur à préextraire.

• Utilisation de CLIENT_PREFETCH_ROWS avec OCIAttrGet() :

  La fonction OCIAttrGet() retourne le jeu de valeurs de rangée de préextraction en vigueur à 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 retournée par OCIAttrGet() n'est peut-être pas la valeur finale des rangées de préextraction et peut être limitée au nombre maximal de rangées autorisé par la valeur de mémoire spécifiée par l'attribut OCI_ATTR_PREFETCH_MEMORY.

  Note
  
  

  Voir aussi :

  • Oracle Call Interface Developer's Guide pour plus d'informations sur l'extraction des résultats et la définition du nombre de pré-extractions.
  • OCIAttrSet()
  • OCI_ATTR_PREFETCH_ROWS;

CLOUD_TABLE_COMMIT_THRESHOLD

Le paramètre CLOUD_TABLE_COMMIT_THRESHOLD contrôle le nombre de modifications mises en mémoire tampon pour les tables en nuage avant l'écriture des modifications dans le stockage d'objets.

Lorsque le paramètre CLOUD_TABLE_COMMIT_THRESHOLD est réglé à une valeur différente de zéro, le système traite la valeur comme un seuil de nombre de modifications et les modifications de la table Cloud sont mises en mémoire tampon jusqu'à ce que le nombre de modifications atteigne le seuil spécifié. Lorsque le seuil est atteint, les modifications en mémoire tampon sont exportées vers le stockage d'objets. La valeur par défaut de ce paramètre est 0 (la mise en mémoire tampon est désactivée).

Pour plus d'informations, voir À propos des tables en nuage.

Note

Note : Ce paramètre s'applique à toutes les tables en nuage et peut être défini par n'importe quel utilisateur doté du privilège ALTER SESSION. Par conséquent, les tables Cloud ne conviennent pas aux données critiques pour la sécurité lorsque les modifications validées doivent être durables et immédiatement visibles par les lecteurs simultanés. Pour cette raison, Cloud Tables peut ne pas être approprié pour des cas d'utilisation tels que les tables de journal de vérification.

JOB_QUEUE_PROCESSES

Définissez le paramètre JOB_QUEUE_PROCESSES pour spécifier le nombre maximal de programmes de travail pouvant être créés pour exécuter des tâches Oracle Scheduler (DBMS_SCHEDULER).

Le réglage de la valeur à 0 désactive les travaux Scheduler non fournis par Oracle.

Les valeurs par défaut et maximales pour JOB_QUEUE_PROCESSES diffèrent selon le modèle de calcul que vous utilisez. Pour plus d'informations, voir Modèles de calcul dans Autonomous AI Database.

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

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

Le réglage de la valeur de JOB_QUEUE_PROCESSES à 0 désactive les travaux de programmateur non fournis par Oracle. Lorsque JOB_QUEUE_PROCESSES est réglé à 0, aucune tâche interne n'est désactivée pour les utilisateurs fournis par Oracle (les tâches liées au service exécutées par les utilisateurs fournis par Oracle continuent d'être programmées).

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.

Voir ALL_USERS pour plus d'informations.

LOCKDOWN_ERRORS

Définissez le paramètre LOCKDOWN_ERRORS pour contrôler si les erreurs de profil de verrouillage de la base de données d'intelligence artificielle autonome sont générées ou ignorées.

Autonomous AI Database utilise des profils de verrouillage pour restreindre certaines fonctionnalités et caractéristiques de base de données. Par défaut, la base de données génère une erreur lorsque vous tentez d'exécuter une commande SQL restreinte par le profil de verrouillage de la base de données d'IA autonome. Le paramètre LOCKDOWN_ERRORS vous permet de supprimer les erreurs de profil de verrouillage. De plus, lorsque LOCKDOWN_ERRORS est réglé à la valeur IGNORE, en ignorant une erreur, la base de données enregistre les détails concernant l'énoncé SQL, l'utilisateur et l'horodatage de la commande.

Note

Note : Évaluez soigneusement vos scripts existants avant de régler la valeur de ce paramètre à IGNORE. Lorsque vous réglez la valeur à IGNORE, les scripts existants que vous utilisez ne déclenchent plus d'erreurs de verrouillage.

Vous pouvez utiliser la vue DBA_LOCKDOWN_ERRORS pour obtenir des informations sur les erreurs de profil de verrouillage. Pour plus d'informations, voir Vue des erreurs de verrouillage.

SESSION_EXIT_ON_PACKAGE_STATE_ERROR

SESSION_EXIT_ON_PACKAGE_STATE_ERROR active ou désactive le traitement spécial pour les ensembles PL/SQL avec état exécutés dans une session.

SESSION_EXIT_ON_PACKAGE_STATE_ERROR indique le traitement d'un ensemble PL/SQL avec état s'exécutant dans une session. Lorsqu'un tel package subit 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

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

Le réglage de SESSION_EXIT_ON_PACKAGE_STATE_ERROR à TRUE fournit un traitement différent pour ce cas. Lorsque SESSION_EXIT_ON_PACKAGE_STATE_ERROR a la valeur TRUE, au lieu de simplement déclencher l'erreur ORA-4068 lorsque l'état du paquetage est abandonné, la session se ferme immédiatement. Cela peut être avantageux car de nombreuses applications sont en mesure de gérer l'arrêt de session en rétablissant automatiquement et de manière transparente la connexion.

RESULT_CACHE_INTEGRITY

Définissez le paramètre RESULT_CACHE_INTEGRITY pour spécifier si la mémoire cache de résultats considère les interrogations utilisant éventuellement des constructions non déterministes comme candidates à la mise en mémoire cache des résultats.

Valeurs

• ENFORCED : Indépendamment du paramètre RESULT_CACHE_MODE ou des conseils spécifiés, seules les constructions déterministes sont admissibles à la mise en mémoire cache des résultats. Par exemple, les requêtes utilisant des fonctions PL/SQL qui ne sont pas déclarées déterministes ne sont jamais mises en cache (sauf si les fonctions sont déclarées déterministes, les résultats des requêtes avec de telles fonctions ne seront pas mis en cache).

• TRUSTED : La base de données respecte le paramètre RESULT_CACHE_MODE et les conseils spécifiés et considérera les interrogations utilisant éventuellement des constructions non déterministes comme candidates à la mise en mémoire cache des résultats. Par exemple, les interrogations utilisant des fonctions PL/SQL qui ne sont pas déclarées déterministes peuvent être mises en mémoire cache. Notez toutefois que les résultats connus pour être non déterministes ne sont pas mis en mémoire cache (par exemple, SYSDATE ou des constructions impliquant SYSDATE).

RESULT_CACHE_MODE

Définissez le paramètre RESULT_CACHE_MODE pour spécifier les interrogations pouvant stocker les jeux de résultats dans la mémoire cache des résultats. Seuls les plans d'exécution d'interrogation avec l'opérateur de cache de résultats tenteront de lire ou d'écrire dans le cache de résultats.

Pour plus d'informations, voir RESULT_CACHE_MODE.

Utiliser les conseils SQL Result Cache

Utilisez les conseils de mise en cache des résultats au niveau de l'application pour contrôler le comportement de mise en cache. Les conseils relatifs au cache de résultats SQL ont priorité sur le mode du cache de résultats et les annotations de table du cache de résultats.

Vous pouvez utiliser les conseils relatifs au cache de résultats SQL comme suit :

• Utilisation du conseil RESULT_CACHE

• Utilisation du conseil NO_RESULT_CACHE

• Utilisation du conseil RESULT_CACHE dans les vues

Utilisation du conseil RESULT_CACHE

Lorsque le mode de mémoire cache des résultats est MANUAL, le conseil /*+ RESULT_CACHE */ indique à la base de données de mettre en mémoire cache les résultats d'un bloc d'interrogation et d'utiliser les résultats mis en mémoire cache dans les exécutions futures.

Pour plus d'informations, voir Utilisation du conseil RESULT_CACHE et Conseil RESULT_CACHE.

Utilisation du conseil NO_RESULT_CACHE

Le conseil /*+ NO_RESULT_CACHE */ indique à la base de données de ne pas mettre en cache les résultats dans les caches de résultats du serveur ou du client.

Pour plus d'informations, voir Utilisation du conseil NO_RESULT_CACHE et conseil RESULT_CACHE.

Utilisation du conseil RESULT_CACHE dans les vues

Le conseil RESULT_CACHE s'applique uniquement au bloc d'interrogation dans lequel le conseil est spécifié. Si le conseil n'est spécifié que dans une vue, seuls ces résultats sont mis en cache.

Pour plus d'informations, voir Utilisation du conseil RESULT_CACHE dans les vues et conseil RESULT_CACHE.

SYSDATE_AT_DBTIMEZONE Sélectionner un fuseau horaire pour SYSDATE sur la base de données IA autonome

SYSDATE_AT_DBTIMEZONE active le traitement spécial dans une session pour la valeur de date et d'heure retournée dans les appels à SYSDATE et SYSTIMESTAMP.

Selon la valeur de SYSDATE_AT_DBTIMEZONE, la date et l'heure sont basées sur le fuseau horaire par défaut de la base de données autonome avec intelligence artificielle, sur le temps universel coordonné (UTC) ou sur le fuseau horaire défini dans la base de données.

Fuseau horaire par défaut de la base de données de l'IA autonome

Le fuseau horaire par défaut de la base de données d'intelligence artificielle autonome est le temps universel coordonné (UTC). Par défaut, les appels à SYSDATE et SYSTIMESTAMP retournent la date et l'heure en UTC.

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

Cet exemple règle le fuseau horaire de la base de données à 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 États-Unis : America/New_York et l'heure est automatiquement ajustée aux commutateurs DST :

ALTER DATABASE SET TIME_ZONE='America/New_York';

Note

Note : Vous devez redémarrer l'instance de base de données IA autonome pour que la modification soit prise en compte.

Après avoir défini le fuseau horaire de la base de données, par défaut SYSDATE et SYSTIMESTAMP continuent de retourner la date et l'heure en UTC (SYSDATE_AT_DBTIMEZONE est FALSE par défaut). Si vous réglez SYSDATE_AT_DBTIMEZONE à TRUE dans une session, SYSDATE et SYSTIMESTAMP retournent le fuseau horaire de la base de données.

Voir Définition du fuseau horaire de la base de données dans Oracle Database 19c ou Oracle AI Database 26ai pour plus d'informations sur l'utilisation de la clause SET TIME_ZONE avec ALTER DATABASE.

Utilisation de SYSDATE_AT_DBTIMEZONE dans une session

Lorsque SYSDATE_AT_DBTIMEZONE a la valeur FALSE dans une session, les appels à SYSDATE et SYSTIMESTAMP retournent des valeurs basées sur le fuseau horaire par défaut de la base de données d'intelligence artificielle autonome, le temps universel coordonné (UTC).

Lorsque SYSDATE_AT_DBTIMEZONE a la valeur TRUE dans une session, les appels à SYSDATE ou SYSTIMESTAMP retournent la date et l'heure en fonction du fuseau horaire de la base de données.

Note

Note : Le réglage de SYSDATE_AT_DBTIMEZONE à TRUE n'a d'incidence que sur l'utilisation de SYSDATE et de SYSTIMESTAMP en tant qu'opérateurs dans l'application SQL (par exemple, dans les interrogations, les opérations LMD et CTAS). Lors de l'utilisation de ce paramètre, il est recommandé que le fuseau horaire client/session corresponde au fuseau horaire de la base de données.

Exemple

L'exemple suivant retourne des dates et des 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