|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
Bonjour,
Voici le contexte : serveur linux redhat ES version 3 avec Oracle 10.2. J'ai un souci depuis 2 jours avec ma base de données, en fait, elle s'arrête d'elle-même sans intervention extérieure. Les logs ORACLE font apparaître un problème de dimensionnement de sga_max_size avec une erreur du type : Specified value of sga_max_size is too small, bumping to 859832320 Je l'ai donc redimensionné à 1024M (auparavant il était à 200M). Suite à cette action, la situation s'est stabilisée puisque pour l'instant la base ne s'arrête plus. Cependant, il subsiste une erreur oracle dans le log : Thread 1 cannot allocate new log, sequence 62471 Checkpoint not complete Current log# 2 seq# 62470 mem# 0: /data/ora/u01/redo/redo_2a.dbf Current log# 2 seq# 62470 mem# 1: /data/ora/u02/redo/redo_2b.dbf Est-ce que cette erreur sur les redos logs peut provoquer un arrêt de la base ? De plus, j'aimerais connaître quels sont les paramètres modifiables de la zone mémoire Library cache ,s'il est opportun de les modifier et dans ce cas comment ? Merci de vos réponses |
|
|
00
|
|
|
#2 |
|
Membre habitué
![]() Inscription : mai 2007 Messages : 113 ![]() |
Inutile de jouer avec le paramètre SGA_MAX_SIZE, il est automatique.
The SGA_MAX_SIZE parameter is used to limit the dynamic sizing of SGA parameters. If the SGA_MAX_SIZE parameter value in the spfile is smaller than the addition of all SGA components, then the dynamic value of SGA_MAX_SIZE instance parameter is automatically set by Oracle to the SGA size. La définition : Initial size of SGA at startup, dependent on the sizes of different pools in the SGA, such as buffer cache, shared pool, large pool, and so on. Pour le reste, il faut augmenter la taille des redologs. Les redos sont trop petits, on retombe sur le premier. Le checkpoint ne peux pas se faire, et l'instance crash |
|
|
00
|
|
|
#3 | |||
|
Expert Confirmé
![]() Inscription : février 2006 Messages : 3 433 ![]() |
Citation:
Citation:
Ces messages Citation:
|
|||
|
|
00
|
|
|
#4 | ||||
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
Merci pour vos réponses.
L'instance s'est de nouveau arrêtée hier soir. Voici les logs dans l'alerte.log : Code :
Le fichier xxxx_pmon_27595.trc contient quand à lui : Code :
|
||||
|
|
00
|
|
|
#5 | |
|
Expert Confirmé
![]() Inscription : février 2006 Messages : 3 433 ![]() |
Citation:
Est-ce qu'il n'y a pas une autre erreur ORA-XXXX dans le fichier trace ? |
|
|
|
00
|
|
|
#6 |
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
Non aucun autre message d'erreur dans les fichiers trace.
|
|
|
00
|
|
|
#7 | |
|
Expert Confirmé
![]() Inscription : février 2006 Messages : 3 433 ![]() |
Une piste possible:
Citation:
Voir les recommandations Oracle. |
|
|
|
00
|
|
|
#8 |
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
J'ai oublié de préciser que la base s'arrête sans qu'aucun accès n'y soit effectué.
|
|
|
00
|
|
|
#9 | |
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
Dans l'admin guide, j'ai trouvé ça
Citation:
|
|
|
|
00
|
|
|
#10 |
|
Expert Confirmé
![]() Inscription : février 2006 Messages : 3 433 ![]() |
Etes-vous sûr qu'il n'ya a pas d'activité de type batch éventuellement déclenchée par un job DBMS_JOB ou job DBMS_SCHEDULER ?
Avez-vous vérifiez bien tous les paramètre noyaux Linux ? Attention si vous executez un "ALTER DATABASE CLEAR LOGFILE", la restauration de la base est compromise ![]() Dans le cas d'un problème de corruption, il y a des messages d'erreur très précis. Ce qui ne semble pas être le cas. Si vous n'avez pas d'autre message d'erreur, contactez le support Oracle. |
|
|
00
|
|
|
#11 |
|
Candidat au titre de Membre du Club
![]() Inscription : juin 2007 Messages : 47 ![]() |
J'en reviens après investigation plus approfondie.
Le problème provenait de la configuration de la machine virtuelle VMWARE ou est hébergée la base. VMWARE était paramètrée avec une allocation dynamique de la mémoire, ce qui provoquait une réaffectation de la mémoire disponible en cas de non utilisation. De plus, il a été constaté la non utilisation de l'espace swap par le système d'exploitation dans cette configuration. Dans une telle situation, le système d'exploitation ne possédant plus de mémoire, tuait le daemon oracle smon provoquant ainsi l'arrêt de la base. Le domaine VMWARE affecté au projet a donc été configuré en allocation mémoire statique et le problème semble résolu. |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com