Oracle párhuzamos lekérdezések optimalizálása, skahin alexey

A lekérdezések felgyorsításának egyik legegyszerűbb módja azok elemzése.
Ez egyszerűen egyszerűen történik:
* Tipp
* A munkamenet beállítása révén:
- N számú szál

Elméletileg ez elég ahhoz, hogy felgyorsítsa a lekérdezést időnként.
De vannak olyan helyzetek, ahol a párhuzam az ellenkezője.

Először nézzük meg a terminológiát - nézzük meg a párhuzamos tervet, csatlakozzunk a 2 táblához:
- Kérelem 1

A T2 táblázat egy olyan tulajdonsággal rendelkezik, hogy az fk_id_skew egyenetlenül tele van és az 1 felé hajló - sokkal gyakoribb, mint mások.
- Kérelem 2

Szóval egy egyszerű lekérdezést tettem:
- Kérelem 3

* A regexp_replace ebben a lekérdezésben szükséges, hogy az adatok nincsenek azonnal kijelölve, és a CPU költségek láthatóak a statisztikában.
* Tippek beillesztése úgy, hogy a tervben szereplő lekérdezés pontosan úgy néz ki, mint itt.

Végrehajtási idő kérése = 49 másodperc.

Adja hozzá a párhuzamos párhuzamot (8), amely nem párhuzamos.
Futási idő = 8s. ez 6-szor gyorsabb.
A lekérdezési terv megértéséhez:
- Terv 1

Alapvető fázisok:
* PX BLOCK ITERATOR - az asztal olvasása több szálas részekben
* A PX SEND - 1 adatfolyam adatokat küld a másiknak. Fontos tudni, hogy csak egyetlen termelő (PX SEND) lehet aktív egyszerre, ami korlátozásokat a párhuzamos végrehajtás terve részletesebben: A második rész az adatok eloszlása ​​a párhuzamos lekérdezés
** RANGE - az adatok tartományokra oszthatók (gyakran rendezve)
** HASH - a hash (hash join, csoportonként) adatbázisa
** RANDOM - véletlenszerű küldés
** KÖZVETÍTÉS - küldünk a táblázatot, hogy minden folyót (. Gyakran egy kis asztal, együtt az azt követő körmérkőzéses táblázat jobb lehet egy előadás kérdés, ha a táblázat bal sokkal nagyobb, mint azt a statisztika, mivel az adatok duplikált minden stream)
** ROUND ROBIN - az adatokat a körfolyamatokba küldjük

Az áramlási adatok megosztásának módjairól külön kell beszélni:

Érdemes megjegyezni, hogy az adatokat a sor oszlopokban lévő értékek, és nem csak a sorok sorolja fel.
Erre azért van szükség, hogy a különböző táblázatokból származó adatok ugyanazon adatkategóriájába illeszkedjenek egy csatlakozási szál.
Ha az Oracle ezt nem tette meg, akkor teljesen különböző adatok juthatnak az 1 szálba, és a csatlakozás nem sikerült.
Ezt érdemes figyelni, mivel ez lehet az oka annak, hogy lassítja a párhuzamos lekérdezés végrehajtását erős adatáteresztés esetén (A párhuzamos lekérdezések összefűzésének okairól)

** P-> P - az egyik párhuzamos csoportból származó adatok átkerülnek egy másik párhuzamos csoportba
** P-> S - a szekvenciális végrehajtással párhuzamosan (a lekérdezés szűk keresztmetszete vagy vége a második, a párhuzamos lekérdezés lelassításának legfontosabb oka)
** PCWP - párhuzamosan a szülővel: szkennelje be a táblát és azonnal csatlakozzon egy másikhoz
** PCWC - éppen ellenkezőleg: a szűrőt áthelyezzük a külső áramról és alkalmazzuk a vizsgálat során
* PX RECEIVE - adatátvitel egy párhuzamos adatfolyamról a másikra
* PX SEND QC - küld adatokat a koordinátornak
* PX COORDINATOR - minden párhuzamos kérés vevõje
* TQ - Áramlási szám

1. Rendezvényterv jelenlétében "P-> S - párhuzamos a sorozatos végrehajtással", kivéve a "PX COORDINATOR"
Ez azt mondja, hogy az Oracle-nek az összes szálat ugyanabban a sorrendben kellett összegyűjtenie, ami a szűk keresztmetszetet a többiek számára a leghosszabb áramlásra várt.

Példát adok a rownumnak. Adja hozzá a vonalszám kiválasztását az egyes táblázatokból:
A terv megváltozott,
* Kiszámításához COUNT rownum párhuzamos folyamat tábla olvasható a lemez „PX BLOCK Iterátor” sorakoznak „P-> S”, amely tagadja az összes perimeschustvo elosztott olvasás.
* A JOIN nem egy külön menetben (: TQ10002)
mert mindkét patak már soros adatkészletré alakult át, és nem használható egyszerre.
Ennek következtében a lekérdezés végrehajtási ideje a nem párhuzamos változathoz (49 s) még hosszabb (51 másodperc) lett, a felesleges párhuzamosítási költségek miatt, amelyeket nem használtak

2. PX SEND ferde - Adattömörítés
amikor az adatfolyamok egyike az adatfolyamok egyikébe kerül.

Mutassa be ezt egyszerűen a korábban létrehozott ferde oszlop t_2.fk_id_skew használatával.

Ha futtatja a lekérdezést, használja a csatlakozási táblák feltételeit: t_2.fk_id_skew = t_1.id
Hogy a párhuzamos lekérdezés általános terve nem változik (lásd 1. terv), de itt a végrehajtási idő 38-ra emelkedik.

Ennek az az oka, hogy a t_2.fk_id_skew oszlop 1.500.000 értéket tartalmaz = 1 és 3.500.000 más. És amikor a "PX SEND HASH" végrehajtása megtörténik, akkor a táblázatok többsége egyetlen szálba kerül a feldolgozáshoz, ahelyett, hogy egyenletesen elosztott lenne.

1. ábra - A lekérdezés legnagyobb része egy szálon hajtódott végre, a többi szál várt rá.

Ábra. 2. - Ugyanez igazolható a PARALLEL lapon: a teljes idő 37c, 1 menet működik.

Az Oracle helyes, mert Nem adhat hozzá adatokat különböző tartományokból.

Összehasonlításképpen megjelenés végrehajtási statisztikák erősen párhuzamosított kérelem (1. minta) azzal a feltétellel nélkül gyűrődéseket t_2.fk_id_uniform = t_1.id

Mindent 8 szálon végeztünk, és mindegyik szál egyenletesen feldolgozta egyenlő részét.

3. Bloom szűrők
Anélkül, hogy a virágzó szűrő bit vektorok létrehozásának mechanikájába lépnék, bemutatom az előnyök használatát.
Példa lekérdezés:
1. A T1 táblázatban szűrővel ("T1", "MOD" = 42) "létrehoz egy virágszűrőt - PX JOIN FILTER CREATE
2. Az 1. tétel szűrője a T2-PX JOIN FILTER USE Táblázatra vonatkozik
Ez korlátozza a megfelelő táblázat méretét.
3. A T2 szűrt táblázat a HASH JOIN BUFFERED-hez van csatlakoztatva
Részletes leírás virágos szűrő: Bloom szűrő

virágzó szűrő jó:
* Párhuzamos kérések - a szálak közötti továbbított adatok száma csökken a jobb oldali táblázat előszűrése miatt
* RAC rendszerek - csökkenti a hálózati adatok számát a csomópontok között
* InMemory táblák - az inmemory táblázatos előszűrés végrehajtása és a nem figyelmen kívül hagyható csatlakozás végrehajtása egy gyorsan szűrett jobb oldali táblán

4. Partíció Bölcs
Általában ez hasonló az előző ponthoz, de a szűrő a jobb oldali táblaterületen helyezkedik el, és csökkenti a vizsgálatokat.
Kifejezésekkel kifejezve:
* PART JOIN FILTER CREATE (: BF0000) - Hozzon létre egy szűrőt a bal oldali táblán
* Pstart Pstop =: BF0000 |: BF0000 - szűrő alkalmazás a jobb oldali PCWC leolvasási műveletben