Pliki *.trc (oracle)
suw...@gmail.com
czy może mi ktoś podpowiedzieć do czego dedykowane są katalogi
"adump", "bdump", "cdump", "dpdump" oraz "udump" (folder \product
\admin\db1) ? Rozumiem że przechowują pliki śladu, ale dlaczego nie w
jednym miejscu.
Czy za tworzenie plików *.tlc odpowiadają tylko polecenia
uruchamiające/zatrzymujące śledzenie dla instancji sesji ? Zauważyłem
że pliki śladu powstają tez podczas zatrzymywania bądź uruchamiania
instancji.
Będę wdzięczny za każda podpowiedź lub link do tematu.
Pozdrawiam
Jakub Wartak
> Witam,
> czy może mi ktoś podpowiedzieć do czego dedykowane są katalogi
> "adump", "bdump", "cdump", "dpdump" oraz "udump" (folder \product
> \admin\db1) ? Rozumiem że przechowują pliki śladu, ale dlaczego nie w
> jednym miejscu.
Info odnosnie 10gR2:
a) adump, dla audytu tzw. "wazniejszych" rzeczy (AUDIT, STARTUP, SHUTDOWN,
zmiany struktury itd), parametr audit_file_dest decyduje gdzie jest to
adump w systemie plikow; audit_trail decyduje gdzie logowac rzeczy, ktore
chcesz audytowac (czyli np na "DB" to wtedy loguje do tabeli SYS.AUD$
wszystkie otwarte polaczenia przez uzytkownika, np. "AUDIT CREATE SESSION
BY user1").
b) bdump, alert.log i pliki sladu procesow tla, parametr
background_dump_dest
c) cdump, zrzuty obrazow pamieci procesow (UNIX: po SIGSEGV), parametr
core_dump_dest
d) dpdump, datapump, ale konkretnie co tam jest skladowanie to nie wiem
e) udump, pliki sladu procesow uzytkownikow, parametr user_dump_dest
Jesli masz jakies bledy procesow typu LGWR itd to dokladne info o nich
wyladuje w bdump. Jesli jakies procesy uzytkownika zakonczona dzialanie
niepoprawnie skoncza info o nich skonczy w udump. Jesli cos na prawde jest
nie tak, to system zrzuca obrazy procesow do cdump (mozesz/Oracle corp.
moze je analizowac debuggerem ;))
> Czy za tworzenie plików *.tlc odpowiadają tylko polecenia
> uruchamiające/zatrzymujące śledzenie dla instancji sesji ? Zauważyłem
> że pliki śladu powstają tez podczas zatrzymywania bądź uruchamiania
> instancji.
Jesli chodzi o *.trc to sa m.in rzeczy generowane przez SQL Trace. Czyli jak
chcesz bardzo dokladnie wiedziec co robi sesja robisz:
SQL> ALTER SESSION SET tracefile_identifier = jestpozno;
Session altered.
SQL> ALTER SESSION SET sql_trace = true;
Session altered.
SQL> select count(*) from a;
COUNT(*)
----------
1
<i cos jeszcze>
Potem w katalogu user_dump_dest dostajesz:
[oracle@xeno udump]$ ls -al *JEST*
-rw-r----- 1 oracle oinstall 73064 Apr 24 00:18 test_ora_4612_JESTPOZNO.trc
I przerabiasz go przez tkprofa:
[oracle@xeno udump]$ tkprof jestpozno.txt test_ora_4612_JESTPOZNO.trc
TKPROF: Release 10.2.0.3.0 - Production on Thu Apr 24 00:21:46 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
I czytasz sobie dokladny trace/statystki z jestpozno.txt co ta sesja robi.
Odpowiadajac na pytanie: mozesz takze zalozyc taki SQL Trace na dzialajacej
juz sesji (czyli powiedzmy stale polaczenie od jakiegos uzytkownika) przez
dbms_system.set_sql_trace_in_session() albo na calej bazie danych. No oraz
te wszystkie bledy o ktorych Oracle alarmuje :)
--
Jakub Wartak
http://vnull.pcnet.com.pl
suw...@gmail.com
( muszę jeszcze poczytać o mechanizmach odpowiedzialnych za
śledzenie).
Jeszcze jedno - jaką rolę / uprawnienia powinien posiadać użytkownik
aby uruchamiać śledzenie dla sesji/instancji ? bądź jak nadawać /
zabierać takie uprawnienia ?
Pozdrawiam
Jakub Wartak
Zdaje sie ze sesja musi miec "ALTER SESSION". Dodajesz odbierasz przez
GRANT/REVOKE. Zapomnialem ze *.trc jeszcze generuja tzw diagnostic events
czyli "ALTER SESSION SET EVENTS ...".
A zamiast ATLER SESSION SET SQL_TRACE=True sie powinno uzywac dla 10-tki:
DBMS_SESSION.SET_SQL_TRACE(TRUE);
Wydaje mi sie, ze zeby uzywac DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION() trzeba
byc polaczyonym z rola AS SYSDBA albo po prostu miec GRANT do EXECUTE na
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION i wywolywac przez
SYS.DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION.