salve,
Luca_spl wrote:
Intendo che mentre era in esecuzione la stored gli altri utenti non riuscivano a fare nemmeno l'accesso al db . sono daccordo che l'operazione richieda molte risorse alla macchina ma non di bloccare in questo modo. Tuttavia ora che ho corretto il problema (tenendo anche conto che creare una tabella all'interno di una transazione è opinabile) la stored viene eseguita senza creare alcun problema l'hardware del server è ben equipaggiato e gli atri utenti non risento dell'operazione in corso.
continua a non quadrarmi...
al di la' del fatto che, probabilmente, visto che la generazione della tabella e' dentro una transazione, tanto vale allora spostarla subito dopo l'header ed utilizzare una tabella temporanea.. ricorda che, tra l'altro, l'inclusione di codice DDL comporta giocoforza la ricompilazione del piano di esecuzione della procedura.. non che a te interessi molto, visto che comunque ci mette 60 secondi per l'esecuzione, ma tant'e'... in SQL Server 2008 hanno migliorato molte parti della
compilazione/riutilizzo di piani compilati.. addirittura l'engine puo' utilizzare "parte" di un piano generato precedentemente..
se quindi hai
CREATE PROC...
AS BEGIN
CREATE TABLE .....
INSERT INTO ....
SELECT .. FROM ...
END;
ovviamente non sara' possibile riutilizzare la parte relativa al CREATE TABLE, ma e' possibile che i piani della parte INSERT INTO e SELECT FROM successivi possano essere utilizzati..
Mi chiedo perche Si bloccava in quel modo? un mio ex collega che ho contattato ieri mi ha dato questa risposta non so se è da prendere in considerazione. (lui è un dba) Eseguire la creazione di una tabella in una transazione crea un look esclusivo sul db master.
forse in altre piattaforme, ma non in SQL Server... il database master non viene assolutamente "toccato" dall'operazione.. i suoi cataloghi non sono coinvolti in alcuna parte nella generazione di oggetti che risiedano in altri database..
ovviamente vengono invece toccati i cataloghi del database coinvolto, dove solitamente viene sollevato un lock a livello di "schema" coinvolto nella generazione della tabella, che puo' essere uno Schema modification lock ovvero uno Schema stability lock.. il secondo e' si lock a tutti gli effetti, ma non compromette alcuna attivita' transazionale altrui in lettura/scrittura e viene generato in occasione della compilazione dei piani di accesso ai dati, consentendo ad altri anche exclusive locks sulla tabella stessa.. il suo fine, in definitiva, e' quello di mantenere la "consistenza" a livello di catalogo della tabella coinvolta nella generazione del piano di esecuzione..
diversamente invece si comporta l'altro, lo Schema modification lock, che invece previene l'accesso da parte di altri alla tabella coinvolta, in quanto e' antecedente all'esecuzione di codice DDL di
manipolazione/generazione/eliminazione di una tabella, ed ovviamente accessi concorrenti non possono essere permessi..
quindi, nel tuo caso, oltre ad avere entrambi i lock, hai in piu' anche la transazione esplicita (che solleva ulteriori lock, magari a livello di riga/pagina che poi possono essere promossi a livello di tabella/e [magari tutte le tabelle coinvolte], ma non sicuramente di database)... di che tipo e' l'isolation level di questa transazione?
Che ne pensate?
vorrei aggiungere .. la persona che ha creato la stored procedure mi ha detto che l'ha sempre fatto è non ha mai avuto problemi con le versioni precedenti di sql server. Attualmente è in uso sql server 2008. Modificato da Luca_spl il 31 marzo 2009 15.32 -
personalmente non ho memoria, in passato, di simili problemi.. ne' ho conoscenza attuale relativamente alla versione corrente.. se sei in grado di generare un esempio che riproduca il problema, potresti provare a postarlo.. magari anche su connect, dove il team di SQL Server possa eventualmente verificare un "problema"..
saluti
