Newsgroup: it.comp.software.database
Titolo: [ORACLE] tablespace TEMP

Ciao a tutti.
Ho un problema con il dimensionamento della TEMP di oracle.
Ho una Materialized view la cui select  estrapolerebbe 51852627 records
(riporto sotto la materialized view )
Facendo due conti :
NAPCX              NUMBER(9)
MAX_MVAP_COD_EVNT  VARCHAR2(20 BYTE),
NCTTO              NUMBER(9)
NTSTA              NUMBER(9)
COD_EVNT           VARCHAR2(20 BYTE)
mi dovrebbe tirare fuori circa 70 byte ( GIUSTO?)  per riga ovvero
3629683890 byte in totale.
Ho dimensionato la tablespace TEMP a 6 Giga.
Quando pero' eseguo la creazione di questa Materialized View  la TEMP mi si
riempe e non riesce ad arrivare alla fine.
Le domande sono queste :
- Nella temp viene memorizzato qualche altro dato oltre a quelli che io ho
ipotizzato ( penso che la risposta sia si...ma non riesco a capire cosa ci
sia in piu')
- E piu' performante gestire gli EXTENT della TEMP in "LOCALY MANAGED" o
"MANAGED IN THE DICTIONARY" ( chiedo questo perche' ho notato che nella
prima maniera la temp mi viene subito allocata per intero e nella seconda
viene allocata progressivamente)
Se ho omesso qualche cosa nella spiegazione non esitate a chiedre.
Ciao e Grazie.
Alex
Create Materialized View "MV_MAX_TST_APPL_TA_AA_E"
TABLESPACE "TASP_SERVIZIO_FATTI"
  NOPARALLEL
  NOLOGGING
BUILD IMMEDIATE REFRESH ON DEMAND ENABLE  QUERY REWRITE
 AS
select mvap_napcx NAPCX
         ,max( mvap_COD_EVNT) MAX_MVAP_COD_EVNT --
         ,mvap_nctto NCTTO
         ,MVap_NTSTA NTSTA
         ,b.EVNT_CODICE COD_EVNT
  from  wv_movim_applicazione -- numero records 1451712
      , mv_eventi_ta_aa b  -- numero records 5719
  where
       mvap_nctto = b.MVct_nctto
       and mvap_COD_EVNT <= EVNT_CODICE
  group by mvap_napcx
          ,MVap_nctto
          ,b.EVNT_CODICE
          ,MVap_NTSTA;

 "MANAGED IN THE DICTIONARY"
In generale, locally managed uniform size. Dove extent size =
sort_area_size; quest'ultima non conviene settarla a dimensioni > di 4M (io
ho giust'appunto 4M su un vldb).
ciao

 ciao
Avevo letto una cosa simile su Metalink ma volevo avere una vostra conferma.
Grazie per la risposta!
Per l'altra domanda sai nulla?
Ciao e grazie
Alex

 - E piu' performante gestire gli EXTENT della TEMP in "LOCALY MANAGED" o
locally managed è oramai il default... serve altro :?
/G
-- 
~~


a parte che se fosse come dici tu , 6GB sarebbero pochi anche
per lo Sn da 3GB , rimane che la temp ti risulreta' sempre
piccola, soprattutto perche' devi calcolarti il prodotto scalare
delle 2 tabelle che la generano, :( quelle clausole where
sono un poco "performanti", e il group ...
e neanche quegli 8GB ti basterebbero, per i motivi
indicati da giorgio, potresti provare o a portarla a 10Gb,
cosi' buttato li', o a farla in passi successivi, la
crei a partire dalle viste sulle tabelle coinvolte :)
altrimenti ....
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 crei a partire dalle viste sulle tabelle coinvolte :)
Pensa che questo snapshot e' gia' il risultato di una select che e' stata
divisa in 3 sotto query.
Ciao e Grazie
Alex

 sort vari e parenti annessi... insomma un putiferio :)
Si...in effetti bastava era abbastanza logico.....non ci avevo pensato.
Esiste una regola per dimensionare la TEMP? del tipo :
Almeno il doppio della query piu' grossa.
Non vorrei sovradimensionare la TEMP.
Ciao e grazie
Alex