Version imprimable
Bonjour à tous
En utilisant l'assistant d'installation d'une base de données , dans l'une des étapes on doit spécifier le chemin d'accès des fichiers de trace USER_DUMP_DEST et BACKGROUND_DUMP_DEST,
quelqu'un ne pourrait il pas me donner une idée sur le rôle de ces fichiers et la manière dont on peut les exploiter
Merci à tous
P.S
oracle 8i / windows 2000 server
User_Dump_Dest : toutes les traces générées par des processus utilisateur (traces de sessions notamment). V$SESSION.TYPE = USER
Backgroup_Dump_Dest : toutes les traces générées par les process systèmes, contient l'alert.log. V$SESSION.TYPE=BACKGROUND
Ces fichiers sont très utiles aux DBAs et inaccessibles (en théorie) et inutiles (sans explications) pour les utilisateurs.
en quoi ils sont utiles aux DBAs, en d'autres termes en quoi ils sont différents des des fichiers LOG par exemple, je sais que ces derniers permettent la récupération en cas d'incidents, qu'en est il des TRC ?
Merci
Les logs sont, comme leurs nom l'indique, des journaux d'activités, permettant de récuperer l'activité sur incident.
Les traces sont là pour indiquer que des évènements "exceptionnels" et nécessitant éventuellement une action.
Voici par exemple un extrait d'un background_dump :
Citation:
/usr/lib/oracle/xe/app/oracle/admin/XE/bdump/xe_s000_5731.trc
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Beta
ORACLE_HOME = /usr/lib/oracle/xe/app/oracle/product/10.2.0/server
System name: Linux
Node name: monserveur
Release: 2.6.12-12.mm.1mdk
Version: #1 Sat Sep 24 23:20:03 CEST 2005
Machine: i686
Instance name: XE
Redo thread mounted by this instance: 1
Oracle process number: 14
Unix process pid: 5731, image: oracle@monserveur (S0)
*** 2006-02-17 11:30:31.795
*** SERVICE NAME:(SYS$USERS) 2006-02-17 11:30:31.794
*** SESSION ID:(29.12) 2006-02-17 11:30:31.794
Memory Notification: Library Cache Object loaded into SGA
Heap size 2245K exceeds notification threshold (2048K)
LIBRARY OBJECT HANDLE: handle=28498ca4 mutex=0x28498d58(0)
name=XDB.XDbD/PLZ01TcHgNAgAIIegtw==
hash=e0f82b0c545a707da230a62675d34c80 timestamp=10-10-2005 03:28:49
namespace=XDBS flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0lwt=0x28498d00[0x28498d00,0x28498d00] ltm=0x28498d08[0x28498d08,0x28498d08]
pwt=0x28498ce4[0x28498ce4,0x28498ce4] ptm=0x28498cec[0x28498cec,0x28498cec]
ref=0x28498d20[0x28498d20,0x28498d20] lnd=0x28498d2c[0x28498d2c,0x28498d2c]
LIBRARY OBJECT: object=23ac3154
type=XDBS flags=EXS/LOC[0005] pflags=[0000] status=VALD load=X
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 286dd404 23ac3210 I/P/A/-/- 0 NONE 00 0.34 0.00
1 23ac324c 23869854 I/P/A/-/- 1 NONE 00 2245.79 2265.42
000-0000-0000 lock=S pin=S latch#=1 hpc=0002 hlc=0002
Merci LeoAnderson
je vois déjà que les fichiers TRACE sont des fichiers texte, contrairement aux fichiers LOG qui sont des binaires, mais juste une autre question, quand tu dis :
tu ne pourrais pas citer un exemple de situations pareilles ?Code:
2
par exemple, une trace est générée quand des sessions rencontrent des ORA-600 ou ORA-7445, quand des deadlocks se produisent, quand de la mémoire supplémentaire est allouée à la base (cas de l'exemple ci-dessus), ...