sql >> Databáze >  >> RDS >> Oracle

Proč bych neměl vytvořit všechny své pouze PL/SQL VARCHAR2 32767 bajtů?

Vypadá to, že toto je jedna z oblastí, kde se funkce PL/SQL vyvíjela oproti verzím, kdy Oracle implementoval různé optimalizace.

Všimněte si, že to také znamená, že některé z odpovědí uvedených v OP jsou také specifické pro vydání, i když to v těchto otázkách/odpovědích není výslovně uvedeno. Až uplyne čas a skončí používání starších verzí Oracle (sním?), budou informace zastaralé (může to trvat desetiletí).

Výše uvedený závěr je podpořen následující citací z kapitoly 12 Ladění aplikací PL/SQL pro výkon of PL/SQL Language Reference 11g R1 :

Tento problém již není zmíněn v 11g R2 ani 12c R1 verzi dokumentu. To je v souladu s vývojem kapitoly 3 Datové typy PL/SQL.

Odpověď:

Od 11gR2 se neliší od použití paměti z hlediska použití varchar2(10) nebo varchar2(32767) . Kompilátor Oracle PL/SQL se za vás postará o špinavé detaily optimálním způsobem!

U verzí před 11gR2 existuje hraniční bod, kde se používají různé strategie správy paměti, a to je jasně zdokumentováno v Pl/SQL Language Reference každého vydání. .

Výše uvedené platí pouze pro proměnné pouze PL/SQL, pokud neexistuje žádné omezení přirozené délky, které lze odvodit z problémové domény. Pokud proměnná varchar2 představuje GTIN-14 pak bychom to měli deklarovat jako varchar2(14) .

Když rozhraní proměnných PL/SQL se sloupcem tabulky používají %type -attribute, protože to je způsob s nulovou námahou, jak udržet váš PL/SQL kód a strukturu databáze v synchronizaci.

Výsledky testu paměti:

Spustil jsem analýzu paměti v Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 s následujícími výsledky:

str_size iterations UGA   PGA
-------- ---------- ----- ------
10       100        65488 0
10       1000       65488 65536
10       10000      65488 655360
32767    100        65488 0
32767    1000       65488 65536
32767    10000      65488 655360

Protože změny PGA jsou identické a závisí pouze na iterations a ne str_size Došel jsem k závěru, že na velikosti deklarované varchar2 nezáleží. Test může být příliš naivní - komentáře vítány!

Testovací skript:

-- plsql_memory is a convenience package wrapping sys.v_$mystat s and
-- sys.v_$statname tables written by Steven Feuerstein and available in the
-- code-zip file accompanying his book.

set verify off

define str_size=&1
define iterations=&2

declare
  type str_list_t is table of varchar2(&str_size);
begin
  plsql_memory.start_analysis;

  declare
    v_strs str_list_t := str_list_t();
  begin
    for i in 1 .. &iterations
    loop
      v_strs.extend;
      v_strs(i) := rpad(to_char(i), 10, to_char(i));
    end loop;
    plsql_memory.show_memory_usage;
  end;

end;
/

exit

Příklad testovacího běhu:

$ sqlplus -SL <CONNECT_STR> @memory-test.sql 32767 10000

Change in UGA memory: 65488 (Current = 1927304)
Change in PGA memory: 655360 (Current = 3572704)

PL/SQL procedure successfully completed.

$


  1. Vytvoření kontingenční tabulky pro docházku pomocí php a mysql

  2. exportovat výsledek dotazu jako CSV prostřednictvím PHP

  3. Jak uložit více opakovatelných polí jako pole v databázi?

  4. Práce s Java daty v Qlik Sense