Van egy Oracle leválogatásom, melyben temporális táblát használok. Ehhez elszöszöl jó egy órát a rendszer. Aztán e tábla segítségével a másik leválogatás már pillanatok alatt lefut.
Szerettem volna megúszni a temporális táblát, és betettem az egészet egy
select q.valami from (select ....) q
join plimplamplum
join cicafule
subselect zárójelbe, de így kivárhatatlanul hosszú lett a dolog (időtúllépéssel leállt).
Van valami olyan Optimizer hint, amivel rá tudom venni, hogy először gyártsa le a q-t, és utána már ezt használja? Itt https://docs.oracle.com/cd/B10500_01/server.920/a96533/hintsref.htm nézegettem, de nem látom a fától az erdőt. Esetleg PUSH_SUBQ?
- 3130 megtekintés
Hozzászólások
pl ez ? de mondjuk ez GTT-t hasznal
- A hozzászóláshoz be kell jelentkezni
Thx
- A hozzászóláshoz be kell jelentkezni
Visszakérdezhetek: mi az a temporális tábla?
Nem a nézettáblára (,,view'') gondolsz, amely tuti, hogy a memóriában keletkezik és létezik, s ezáltal is sokkal gyorsabban elérhető belőle az adat, mint a fizikai táblában (,,table'')?
Ha viszont a SELECT-tet kell optimalizálni, érdemes elovasni ezt, illetve ezt (talán ez utóbbi látványosabb, mint az általad adott linken levő).
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
Temporális táblán rendes fizikai táblát értek, amit csak a lekérdezés kedvéért gyártok le és utána el is dob(hat)ok. (Tehát nem view-t.)
Köszi a látványos összefoglaló linkjét!
- A hozzászóláshoz be kell jelentkezni
Ami ugy keletkezik hogy amikor a View-t hasznalod az a View-kent eltarolt SQl-edet futtatja. Tehat marhara nyaggatja a fizikai tablat ugyanugy hiszen a View-t fel is kell epiteni...
- A hozzászóláshoz be kell jelentkezni
Nem használok view-t, mint írtam.
- A hozzászóláshoz be kell jelentkezni
nem is neked irtam :)
Csak a amire valaszoltam abbol az jon le hogy milyen kurva jo a view szemben egy temp tablaval.
Igazabol nem sokkal jobb ( ha a problema az hogy a select lassan dolgozodik fel )
A View in Oracle and in other database systems is simply the representation of a SQL statement that is stored in memory so that it can easily be re-used.
Note that this command does not result in anything being actually stored in the database at all except for a data dictionary entry that defines this view. This means that every time you query this view, Oracle has to go out and execute the view and query the database data
- A hozzászóláshoz be kell jelentkezni
Rendben, adást vettem. (Amúgy a józan ész is ezt diktálja, mert nyilván azért jön olyan gyorsan és egyszerűen létre a view, mert a tényleges használatakor a főtáblá(ka)t matatja.)
- A hozzászóláshoz be kell jelentkezni
Amit Te keresel az a select with... /*+materialize*/.
btw, megírtam volna a selectet is, de sajnos ezt a join így, join úgy szintaktikát képtelen vagyok az agyamban rögzíteni, mikor van sokkal egyszerűbb :D
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Esetleg egy CTE-vel? (WITH Clause)
- A hozzászóláshoz be kell jelentkezni
A sima MATERIALIZE nem jött be (egész éjjel futott a szkript, eredménytelenül), most megpróbálom ezt az előreszedett WITH CTE megoldást...
Ééééés sikerrel jártam! Itt a nyerő javaslat!!! :-)
Köszönöm.
with q as (
select /*+ MATERIALIZE */
...
where
...
)
select
...
from q
join plimplamplum
join cicafule
...
- A hozzászóláshoz be kell jelentkezni
Nezd meg a cost-jat (foleg az IO-cost erdekeljen) materialize-zal es anelkul is.
Meg az indexhasznalatot is :D
Ha a plimplamplum es/vagy cicafule joinolasa nem hasznal indexet (nyilvan az o oldalukrol), akkor lehet is tervezni rajuk a indexet.
- A hozzászóláshoz be kell jelentkezni