Discussion :

[schlitters]

Bonjour,
Dans le répertoire bdump (répertoire vers lequel pointe background_dump_dest de mon fichier init.ora) un fichier SID_mmon????.trc (où ???? sont des chiffres) d’ 1,3 Mo est créé toutes les cinq minutes (environs).
Ces fichiers sont générés même lorsqu’il n’y a aucun traitement sur la base durant la journée (càd Instance lancée, base montée, base ouverte c’est tout)

Faute de place sur mon disque tous les jours je supprime ces fichiers *.trc, sans jamais avoir rencontré de problème (je sais c'est bourrin et surtout illogique par rapport à ma prochaine question).

Ce que j’aimerais savoir, c’est à quoi servent exactement ces fichiers traces, et comment paramétrer ORACLE pour diminuer le nombre de fichiers créés (un toutes les heures, voir un tous les jours si ces fichiers ne sont pas nécessaires)

D’avance merci,
Fred

ORACLE 10gR1
Linux RedHat 4AS

[schlitters]

Ci joint le début d'un des fichiers trc généré dans bdump/

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
41
42
 
Dump file /u02/oradata/mabase/bdump/mabase_mmon_10847.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product
System name:    Linux
Node name:      srv1
Release:        2.6.9-5.EL
Version:        #1 Wed Jan 5 19:22:18 EST 2005
Machine:        i686
Instance name: mabase
Redo thread mounted by this instance: 1
Oracle process number: 11
Unix process pid: 10847, image: oracle@srv1 (MMON)
*** SERVICE NAME:(SYS$BACKGROUND) 2006-05-17 09:03:07.792
*** SESSION ID:(50.416) 2006-05-17 09:03:07.792
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, PC: [0x873a1fc, keltinso()+3532]
Registers:
%eax: 0x00000000 %ebx: 0x00000018 %ecx: 0x40b4ebfc
%edx: 0x0c03c0ec %edi: 0x00000000 %esi: 0x00000017
%esp: 0xbfffda70 %ebp: 0xbfffdfd4 %eip: 0x0873a1fc
%efl: 0x00010246
  keltinso()+3513 (0x873a1e9) movzw 0xfffffaa8(%ebp),%ebx
  keltinso()+3520 (0x873a1f0) lea 0x1(%ebx),%eax
  keltinso()+3523 (0x873a1f3)  mov %ax,0xfffffaa8(%ebp)
  keltinso()+3530 (0x873a1fa) xor %eax,%eax
> keltinso()+3532 (0x873a1fc) movb (%edi),%dh
  keltinso()+3534 (0x873a1fe) mov %edi,%ecx
  keltinso()+3536 (0x873a200) testb %dh,%dh
  keltinso()+3538 (0x873a202) je 0x873a210
  keltinso()+3540 (0x873a204) add $1,%ecx
*** 2006-05-17 09:03:07.872
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [keltinso()+3532] [SIGSEGV] [Address not mapped to object] [0x0] [] []
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+493         call     ksedst()+0           1 ? 0 ? 1 ? 1 ? 0 ? 0 ?
ssexhd()+1132        call     ksedmp()+0           3 ? 0 ? 0 ? 0 ? 0 ? 0 ?
__pthread_sighandle  call     ssexhd()+0           B ? BFFFD700 ? BFFFD780 ?
r_rt()+167                                         18 ? 17 ? 0 ?

Je vous fait grâce de la suite parce que c'est assez imbuvable comme fichier ...

De ce que j'ai pu comprendre par ci par là, ces fichiers *.trc seraient créés à cause d'une erreur. Quelqu'un peut il confirmer, et m'expliquer le but des fichiers trc en général ??

Ce que je ne comprends pas c'est pourquoi cette base génére une erreur, alors que deux autres bases tournent sur le même serveur et ne générent pas de fichiers trc ?

Fred

[bouyao]

Je pense que c'est le bug : 4089968

ORA-07445 [KELTINSO()+3532]


*** 12/27/04 08:14 am ***
*** 12/27/04 08:23 am ***
*** 12/27/04 08:34 am ***
*** 12/27/04 03:46 pm *** (CHG: Asg->NEW OWNER)
*** 12/27/04 04:19 pm *** (CHG: SubComp->SVRMAN ALERT)
*** 12/27/04 04:40 pm ***
*** 12/28/04 06:22 am *** (CHG: Asg->NEW OWNER)
*** 12/28/04 06:22 am ***
*** 12/28/04 10:19 am ***
*** 12/28/04 12:12 pm *** (CHG: Sta->10)
*** 12/28/04 12:12 pm ***
*** 12/28/04 02:40 pm ***
*** 12/28/04 03:29 pm ***
*** 01/04/05 02:25 pm *** (CHG: Sta->32)
*** 01/04/05 02:25 pm ***

Essaye de faire une mise à jours en version superieur

Tu peut limiter la taille des fichiers trace en utilisant le parametre MAX_DUMP_FILE_SIZE

[schlitters]

Merci bouyao pour ta réponse, je vais regarder le paramétre MAX_DUMP_FILE_SIZE en éspérant que ça régle déjà mon probléme d'espace disque perdu pour rien.

Je vais essayer une mise à jours en version superieur ...

PS: Je mets résolu, même si ça ne l'ai pas vraiment .....