Bonjour,
 
J'ai un client utilisant 10 postes et 1 serveur SBS 2008.
4 clients utilisent la messagerie Exchange (pas de SharePoint pour le moment).
 
Le serveur a 12 Go de RAM et un RAID 5 de disques SAS 15tr/min : bref ça marche très bien.
Le serveur a une moyenne CPU en dessous de 10 % et 6 Go de RAM utilisé : de ce côté là ça roule.
Antivirus NOD32 4.2 Business Edition.
 
Sur le serveur une base de données Oracle est installée, je ne suis pas spécialiste Oracle alors je vous donne les éléments que j'ai relevé :
 
- Version 11GR2
 
La raison de mon post :
 
- Les processus Oracle tournent en 32 bits : normal ? j'aurai imaginé comme sous SQL Server la présence d'une version 64 bits.
 
Les postes clients utilisent les clients Oracle 11GR2 32 bits : là normal on est sous XP 32 bits
Les clients se pleignent de ralentissement sous l'appli utilisant Oracle : leur prestataire bien sur accuse le serveur mais ne semble pas très au point sur le sujet.
 
De mon côté (administration du réseau) tout semble fonctionner correctement (réseau Gbits sur switch Procurve : là aussi ça ne coince pas).
 
 
Si vous avez des idées ou protocoles de tests à me soumettre pour la résolution des problèmes sous Oracle ... ?

ca rame continuellement ou a certains moments ?  
faut regarder coté memoire allouée a l'instance ...

ce n'est pas forcément le paramétrage de la SGA et PGA, cela peut être une appli mal faite (indexes manquants...), une récolte des statistiques pas faite ou pas à jour, un paramétrage de l'instance mal fait 'un mode d'optimisateur en ALL_ROWS alors qu'il faudrait un CHOOSE), etc.
 
Pour moi il faudrait faire comme suit :
1) déterminer les responsabilités
Si la solution (= appli + bdd + volumétrie des données) est du ressort du prestataire, alors il se débrouille.
Botter en touche en accusant le serveur, c'est possible avec des preuves à l'appui : facile de dire que c'est le serveur si côté système tu vois qu'il ne fais rien
2) Trouver le goulot d'étranglement : si ce n'est pas le CPU, ni la RAM, ni les I/O disques, ni le réseau, tout laisse à penser que c'est Oracle, sauf que Oracle c'est un OS dans un OS...
3) Si c'est côté BDD, alors trouver le goulot d'étranglement dans la BDD
Les causes peuvent être multiples : paramétrage de l'instance, design de la structure de la base, volumétrie des données, requêtes malm gaulées...
 
Si comme tu dis tu n'as pas de connaissances Oracle, ca risque d'être compliqué pour avancer... Peux-tu au moins te connecter à la base en tant que SYSTEM ?
Le mieux est de récolter des métriques factuelles et de les balancer à la gueule du presta
Par exemple tu pourrais dire "quand je cliques là pour avoir tel rapport, ca rame alors que le CPU, Mem, Disque, Réseau sont utilisé à n%"
 
Mon pif me dit que ce sont des requêtes balancées sur une base mal conçue, mais pour le prouver il faut regarder les requêtes lancées sur la base et regarder le plan d'exécution
 
Sinon un quickwin : vérifier que les statistiques sont à jour et que tu es en mode CHOOSE dans l'optimisateur Oracle
Il faut pouvoir se connecter en tant que SYSTEM sur la base, et faire un coup de :

SHOW parameters optimizer_mode

 
ensuite que tes stats sont à jour :

ALTER session SET NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS';
SELECT table_name, owner, last_analyzed FROM dba_tables;

Tu obtiendras la date de la dernière stats pour chaque table

Bonsoir et merci pour vos réponses.
 
D'après le client en gros tout se passe bien et d'un coup pour afficher une fenêtre (genre la liste des commandes) ça prend 30 secondes alors que d'habitude il en faut 2. Le presta dit que c'est la connexion à la base qui est longue à s'établire.
 
Du côté serveur je ne vois rien de spéciale.
Le prestataire m'indique ce soir qu'il utilise une version Embedded d'Oracle : 32 bits (mon OS est un 64 bits : ça peut poser des problèmes ?).
J'ai exclu les répertoires d'Oracle de mon antivirus : on ne sait jamais si c'est lui qui ralenti l'accès aux données.
 
Couak, on est clairement dans le cas n°1 ...
J'ai de bonnes connaissances en SQL Server mais Oracle .... nada.
Je vais regardé si j'ai accès à un outil de gestion de la bdd afin de voir la tronche des tables, si il y a des indexs, etc. (ça serait étonnant d'avoir les accès mais bon).
 
Sinon le prestataire me demande de désactiver le parefeu du serveur pendant 48h pour voir (de mon point de vu ça me fait rire).

Si en 11g c'est comme en 10g, c-a-d qu'avec l'assistant de création d'une base tu as DB Console d'installé, tu peux essayer de te connecter à l'application par http://tonserveur:5500/em mais il te faudra de tte manière login/password
Avec dbconsole tu peux avoir pas mal de rapports simples et un état des lieux de la base sans rien y connaître (à la manière de Enterprise Manager de SQL Server)
 
Comme la plupart des applications il y a des portes dérobées si tu es admin de la machine : tu ajoutes ton user OS dans le groupe local ORA_DBA et tu te connectes en ligne de commande sans mot de passe :

avec SID le SID de ta base
 
Une fois connecté à la base, le plus simple est de te créer un nouvel utilisateur avec :

 
Ensuite je te conseille de prendre SQL Developer (gratuit) sur le site d'Oracle et de te connecter pour regarder la base

Je viens d'y repenser : une requête qui va vite et qui tout d'un coup rame, j'ai déjà connu et la cause était toute bête
 
La requête était très souvent utilisée, donc les données était encore dans le cache. Au bout d'une dizaine de minutes sans avoir utiliser la requête, les données sortaient du cache et on se retrouvait avec un FTS (full table scan : balayage complet de la table) sur le disque (donc forcément moins rapide)
La résolution était elle aussi très simple : on a trappé la requête incriminée avec l'audit d'oracle, pour y ajouter un index calculé, et on était passé d'une dizaine de secondes d'exécution à moins d'1 seconde
 
Moralité : conception de la base mal faite

Merci pour toutes ces infos ^^
Je vais regarder tout ça d'ici mercredi afin d'essayer de localiser la source du problème.
 
Je te tiens au courant bien sur !

Bonsoir,
 
Les résultats ont mis du temps à tomber.
L'exclusion d'Oracle de l'analyse NOD32 (V4.2) semble avoir très largement amélioré les choses, pour le reste après quelques demandes au dev de l'appli plus de nouvelle ... et aps de réponse (comme dit plus haut sur que l'appli demande de l'optimisation.
 
A noter quand même que c'est la deuxième fois ce mois que je croise des pbs Oracle avec NOD32.

de manière général il faut exclure de l'antivirus les datafiles des bases de données, que ce soit Oracle ou autre
 
bon finalement le problème était tout bête

 
En parti oui mais mon insistance avec tes questions on du faire un peu peur au dev