[Oracle 10g]Database Time Spent waiting

J'ai une base Oracle 10g installée sur un serveur sous Linux Suse 10. J'ai depuis le début le message suivant dans la console EM :

Mesures "Database Time Spent Waiting (%)" : 100 pour la classe d'événements "Concurrency" ..

je n'arrive pas à parametrer ma base pour corriger ce probleme.

Je suis en archivelog - ce qui doit augmenter, je pense, le nombre d'ecriture sur les fichiers de journalisation. Je ne dispose helas pas d'une batterie de disques .. Nous sommes dans une petite structure - une dizaine de développeurs de pages web php avec des requetes sur une base de données.
J'essaie tant bien que mal d'administrer la bdd Oracle 10g. Le volume de transaction n'est pas en cause - s'agissant d'un serveur de développement.

Mon serveur est un Dell equipé de 2 processeurs - 2 go de ram ecc - 1 controleur scsi - 2 hdd en mirroir ..

Il est clair que la contention doit resulter du fait que l'ecriture ne se fait que sur un canal que ce soit pour les datafile, les redolog, les archives etc .. mais un autre serveur ( en oracle 9i, plus chichement doté ne me fait pas ce genre d'anomalie ) ..

Désolé pour la naiveté de mes questions .. mais comment pourrais-je corriger le probleme ?

L'attente "Concurrency" c'est peut-être tout simplement que tu as des locks sur certaines tables de ta base ;)
Utilise Statpack ou AWR pour avoir une analyse

Citation:

Envoyé par scheu

L'attente "Concurrency" c'est peut-être tout simplement que tu as des locks sur certaines tables de ta base ;)
Utilise Statpack ou AWR pour avoir une analyse

j'ai fait .. mais

Citation:

Les attentes d'E/S sur des tablespaces temporaires n'ont pas consommé une part importante du temps base de données.
Le débit du sous-système d'E/S n'a pas été largement inférieur à ce qui était prévu.
La taille de la mémoire SGA a été correctement estimée

et surtout

Citation:

Aucune recommandation n'est disponible

je continue à chercher .. :koi:

Les conseils générés automatiquement ne sont pas toujours fiables, c'est aussi pour ça que le DBA a du travail ;)
Regarde les sessions les plus consommatrices pour l'attente "Concurrency"

Citation:

Envoyé par scheu

Regarde les sessions les plus consommatrices pour l'attente "Concurrency"

j'y travaille .. mais comme c'est une base de developpement, il n'y a pas beaucoup d'activité .. et malgré le peu d'activité, j'ai ce genre de message . ce qui semble indiquer que ce ne sont pas les requetes des utilisateurs qui posent probleme - enfin, elles ne sont pas les seules puisque meme les outils d'administration - la surveillance genere un taux d'activité assez elevé .. et je ne parle pas des rebuild d'index etc ..

1 pièce(s) jointe(s)

http://www.developpez.net/forums/att...1&d=1214985223

rien n'y fait, modif sga , augmentation taille buffer ...

le pire , c'est qu'il n'y a quasiment aucune activité sur ma base ..

Y a-t-il des "verrous externes d'instance" ?
Regarde depuis le graphe "nombre moyen de sessions actives" de l'onglet principal "performances", clique sur "concurrency" dans la légende et regarde les sessions les plus actives pour "concurrency"

Citation:

Envoyé par scheu

Y a-t-il des "verrous externes d'instance" ?
Regarde depuis le graphe "nombre moyen de sessions actives" de l'onglet principal "performances", clique sur "concurrency" dans la légende et regarde les sessions les plus actives pour "concurrency"

il n'y a rien apparemment .. les taches d'administration me font le meme probleme .. si je fais par exemple une recherche des taches qui ont consommé le plus ... ça me fait le meme probleme .. le seul "tuning" que me propose ADDM , c'est d'augmenter ma SGA target .. je suis à 1008M .. mon serveur n'ayant que 2Go , je me vois mal l'augmenter beaucoup plus ..
Mon probleme semble quand meme provenir des redolog .. ce doit peut-etre provenir de mes disques qui ont des acces trop lents, ce qui penalise le LOGWR .. du coup ça genere beaucoup d'attente ..
Il faut dire que je ne dispose que d'1 pack de disque en mirroir et que tout est sur le meme disque - mon os, ma base, mon instance, les redologs , les datafile etc ..
Je suis en archivelog pour me permettre aussi des sauvegarde RMAN à chaud, donc , c'est clair que ça journalise .. tous mes users ont leurs tables et index en logging ..
J'ai 1 user avec de grosses tables partitionnées mais comme c'est un serveur de developpement, il n'y a quasi pas d'activité .. mon collègue vient de faire un delete important, ça m'a généré pas mal de nouvelles erreurs :

par ex

Citation:

Recherchez la cause des attentes "os thread startup" importantes. Reportez-vous au manuel Oracle "Database Reference" pour la description de cet événement d'attente

j'ai aussi changé le parametre _kgl_large_heap_warning_threshold, ce qui, il semblerait, me provoque maintenant ..

Citation:

ORA-32004: obsolete and/or deprecated parameter(s) specified

Citation:

Envoyé par turlut

Mon probleme semble quand meme provenir des redolog .. ce doit peut-etre provenir de mes disques qui ont des acces trop lents, ce qui penalise le LOGWR .. du coup ça genere beaucoup d'attente ..

qu'est ce qui te fait dire ça ?

Citation:

Envoyé par turlut

j'ai aussi changé le parametre _kgl_large_heap_warning_threshold, ce qui, il semblerait, me provoque maintenant ..

pourquoi tu veux changer ce paramètre ? :koi:

T'as cherché le TOP 5 des évènements de la base ?

Citation:

Envoyé par orafrance

qu'est ce qui te fait dire ça ?

pourquoi tu veux changer ce paramètre ? :koi:

T'as cherché le TOP 5 des évènements de la base ?

ce qui me fait dire cela .. ce sont les messages d'alerte que je reçois sans cesse. Mais je suis débutant donc j'interprete peut etre mal les infos ..

j'ai aussi

Citation:

La classe d'attente "E/S utilisateur" a consommé une part importante du temps base de données.
La taille de la mémoire SGA a été mal estimée, d'où des E/S ou des analyses réelles (hard parses) supplémentaires.
Des segments de base de données particuliers responsables d'une attente d'E/S utilisateur importante ont été trouvés.

en plus des messages recueillis précédemment et pour lesquels j'ai mis une capture d'cran sur mon message précédent

Je suis en Linux SLES10 - oracle 10.2.0.1

Pour les parametres obsoletes, je suis allé voir dans mon alert.log et il semblerait que ce soit log_archive_start !! ce parametre a disparu sur la 10g ?

activité les plus consommatrices en ce moment

Citation:

100,00 166 SYS oracle@mafate (LGWR)

donc LGWR et OMS à l'instant meme ..
je ne comprends pas car il n'y a vraiment aucune activité particulière sur cette instance ..

pour le param _kgl_... j'ai eu des soucis avec lui, en regardant les alert, je suis allé sur google .. et suis tombé sur un site qui m'indiquait qu'il fallait mettre une valeur à ce param sinon ça générait les messages que j'avais eu .. je les avais noté mais hélas .. je ne retrouve pas mon papier ..

Citation:

Envoyé par turlut

ce qui me fait dire cela .. ce sont les messages d'alerte que je reçois sans cesse.

Et c'est confidentielle pour que tu ne nous les partages pas ? :mouarf:

Citation:

Envoyé par turlut

en plus des messages recueillis précédemment et pour lesquels j'ai mis une capture d'cran sur mon message précédent

Donc toujours rien sur les redologs :?

Citation:

Envoyé par turlut

Pour les parametres obsoletes, je suis allé voir dans mon alert.log et il semblerait que ce soit log_archive_start !! ce parametre a disparu sur la 10g ?

Etrange... tu as l'extrait de l'alert ? Et sinon, tu n'as pas répondu pour le paramètre caché :koi:

Citation:

Envoyé par turlut

donc LGWR et OMS à l'instant meme ..
je ne comprends pas car il n'y a vraiment aucune activité particulière sur cette instance ..

Bah si la base ne fait rien c'est un peu logique de trouver les process de la base dans le top 5 tu crois pas ? Si tu fais un SELECT * FROM dba_segments t'aura du scattered read en 1er :aie:

C'est quand la base travaille qu'il faut regarder les attentes sinon ça n'a aucune signification. Si je viens te voir pendant la pose café est-ce que je dois en conclure que le problème de ta productivité c'est que tu tapes pas assez vite sur le clavier ? Evidemment que c'est pas quand tu es au café qu'on peut apprécier ton travail... c'est pareil pour la base :mouarf:

Citation:

Envoyé par orafrance

Et c'est confidentielle pour que tu ne nous les partages pas ? :mouarf:

Donc toujours rien sur les redologs :?

Etrange... tu as l'extrait de l'alert ? Et sinon, tu n'as pas répondu pour le paramètre caché :koi:

Bah si la base ne fait rien c'est un peu logique de trouver les process de la base dans le top 5 tu crois pas ? Si tu fais un SELECT * FROM dba_segments t'aura du scattered read en 1er :aie:

C'est quand la base travaille qu'il faut regarder les attentes sinon ça n'a aucune signification. Si je viens te voir pendant la pose café est-ce que je dois en conclure que le problème de ta productivité c'est que tu tapes pas assez vite sur le clavier ? Evidemment que c'est pas quand tu es au café qu'on peut apprécier ton travail... c'est pareil pour la base :mouarf:
Code:

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 34 35 36 37 38 39 40 Starting up ORACLE RDBMS Version: 10.2.0.1.0. System parameters with non-default values: processes = 150 __shared_pool_size = 188743680 __large_pool_size = 4194304 __java_pool_size = 4194304 __streams_pool_size = 0 nls_language = FRENCH nls_territory = FRANCE sga_target = 1056964608 control_files = /u01/app/oracle/oradata/ORAMAF/control01.ctl, /u01/app/oracle/oradata/ORAMAF/control02.ctl, /u01/app/oracle/oradata/ORAMAF/control03.ctl db_block_size = 8192 __db_cache_size = 847249408 compatible = 10.2.0.1.0 log_archive_start = TRUE log_buffer = 14302208 db_file_multiblock_read_count= 16 db_recovery_file_dest = /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size= 4294967296 fast_start_mttr_target = 120 db_flashback_retention_target= 360 undo_management = AUTO undo_tablespace = UNDOTBS1 _kgl_large_heap_warning_threshold= 8388608 remote_login_passwordfile= EXCLUSIVE db_domain = dispatchers = (PROTOCOL=TCP) (SERVICE=ORAMAFXDB) utl_file_dir = * job_queue_processes = 10 background_dump_dest = /u01/app/oracle/admin/ORAMAF/bdump user_dump_dest = /u01/app/oracle/admin/ORAMAF/udump core_dump_dest = /u01/app/oracle/admin/ORAMAF/cdump audit_file_dest = /u01/app/oracle/admin/ORAMAF/adump db_name = ORAMAF open_cursors = 300 pga_aggregate_target = 200278016 _awr_flush_threshold_metrics= TRUE Deprecated system parameters with specified values: log_archive_start End of deprecated system parameter listing
le parametre _kgl_large_heap_warning_threshold ça je l'ai lu sur un forum .. je rechercherai ..

non, c'est vrai, je fais peut etre fausse route sur les redolog .. en regardant le fichier alert, j'ai juste vu que j'archivais toutes les 5-6 secondes .. alors j'ai augmenté les fichiers des groupe de journaux .. mais c'est du pifometre ..

quand j'ai de l'activité .. le resultat est toujours le meme .. augmenter la sga_target à 1008, puis 1260 puis 1580 etc ... mais meme en l'augmentant , je ne resouds pas les problemess.. et n'ayant que 2go de memoire vive, je me dis quand meme qu'il me faut m'arreter à une valeur inferieure, non ? et laisser un peu de ram pour mon os et les autres activités de ma machine ..

je dois quitter, a l'ile de la Reunion, on est en avance sur vos horaires ..

mais je reviens sur le fil demain ... je vais collecter des infos au moment ou je vais créer de l'activité .. que me faut-il recueillir comme log, infos , trace etc ..

Citation:

Envoyé par turlut

le parametre _kgl_large_heap_warning_threshold ça je l'ai lu sur un forum .. je rechercherai ..

Ha ouais... tu vois un paramètre caché dans un forum alors tu te dis que ça pourrait être marrant d'essayer :mouarf: Elle est pas mauvaise celle-là :aie:

Citation:

Envoyé par turlut

non, c'est vrai, je fais peut etre fausse route sur les redolog .. en regardant le fichier alert, j'ai juste vu que j'archivais toutes les 5-6 secondes .. alors j'ai augmenté les fichiers des groupe de journaux .. mais c'est du pifometre ..

le nombre de fichier ou leur taille ?

Citation:

Envoyé par turlut

quand j'ai de l'activité .. le resultat est toujours le meme .. augmenter la sga_target à 1008, puis 1260 puis 1580 etc ... mais meme en l'augmentant , je ne resouds pas les problemess.. et n'ayant que 2go de memoire vive, je me dis quand meme qu'il me faut m'arreter à une valeur inferieure, non ? et laisser un peu de ram pour mon os et les autres activités de ma machine ..

Faut pas croire tout ce que dit Oracle ;)

Citation:

Envoyé par turlut

je vais collecter des infos au moment ou je vais créer de l'activité .. que me faut-il recueillir comme log, infos , trace etc ..

v$system_event au début et à la fin de l'activité et surveille v$session_wait pour relever les éléments les plus probants... éventuellement utilise statpack peut-être plus facile à exploiter via le forum ;)

Bonne plage :ccool:

Citation:

Envoyé par orafrance

Ha ouais... tu vois un paramètre caché dans un forum alors tu te dis que ça pourrait être marrant d'essayer :mouarf: Elle est pas mauvaise celle-là :aie:

n'étant pas un pro - je suis sans doute crédule et je crois ce que je lis - à tort, visiblement. :(
dois-je le supprimer ce parametre ?
pour le parametre en question - c'est là que je l'ai lu http://www.developpez.net/forums/sho...d.php?t=172649

dois-je egalement supprimer log_archive_start de mon spfile ? puisque le startup.log me dit que ce param est obsolete and/or deprecated

Citation:

Envoyé par orafrance

le nombre de fichier ou leur taille ?

4 groupes de 1 fichier de 300 Mo - j'avais essayé 4 groupes de 3 fichiers mais ça ne m'avait pas avancé - en plus faute de disques, ils sont tous sur le meme .. donc l'interet me semble moins évident ..

Citation:

Envoyé par orafrance

Faut pas croire tout ce que dit Oracle ;)

pourtant 1 oracle, ça dit vrai en principe :lol:

Citation:

Envoyé par orafrance

v$system_event au début et à la fin de l'activité et surveille v$session_wait pour relever les éléments les plus probants... éventuellement utilise statpack peut-être plus facile à exploiter via le forum ;)
Bonne plage :ccool:

Bonne plage - euh, non - c'est l'hiver ici .. et l'eau à 22-24 degrés, c'est trop froid .. :mouarf:
je vais essayer de surveiller ce que vous m'indiquez - mais j'ai 2 mains gauches, donc .. je vais googler pour voir comment mettre ça en oeuvre ..(statpack notamment).

Merci en tout cas pour votre patience .. je vais retourner faire du cobol si ça continue .. et mon bon vieux gcos7 !!

Ah encore un truc qui n'a sans doute rien à voir, mais isqlplus se plante assez régulièrement aussi , je suis obligé de relancer isqlplusctl start .. ou meme parfois, quand ça ne fonctionne pas, de relancer la base par rcoracle restart .. pas doué le gars, je sais !! :cry:

edit quelques minutes plus tard ... statspack mis en place et snap effectué .. mais absence de grosse activité pour le moment - je referai un snap plus tard .. quelle partie du rapport peut etre parlante ? j'ai voulu le mettre sur le forum mais il est trop volumineux ..

petit extrait :
Code:

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 34 35 36 37 38 39 Wait Event Histogram DB/Inst: ORAMAF/ORAMAF Snaps: 11-21 -> Total Waits - units: K is 1000, M is 1000000, G is 1000000000 -> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms -> % of Waits - value: .0 indicates value was <.05%, null is truly 0 -> Ordered by Event (idle events last) Total ----------------- % of Waits ------------------ Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s -------------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- control file parallel writ 292 98.3 .7 1.0 control file sequential re 2462 100.0 db file scattered read 1 100.0 db file sequential read 53 20.8 11.3 11.3 45.3 11.3 enq: RO - fast object reus 1 100.0 latch: library cache 19 89.5 10.5 latch: shared pool 11 90.9 9.1 LGWR wait for redo copy 4 100.0 local write wait 3 100.0 log file parallel write 455 93.6 1.1 .4 1.8 1.3 1.3 .4 log file sync 101 88.1 1.0 5.9 1.0 1.0 3.0 os thread startup 13 100.0 reliable message 1 100.0 SQL*Net break/reset to cli 80 98.8 1.3 SQL*Net more data to clien 20 100.0 dispatcher timer 13 100.0 jobq slave wait 254 100.0 pmon timer 281 1.8 98.2 rdbms ipc message 3105 7.9 1.5 .3 .4 .9 .4 29.0 59.6 smon timer 3 100.0 SQL*Net message from clien 3375 78.7 5.9 3.4 .7 .3 .1 3.9 7.1 SQL*Net message to client 3374 100.0 SQL*Net more data from cli 90 100.0 Streams AQ: qmn coordinato 59 49.2 50.8 Streams AQ: qmn slave idle 29 100.0 Streams AQ: waiting for me 167 .6 99.4 Streams AQ: waiting for ti 19 26.3 26.3 47.4 virtual circuit status 28 100.0 wait for unread message on 827 100.0 -------------------------------------------------------------

Citation:

Envoyé par turlut

n'étant pas un pro - je suis sans doute crédule et je crois ce que je lis - à tort, visiblement. :(
dois-je le supprimer ce parametre ?
pour le parametre en question - c'est là que je l'ai lu http://www.developpez.net/forums/sho...d.php?t=172649

le sujet n'a rien à voir avec ton problème et en plus il se termine en disant que ce n'est pas concluant et toi tu le mets quand même... c'est pas très sérieux :?

Citation:

Envoyé par turlut

dois-je egalement supprimer log_archive_start de mon spfile ? puisque le startup.log me dit que ce param est obsolete and/or deprecated

Evidemment oui puisqu'il est obsolète.

Citation:

Envoyé par turlut

4 groupes de 1 fichier de 300 Mo - j'avais essayé 4 groupes de 3 fichiers mais ça ne m'avait pas avancé - en plus faute de disques, ils sont tous sur le meme .. donc l'interet me semble moins évident ..

Encore une fois, tu as agis avant de comprendre. Si tu fais trop de checkpoint c'est que le redo se rempli très vite et Oracle doit passer souvent au suivant. Pour régler ça tu dois donc augmenter la taille du redo et non leur nombre :?

Citation:

Envoyé par turlut

Bonne plage - euh, non - c'est l'hiver ici .. et l'eau à 22-24 degrés, c'est trop froid .. :mouarf:

Ha oui c'est vrai :aie:

Citation:

Envoyé par turlut

je vais essayer de surveiller ce que vous m'indiquez - mais j'ai 2 mains gauches, donc .. je vais googler pour voir comment mettre ça en oeuvre ..(statpack notamment).

http://oracle.developpez.com/guide/tuning/statpack/ :mrgreen:

Citation:

Envoyé par turlut

Merci en tout cas pour votre patience .. je vais retourner faire du cobol si ça continue .. et mon bon vieux gcos7 !!

Pas de problème, prend juste l'habitude de consulter la doc : http://www.oracle.com/pls/db102/sear...k=quick_search

Citation:

Envoyé par turlut

Ah encore un truc qui n'a sans doute rien à voir, mais isqlplus se plante assez régulièrement aussi , je suis obligé de relancer isqlplusctl start .. ou meme parfois, quand ça ne fonctionne pas, de relancer la base par rcoracle restart .. pas doué le gars, je sais !! :cry:

je ne sais pas, je ne l'utilise pas :?

Citation:

Envoyé par turlut

quelle partie du rapport peut etre parlante ? j'ai voulu le mettre sur le forum mais il est trop volumineux ..

tu peux joindre un fichier à ton message dans le forum :)

Sinon, au moins le début, avant les requêtes.
Apparemment, il n'y a pas assez d'activité, on ne voit rien de particulier. A part que les accès disques ont l'air très rapide avec la plupart des attentes disques <1ms :king:

Citation:

Envoyé par orafrance

le sujet n'a rien à voir avec ton problème et en plus il se termine en disant que ce n'est pas concluant et toi tu le mets quand même... c'est pas très sérieux :?

comment puis-le retirer maintenant ? puisque c'est un parametre caché mais pas obsolète ..

Citation:

Envoyé par orafrance

Evidemment oui puisqu'il est obsolète.

fait

Citation:

Envoyé par orafrance

Encore une fois, tu as agis avant de comprendre. Si tu fais trop de checkpoint c'est que le redo se rempli très vite et Oracle doit passer souvent au suivant. Pour régler ça tu dois donc augmenter la taille du redo et non leur nombre :?

300 Mo pour une base à faible activité, je pensais que c'était très suffisant .. sur ma 9i , j'ai 3 fichiers de 100Mo et aucun souci avec les memes users et schemas actifs .. En fait, je ne sais pas dimensionner ces fichiers - y-a-t'il une règle ? mais je vais fouiller la base de connaissances sur developpez.net ..

Citation:

Envoyé par orafrance

je ne sais pas, je ne l'utilise pas :?

c'est une demande de mes collègues qui apprécient la mise en forme des resultats ..

Citation:

Envoyé par orafrance

Sinon, au moins le début, avant les requêtes.
Apparemment, il n'y a pas assez d'activité, on ne voit rien de particulier. A part que les accès disques ont l'air très rapide avec la plupart des attentes disques <1ms :king:

je me demande si ce n'est pas EM qui est particulièrement bavard et que ces messages d'alerte ne sont pas si pertinents que cela ..:roll:

Citation:

Envoyé par turlut

300 Mo pour une base à faible activité, je pensais que c'était très suffisant ..

T'as des checkpoints à quelle fréquence ?

Citation:

Envoyé par turlut

c'est une demande de mes collègues qui apprécient la mise en forme des resultats ..

Ils n'ont qu'à installer SQL Developper :)

Citation:

Envoyé par turlut

je me demande si ce n'est pas EM qui est particulièrement bavard et que ces messages d'alerte ne sont pas si pertinents que cela ..:roll:

c'est ce que je t'ai dit déjà, il y a des chances que ce soit le cas en effet :)

Citation:

Envoyé par orafrance

T'as des checkpoints à quelle fréquence ?

environ toutes les 30 secondes .. si je lis bien les switch des logs ci-dessous

Code:

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
Thread 1 cannot allocate new log, sequence 516
Checkpoint not complete
  Current log# 3 seq# 515 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo03.log
Thread 1 advanced to log sequence 516
  Current log# 1 seq# 516 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo01.log
Mon Jun 30 14:50:07 2008
Thread 1 cannot allocate new log, sequence 517
Checkpoint not complete
  Current log# 1 seq# 516 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo01.log
Thread 1 advanced to log sequence 517
  Current log# 4 seq# 517 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo04.log
Mon Jun 30 14:50:35 2008
Thread 1 cannot allocate new log, sequence 518
Checkpoint not complete
  Current log# 4 seq# 517 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo04.log
Thread 1 advanced to log sequence 518
  Current log# 2 seq# 518 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo02.log
Mon Jun 30 14:51:07 2008
Thread 1 advanced to log sequence 519
  Current log# 3 seq# 519 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo03.log
Mon Jun 30 14:51:48 2008
Thread 1 advanced to log sequence 520
  Current log# 1 seq# 520 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo01.log
Mon Jun 30 14:52:27 2008
Thread 1 advanced to log sequence 521
  Current log# 4 seq# 521 mem# 0: /u01/app/oracle/oradata/ORAMAF/redo04.log

j'ai aussi pas mal de

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Memory Notification: Library Cache Object loaded into SGA
Heap size 3662K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw== 
Tue Jul  1 04:00:11 2008
Memory Notification: Library Cache Object loaded into SGA
Heap size 3932K exceeds notification threshold (2048K)
Details in trace file /u01/app/oracle/admin/ORAMAF/udump/oramaf_ora_32160.trc
KGL object name :XDB.XDA8XlWX/h+P3gQFeMmGQWfg== 
Tue Jul  1 04:07:31 2008
Starting control autobackup
Tue Jul  1 04:07:34 2008
Errors in file /u01/app/oracle/admin/ORAMAF/udump/oramaf_ora_32184.trc:
Tue Jul  1 04:07:34 2008
Errors in file /u01/app/oracle/admin/ORAMAF/udump/oramaf_ora_32184.trc:
Tue Jul  1 04:07:34 2008
Errors in file /u01/app/oracle/admin/ORAMAF/udump/oramaf_ora_32184.trc:
Control autobackup written to DISK device

Citation:

Envoyé par orafrance

Ils n'ont qu'à installer SQL Developper :)

je vais essayer de le trouver en français ..

Citation:

Envoyé par orafrance

c'est ce que je t'ai dit déjà, il y a des chances que ce soit le cas en effet :)

j'ai quand meme environ 500 notifications par jour ... "Database Time Spenting " .. Clause Concurrency ..

c'est quand même étrange que les redos soient si sollicités s'il n'y a pas d'activité... t'as quoi dans les sessions ACTIVE ?

que donne :

Code:

SELECT * FROM v$log;

Citation:

Envoyé par orafrance

c'est quand même étrange que les redos soient si sollicités s'il n'y a pas d'activité... t'as quoi dans les sessions ACTIVE ?

que donne :

Code:

SELECT * FROM v$log;

Code:

1
2
3
4
5
6
   GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TI
--------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------
        1          1        536  314572800          1 YES INACTIVE              23583854 02/07/08
        2          1        537  314572800          1 YES INACTIVE              23652152 02/07/08
        3          1        538  314572800          1 NO  CURRENT               23678524 03/07/08
        4          1        535  314572800          1 YES INACTIVE              23581266 02/07/08

j'ai l'impression que ce sont mes taches d'administration qui me mangent de la ressources ..
OMS - users DBSNMP et SYSMAN ...