2013-10-29 9 views
6

Ho una stored procedure che prima controlla una tabella temporanea (#temp_table), la elimina se esiste, usa la tabella, quindi alla fine la cade quando ha finito. Questo SP viene chiamato in modo casuale quando un utente fa qualcosa per attivarlo ed è probabile che a volte l'SP venga eseguito nello stesso momento o con qualche sovrapposizione.In MS SQL Server 2005, cosa succede quando si accede a una tabella temporanea da diverse esecuzioni dello stesso SP?

Diciamo che ho Exec1 ed Exec2 entrambi della stessa SP che creano, alterano e rilasciano la tabella #temp, e sono in esecuzione in millisecondi l'una dall'altra.

Cosa succede? Exec1 bloccherà #temp_table e Exec2 attende mentre Exec1 termina? Sarebbe ovviamente auspicabile nel mio caso. Non vorrei che sia Exec1 & 2 per utilizzare la tabella allo stesso tempo, né vorrei Exec2 non riuscire perché Exec1 sta già utilizzando la tabella.

[EDIT] Devo convertire la mia tabella temporanea in una variabile di tabella?

risposta

5

Nel server SQL se si crea una tabella temporanea locale è con un solo # server sql con segno utilizza un numero insufficiente di punteggio e qualche ID nel back-end. Supponiamo che tu crei una tabella Temp con il nome #Temp sql server in temp db Crea una tabella con il nome #Temp_______10912098, ogni tabella Temp creata in connessioni separate avrà il proprio ID alla fine del nome.


TempTables

Queste sono tutte le tabelle temporanee create in diverse connessioni tutti ha il nome #Temp ma vengono aggiunti con alcune sottolineature e un server SQL unique id usa per differenziare tra di loro.

+1

Quindi nel mio SP ho 'SE OBJECT_ID ('tempdb .. # temp_table') NON È NULL \t DROP TABLE # temp_table' questo non fa nulla? Oppure questo potrebbe avere un impatto negativo su altre esecuzioni? – jreed121

+2

Non è necessario se lo si chiama da una nuova sessione ogni volta (ad esempio da un'app Web), poiché l'ambito della tabella temporanea è limitato alla sessione. Vedi la mia risposta per maggiori informazioni. –

+3

Non è necessario, come ha detto Dommer, ma è sempre una buona pratica controllare l'esistenza di un OBJECT prima di provare a crearlo. mantieni quel pezzo di codice nel tuo proc. –

4

L'ambito della tabella temporanea #table è limitato alla sessione, quindi non dovrebbe essere un problema.

Se si è utilizzato uno ##table, questo è globale e si verificano problemi.

vedere qui: MSDN SQL Tables

In particolare questo bit:

Se una sessione di database crea la tabella temporanea locale #employees, solo la sessione può lavorare con la tavola, e viene eliminato quando il sessione si disconnette. Se si crea la tabella temporanea globale ##employees, qualsiasi utente nel database può lavorare con questa tabella. Se nessun altro utente lavora con questa tabella dopo averlo creato, la tabella è eliminata quando si disconnette. Se un altro utente lavora con la tabella dopo averlo creato, SQL Server lo elimina dopo la disconnessione e dopo che tutte le altre sessioni non lo utilizzano più attivamente.

3

Le tabelle temporali denominate con un hash # sono specifiche per la singola connessione.

Quindi, se due connessioni (note anche come "processi" o "SPID") fanno riferimento a una tabella temporanea dallo stesso #tablename, fanno effettivamente riferimento a tabelle diverse.

Si può vedere questo se si guarda in tempdb. Ci saranno più tabelle denominate cose come #748B826C.Queste sono in realtà variabili di tabella temporanee come declare @t table (ix int identity primary key) e il nome di tabelle temporanee con un hash.

Pertanto, a condizione che si tratti di connessioni diverse anziché di trigger ricorsivi, non dovrebbero esserci problemi.

Tuttavia, se si è preoccupati della possibilità di trigger ricorsivi, è necessario utilizzare variabili di tabella. Questi sono limitati allo scopo del batch o del proc memorizzato.