Performance Oracle & UNIX

Je sais que le sujet est un peu limite pour ce forum mais je pense que tout DBA a du a un moment ou un autre se poser des questions sur l'OS qu'il utilise.

Avez vous une bonne documentation pour interpreter les resulats des commande top, sar, vmstat. J'ai les man pages mais elle se contente de definir les colonnes sans dire quelle sont les plages de valeurs acceptables.

Plus precisement je me pose une question sur le SWAP

sar -q

11:34:36 runq-sz %runocc swpq-sz %swpocc
11:34:41 1.5 50 0.0 0
.....
13:45:21 1.4 40 0.0 0
13:45:26 1.2 25 2.5 80

Average 1.4 32 5.1 11

Avec regulièrement des %swpocc autour de 100 et une moyenne de 11. J'imagine que cela pose un problème de swapper mais est ce que 11 de moyenne c'est un petit swap supportable ou djà une valeur innaceptable sur un systeme transactioonnel en production.

Merci

Les avis peuvent être très partagés sur la question. Certains disent que si votre système n'utilise pas 100% de CPU vous perdez de l'argent puisque ce qui n'est pas utilisé ne peut pas l'être .. D'autres diront au-delà de X %,
c'est mauvais car on n'a plus de marge au cas où ...

A mon avis, un bon critère consiste à mesurer la satisfaction des utilisateurs: les temps de réponse sont-ils bons pour les utilisateurs ? Si oui, les valeurs de top, sar et vmstat sont secondaires. Si non, elles font partie des éléments à analyser comme ce qui se passe sur le poste client (pour du client/serveur), ce qui se passe dans le serveur d'applications (pour du web), ce qui se passe sur le réseau et bien sûr dans la base de données.

Pour ma part, sans être aussi catégorique que pifor, je commencerais par Oracle : est-ce que tous les "indicateurs" statspack sont Ok ? est-ce que vous y voyez des problèmes qui pourraient laisser penser à une faiblesse hardware plutôt que relevant du tuning de la base.

On commence par tuner la base, et ensuite, quand la base ronronne comme une ferrari, on s'interroge sur le dimensionnement du serveur si les problèmes de perf. persistent.

sinon
1. Le budget matériel serait exponentiel
2. Le métier de DBA n'en serait pas un.

Merci a vous deux pour vos réponses.

Si je m'interesse a au resultat de sar, c'est que les utilisateurs ne sont pas satisfait.

J'ai aussi regardé statspack qui pourrait eventuellement me dire que j'ai pas assez de mémoire dans le Data Buffer mais avant d'en ajouter j'essayer de regarder si j'en ai. Et la je tombe sur sar qui dit apparement que je swap. D'ou mon autre thread sur MTS pour essayer de voir si je ne peux pas mieux utiliser la memoire que j'ai.

Voila vous savez tout... Si vous avez des commentaires aussi bien sur la démarche que sur les conclusions ils sont les bienvenues

Un mauvais hit ratio ne veut pas forcément dire qu'il faut rajouter de la mémoire !!!

Est-ce que le(s) block(s) size sont optimisé(s) ? est-ce que les db_xk_cache_size sont optimisés ? (globalement, la quantité peut rester inchangée en jouant entre les différents pool) ?
et surtout : est-ce que les requêtes sont optimisés ? est-ce qu'il n'y a pas que des full scan ? ...

Ce n'est pas le hit ratio qui m'a alerté mais un "free buffer waits" dans le top event qui peut etre du entre autre a un pb de taille du buffer cache.

J'ai bien sur commencé par les requettes et j'ai quelques Full Scan que j'ai réglé. J'attends de voir ce que cela donner sur la base de production avant de tirer des conclusions. Mais j'essaye de préparer la prochaine étape

Merci