|
MarkoBalkan
Član broj: 141124
Poruke: 1624
..133.247-dsl.net.metronet.hr.
|
napravio sam Materialized view koji se refresha na comit.
ovo je home proba.
napravio sam tablicu proizvodi i tablicu računi.
u tablicu računi se unosi ID_računi, ID_proizvod i količina.
tablica proizvodi sadrži -> ID_proizvod, ime_proizvoda i jedinicna_cijena.
a query za Materialized view je:
SELECT PROIZVODI.ID,PROIZVODI.IME,sum(RACUNI.KOLICINA), sum(PROIZVODI.CIJENA*RACUNI.KOLICINA) AS UKUPNO FROM PROIZVODI,RACUNI WHERE
PROIZVODI.ID=RACUNI.ID_PROIZVODI GROUP BY PROIZVODI.ID,PROIZVODI.IME
dobijem slijedeće podatke -> ID_Proizvoda, ime, sum(kolicina), ukupna_cijena
za svaki proizvod dobijem sumarnu kolicinu i ukupnu cijenu.
mene zanima, kako u praksi to radi kad imamo nekoliko vezanih tablica u Materialized view i imamo velik broj inserata (za svaki insert ili nekoliko njih se radi comit ili kako je već riješeno?
napominjem ovo je bilo samo za probu doma.
|
|
|
| |
|
|
nebojsa_1
DBA
Kanada
Član broj: 213216
Poruke: 19
199.166.15.*
|
Za bilo koju ozbiljnu implementaciju sa vise od jednim korisnikom na bazi ovo resenje je vrlo lose.
Svaka transakcija koja menja neku od ove dve tabele trajace duze , Dok se ne izvrsi select i izmeni mview.
Takodje imaces ozbiljene probleme sa zakljucavanjem slogova u mview-u.
|
|
|
| |
|
|
MarkoBalkan
Član broj: 141124
Poruke: 1624
..131.113-dsl.net.metronet.hr.
|
pa zar se vrijednosti ne čuvaju fizički, a ako se nešto ubaci u bazu automatski se mv refresh-a tj pribroje se samo nove vrijednosti?
|
|
|
| |
|
|
nebojsa_1
DBA
Kanada
Član broj: 213216
Poruke: 19
199.166.14.*
|
Postoje dve mogucnost da se mview updatuje
Jedna je fast refresh koji zahteva da se kreira mview log i druga je komplean refresh.
Iz sintakse se ne vidi da je log kreiran pa sam pretpostavio da ce biti komplean refresh.
Ako se kreira odgovarajuci log koji ce omoguciti fast refresh ovog vewa tada ce perfromanse ce biti bolje ali opet
ovo resenje nije preporucljivo za OLTP.
Kad god se unese racun i zada commit izvrsice se update ovog mviewa i to ce produziti vreme za commit transakcije.
Tu je i problem sa zakljucavanjem.
Za svaku robu postojace jedan red u mview-u. Ako recimo 2 korisnika unesu istu robu u racun pri izvrsenju commita oni ce pokusati
da zakljucaju isti rekord u mviewu. Jedna transakcija ce morati da ceka da se druga zavrsi.
Zato ovakva resenja i nisu preporucljiva za OLTP.
Ako je broj korisnika mali tj. nikad vise od 1-2 ne unosi fakturu u isto vreme onda ovo moze i da prodje.
Postoji i prost test.
Napravi skript koji unosi nekoliko faktura sa istim robama pa otvori 1, 2, 3, 5 sesije u isto vreme i izvrsi skript.
Uradi to isto i bez mviewa.
Uporedi vremena izvrsavanja.
|
|
|
| |
|
|
MarkoBalkan
Član broj: 141124
Poruke: 1624
..4.129.8-dsl.net.metronet.hr.
|
a dali se mv koristi u praksi?
ako se koristi, na koji način se koristi i za šta?
|
|
|
| |
|
|
nebojsa_1
DBA
Kanada
Član broj: 213216
Poruke: 19
199.166.15.*
|
Postoje dva razlicita nacina koriscenaja mviewa
1. Za replikaciju podataka sa jedne baze na drugu.
2. U DS i DW sistemima za ubrzavanje kompleksnih upita.
(Nesto slicno tvom primeru)
Koriscenjem opcije Query Rewrite moze se vrsiti tuning aplikacija za koje se ne moze menjati upit.
(Iako upit referencira tabelu , oracle transparentno menja upit i koristi mview umesto tabele)
Ovo ne znaci da ne moze da se koristi i u OLTP ali se mora biti svestan nezeljenih efekata.
U tvom primeru , ako nije nepohodno da rezultat upita bude 100% tacan, mogao bi da napravis mview log da bi korisio fast refresh i da
radis refresh mviewa svakih 15 min.
Na taj nacin izbegao bi probleme sa zakljucavanjem a upit bi bio brz. (Naravno rezultat bi bio do 15 minuta stariji od stvarnih podataka)
|
|
|
| |
|
Materialized view i veliki broj inserta
