2010-03-22 15 views
5

Ho una tabella vuota che in precedenza aveva una grande quantità di righe.Eliminazione da tabella vuota prendendo forver

La tabella ha circa 10 colonne e indici su molti di essi, nonché indici su più colonne.

DELETE FROM item WHERE 1=1 

Questo richiede circa 40 secondi per completare

SELECT * FROM item 

questo richiede 4 secondi.

Il piano di esecuzione di SELECT * FROM ITEM mostra quanto segue;

SQL> select * from midas_item; 

no rows selected 

Elapsed: 00:00:04.29 

Execution Plan 
---------------------------------------------------------- 
0  SELECT STATEMENT Optimizer=CHOOSE (Cost=19 Card=123 Bytes=73 
     80) 

1 0 TABLE ACCESS (FULL) OF 'MIDAS_ITEM' (Cost=19 Card=123 Byte 
     s=7380) 





Statistics 
---------------------------------------------------------- 
     0 recursive calls 
     0 db block gets 
    5263 consistent gets 
    5252 physical reads 
     0 redo size 
    1030 bytes sent via SQL*Net to client 
    372 bytes received via SQL*Net from client 
     1 SQL*Net roundtrips to/from client 
     0 sorts (memory) 
     0 sorts (disk) 
     0 rows processed 

qualsiasi idea del motivo per cui ci sarebbe voluto così tanto tempo e come risolverlo sarebbe molto apprezzato !!

+0

Potete dirmi quanti dati (righe) non ha questa tabella? – bragboy

+1

Ci sono altre tabelle vuote che fanno riferimento a questa tabella con chiavi esterne? – dpbradley

+0

La tabella aveva circa 200.000 righe quando l'ho cancellata l'ultima volta. Ha avuto molto di più che in passato anche se (probabilmente 2mil file diff sopra è vita) – Will

risposta

2

Select è solo facendo una scansione completa della tabella. Cancellare d'altra parte (in Oracle) dovrà memorizzare l'intera riga eliminata nei segmenti di rollback per consentire di annullare le modifiche in un secondo momento (in modo che possa essere anche più lento dell'inserto).

è possibile trovare un tempo molto lungo e utile discussione legata a quella sulla Chiedi Tom forum. A seconda del tuo caso aziendale, potresti applicare più tecniche.

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2345591157689

2

Se sulla tabella sono presenti molti indici, l'eliminazione richiederà tempo, poiché anche ciascuna voce dell'indice deve essere rimossa. Gli indici accelerano i processi di lettura e rallentano la scrittura o altri processi di modifica (da qui la selezione rapida).

- EDIT: Scusa non ho letto completamente le domande. Se la tabella è vuota, non può essere un problema di indice. o sarò sorpreso se lo fosse -

+0

beh, la selezione richiede ancora 4 secondi, ma si, veloce nel confronto – Will

+0

Ma sta dicendo che la tabella non ha ancora righe, quindi il DELETE non dovrebbe modificare gli indici. –

1

Se si eliminano regolarmente tutte le righe da una tabella, "troncare la tabella XXX" è in genere molto più veloce di un'eliminazione di massa. Forse provalo e vedi quanto più velocemente puoi ottenerlo.

+0

Vero - ma assicurati di capire cosa fa TRUNCATE (rilascia spazio, effettua transazioni). –

+0

Ho usato troncare per eliminare tutte le righe – Will

3

Se la tabella in precedenza era piena di una grande quantità di dati, Oracle eseguirà la scansione fino al limite massimo, anche se non ha dati ORA. È possibile utilizzare l'istruzione TRUNCATE per reimpostare HWM.

Also on AskTom

+0

Questo è stato anche il mio primo pensiero, ma non sono sicuro che questo spieghi perché il DELETE sia molto più lento di SELECT. –

+0

Ho usato TRUNCATE TABLE per cancellare il contenuto originariamente, era ancora lento dopo averlo usato. – Will

4

Una possibilità è una serratura. Cioè c'era una riga nella tabella che era stata commessa e bloccata da un'altra eliminazione. La tua cancellazione si è seduta e ha atteso il blocco. Quando è stata eseguita la transazione di blocco, la cancellazione è stata quindi in grado di terminare.

Una seconda possibilità è che è stata eseguita prima la cancellazione, che ha recuperato i blocchi dal disco nella cache (che ha richiesto tempo). Quando è stata eseguita la selezione, i dati erano nella cache e quindi sono più veloci. Penso che questo sia meno probabile quando selezioni le statistiche indicate "5252 letture fisiche", quindi non le otteneva dalla cache SGA. È possibile che sia stata coinvolta una cache del disco.

Una terza possibilità è che ci sia un trigger BEFORE/AFTER DELETE (non PER OGNI RIGA) che ha fatto qualcosa.

Una quarta possibilità è che il DELETE ha provocato un blocco ritardato di pulizia. Quando le righe sono state effettivamente cancellate, se sono state scritte sul disco prima di essere impegnate, avrebbero ancora le informazioni di blocco/transazione. La tua cancellazione arriva, legge i blocchi, vede le informazioni sulla transazione ormai obsolete, la rimuove e riscrive il blocco.

Una quinta possibilità è la contesa. Forse c'era solo più successo nello stesso momento dell'eliminazione.

Un sacco di possibilità. Se è possibile riprodurlo, fare una traccia con gli eventi di attesa ed eseguirlo attraverso TKPROF.

Problemi correlati