Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?
Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ? - SQL/NoSQL - Programmation
Marsh Posté le 25-01-2006 à 20:36:47
as-tu des traces pertinentes dans le répertoire des traces ? (généralement <ORACLE_HOME>\database\SID\trace de mémoire)
Quelle est l'appli qui est à la base de ton intranet ? Si c'est PHP, ca fait appel à OCI, qui je crois utilise des cursors pour gérer sa partie privée
Regarde ton paramètre OPEN_CURSORS
Code :
|
Regarde la taille de ta share pool
Mais ca se trouve on cherche pas là où il faudrait, vaut mieux analyser les logs plutôt que d'augmenter à tout hasard des paramètres qui pourrait écrouler la machine
Marsh Posté le 25-01-2006 à 22:50:11
Salut,
Merci pour ta réponse !
Tout d'abors, je viens de passer 3 heures à revoir le code de l'appli intranet, afin de vérifier que je ferme correctement toutes les connections.
En effet, au départ la destruction des objets merdait, et j'avais déjà tout remodifié.
J'avais donc rechangé, histoire de bien tout fermer comme il faut.
Mais là, en ajoutant des logs sur mon objet de connection, je me suis apperçu que les objets mettaient trois plombes à se détruire... Et du coup une connection ouverte restait ouverte 300 secondes, même si elle n'était plus du tout utilisée.
Après re-modifications, je force bien la fermeture de chaque connection "à la main".
Seulement, la plupart du temps j'ai des erreurs "NullReferenceException", ce qui indique que mon ancien code marchait... parfois ! Un coup de try de goret, et maintenant ça doit être bon. J'espère juste que ça ferme pour de bon... Pas moyen de monitorer ADO malheureusement (ou alors je ne connais pas le moyen de le faire, et je suis preneur d'une suggestion ! 
)
Sinon, le langage utilisé pour l'intranet, c'est C#/.NET
J'avais déjà posté ma détresse sur le sujet des connexions la semaine dernière.
Pour ce qui est des paramètres :
|
Hmmm... Faut être SYSTEM pour les voir ? Si c'est le cas, on est mal barrés, j'ai pas ce login, et la société qui a installé la base étant coulée depuis, je vois pas trop comment récupérer le mot de passes 
Arf !
|
300 ça me semble pas trop mal déjà... A moins que les curseurs restent ouverts pendant qu'on se balade dans le jeu de résultat ?
Sinon, pour les logs, y'a rien dans le répertoire que tu indiques... Enfin... Il n'existe pas 
Le "initSID.ora :
|
A noter que "RULES" est déprecated, mais l'ERP a été écrit à l'origine pour obtenir de meilleurs perfs avec ce mode. Dans la doc technique, il est stipulé que sur les 9i et 10g ils préconisent maintenant STATISTICS, mais mettent en garde contre l'importance du tunning afin de ne pas avoir des perfs catastrophiques, et préconisent donc toujours RULES pour les sociétés qui n'ont pas un DBA sous la main (c'est le cas chez ce client)
Voici le "SQLNet.log" :
|
A noter que ces erreurs sont quelques instants après le reboot, à priori des requêtes en spool qui se sont faites gicler du moteur qui s'arrêtait (3 minutes avant le reboot du serveur, sâchant qu'il était planté depuis au moins 30 minutes)
-- Edit : En fait, en regardant bien, cette erreur se produit quelques instants après chaque reboot. Ca doit correspondre au message d'erreur qu'on a au moment du chargement de l'ERP : il essaie de démarrer la base, qui est déjà démarrée...
M'enfin c'est pas bien grave, puisque la base est déjà démarrée
A noter que dans l'EventLog de Windows, à part des tas d'alerts "PerfLog" indiquant des délais exprirés dans les prises de mesures des perfs système, y'a aucun truc étrange avant le reboot. Ces messages sont explicables par la charge CPU de 100% pendant 30 minutes.
Le "SIDALRT.log" est normal :
|
=> Les rotations de logs ne sont pas plus rapides avant qu'après reboot.
Et rien de particulier dans le listner.log
|
Message édité par Arjuna le 25-01-2006 à 22:56:50
Marsh Posté le 25-01-2006 à 23:43:38
au vu de ton init, les traces sont dans ton ORACLE_HOME\trace
ton share pool n'est pas énorme, mais ptet que l'ERP n'a pas besoin de plus
pour ce qui est du plan d'exécution, effectivement le mieux est de mettre un mode CHOOSE plutôt que RULES, et récolter les stats de manière périodique (package dbms_stats je crois)
pas besoin d'un DBA, juste besoin d'un mec qui le met en place via l'ordonnaceneur de la boîte ou via le plannificateur de tâche windows, ou via l'ordonnanceur interne d'oracle (package dbms_jobs je crois)
Mais bon si l'éditeur de l'ERP dit qu'il ne faut pas, mieux ne vaut pas s'amuser à changer des trucs en prod. sans en mesurer les réelles impacts, car en activant les stats il peut arriver que l'on perd en perf.
Mais cela ne résoudra pas ton problème
au vu du listener.log il n'y pas tant de connexions parallèles que ca, mais j'avoue que voir un Oracle planter sans raisons apparentes, c'est assez rare, même en ayant des connexions mal déconnectées, normalement Oracle les déconnecte proprement
j'aime pas trop l'option "compatible = 8.1.5.0.0" mais bon on n'y peut rien
tu n'as plus qu'à espérer un vrai DBA expérimenté traîne ici =)
As-tu regarder les alertes systèmes du serveur ? Parfois des choses intéressantes peuvent apparaîtres dans l'event viewer de windows
bon courage
Marsh Posté le 25-01-2006 à 23:54:53
Justement, y'a rien dans l'eventlog de Windows. Juste des alertes "perflib".
Ceci dit, on n'est pas sûrs que c'est Oracle qui part en live... En effet, l'ERP et Oracle sont sur le même serveur, et quand la charge était de 100%, aucun process ne dépassait 5% d'utilisation CPU, du coup c'est un service ou un process "caché" qui est parti en couille, et impossible de savoir lequel
Sujets relatifs:
- Exporter les enregistrements d'une base au oracle au format XML
- [FTP] Serveur FTP pour site Web
- RMI -> obligé d'avoir la même version de JVM sur clients et serveur ?
- aide sur SQL serveur
- Lancer un exe sur le serveur
- [Resolu] [PHP-MySQL] Serveur MySQL derrière un proxy
- [Résolu][Oracle] Mutating table sur un update
- [Oracle] Désactiver un trigger pendant un UPDATE
- tomcat jsp et connection oracle
- Oracle : erreur ORA-00947 en insertion
Marsh Posté le 25-01-2006 à 15:49:23
Salut,
j'ai pas trop cherché à creuser sur le coup, puisque c'était la première fois que ça plantait. J'ai donc arrêté proprement ce qui tournait encore, rebooté le serveur, et tout est reparti normalement.
Semaine dernière : un module de l'ERP qui tourne chez un de nos client part en sucette. Ayant 40 utilisateurs en train de boire des cafés à côté de la salle serveur tout en déplorant l'incompétence notable du service informatique (:sweat
Lundi matin : badaboum. Même scénario. Sauf que là moi j'étais pas là, du coup c'est la cliente qui a rebooté le serveur, et j'ai pas vraiment eu l'occasion de creuser cette fois là non plus.
Ce matin : A ma demande, un technicien réseau/système vient auditer le réseau pour voir si on n'a pas des problème (l'erreur concernait la création d'un "serveur rpc", j'en avais déduit à la va vite une instabilité réseau). Coup de pot (enfin, façon ce parler) bananage à nouveau, mais cette fois un bon gros bananage de chez bananage. CPU bloqué à 100% pendant plus de 30 minutes, Oracle explosé à coup de process // dans tous les sens, et interface de contrôle de l'ERP plantée et impossible à redémarrer. On a attendu que ça se calme, et on a rebooté le serveur.
Depuis ça marche, mais on s'attends à ce que ça repète d'ici peu.
Après un appel à un collègue expert de l'ERP en question, il m'indique que les erreurs qu'on a obtenu sont généralement liées à des problèmes de manque de ressources. Si le nombre d'utilisateurs n'a pas changé, on a effectivement un changement notable dans la charge de la base Oracle, puisque j'ai écrit un intranet qui consulte la base Oracle en // de l'ERP.
Ayant écrit la chose en .NET, avec des évènements (databound sur des datagrid), je pense que le site génère joyeusement des requêtes en // à chaque page. Et notamment sur une page, je dois éxécuter environ 100 requêtes... Alors à la queue leue leue, pas de souci, ce sont des requêtes simples et rapides. Mais en // ça peut aisément être une source possible de problèmes dans Oracle.
Le collègue en question m'a indiqué que sur la version Unix de l'ERP (là on est sous Windows), il avait à plusieurs reprises résolu ce problème en augmentant le nombre de sémaphores du kernel Unix, et en augmentant le nombre de processes Oracles.
Seulement, là on est sous Windows, et si je ne m'abuse, y'a pas de sémaphores. Doit y avoir un autre truc par contre. Genre me semble-t-il une clé dans la base de registres qui permet de changer le nombre de process // et de threads.
Et pour la config d'Oracle, il n'a pas su me dire dans quel fichier c'était, ni encore moins quelle valeur mettre. Et vu que je suis pas plus DBA que lui, je sais pas non plus.
Donc la question est :
Où trouve-je les paramètres en question ? (Windows 2000 / Oracle 8.1.7)
Voyez-vous d'autres explications ?