Dočasné tabulky jsou v podstatě stejné jako tabulky v paměti díky ukládání do mezipaměti a asynchronnímu I/O a řešení dočasné tabulky nevyžaduje žádnou režii pro převod mezi SQL a PL/SQL.
Potvrzení výsledků
Při porovnání dvou verzí s RunStats verze dočasné tabulky vypadá mnohem horší. Všechen ten odpad pro dočasnou tabulkovou verzi v Run1 a jen trochu paměti navíc pro verzi PL/SQL v Run2. Zpočátku se zdá, že PL/SQL by měl být jasným vítězem.
Type Name Run1 (temp) Run2 (PLSQL) Diff
----- -------------------------------- ------------ ------------ ------------
...
STAT physical read bytes 81,920 0 -81,920
STAT physical read total bytes 81,920 0 -81,920
LATCH cache buffers chains 104,663 462 -104,201
STAT session uga memory 445,488 681,016 235,528
STAT KTFB alloc space (block) 2,097,152 0 -2,097,152
STAT undo change vector size 2,350,188 0 -2,350,188
STAT redo size 2,804,516 0 -2,804,516
STAT temp space allocated (bytes) 12,582,912 0 -12,582,912
STAT table scan rows gotten 15,499,845 0 -15,499,845
STAT session pga memory 196,608 19,857,408 19,660,800
STAT logical read bytes from cache 299,958,272 0 -299,958,272
Ale na konci dne záleží pouze na nástěnných hodinách. Kroky načítání i dotazování běží mnohem rychleji s dočasnými tabulkami.
Verzi PL/SQL lze vylepšit nahrazením BULK COLLECT s cast(collect(test_o(MOD(a, 10), '' || MOD(a, 12))) as test_t) INTO t . Stále je však výrazně pomalejší než dočasná tabulková verze.
Optimalizované čtení
Čtení z malé dočasné tabulky používá pouze vyrovnávací paměť, která je v paměti. Spusťte pouze část dotazu mnohokrát a sledujte, jak se consistent gets from cache (paměť) se zvýší, zatímco physical reads cache (disk) zůstat stejný.
select name, value
from v$sysstat
where name in ('db block gets from cache', 'consistent gets from cache',
'physical reads cache');
Optimalizované zápisy
V ideálním případě by neexistoval žádný fyzický vstup/výstup, zejména proto, že dočasná tabulka je ON COMMIT DELETE ROWS . A zdá se, že příští verze Oracle může takový mechanismus zavést. Ale v tomto případě na tom moc nezáleží, nezdá se, že by vstup/výstup disku věci zpomaloval.
Spusťte krok načítání několikrát a poté spusťte select * from v$active_session_history order by sample_time desc; . Většina I/O je BACKGROUND , což znamená, že na něj nic nečeká. Předpokládám, že interní logika dočasné tabulky je jen kopií běžných mechanismů DML. Obecně platí, že nová data tabulky mohou musí být zapsán na disk, pokud je potvrzen. Oracle na tom může začít pracovat, například přesunem dat z vyrovnávací paměti protokolu na disk, ale není kam spěchat, dokud nedojde ke skutečnému COMMIT .
Kam jde čas PL/SQL?
Nemám tušení. Existuje více kontextových přepínačů nebo jedna konverze mezi motory SQL a PL/SQL? Pokud vím, žádná z dostupných metrik neukazuje čas vynaložené na přepínání mezi SQL a PL/SQL.
Možná se nikdy přesně nedozvíme, proč je kód PL/SQL pomalejší. Moc se tím netrápím. Obecná odpověď zní, že drtivá většina databázové práce se stejně musí dělat v SQL. Dávalo by velký smysl, kdyby Oracle věnoval více času optimalizaci jádra své databáze, SQL, než přídavného jazyka PL/SQL.
Další poznámky
Pro testování výkonu může být užitečné odstranit connect by logiku do samostatného kroku. Tento SQL je skvělý trik pro načítání dat, ale může být velmi pomalý a náročný na zdroje. Realističtější je jednou načíst vzorovou tabulku pomocí tohoto triku a poté z této tabulky vložit.
Zkusil jsem použít novou funkci Oracle 12c, dočasné vrácení zpět a novou funkci 18c, soukromé dočasné tabulky. Ani jeden nezlepšil výkon oproti běžným dočasným tabulkám.
Nesázel bych na to, ale vidím způsob, jak by se výsledky s přibývajícími daty úplně změnily. Vyrovnávací paměť protokolu a mezipaměť vyrovnávací paměti mohou být jen tak velké. A nakonec by se I/O na pozadí mohly přidat a přetížit některé procesy, čímž by se BACKGROUND počkejte do FOREGROUND Počkejte. Na druhou stranu je tu jen tolik paměti PGA pro řešení PL/SQL a pak se věci zhroutí.
Konečně to částečně potvrzuje mou skepsi k „in-memory databázím“. Ukládání do mezipaměti není nic nového, databáze to dělají desítky let.