2011-09-08 9 views
35

Qual è la migliore procedura per gestire il rilascio di una tabella temporanea. Ho letto che dovresti gestire esplicitamente il drop e anche che il server SQL dovrebbe gestire la drop .... qual è il metodo corretto? Ho sempre avuto l'impressione che dovresti fare la tua pulizia delle tabelle temporanee che crei in uno sproc, ecc. Ma poi ho trovato altri bit che suggeriscono il contrario.Rilasciare in modo esplicito la tabella temporanea o lasciare che SQL Server la gestisca.

Qualsiasi intuizione sarebbe molto apprezzata. Sono solo preoccupato di non seguire le migliori pratiche con le tabelle temporanee che creo.

Grazie,

S

+6

SQL Server farà cadere automaticamente le tabelle locali '# temp' quando escono dall'ambito di applicazione, quindi non importa AFAIK. Non sono sicuro se questo auto drop si verifichi in modo sincrono prima che l'oscillazione venga o meno, in modo tale che potrebbe fare una leggera differenza rispetto a un calo esplicito, ma per le tabelle di grandi dimensioni penso che il calo sia comunque rinviato. –

+2

Anche un esempio di argomento a favore dell'uno o dell'altro metodo (specialmente a favore dell'eliminazione esplicita) sarebbe apprezzato. Io, per esempio, non posso davvero giustificare l'eliminazione esplicita come la "migliore pratica", né posso affermare che sia * sempre * ridondante. D'altra parte, quelli con un livello più alto di esperienza nella zona potrebbero darti una risposta davvero buona se davvero ci dicessi perché esattamente tu (o qualcun altro la cui opinione in merito a un certo punto ti è sembrata ragionevole) riguardi uno metodo migliore dell'altro. –

risposta

25

La mia vista è, per prima cosa, vedi se hai davvero bisogno di una tabella temporanea - oppure - puoi accontentarti di un CTE. Secondo, lascerei sempre i miei tavoli temporanei. A volte è necessario disporre di una tabella temporanea per la connessione (ad esempio ## temp), quindi se si esegue la query una seconda volta e si dispone di codice esplicito per creare la tabella temporanea, verrà visualizzato un errore che indica la tabella esiste già. Ripulire da soli è SEMPRE una buona pratica software.

+1

Attenzione che ## temp è visibile a tutti (ad esempio altre connessioni), ma verrà eliminato quando termina la sessione originale. – Vedran

0

Come per la mia vista. Non è necessario rilasciare tabelle temporanee in modo esplicito. Il server SQL si occuperà di eliminare le tabelle temporanee archiviate in db temp in caso di shorage di spazio per elaborare la query.

2

In uno scenario multi-thread in cui ogni thread crea il proprio set di tabelle e il numero di thread viene limitato, non rilasciare le proprie tabelle significa che il governatore prenderà in considerazione il thread e genererà più thread ... tuttavia il le tabelle temporanee sono ancora in circolazione (e quindi le connessioni al server) quindi supererai i limiti del tuo governatore. se si rilasciano manualmente le tabelle temporanee, il thread non termina finché non vengono eliminate e non vengono generati nuovi thread, mantenendo così la capacità del governatore di evitare di sovraccaricare il motore SQL

+2

ho trovato questo difficile da seguire. – FistOfFury

+0

@FistOfFury, un governor è un dispositivo che limita la creazione di thread. un caso d'uso in cui è vantaggioso è dove si possono avere un sacco di compiti da eseguire in un database ma non si vuole sovraccaricare il server ... in tal caso si ha qualche tipo di schema di rilevamento dell'utilizzo della CPU (o una semplice discussione limite) e generare nuovi thread solo in base ad esso – ekkis

+0

penso di averlo capito. quindi questo è un caso d'uso particolare quando si ha un processo che crea tabelle temporanee ripetutamente in parallelo, il che finisce per travolgere il database. Ciò ha senso. – FistOfFury

6

Tabelle temporanee locali (numero singolo in il nome) verrà automaticamente eliminato quando non rientra nello scope, quindi il dropping esplicito non ha senso se l'ambito è di breve durata (una stored procedure ad esempio).

+0

a volte si ha poco controllo sull'ambito (pool di connessioni) –

+0

@MeggieLuski è un equivoco poiché le tabelle temporanee verranno eliminate a causa della chiamata di sp_reset_connection quando viene riutilizzata una connessione da un pool. – Vedran

+1

sì ma a volte non si ha il controllo su quando si esegue il reset della connessione sp, specialmente se si dispone di più livelli nell'architettura yoru –

Problemi correlati