Statystyki DBMS_STATS
MarcinP - 13-11-2006 00:43
Statystyki DBMS_STATS
Czesc,
na poczatek nie krzyczcie - duzo googlalem, i nie moglem znalezc
odpowiedzi na moje pytanie
Chcialbym, przy pomocy pakietu DBMS_STATS zebrac informacje o tym ile
czasu zajmuje wykonanie danych zapytan (dobrze byloby tez dowiedziec
sie ile blokow danych dane zapytanie przetwarza)
Przy pomocy dbms_stats stworzylem odpowiednia tabelke ktora przechowuje
statystyki, udalo mi sie nawet ja jakimis statystykami zapelnic
Jednak dane w tej tabelce sa nieczytelne.. nazwy kolumn nic mi nie
mowia..jak je odtworzyc w formie czytelnej ? moze potrzebne sa jakies
perspektywy o ktorych nie wiem ?
Pozdrawiam
Marcin
Michał Kuratczyk - 13-11-2006 00:43
MarcinP wrote:
> Chcialbym, przy pomocy pakietu DBMS_STATS zebrac informacje o tym ile
> czasu zajmuje wykonanie danych zapytan (dobrze byloby tez dowiedziec
> sie ile blokow danych dane zapytanie przetwarza)
Nic dziwnego, że nie znalazłeś jak to zrobić przy użyciu DBMS_STATS, bo on
nie do tego służy. DBMS_STATS.gather_* zbiera statystyki z obiektów, aby
optymalizator (CBO) miał wiedzę niezbędną mu do podejmowania właściwych
decyzji (wybierania właściwych planów zapytań).
Do zbierania czasów i przetwarzanych bloków służy przede wszystkim sql_trace
(alter session set sql_trace=true i potem 'tkprof plik.trc plik.prf', gdzie
plik.trc, to utworzony po stronie serwera plik trace). Nieco prostszym w
użyciu narzędziem jest autotrace ('set autotrace traceonly' w sqlplus),
który pokazuje plan zapytania i pewne statystyki (m.in. liczbę odczytanych
bloków). Do tego możesz zrobić 'set timing on' i będziesz miał czas
(zegarowy, mało precyzyjny, ale dający pojęcie). sql_trace daje Ci znacznie
więcej informacji - np bardzo przydatne informacje o wait events, czyli ile
czasu i na co czekała sesja w czasie gdy była śledzona (można dzięki temu
wykryć rywalizację o dostęp do danych, przeciążenie I/O, nadużywanie
latches i wiele innych).
Uwaga: plan zapytania pokazywany przez autotrace i właściwie chyba wszystkie
inne narzędzia poza sql_trace jest planem PRZEWIDYWANYM, a czasem zdarza
się, że faktycznie zapytanie wykonywane jest według innego planu. Ten
prawdziwy, faktyczny, sprawdzisz zawsze w pliku .trc. Podobnie wartości,
które widzisz w planie autotrace i podobnych (a najciekawszą z nich jest
cardinality) są szacunkami na podstawie statystyk (zebranych wcześniej
przez DBMS_STATS), a nie faktycznymi wartościami, które zaszły/zajdą.
Porównując cardinality z planu wyświetlanego przez autotrace z danymi
z pliku .trc można często znaleźć odpowiedź na pytanie "czemu ten cholerny
Oracle wybiera ten plan a nie inny?!" (w autotrace widzisz czego się
spodziewał, a w trc co zastał - jeśli są jakieś istotne różnice, to znaczy,
że szacunki były złe, zazwyczaj z powodu kiepskich lub nieaktualnych
statystyk).
--
Michał Kuratczyk
dap - 13-11-2006 00:43
Hej,
uzyj Statspacka ktory bedzie zbieral informacje co godzine.
Dla linucha...
sqlplus "/ as sysdba"
@?/rdbms/admin/spcreate
@?/rdbms/admin/spauto
dbms_stats gromadzi informacje o schematach oraz o tym jak szybka jest
Twoja baza.
dap
--
,= ,-_-. =. gnu.org
((_/)o o(\_)) polanski.biz
`-'(. .)`-' xoops.pl
\_/
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
mysql, statystykl, jak wyciagnac dane rozkladu czasu ze wzgledu na okres pelnych godzin
statystyka =?ISO-8859-2?Q?uprawnie=F1_w_oracle_10g?=
[php+MySQL] baza + statystyka
jak zrobic statystyki narastajace do daty?
[MySql] prosta statystyka dzienna
Statystyki w nowym panelu
Statystyki piłkarskie
Statystyki dla Informixa
Statystyki w Postgresie
Projekt, przykłady dobrych specyfikacji, itd
zanotowane.pldoc.pisz.plpdf.pisz.plshutter.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
