 |
|
|
|
|
|
|
|
| |
| |
| |
Technique |
|
Domaines |
|
Divers | |
Contact | |
CURSOR_SPACE_FOR_TIME
Mettre ce paramètre à TRUE revient à scotcher les instructions SQL dans la partie commune du contexte et à ne plus libérer la zone privée du contexte tant que les curseurs du process client restent ouverts. Dans ce cas, vous devez assigner un SHARED POOL assez grand (voir le SHARED_POOL_SIZE) pour pouvoir contenir toutes les instructions SQL impliquées. Si le SHARED POOL est insuffisant, des instructions SQL risquent de ne pas pouvoir être analysées (étape parse). Un message d’erreur est également issu si la zone SQL privée est insuffisante. Si ce paramètre est mis à FALSE, un contrôle doit être fait pour vérifier la présence de la requête SQL dans le library cache.
MAXDATAFILES
C'est le nombre maximal de fichier de données que la base pourra contenir. Il conditionne de façon irréversible, la taille du fichier de contrôle, car elle permet à ORACLE de définir le nombre d'entrées à réserver pour enregistrer la définition des fichiers Database. Sa valeur par défaut est celle du paramètre de démarrage DB_FILES (32 par défaut, le maximum dépend de l'OS) définie au STARTUP de l'instance avant la création de la base. La modification du paramètre DB_FILES du fichier INIT.ORA permet de limiter le nombre de fichiers Database qu'il sera possible de gérer pour l'instance, mais ne permet pas de dépasser MAXDATAFILES.
MAXLOGFILE
C'est le nombre maximum de GROUPES de fichiers de Redo Log. Il conditionne de façon irréversible, la taille du fichier de contrôle, car elle permet à ORACLE de définir le nombre d'entrées à réserver. Le paramètre LOG_FILES du fichier INIT.ORA permet de limiter le nombre de fichiers de Redo Log pour l'instance en cours, mais ne permet pas de dépasser MAXLOGFILES
MAXLOGMEMBERS
Il conditionne de façon irréversible, la taille du fichier de contrôle, car elle permet à ORACLE de définir le nombre d'entrées à y réserver pour enregistrer la définition des n maximum membres par groupe de fichiers Redo Log. La modification du paramètre LOG_FILES permet de limiter le nombre de fichiers Redo Log qu'il sera possible de gérer pour l'instance, mais ne permet pas de dépasser MAXLOGFILES
MAXLOGHISTORY
N'est utilisable qu'avec l'option Parallel Server d'ORACLE. Il indique le nombre maximum irréversible de fichiers Redo Log archivés pour une restauration physique automatique d'ORACLE avec l'option Parallel Server. Le minimum est 0, le maximum est un multiple de MAXINSTANCES et dépend de l'O.S.
MAXINSTANCES
Permet de limiter le nombre d'instances pouvant être démarrées sur cette base de données
CHECKPOINT_PROCESS (obsolète en V8)
Paramètre de init.ora, il déclenche en V7 le process background CKPT. Dans cette architecture, les checkpoints peuvent avoir un impact négative sur les performances, DBWR écrit dans les fichiers de la base et LGWR met à jour les fichiers redo log et les fichiers de contrôle, ainsi que les entêtes des fichiers. CKPT prend en charge une partie de ces activités, laissant LGWR écrire uniquement les buffers du redo log buffer vers les fichiers redo. A partir de V8, ce paramètre devient inutile, CKPT devient un processus obligatoire.
O7_DICTIONARY_ACCESSIBILITY
Le paramètre O7_DICTIONARY_ACCESSIBILITY contrôle les restrictions des privilèges SYSTEME. Si ce paramètre est TRUE, les objets dans le schéma de SYS sont accessibles. (C’est le comportement par défaut de Oracle 7). Si ce paramètre est FALSE, les privilèges SYSTEME qui permettent l’accès aux objets dans d’autres schémas ne permettent pas l’accès aux objets du catalogue (qui appartiennent à SYS).
Par conséquent, si O7_DICTIONARY_ACCESSIBILITY=FALSE, alors le privilège SELECT ANY TABLE permettra l’accès aux tables et vues dans tous les schémas SAUF SYS. EXECUTE ANY PROCEDURE permettra l’exécution de toute procédure ou fonction à l’exception de celles de SYS.
Dans le cas ou les utilisateurs doivent pouvoir accéder au schéma SYS, ils auront besoin de l’octroi des privilèges objet spécifiques. Un set de privilèges nécessaires dans ce cas est fédéré dans les rôles SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE et DELETE_CATALOG_ROLE
ALWAYS_ANTI_JOIN
Ce paramètre est très important pour les requêtes SQL qui utilisent l’opérateur not in. Cet opérateur est évalué par défaut comme une sous requête corrélée (séquentiellement) si ALWAYS_ANTY_JOIN = NESTED_LOOPS. En le mettant à HASH, le moteur Oracle utilisera le parallélisme du hash join pour effectuer les anti-joins. Dans ce dernier cas, le hint HASH_AJ déterminera l’utilisation parallélisée de la requête :
SQL> select * from fils
2 where prenom like 'Stef%'
3 and pereid is not null
4 and pereid not in
5 (select /*+ hash_aj */ id
6 from peres
7 where id is not null
8 and prenom = 'Radu');
PEREID ID NOM PRENOM
---------- ---------- ---------- ----------
1 1 Caulea Stefan
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=53)
1 0 HASH JOIN (ANTI) (Cost=3 Card=1 Bytes=53)
2 1 TABLE ACCESS (FULL) OF 'FILS' (Cost=1 Card=1 Bytes=40)
3 1 VIEW OF 'VW_NSO_1' (Cost=1 Card=1 Bytes=13)
4 3 TABLE ACCESS (FULL) OF 'PERES' (Cost=1 Card=1 Bytes=20)
L’opération précédente sera effectué avec un hash anti-join, du fait de la présence du hint HASH_AJ. En mettant ce paramètre à HASH dans init.ora, Oracle utilisera systématiquement le HASH anti-join, qui est globalement plus bénéfique que les nested loops.
clé primaire (primary key)
Ensemble de colonnes qui impose l'unicité des lignes. La combinaison des valeurs de colonnes dans une primary key est unique pour l’ensemble des lignes de la table. La clé primaire devrait être les moyen le plus fréquemment employé pour accéder aux lignes.
service name
Il s’agit d’un ensemble des représentations logiques d’une ou plusieurs instances de la même base de données, cible des connexions clients. Une base de données peut être représentée par multiple services. Il est constitué du nom de la base de données et le nom du domaine. Il est identique au nom global de la base (GLOBAL_NAME). Il fait partie de la zone connect data du descripteur de connexion sous le nom SERVICE_NAME.
connect data
Présente dans la zone connect descriptor, elle définit la base de données de destination de la connexion.
IDBA.WORKGROUP: (description=(address= (protocol=tcp)(host=SCLAVOS)(port=1521)
(connect_data=(service_name=idba.workgroup)))
connect descriptor
Il s’agit de la description de la destination pour une connexion (réseau. Il est constitué d’un service de destination et le routage réseau nécessaire pour l’y atteindre. En Oracle < 8.1, le service de destination est associé au SID, pour les versions ultérieures il est associé au nom du service (service name) Les représentations ‘pauvres’ du routage doivent indiquer au minimum le chemin vers le listener désiré.
connect identifier
Il s’agit d’une information qui indique la cible de connexion à une instance. Les utilisateurs l’emploie sous la forme connect username/password@connect_identifier. Il est d’habitude répertorié dans tnsnames.ora.
global database name
Le nom d’une base de données qui la différencie de toute autre base de données. Il est sous la forme idba.club-internet.fr. idba est le nom de la base. Club-internet.fr spécifie le nom du domaine ou cette base est présente. D’habitude, le nom du domaine de la base est identique au nom du domaine réseau. Ce nom est repris par service_names (inscrit dans init.ora).
connect-time failover
c’est l’algorithme de routage d’une connexion cliente vers un autre listener si le listener ‘courant’ ne répond plus. Cet algorithme est permis par l’enregistrement du service (service registration) (8i>)
service registration
caractéristique de PMON qui fait connaître l’instance auprès du listener. Cette possibilité rend pas obligatoire les informations dans listener.ora. Il consiste en une liste d’informations résultant en la rédirection des connexions vers le serveur approprié :
-
Service names pour chaque instance de la base
Les noms d’instances de la base
Service handlers (dispatchers and dedicated servers) disponibles pour chaque instance
consistent changes
Cette statistique, trouvée en V$SYSSTAT, indique le nombre d’avatars d’un bloc (un avatar du bloc est nécessairement crée pour chaque demande de lecture consistante). Cet image ‘avant’ du bloc est recrée à partir des rollback segments. Beaucoup de transactions concurrentes peuvent déterminer un grand nombre de versions cohérentes de lecture pour les blocs.
consistent gets
Cette statistique, trouvée en V$SYSSTAT, indique le nombre de demandes de lecture consistante de ce bloc.
db block changes
Cette statistique, trouvée en V$SYSSTAT, intimement liée à consistent changes indique le nombre de modifications effectuées sur les blocs présents dans la SGA lors d’un update ou d’un delete. Ces modifications donnent lieu aux écritures dans les redo logs et deviendront permanentes si les transactions concernées seront validées. Cette statistique donne une image globale de l’activité de l’instance concernant le travail de la base. Son suivi permet d’estimer la charge de la base.
Log buffer space
Cette statistique, trouvée en V$SYSSTAT, représente l’intervalle global d’attente dans le buffer redo, indication que les buffers sont remplis plus rapidement que LGWR ne les écrive. Ceci peut également être déterminé par les contention disque. Si cette statistique est balaise, agrandir les buffers de LGWR ou vérifier les contentions des disque ou ils résident.
Log file space/switch
Cette statistique, trouvée en V$SYSSTAT, représente le temps d’attente lors de l’écriture des buffers redo sur disque. Si grand, agrandir les log buffers.
| Copyright © 1998-2002 Radu Caulea, TAFORA | MAJ 06/11/2006 |  |
| Commentaires et suggestions radu[CHEZ]tafora.fr | ||