Discussion :

[Invité]

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 ?

[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

[Invité]

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

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

Aucune recommandation n'est disponible

je continue à chercher ..

[scheu]

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"

[Invité]

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 ..

[Invité]

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

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

[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"

[Invité]

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

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 ..

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

[orafrance]

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 ?

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 ?

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

[Invité]

qu'est ce qui te fait dire ça ?



pourquoi tu veux changer ce paramètre ?

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

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

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 ..

[orafrance]

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 ?

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

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é

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

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

[Invité]

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

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é

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

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

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
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 ..

[orafrance]

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 Elle est pas mauvaise celle-là

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 ?

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

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

[Invité]

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

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

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 ..

Faut pas croire tout ce que dit Oracle

pourtant 1 oracle, ça dit vrai en principe

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

Bonne plage - euh, non - c'est l'hiver ici .. et l'eau à 22-24 degrés, c'est trop froid ..
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 !!

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 :

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
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
          -------------------------------------------------------------

[orafrance]

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

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.

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

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

Ha oui c'est vrai

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/

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

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 !!

je ne sais pas, je ne l'utilise pas

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

[Invité]

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 ..

Evidemment oui puisqu'il est obsolète.

fait

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 ..

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 ..

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

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 ..

[orafrance]

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

T'as des checkpoints à quelle fréquence ?

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

Ils n'ont qu'à installer SQL Developper

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 ..

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

[Invité]

T'as des checkpoints à quelle fréquence ?

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

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
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 :

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
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

Ils n'ont qu'à installer SQL Developper

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

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 ..

[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 :

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

SELECT * FROM v$log;

[Invité]

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 :

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

SELECT * FROM v$log;

Code :

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

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 ...