Plan - vysvetlenie

[Stanislav Hruška]

Povedal som si, že som už dosť veľký nato, aby som sa na to pozrel. Mám pre daný dopyt dva druhy skenovania:

• Unigue Scan - zásadne len na primárnych kľúčoch
• Range Scan (full match) - cudzie kľúče a môj index

Našťastie žiaden natural, či niečo podobné.
Rád by som vedel, v skratke, ako fungujú tieto dva skeny.
DEPOSITS má 16 740 000 záznamov. Najdlhšia tabuľka 4 650 záz. a dve so 4 000. Ostatné sú podstatne kratšie.
Predpokladám, že tu nemám šancu na nejaké zlepšenie/skrátenie času.
Ďakujem. Prikladám celý plán

Kód: [Vybrat]

    -> Sort (record length: 892, key length: 252)         -> Nested Loop Join (inner)
            -> Nested Loop Join (inner)
                -> Nested Loop Join (inner)
                    -> Filter
                        -> Hash Join (inner)
                            -> Aggregate
                                -> Sort (record length: 92, key length: 24)
                                    -> Nested Loop Join (inner)
                                        -> Filter
                                            -> Table "FOCS" as "P FO" Access By ID
                                                -> Bitmap
                                                    -> Index "FK_FOCS1" Range Scan (full match)
                                        -> Filter
                                            -> Table "DEPOSITS" as "P D" Access By ID
                                                -> Bitmap
                                                    -> Index "I_DEPOSITS_FP" Range Scan (full match)
                            -> Record Buffer (record length: 57)
                                -> Filter
                                    -> Aggregate
                                        -> Sort (record length: 92, key length: 24)
                                            -> Nested Loop Join (inner)
                                                -> Filter
                                                    -> Table "FOCS" as "C FO" Access By ID
                                                        -> Bitmap
                                                            -> Index "FK_FOCS1" Range Scan (full match)
                                                -> Filter
                                                    -> Table "DEPOSITS" as "C D" Access By ID
                                                        -> Bitmap
                                                            -> Index "I_DEPOSITS_FP" Range Scan (full match)
                    -> Nested Loop Join (inner)
                        -> Filter
                            -> Table "OWNER_FLAT" as "OWF" Access By ID
                                -> Bitmap
                                    -> Index "PK_OWNER_FLAT" Unique Scan
                        -> Filter
                            -> Table "DEPOSITS" as "D" Access By ID
                                -> Bitmap And
                                    -> Bitmap
                                        -> Index "FK_DEPOSIT_OWF" Range Scan (full match)
                                    -> Bitmap
                                        -> Index "I_DEPOSITS_FP" Range Scan (full match)
                        -> Filter
                            -> Table "FOCS" as "FO" Access By ID
                                -> Bitmap
                                    -> Index "PK_IDFOCS" Unique Scan
                        -> Filter
                            -> Table "BLOCKS" as "B" Access By ID
                                -> Bitmap
                                    -> Index "FK_BLOCKS_FOCS" Range Scan (full match)
                -> Filter
                    -> Table "OWNERS" as "O" Access By ID
                        -> Bitmap
                            -> Index "PK_OWNERS" Unique Scan
                -> Filter
                    -> Table "SERVICEPARAMETERS" as "SP" Access By ID
                        -> Bitmap
                            -> Index "PK_SERVICEPARAMETERS" Unique Scan
                -> Nested Loop Join (inner)
                    -> Filter
                        -> Table "FLATS" as "F" Access By ID
                            -> Bitmap
                                -> Index "PKFLATS" Unique Scan
                    -> Filter
                        -> Table "ENTRIES" as "E" Access By ID
                            -> Bitmap
                                -> Index "PKENTRIES" Unique Scan
            -> Filter
                -> Table "SERVICES" as "S" Access By ID
                    -> Bitmap
                         -> Index "PKSERVICES" Unique Scan

[Stanislav Hruška]

Ďalší experiment:
Pridal som index FKOWNER_FLAT + FKFOCS. Výsledok toho istého dopytu (139 500 záz.) je:

• Nárast DB z 1,72 na 1,83 GB = + 110 MB (6,4 %)
• Index je použitý. Namiesto posledného I_DEPOSITS_FP
• Skrátenie času zo 41,4 s na 37 = ~4.4 s (~10 %)

Také skrátenie času odozvy si užívateľ ani neuvedomí. Dosť pochybujem o tom, že to stojí za to.
Váš názor je aký?

[Stanislav Hruška]

Len pre zaujímavosť.
V jednom 36,6 s dopyte som vyhodil všetky väzby "navyše" v INNER JOIN. Zrazu som na 12,6 s 
Ale ten 37,0 s dopyt neskrátim.
Dôvodom je skutočnosť, že tam mám dve CTE so Sum(DEPOSITS.DEPOSIT). Rozlišujú sa len dátumom. Jeden z nich je spätne napojený na DEPOSITS. Túto väzbu nemôžem zrušiť, lebo potrebujem jednotlivé položky DEPOSIT!

[František]

ta Sum(DEPOSITS.DEPOSIT) sa meni v nejakej zavislosti? alebo je to hodnota, ktora by sa dala ulozit a aktualizovat? to by myslim vyrazne skratilo selekt

[František]

alebo mam pre teba dalsi asi "spanielsku dedinu", ktoru som objavil iba pred par rokmi WINDOW DB funcie

https://biportal.cz/sql-funkce-na-poradi/

[František]

lebo ak su to nejake platby, tak vysledna suma by mala byt v DB ulozena, aby bol pevny a nemenny  zaznam o tom, ze niekto dostal take vyuctovanie,
takze sa vygeneruju platby - to nevadi ze to trocha trva - a potom pri vypise to uz pocitat nemusi

[Stanislav Hruška]

ta Sum(DEPOSITS.DEPOSIT) sa meni v nejakej zavislosti?

Je to súčet všetkých predpisov pre daného Vlastník_Byt za určité obdobie pre  všetky služby.
Pre každého Vlastník_Byt +  služba je v tabuľke jeden riadok. Je to riadková tabuľka. Ich súčet sa dá získať iba takto. Počas roka sa hodnota predpisu môže meniť. A to rôznymi spôsobmi.
Netreba sa tým trápiť, lebo to je extrémna situácia. Nemyslím si, že niekedy nastane.
139 500 záznamov = 4500 x Vlastník_Byt + 31 služieb. To je tak zhruba 12 000 obyvateľov   Služieb býva tak do 20.
Ja som s tým časom celkom spokojný.

[František]

Počas roka sa hodnota predpisu môže meniť. A to rôznymi spôsobmi.

to znemna za m v marci za marec mam predpis 100 a v auguste si vylistujem za marec a ma 120?

[Stanislav Hruška]

Samozrejme.
Ale predmet otázky je o inom. Prosím, vráťme sa k téme.

[Jan Fiala]

Tvůj problém je, že stahuješ 140 000 záznamů. Ten dotaz proběhne rychle, ale většinu toho času, který měříš spadá na stažení dat.
Fakt potřebuješ na klienta přenést 140 000 záznamů? Co s tím ten uživatel bude dělat?
On by měl dostat nějakých 200 zpracovaných záznamů.
Pokud to chceš optimalizovat, pak uložené procedury na SQL serveru. Ten to zpracuje a pošle výsledek na klienta.

[Stanislav Hruška]

To sú údaje do FastReport. Je na užívateľovi, či si vyberie danú voľbu. Či je preňho ešte únosná. To sa generujú údaje pre všetky SVB. Užívateľ si môže vybrať jediné a to zbehne rýchlo.

[pf1957]

To sú údaje do FastReport. Je na užívateľovi, či si vyberie danú voľbu. Či je preňho ešte únosná. To sa generujú údaje pre všetky SVB. Užívateľ si môže vybrať jediné a to zbehne rýchlo.

Ja bych se na to vykaslal.

Kdyz jsem naposledy exportoval cele (blize nespecifikovane) vyuctovani za buhvi jake obdobi do Excelu, tak byla rychlost to posledni, na cem mi zalezelo: at si to spusti a jde treba na obed. Az se vrati, bude tam mit v adresari hafo .xls souboru. Jen je treba spravne odhadnout a napsat mu, jak dlouho to bude trvat a dat mu moznost to zrusit/sestrelit, progress bar by mel byt asi samozrejmosti.

[Stanislav Hruška]

Ja bych se na to vykaslal.

To som už urobil. Viď čo si ma citoval.
Dlhé odozvy ešte len budem riešiť. Ten progress bar bude problém. Kvôli odhadu času. Lepšie bude niečo iné: točiaci sa kurzor, hodiny...

[František]

Kód: [Vybrat]

screen.cursor := crSQLWait;
try

....

finally
screen.cursor := crDefault;
end;
ale myslim si ze to nenahradi lespsi navrh

[František]

Počas roka sa hodnota predpisu môže meniť. A to rôznymi spôsobmi.

to znemna za v marci za marec mam predpis 100 a v auguste si vylistujem za marec a mam 120?

dufam ze toto nemyslis vazne