GoldenLine
Zaloguj się
Irek Słonina

Irek Słonina programowanie, bazy
danych i linuksy

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Oracle 11g.

Mam taki kod:


SELECT

    kol1, kol2

FROM jebucko_duzo_danych a

JOIN tu_tez_niemalo b ON (a.klucz1=b.klucz1)


czas wykonania: 0.1s

który sobie łączę w joinie:



SELECT kol1, kol2, ccc

FROM bardzo_duza_tabelka bdt

LEFT JOIN (

    SELECT

        kol1, kol2

    FROM jebucko_duzo_danych a

    JOIN tu_tez_niemalo b ON (a.klucz1=b.klucz1)

) xxx ON (bdt.kol1 = xxx.kol1)


czas wykonania: 40s


jesli dla testu sobie to pierwsze, małe zapytanie zmaterializuje:


create materialized view widok_material

AS

    SELECT

        kol1, kol2

    FROM jebucko_duzo_danych a

    JOIN tu_tez_niemalo b ON (a.klucz1=b.klucz1)


i przerobię to problemowe zapytanie na:



SELECT kol1, kol2, ccc

FROM bardzo_duza_tabelka bdt

LEFT JOIN widok_material ON (bdt.kol1 = xxx.kol1)


czas wykonania: 2s
^^^ ten czas jest bardzo przyzwoity jak na moje potrzeby.

Mój skromny wniosek: Oracle przelicza małe to podzapytanie
dla każdego wiersza, z którym jest złączany.

Pytanie konkursowe: jak kazać Oracle'owi żeby wykonał
to tylko raz? Są na to jakieś magiczne zaklęcia?
Link do wypowiedziLink
Grzegorz G.

Grzegorz G. ASE / Systems
Architect, Syniverse

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Albo jakiś hint odnośnie planu zapytania, albo może subquery factoring - względnie z hintem /*+ materialized */ (lub czymkolwiek jak rownum żeby to się zmaterializowało)?

EDIT: Albo statystyki jakieś nieświeże / nieprawdziwe? Może wrzuć plany dla wszystkich trzech zapytań i się dojdzie czemu?Grzegorz G. edytował(a) ten post dnia 19.02.10 o godzinie 14:10
Link do wypowiedziLink
Irek Słonina

Irek Słonina programowanie, bazy
danych i linuksy

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...



WITH

pseudowidok_material AS (

    SELECT /*+ materialize */

        kol1, kol2

    FROM jebucko_duzo_danych a

    JOIN tu_tez_niemalo b ON (a.klucz1=b.klucz1)

)

SELECT kol1, kol2, ccc

FROM bardzo_duza_tabelka bdt

LEFT JOIN pseudowidok_material xxx ON (bdt.kol1 = xxx.kol1)


Daje mi moje upragnione 2s. Dzięki!
Prawdziwe zapytanie składa się z parunastu tabel, boję się tak na szybko ruszać ich statystyki. /*+ materialize */ rozwiązuje mój problem.
Link do wypowiedziLink
Grzegorz G.

Grzegorz G. ASE / Systems
Architect, Syniverse

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Żeby później na mnie nie było że to jednak głupi pomysł ;-) - coś tam pamiętam, że /*+ materialize */ jest (a może było w 9i/10g?) hintem nieudokumentowanym; z tego co kojarzę to można to samo uzyskać wrzucając rownum do listy kolumn. Ale może mi się z czymś pomyliło.
Link do wypowiedziLink
Izabela Korzińska

Izabela Korzińska Architekt /
Developer ETL/TEam
Leader, Roche Polska

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Grzegorz G.:
Albo jakiś hint odnośnie planu zapytania, albo może subquery factoring - względnie z hintem /*+ materialized */ (lub czymkolwiek jak rownum żeby to się zmaterializowało)?

Dzięki :)
Rozwiązałeś mój częsty problem, o którym nie wiedziałam, że go mam :)

To niby nic nie wnoszący do wątku tekst, ale nie mogłam się powstrzymać, żeby nie podziękować. Odkąd odkryłam hinty, sporo przyspieszyłam niektóre zapytania. O materialized nie wiedziałam. Ten będzie moim ulubionym. W ogóle chyba się zaraz rozejrzę po necie w sprawie całej reszty hintów. Jeszcze raz thx.
Link do wypowiedziLink
Irek Słonina

Irek Słonina programowanie, bazy
danych i linuksy

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Grzegorz G.:
Żeby później na mnie nie było że to jednak głupi pomysł ;-) - coś tam pamiętam, że /*+ materialize */ jest (a może było w 9i/10g?) hintem nieudokumentowanym; z tego co kojarzę to można to samo uzyskać wrzucając rownum do listy kolumn. Ale może mi się z czymś pomyliło.

Rzeczywiście, dodanie rownum daje taki sam - szybki efekt wykonania zapytania, podobnie do materialized.

Dziwną sprawą jest, że jeśli próbuję wynik selecta wrzucić do tabeli tymczasowej to wraca długi czas wykonywania zapytania. Tylko użycie prawdziwego zmaterializowanego widoku daje szybkie wykonanie zapytania.
To takie tylko narzekanie, w tym wypadku nie jest to dla mnie problem.
Link do wypowiedziLink
Grzegorz G.

Grzegorz G. ASE / Systems
Architect, Syniverse

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Co do rownum, to efekt jest ten sam, bo zapytanie musi się zmaterializować żeby go poprawnie wyliczyć.

Co do tej tabeli, to dziwne, nie rozumiem; subquery factoring ląduje w temporary tablespace i w tym bym się doszukiwał przewagi, no ale jak tworzysz snapshot to prawdopodobnie ląduje w podobnym miejscu co tabela...Dziwne. Może w jakiś magiczny sposób Oracle jak wie co to (czyli factoring / snapshot - oba oparte explicite na zapytaniu) to wie co z tym zrobić, a jak tabela to nie ma pojęcia? Próbowałeś pozbierać statystyki dla tej tymczasowej tabeli? Bo indeks to już pewnie byłoby oszustwo ;-).

Co do hintów generalnie, to ja nie lubię, nie używam, i złoszczę się jak ktoś używa ;-). Powinno dobrze działać i bez hinta, no chyba, że z jakichś względów musisz dostarczyć Oracle'owi informację, którą skądinąd masz, a on nie ma prawa jej mieć. Przykładowo ładowałaś jakieś tymczasowe tabelki, wiesz ile wierszy tam jest (np. z sql%rowcount), nie ma sensu zbierać na nich statystyk (bo zaraz je struncate'ujesz) i używasz /*+ cardinality */.
Hinty są ok, żeby np. sprawdzić na szybko czy coś zadziała lepiej na innym planie wykonania - ale do systemu live to raczej nie. Być może to tylko osobista preferencja, ale np. wrzucanie hintów odnośnie planu wykonania (z serii /*+ nested loops */ /*+ use_hash */ /*+ index */) to lipa trochę, bo przy różnej zawartości tabelek różne plany mogą okazywać się optymalne. W sumie po to jest CBO no nie? :-)
Link do wypowiedziLink
Jacek Tomaka

Jacek Tomaka AWK!

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

BTW: Ile to jest "jebucko dużo danych" ?
Link do wypowiedziLink
Irek Słonina

Irek Słonina programowanie, bazy
danych i linuksy

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Jacek Tomaka:
BTW: Ile to jest "jebucko dużo danych" ?

Diabeł złapał Polaka Niemca i Ruska i mówi
- Kto poda odległość której ja nie znam Ten wyjdzie na wolność
Pierwszy mówi Rusek
- 5km
- E tam znam
Na to Niemiec
- 50km
E tam znam
Polak zastanawia się chwile i mówi
-W chuj
Na to diabeł
- No nie znam takiej odległości możesz wyjść
Polak idzie zadowolony gdy nagle dogania go diabeł
i pyta
- Polak gdzie to w chuj dokładnie jest.
- Widzisz to drzewo?- pyta Polak
-Widze
-No to jeszcze w pizdu dalejIrek Słonina edytował(a) ten post dnia 24.02.10 o godzinie 00:24
Link do wypowiedziLink
Jacek Tomaka

Jacek Tomaka AWK!

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

;) Pytalem powaznie.
Bo wydaje mi sie, ze jakby bylo "jebucko duzo danych" to taka materializacja by sie nie skonczyla. Wiec pewnie to sa tysiace krotek raczej niz miliony.
Link do wypowiedziLink
Marcin Badtke

Marcin Badtke Administrator Baz
Danych, Citibank
Europe plc

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Irek Słonina:


WITH

pseudowidok_material AS (

    SELECT /*+ materialize */

        kol1, kol2

    FROM jebucko_duzo_danych a

    JOIN tu_tez_niemalo b ON (a.klucz1=b.klucz1)

)

SELECT kol1, kol2, ccc

FROM bardzo_duza_tabelka bdt

LEFT JOIN pseudowidok_material xxx ON (bdt.kol1 = xxx.kol1)


Daje mi moje upragnione 2s. Dzięki!
Prawdziwe zapytanie składa się z parunastu tabel, boję się tak na szybko ruszać ich statystyki. /*+ materialize */ rozwiązuje mój problem.

Cieszę się, że udało się rozwiązać problem, ale...
1. hint powoduje niejawne utworzenie tymczasowej tabeli tylko na czas wykonania zapytania
2. pytanie jak często i przez ile równoczesnych sesji zapytanie będzie wykonywane ?
3. jak duża jest zmaterializowana tabela ?

Pytam bo rozwiązanie z którego jesteś taki zadowolony powoduje zwiększone użycie przestrzenie temp. Jeśli wolumen danych jest duży na dodatek pomnożony przez dużą ilość równoczesnych sesji to możesz zabić serwer bazy danych. Może warto zerknąć na plany zapytań i statystyki aby Oracle sam wybrał właściwy plan ? Albo zmaterializować widok raz na jakiś czas aby wiele sesji mogło korzystać i nie musiało generować go dla siebie ?

Istnieje spora szansa, że 40s miałeś dlatego, że gdzieś pojawił się full scan.
Link do wypowiedziLink
Łukasz Kwietniewski

Łukasz Kwietniewski Projektant
techniczny,
specjalista

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Jacek Tomaka:
BTW: Ile to jest "jebucko dużo danych" ?
mały offtop:
zapewne pierdylion* rekordów
Link do wypowiedziLink

konto usunięte

Temat: [Oracle11g] Podzapytanie w JOINie przeliczane ponownie...

Takie naiwne pytanie do autora wątku - w pierwszym przykładzie nie uważasz przypadkiem "wykonania zapytania" za to samo co "wyświetlenie pierwszych wyników" ? :>

Bo dla mnie sam FTS na jebucko_duzo_danych nie może trwać 0,1 s. (chyba, że mamy różne pojęcie o dużej ilości danych ;)).

Pozdrawiam,
IP
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj