Articles avec le tag ‘Base de données’

Introduction

Vous en avez jamais eu marre d’installer Oracle avec le lourd Universal Installer en Java ? Ou alors vous voulez installer Oracle sur votre serveur mais vous ne voulez pas utiliser X ? Le silent mode est donc fait pour vous.

Le mode d’installation silencieux utilise des fichiers de réponses (Response files dans son appellation original) qui permet de spécifier toutes les informations nécessaires.

Créer votre response file

Un response file est un fichier texte qui porte par défaut l’extension .rsp . Vous pouvez en créer un vous-même avec toutes les informations que vous voulez ou en générer un à la fin d’une installation graphique de Oracle.

Voici un exemple de response file que j’utilise pour une installation d’Oracle Database toute simple : Le télécharger . Vous pouvez vous en inspirez et changer les valeurs pour que ça colle à votre installation.

L’installation en silent mode

L’installation en silent mode est très simple. Après avoir dézippé les deux archives d’installation que vous pourrez télécharger en cliquant ici , vous vous positionnez dans le répertoire créé

unzip linux_11gR2_database_1of2.zip

unzip linux_11gR2_database_2of2.zip

cd database

Vous devez définir la variable DISTRIB avant de commencer

export DISTRIB=`pwd`

Puis vous lancer l’Universal Installer avec quelques options supplémentaires

./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -responseFile /chemin/vers/responsefile

L’installation durera une petite dizaine de minute.

Par la suite, il ne vous restera plus qu’à exécuter les classiques deux scripts en tant que root comme indiqué lors de l’installation. Facile non ?

Introduction

Votre instance peut vous poser de très nombreux problèmes. Parmi ceux-ci,il y en a que tous les débutants font les premiers jours en tant que DBA Oracle. Vous trouvez ici une liste non-exhaustive d’erreurs courantes et leurs solutions

Les erreurs

Error while loading shared libraries

Système : Oracle Enterprise Linux 5 / Oracle Database 11G

Cause : SELinux en mode Enforcing

Solution : Lancer la commande setenforce 0 . Vous pouvez vérifier l’état de SELinux avec la commande getenforce

SP2-0024 : Rien à modifier

Cause: Oracle n’arrive pas à trouver le .sql que vous spécifiez

Solution: Mettre le chemin complet dans la commande. Exemple : @/app/oracle/scripts/script.sql au lieu de @script.sql

ORA-32017: failure in updating SPFILE

Autre : ORA-16179: incremental changes to « log_archive_dest_2″ not allowed with SPFILE

Cause : Erreur fréquente. Lors de l’ALTER SYSTEM, vous avez oublié la clause LOCATION

Solution : ALTER SYSTEM SET log_archive_dest_2=’LOCATION=/app/oracle/oradata/arch’ scope=both

Introduction

Imaginez-vous dans cette situation : un programmeur vous appelle « Monsieur CAPITAINE, j’ai des problèmes avec un de mes traitements sur l’instance de Dèv, c’est très lent. Pouvez-vous me dire ce qui est lent ? ». Qu’allez-vous faire ? Vous allez lancer des traces.

C’est un des outils les plus pratiques du DBA Oracle. Une trace est un fichier plat qui recense tous les ordres SQL passés entre un laps de temps que vous définirez. Dans l’exemple plus haut, l’intervalle serait Début du traitement – Fin du traitement .

Un peu de technique

Voici une trace : Cliquez ici pour la voir

Première impression : « Gné ? » . Vous avez tout à fait raison. Les traces, en elle-même, sans être parsées par l’utilitaire tkprof sont globalement illisibles sauf pour les DBA très expérimentés qui se feront une joie de vous les déchiffrer.

Pour satisfaire votre curiosité, voici la même trace qu’au dessus mais à la différence d’être parsées par TKPROF : Cliquez ici pour la voir

Comment on trace ?

Il y a plusieurs façons de générer des traces. Vous pouvez les générer pour « vous » au niveau session, mais vous pouvez aussi les générer pour une session différente de la vôtre.

Tracer votre propre session

Tout d’abord au niveau de votre de votre session, la solution la plus simple est l’ALTER SESSION :

ALTER SESSION SET EVENTS ‘10046 trace name context forever,level 12′;

Vous n’avez plus qu’à exécuter votre traitement qui pose des soucis de performance. Une fois terminée, vous n’avez qu’à entrer cette commande :

ALTER SESSION SET EVENTS ‘10046 trace name context off’;

Tiens d’ailleurs en parlant de ça je pourrais les trouver où mes traces ?

Pour trouver l’emplacement de vos traces, il suffit d’ouvrir SQL*plus et de copier la commande

show parameter user_dump_dest

Le résultat est le dossier exact où se trouve toutes vos traces générées.

Tracer une session distante

Maintenant, pour tracer des sessions distantes, vous pouvez utiliser le package DBMS_SYSTEM comme ceci :

EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (sid=>[sid],serial#=>[serial],sql_trace=>TRUE);

Exécutez votre traitement puis pour stopper les traces :

EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (sid=>[sid],serial#=>[serial],sql_trace=>FALSE);

Attention : Votre utilisateur doit avoir le droit EXECUTE sur le package DBMS_SYSTEM pour faire ceci.

Je fais comment pour récupérer le SID et le SERIAL ?

Le SID (Session ID) et le Serial# sont des identifiants uniques attachés à chaque session sur votre base de données Oracle. Pour récupérer le SID de la session visée, exécutez cette requête :

SELECT SYS_CONTEXT('userenv','SID') SID FROM DUAL;

Ensuite, avec un utilisateur qui a les privilèges de SELECT sur la vue V$SESSION, vous pouvez retrouver le serial avec cette requête :

SELECT serial# FROM V$SESSION WHERE sid=[SID précédemment trouvé];

Conclusion

Maintenant que vous savez lancer des traces de votre session et d’une distante, il vous faut les rendre lisibles. Pour ceci, la page suivante vous apprendra à manipuler l’utilitaire tkprof.

Introduction

L’Optimizer est la partie la plus importante d’une instance Oracle. C’est lui qui choisit quelle chemin il va prendre pour prendre/modifier les données que vous lui ordonnez. Toutes les étapes qu’il va prendre s’appelle le plan d’exécution.

Exemple de plan d’exécution généré via SQL*Plus :

Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=143 Card=1438 Bytes=503300)
   1    0   TABLE ACCESS (FULL) OF 'PS_PERSONAL_DATA' (Cost=143 Card=1438 Bytes=503300)

Sur celui-ci par exemple, on observe que l’Optimizer a choisi de scanner complètement la table PS_PERSONAL_DATA , qu’il a parcouru 1438 lignes soit 503,300 kiloBytes de données et que la requête a un coût estimé à 143.

Je paris que vous avez un certain nombre de questions qui vous viennent à la tête tout de suite :

Comment il choisit son « chemin » ce fameux Optimizer ?

Alors, il choisit en fonction de ce qu’on appelle « le coût ». Le coût est un indice qu’Oracle donne à certaines étapes du plan d’exécution. Plus le coût est grand, plus l’action est consommatrice de ressources/temps (dans l’idéal d’Oracle parce que ça se passe pas tout le temps comme ça). Par exemple, un balayage complet d’une table aura un coût plus élevé qu’une sélection partielle de lignes.

Comment elle calcule le coût notre base de données ?

Ca, c’est le jardin secret d’Oracle. C’est un algorithme que seules quelques personnes connaissent dans le monde entier. Pour avoir une migration d’Oracle 8i vers 10G,  le fait que ce soit secret est la principale cause des déboires des Administrateurs de bases de données lors des changements de version d’Oracle. On ne sait jamais vraiment si les performances seront très dégradées/améliorées lorsqu’on migre une application sur une nouvelle version d’Oracle.

Peut-on influencer les choix de l’Optimizer ?

Bien sûr qu’on peut ! C’est d’ailleurs le sujet de cet article. Influencer l’Optimizer est une des principales pistes de Tuning que vous devez explorer sur votre base de données.

Y a-t-il eu des changements importants dans l’Optimizer ces dernières versions ?

Beaucoup de changements. Depuis la version 10G, Oracle a « abandonné » (plutôt déprécié) les modes Rule et Choose et a tout misé sur le mode Cost-based. Vous pouvez choisir entre le mode ALL_ROWS qui privilégie le débit et le mode FIRST_ROWS(n) qui privilégie le temps pour les « n » premiers résultats. Bien sûr, vous pouvez toujours choisir le mode RULE mais l’Optimizer ne tiendra pas compte de ce mode et passera en mode Cost-Based si il juge que c’est mieux pour certaines requêtes.

Finis les questions ? On passe à la liste des paramètres ! Si vous avez d’autres questions, postez les en commentaire. J’ajouterai les réponses à la liste des questions ci-dessus.

Je ne traiterai que des version 10G et 8i dans cette page car je n’ai pas beaucoup travaillé sur d’autres versions (9i et 11G). De plus, je n’évoque que des paramètres conseillés pour l’OLTP (environnement transactionnel) car je n’ai pas d’expériences en DatawareHouse.

OPTIMIZER_MODE

C’est le mode de fonctionnement de l’Optimizer. 4 valeurs sont possibles : CHOOSE, RULE, ALL_ROWS, FIRST_ROWS. Le premier paramètre laisse l’Optimizer choisir entre le mode RULE et COST BASED. Le deuxième paramètre force le mode RULE . Les deux derniers paramètres forcent le mode COST BASED mais avec deux approches différentes :

• ALL_ROWS permet de privilégier le débit global

• FIRST_ROWS permet de privilégier le débit des premiers résultats sortis par une requête

Note : Le mode Rule est devenu obsolète en 10G

Rang de valeurs : RULE, ALL_ROWS, FIRST_ROWS, CHOOSE

Valeur par défaut : ALL_ROWS en 10G, CHOOSE en 8i

Valeur Recommandée pour l’OLTP : CHOOSE

OPTIMIZER_DYNAMIC_SAMPLING

Contrôle le niveau de dynamic sampling, qui permet de calculer les statistiques automatiquement. Plus la valeur est grande, plus le « Dynamic Sampling » est agressif. A 0, le Dynamic Sampling est désactivé.

Note : Existe seulement en 10G

Rang de valeur : 0-10

Valeur par défaut : 2

Valeur recommandée pour l’OLTP : Ca dépend de la quantité de donnée mise à jour/insérées durant une journée. Si vous modifiez/ajoutez plus de 10% de vos données actuelles dans vos tables, Oracle conseille de mettre une valeur grande. Sinon, une valeur de 2 suffira.

OPTIMIZER_INDEX_CACHING

Détermine en pourcentage de nombre de blocs d’index auxquels l’Optimizer peut s’attendre dans le cache.

Rang de valeur : 0 – 100

Valeur par défaut : 0

Valeur recommandée pour l’OLTP : 0

OPTIMIZER_SECURE_VIEW_MERGING

Existe seulement en 10G

Permet d’autoriser ou pas l’Optimizer à vérifier si la vue viole des règles de sécurité.

Rang de valeur : True, False

Valeur par défaut : True

Valeur recommandée pour l’OLTP : False

OPTIMIZER_INDEX_COST_ADJ

Ajuste le coût de parcours d’un index contre un Full Scan. Plus la valeur est petite, plus l’optimiseur est enclin à choisir un index dans le plan d’exécution.

Rang de valeur : 1 – 10 000

Valeur par défaut : 100

Valeur recommandée pour l’OLTP : 100

OPTIMIZER_FEATURES_ENABLE

Permet de forcer l’exécution du noyau comme il était dans une certaine version d’Oracle. Par exemple, si ce paramètre vaut 8.0.6, l’optimizer exécutera la requête comme sur une instance Oracle 8.0.6.

Rang de valeur : Tous les numéros de versions Oracle

Valeur par défaut : Numéro de version d’Oracle

Valeur recommandée pour l’OLTP : Valeur par défaut

OPTIMIZER_PERCENT_PARALLEL

Obsolète en 10G.

Plus la valeur est grande, plus l’Optimizer sera enclin à exécuter en parallèle des requêtes. Ce qui permet d’améliorer significativement les gros traitements, surtout les FULL TABLE SCAN. La valeur de 100 force l’Optimizer à exécuter constamment les requêtes en parallèles. Ce paramètre est surtout utile pour le datawarehousing. Il est plutôt conseillé de passer par des indexs en OLTP.

Rang de valeur : 0 – 100

Valeur par défaut : 0

Valeur recommandée pour l’OLTP : 100 / Nombre d’utilisateurs simultanés

OPTIMIZER_MAX_PERMUTATIONS

Seulement en 8i. Paramètre caché en 10G.

Restreint le nombre de permutations de tables que l’Optimizer va prendre en compte dans les requêtes avec des jointures.

Rang de valeur : 4 – 80 000

Valeur par défaut : 80 000

Valeur recommandée pour l’OLTP : < 1000