Discussion :

[guappi]

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

[louping]

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

[pifor]

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,

D'accord.

, et l'instance crash

Pas d'accord !

Ces messages

Thread 1 cannot allocate new log, sequence XXXX
Checkpoint not complete

signalent un problème de performance, c'est tout. Pour analyser pourquoi il y a crash de l'instance il faut rechercher un message explicite (comme ORA-00600 par example) qui est souvent associé à un fichier trace (.trc) créé dans le même répertoire que le fichier alert.log.

[guappi]

Merci pour vos réponses.
L'instance s'est de nouveau arrêtée hier soir.
Voici les logs dans l'alerte.log :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Tue Sep 18 17:21:34 2007
Thread 1 cannot allocate new log, sequence 62513
Checkpoint not complete
  Current log# 2 seq# 62512 mem# 0: /data/ora/u01/redo/redo_2a.dbf
  Current log# 2 seq# 62512 mem# 1: /data/ora/u02/redo/redo_2b.dbf
Tue Sep 18 17:21:35 2007
Completed checkpoint up to RBA [0xf430.2.10], SCN: 6851191097457
Tue Sep 18 17:21:36 2007
Beginning log switch checkpoint up to RBA [0xf431.2.10], SCN: 6851191097566
Thread 1 advanced to log sequence 62513
  Current log# 1 seq# 62513 mem# 0: /data/ora/u01/redo/redo_1a.dbf
  Current log# 1 seq# 62513 mem# 1: /data/ora/u02/redo/redo_1b.dbf
Tue Sep 18 17:22:51 2007
Completed checkpoint up to RBA [0xf431.2.10], SCN: 6851191097566
Tue Sep 18 17:22:53 2007
Beginning log switch checkpoint up to RBA [0xf432.2.10], SCN: 6851191097699
Thread 1 advanced to log sequence 62514
  Current log# 2 seq# 62514 mem# 0: /data/ora/u01/redo/redo_2a.dbf
  Current log# 2 seq# 62514 mem# 1: /data/ora/u02/redo/redo_2b.dbf
Tue Sep 18 17:28:00 2007
Completed checkpoint up to RBA [0xf432.2.10], SCN: 6851191097699
Tue Sep 18 17:28:50 2007
Incremental checkpoint up to RBA [0xf432.22c6.0], current log tail at RBA [0xf432.22c6.0]
Tue Sep 18 17:57:47 2007
Errors in file /data/ora/adm/bdump/xxxx_pmon_27595.trc:
ORA-00474: Message 474 not found; No message file for product=RDBMS, facility=ORA
Tue Sep 18 17:57:47 2007
PMON: terminating instance due to error 474
Instance terminated by PMON, pid = 27595

Le fichier xxxx_pmon_27595.trc contient quand à lui :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
*** 2007-09-18 17:57:47.599
*** SERVICE NAME:(SYS$BACKGROUND) 2007-09-18 17:57:47.489
*** SESSION ID:(115.1) 2007-09-18 17:57:47.488
Background process SMON found dead
Oracle pid = 8
OS pid (from detached process) = 27607
OS pid (from process state) = 27607
dtp = 0x2000e970, proc = 0x5fda83bc
Dump of memory from 0x2000E970 to 0x2000E99C
2000E970 0000007C 5FDA83BC 00000000 00000000  [|......_........]
2000E980 4E4F4D53 00000200 00006BD7 073AAF81  [SMON.....k....:.]
2000E990 00000001 20D2D4EA 00040081           [....... ....]
Dump of memory from 0x5FDA83BC to 0x5FDA8970
5FDA83B0                            00000102              [....]
5FDA83C0 00000000 00000000 00000000 00000000  [................]
5FDA83D0 5FF50AF0 5FB5173C 5FE60BC8 5FB509C4  [..._<.._..._..._]
5FDA83E0 00000000 5FB50A28 5FB50A28 5FB51730  [....(.._(.._0.._]
5FDA83F0 00001601 5FE4E830 5FE60BC8 00000008  [....0.._..._....]
5FDA8400 5FE61620 5FE61798 00000000 5FF4FEB8  [ .._..._......._]
5FDA8410 5FF50B08 00000000 00000000 00000000  [..._............]
5FDA8420 00000000 00000000 00000000 00000000  [................]
        Repeat 2 times
5FDA8450 00000000 00000000 00050000 00000000  [................]
5FDA8460 00040000 00000000 00050000 00000000  [................]
5FDA8470 00050000 00000000 00040000 00000000  [................]
5FDA8480 00040000 00000000 000A0000 00000000  [................]
5FDA8490 000C0000 00000000 00050000 00000000  [................]
5FDA84A0 00110000 00000000 00000000 00000000  [................]
5FDA84B0 00000000 00000000 00000000 00000000  [................]
        Repeat 3 times
5FDA8960 00000000 00000000 00000000 00000003  [................]
error 474 detected in background process
ORA-00474: Message 474 not found; No message file for product=RDBMS, facility=ORA

Comme le dit louping, je pense qu'il faut agrandir les redos.

[pifor]

ORA-00474: SMON process terminated with error
Cause: The system cleanup process died
Action: Warm start instance

Le fait qu'Oracle ne trouve pas un message d'erreur peut signifier que soit ORACLE_HOME n'est pas correctement défini soit qu'il y a eu un problème d'installation.

Est-ce qu'il n'y a pas une autre erreur ORA-XXXX dans le fichier trace ?

[guappi]

Non aucun autre message d'erreur dans les fichiers trace.

[pifor]

Une piste possible:

Subject: HP-UX: Database Crashed with ORA-447, Nothing Useful in Tracefiles
Doc ID: Note:1011300.102 Type: PROBLEM
Last Revision Date: 12-JUL-2007 Status: PUBLISHED

Si le paramètre noyau nombre de fichier ouverts est insuffisant, il pourrait expliquer ce problème. Attention: si vous avez 100 sessions simultanées sur l'instance et la base possède 10 fichiers, il faut au moins avoir le paramètre configuré à au moins 10x100= 1000 fichiers ouverts car chaque session peut ouvrir un datafile et ne le fermerait qu'à la fin de la session.

Voir les recommandations Oracle.

[guappi]

J'ai oublié de préciser que la base s'arrête sans qu'aucun accès n'y soit effectué.

[guappi]

Dans l'admin guide, j'ai trouvé ça

A redo log file might become corrupted while the database is open, and ultimatelystop database activity because archiving cannot continue. In this situation the ALTER
DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without
shutting down the database.

Je viens de clearer les redos logs et je surveille.

[pifor]

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.

[guappi]

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.