[Oracle] brak danych w sql_plan dla SELECT
Piotr Grzegrzolka - 14-02-2006 09:37
[Oracle] brak danych w sql_plan dla SELECT
Witam,
mam taki problem: przez wiele kilkanaście tygodni były gromadzone dane m.in. z
v$plan_table o wykorzystaniu obiektów. Na tej podstawie usunęliśmy w ubiegłym
tygodniu indeksy nie wykorzystywane w naszej bazie (Oracle 9.2.0.5). Ale w
niedzielę uruchomił się job (z konta SYS) i zadanie to wykonuje się do chwili
obecnej (normalnie kończyło się po 1-3 godzinach) - czytana jest cała tabela.
W tej chwili wykonuje się zapytanie:
select /*+ all_rows */ count(1) from "USER"."JAKAS_TABELA" where "ID" = :1
Na tej kolumnie był założony indeks "ID_FK", który w ubiegłym tygodniu
usunęlismy. Okazuje się, że tego selecta (a właściwie jego planu zapytania)
nie ma w widoku sys.v$sql_plan...
Czy ktoś ma pomysł, czym to jest spowodowane?
Dziękuję bardzo,
Piotr Grzegrzółka
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
news997 - 15-02-2006 09:43
> Witam,
>
> mam taki problem: przez wiele kilkanaście tygodni były gromadzone dane
> m.in. z
> v$plan_table o wykorzystaniu obiektów. Na tej podstawie usunęliśmy w
> ubiegłym
> tygodniu indeksy nie wykorzystywane w naszej bazie (Oracle 9.2.0.5). Ale w
> niedzielę uruchomił się job (z konta SYS) i zadanie to wykonuje się do
> chwili
> obecnej (normalnie kończyło się po 1-3 godzinach) - czytana jest cała
> tabela.
> W tej chwili wykonuje się zapytanie:
> select /*+ all_rows */ count(1) from "USER"."JAKAS_TABELA" where "ID"
> = :1
> Na tej kolumnie był założony indeks "ID_FK", który w ubiegłym tygodniu
> usunęlismy. Okazuje się, że tego selecta (a właściwie jego planu
> zapytania)
> nie ma w widoku sys.v$sql_plan...
> Czy ktoś ma pomysł, czym to jest spowodowane?
>
> Dziękuję bardzo,
>
> Piotr Grzegrzółka
Nie za bardzo rozumiem o co Ci dokladnie chodzi, ale moje 3 grosze...
ID_FK - to prawdopodobnie klucz obcy a te pod oraclem nie sa standardowo
indeksowanie, wiec takie indeksy lepiej zostawic w spokoju. Przy laczeniu
tabela1.PK -> tabela2.FK - tabela2 jest dla kazdego rekodu z tabeli1
skanowana w calosci. (Zwykle)
Jesli potrzebujesz plan selecta to:
explan plan for
select /*+ all_rows */ count(1) from "USER"."JAKAS_TABELA" where "ID" = :1
;
a nastepnie
select * from table(dbms_xplan.display) ;
Co do gromadzenie informacji o wykorzystywanych indeksach, toz tego co
pamietam plan do zapytania jest generowany nawet przy takim explain, a nie
tylko i wylacznie gdy zapytanie jest wykonywane. Dlatego poleganie tylko na
informacjach zawartych w v$sql_plan czy innych wewnetrznych Oracle moze byc
troche mylace. Ja raczej preferuje metode zrozumienia aplikacji i recznego
usuwania indeksow.
dap
--
polanski.biz
Piotr Grzegrzolka - 15-02-2006 09:43
news997 <news997@gazeta.pl> napisał(a):
> Nie za bardzo rozumiem o co Ci dokladnie chodzi, ale moje 3 grosze...
Każdy SELECT (i inne klauzule) powinien mieć ślad (m.in. w postaci treści
polecenia w widoku v$sqltext oraz planu wykonania w widoku v$sql_plan). A
ponieważ nie mam tych danych, bardzo się dziwię :-0
> ID_FK - to prawdopodobnie klucz obcy a te pod oraclem nie sa standardowo
> indeksowanie, wiec takie indeksy lepiej zostawic w spokoju. Przy laczeniu
> tabela1.PK -> tabela2.FK - tabela2 jest dla kazdego rekodu z tabeli1
> skanowana w calosci. (Zwykle)
Zamiarem zbierania statystyk dot. wykorzystania obiektów było usunięcie
nieużywanych indeksów (właśnie takich, dla których nie ma wpisów do widoku
v$sql_plan) - jednakże nie chciałem korzystać z klauzuli MONITORING (lub coś
takiego w ALTER INDEX)
> Jesli potrzebujesz plan selecta to:
> explan plan for
> select /*+ all_rows */ count(1) from "USER"."JAKAS_TABELA" where "ID" = :1
> ;
> a nastepnie
> select * from table(dbms_xplan.display) ;
W pracy korzystam z SQL Navogatora, któy ma m.in. możliwośc pokazania
graficznego planu zapytania ...
> Co do gromadzenie informacji o wykorzystywanych indeksach, toz tego co
> pamietam plan do zapytania jest generowany nawet przy takim explain, a nie
> tylko i wylacznie gdy zapytanie jest wykonywane. Dlatego poleganie tylko na
> informacjach zawartych w v$sql_plan czy innych wewnetrznych Oracle moze byc
> troche mylace. Ja raczej preferuje metode zrozumienia aplikacji i recznego
> usuwania indeksow.
Myślę, że na "podstawowych" widokach takich jak v$sql_plan czy v$sqltext można
w zupełności polegać (co innego widoki np. EXU8PHS, EXU9XDBUID,...).
Aplikacja nam sie rozrosła (sami ją rozwijamy), indeksy zajmują więcej GB niż
dane (baza OLTP). W takiej sytuacji, po zbadaniu indeksów, chcielismy usunąć
te nieużywane. A tu taki klops....
Pozdrawiam,
Piotr Grzegrzółka
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
news997 - 15-02-2006 09:43
----- Original Message -----
From: "Piotr Grzegrzolka" <piotrgrz@gazeta.SKASUJ-TO.pl>
Newsgroups: pl.comp.bazy-danych
Sent: Wednesday, February 15, 2006 9:57 AM
Subject: Re: [Oracle] brak danych w sql_plan dla SELECT
> news997 <news997@gazeta.pl> napisał(a):
>
>> Nie za bardzo rozumiem o co Ci dokladnie chodzi, ale moje 3 grosze...
> Każdy SELECT (i inne klauzule) powinien mieć ślad (m.in. w postaci treści
> polecenia w widoku v$sqltext oraz planu wykonania w widoku v$sql_plan). A
> ponieważ nie mam tych danych, bardzo się dziwię :-0
Czyli pytanie jest taki, kiedy znika plan wykonania zapytania z pamieci?
Na pewno po restarcie oraz po wykasowaniu zawartosci shared_pool.
>> Co do gromadzenie informacji o wykorzystywanych indeksach, toz tego co
>> pamietam plan do zapytania jest generowany nawet przy takim explain, a
>> nie
>> tylko i wylacznie gdy zapytanie jest wykonywane. Dlatego poleganie tylko
>> na
>> informacjach zawartych w v$sql_plan czy innych wewnetrznych Oracle moze
>> byc
>> troche mylace. Ja raczej preferuje metode zrozumienia aplikacji i
>> recznego
>> usuwania indeksow.
> Myślę, że na "podstawowych" widokach takich jak v$sql_plan czy v$sqltext
> można
> w zupełności polegać (co innego widoki np. EXU8PHS, EXU9XDBUID,...).
> Aplikacja nam sie rozrosła (sami ją rozwijamy), indeksy zajmują więcej GB
> niż
> dane (baza OLTP). W takiej sytuacji, po zbadaniu indeksów, chcielismy
> usunąć
> te nieużywane. A tu taki klops....
Hmm... skasuj moze (po wczesniejszej analizie) te najwieksze objetosciowo.
dap
Piotr Grzegrzolka - 16-02-2006 10:04
news997 <news997@gazeta.pl> napisał(a):
> Czyli pytanie jest taki, kiedy znika plan wykonania zapytania z pamieci?
> Na pewno po restarcie oraz po wykasowaniu zawartosci shared_pool.
Tak, ale obie sytuacje nie miały miejsca (na 100%).
Problem polega na tym, że dla tego samego joba (nie był modyfikowany przez
kilkanaście tygodni) [korzysta on wyłącznie z jednego pakietu, który tez nie
był modyfikowany w tym czasie]:
-) przez kilka (naście) ostatnch tygodni job wykonuje się sprawnie (max 1-3
godziny), nie widac wykorzystania indeksu ID_FK w v$sql_plan,
-) w ostania niedzielę po usunięciu indeksu job działał ponad 24 godziny (i
wtedy wycięliśmy sesję) - wtedy w v$session widać było hash_value dla tego
SELECT-a,
-) po założeniu indeksu job wykonał się w 15-20 minut, ale jak sprawdzaliśmy
chwilę po zakończeniu jego działania, nie było wierszy związanych z tym
SELECT-em ani w v$sql_plan ani w v$sqltext...
> Hmm... skasuj moze (po wczesniejszej analizie) te najwieksze objetosciowo.
Zbieranie tych informacji miało byc analizą...
Pozdrawiam,
Piotr Grzegrzółka
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Lucyna Witkowska - 16-02-2006 10:04
Piotr Grzegrzolka <piotrgrz@gazeta.skasuj-to.pl> napisał:
> -) po założeniu indeksu job wykonał się w 15-20 minut, ale jak sprawdzaliśmy
> chwilę po zakończeniu jego działania, nie było wierszy związanych z tym
> SELECT-em ani w v$sql_plan ani w v$sqltext...
Szkoda, ze nie sprawdziliscie w trakcie wykonywania. Byc moze po prostu
sql wylecial juz z shared pool.
> > Hmm... skasuj moze (po wczesniejszej analizie) te najwieksze objetosciowo.
> Zbieranie tych informacji miało byc analizą...
Dla pocieszenia ;-) - w systemie jak najbardziej OLTP, z aplikacją
napisana przez amerykanska firmę, indeksy też zajmują wiecej miejsca niz dane.
Pozdrowienia,
LW
Piotr Grzegrzolka - 16-02-2006 10:05
Lucyna Witkowska <ypwitkow@nospamcyf-kr.edu.pl> napisał(a):
> Szkoda, ze nie sprawdziliscie w trakcie wykonywania. Byc moze po prostu
> sql wylecial juz z shared pool.
SQL nie "wyleciał" - w zbieranych przez nas danych (np. z widoku v$sqlarea)
mam m.in. selecty, które mają wcześniejsze first_load_time niż SELECT-y z tego
joba (dodatkowo i jedne i drugie mają wartość kolumny 'load' =1). Tak więc
sądzę, że dane nie mogły "wylecieć"...
Piotr Grzegrzółka
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
news997 - 16-02-2006 10:05
"Piotr Grzegrzolka" <piotrgrz@gazeta.SKASUJ-TO.pl> schrieb im Newsbeitrag
news:dsv7s5$6k5$1@inews.gazeta.pl...
> Lucyna Witkowska <ypwitkow@nospamcyf-kr.edu.pl> napisał(a):
>
>> Szkoda, ze nie sprawdziliscie w trakcie wykonywania. Byc moze po prostu
>> sql wylecial juz z shared pool.
> SQL nie "wyleciał" - w zbieranych przez nas danych (np. z widoku
> v$sqlarea)
> mam m.in. selecty, które mają wcześniejsze first_load_time niż SELECT-y z
> tego
> joba (dodatkowo i jedne i drugie mają wartość kolumny 'load' =1). Tak więc
> sądzę, że dane nie mogły "wylecieć"...
A wlaczales trace? Bo przypomniam sobie jak jeden ekspert opowiadal, ze
wlaczenia trace zmienia plan wykonania. Jeszcze to sprawdze.
dap
--
polanski.biz
xoops.pl
Piotr Grzegrzolka - 16-02-2006 10:05
news997 <news997@gazeta.pl> napisał(a):
> > Tak więc
> > sądzę, że dane nie mogły "wylecieć"...
> A wlaczales trace? Bo przypomniam sobie jak jeden ekspert opowiadal, ze
> wlaczenia trace zmienia plan wykonania. Jeszcze to sprawdze.
Trace nie jest włączony.
Kod joba jest prosty "begin uruchom_zadanie; end;".
Piotr Grezgrzółka
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle 19g +Insert +Insert +Insert...
[oracle] zapytanie dynamiczne z =?ISO-8859-2?Q?=22dynamiczn=B1_?==?ISO-8859-2?Q?nazw=B1_tabeli=22?=
[Oracle] jak =?ISO-8859-2?Q?ograniczy=E6_pami=EA=E6_dla_se?==?ISO-8859-2?Q?rwera=3F?=
jak to =?ISO-8859-2?Q?zrobi=E6=2E=2E=2E=3F_TSQL_sql_server?==?ISO-8859-2?Q?_?=
[oracle] czy da =?ISO-8859-2?Q?si=EA_z_poziomu_procedury_?==?ISO-8859-2?Q?zrobi=E6_kopi=EA_zapasow=B1=3F?=
[oracle 10g] czy =?ISO-8859-2?Q?mo=BFna_wy=B3=B1czy=E6_wszys?==?ISO-8859-2?Q?tkie_wi=EAzy_w_schemacie=3F?=
MSSQL Express czy Oracle Express
=?iso-8859-2?q?[oracle]_Jak_sprawdzi=E6_wielko=B6=E6_tabeli_=3F=3F?=
=?ISO-8859-2?Q?Poszukjue_ksi=B1=BFki_"Oracle_?= =?ISO-8859-2?Q?optymalizacja_wydajno=B6ci"..?=
[Oracle] =?ISO-8859-2?Q?=A3=B1czenie_wierszy_z_zapytania_?==?ISO-8859-2?Q?w_jeden_string?=
zanotowane.pldoc.pisz.plpdf.pisz.plmisida.pev.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 |
|
