none
Elaborazione query RRS feed

  • Domanda

  • sono uno sviluppatore web , ho notato che il tempo di attesa per visualizzare i dati restituiti da una query sql dipende dal numero di record che essa restituisce. ho notato che i risultati sono caricati un po alla votla a video fino all'esecuzione completa della query. Da codice i dati li ottengo solo al termine dell'esecuzione ed inoltre il tempo di attesa è comunque superiore a quello impiegato dalla consolle.

    esiste un driver o provider che mi consenta di ottimizzare i tempi di attesa o poter invocare il risultato di una qery sql così come fa la cnsolle?

    mercoledì 20 ottobre 2010 13:36

Risposte

  • salve luigi,

    in parole molto povere, tecnicamente SQL Server restituisce al chiamante uno stream TDS, contenente dati e messaggi, che spetta al chiamante utilizzare.. dal canto suo quindi, SQL Server restituisce uno stream tendenzialmente "continuo" (ma non prendermi in parola perche' cosi' in effetti non e') man mano che i suoi buffer interni si caricano con il risultato delle proiezioni.. questo flusso viene assorbito dal chiamante, che di solito e' un layer di accesso ai dati, sia esso Ado, Ado.Net e via di seguito.. quest'ultimo non e' direttamente assimilabile al driver di collegamento, sia esso MDASQL (OLE DB) o SqlNativeClient (nativo .Net) in quanto sono questi ultimi a gestire il traffico da e per il servizio, appoggiandosi sul protocollo di rete preposto o, in caso di collegamento locale, su Shared Memory.. lato client, il layer di connessione e' responsabile di prelevare questy buffer trasmessi via "rete" (o shared memory) il prima possibile sia al fine di svuotarli e renderli nuovamente disponibili alla ricezione che al fine di comunicare al servizio che "qualcuno e' in ricezione".. in assenza di consumo di questi stream, SQL Server tendenzialmente riconoscera' una caduta di connessione al termine dei timeout impostati, effettuando il discard dell'esecuzione se non terminata e procedendo ai cleanup laddove necessari.. sempre il client deve poi interagire con l'applicativo chiamante, ed e' qui che solitamente intervengono i "ritardi".. al fine di restituire un risultato utilizzabile, solitamente infatti questi layer attendono il completo popolamento del "cursore" interno cosi' da popolare il "recordset" da restituire all'applicazione chiamante, visto che un risultato "parzialmente popolato" non e' di solito mai ne' utilizzabile ne' gestibile dalle GUI utente.. si ottiene cosi' una richiesta "sincrona" che sara' "risposta" al completamento del risultato, dove poi (sia esso ad esempio SQLClient [da non confondere con lo SNAC]) consente ad esempio il popolamento di un datatable o il ciclo su un datareader.. e sino a qui, malgrado possibili ritardi dovuti sia al traffico di rete che alla memoria da allocare per la condensazione del risultato, solitamente i timing sono accettabili.. in questo discorso ovviamente non prendo in considerazione i ritardi lato server, dovuti eventualmente all'esaurimento del server stesso per magari elevato carico, ma piu' sicuramente dovuti all'esecuzione stessa della query primigenia, che deve prima trovare il piano di esecuzione da utilizzare e quindi provvedere ad accedere al disco come anche unire i risultati parziali al fine di ottenere il risultato desiderato.. qualora questi timing siano ritenuti inaccettabili e' ovviamente necessario provvedere ad identificare le cause del collo di bottiglia, siano esse ad esempio una scorretta indicizzazione della base dati come anche un'elevata frammentazione della stessa ovvero pessima architettura di modellazione (cause risolvibili reingegnerizzando la base dati tornando al momento della modellazione), ma anche tipicamente fisiche, ad esempio dovuti a soluzioni di I/O scadenti o insufficiente memoria disponibile per la macchina stessa (risolvibili modificando l'hardware, ma tendenzialmente queste cause non sono sotto diretto controllo degli amministratori di base dati e va anche considerato che molto piu' spesso le cause sono quelle a diretto carico degli stessi, quindi le altre).. il tuning qui diventa spesso "brutale", utilizzando strumenti quale il Profiler di SQL Server per verificare "cosa" venga richiesto e "come" venga ottenuto analizzando piani di esecuzione e quant'altro.. ma stiamo "parlando" di problemi lato client, quindi "legati" ad esempio ai controlli di visualizzazione dei dati restituiti.. talvolta si puo' richiedere una risposta "asincrona", vedi ad esempio i metodi di SQLCommand che cominciano con "BeginXXX" (http://msdn.microsoft.com/en-us/library/7szdt0kc.aspx).. nel caso in esame, cio' non significa che "ogni riga" ritornata sara' "visualizzata" singolarmente, ma si lascia cosi' la UI libera di "fare le sue cose", come un context switch :).. c'e' pero' chi si e' "riscritto" l'accesso ai dati in modo da poter fare anche questo, come pare faccia anche SSMS, che in effetti sembra molto piu' discreto di, ad esempio, DataGridView di WinForms legato ad un datatable... ma tutto questo vale se i risultati sono "cosi' corposi" da appesantire i motori grafici dei controlli... sempre tornando lato server, considera ad esempio che i benchmark si effettuano richiedendo a SSMS di tralasciare i "tempi" relativi alla UI per avere le tempistiche pure relative all'esecuzione della sola query...  ascrivendo quindi la problematica non gia' all' "esecuzione e traffico della query" bensi' alla renderizzazione dei dati lato client, la domanda quindi, diventa: "ma quante righe vuoi mostrare all'utente?" :) ed anche "sei proprio sicuro di volerle mostrare TUTTE?" :)

    ad ogni modo, i driver disponibili sono "limitati" (in senso quantitativo) e non credo ne esistano di piu' performanti di quelli "nativi", quindi forse, al di la' della modifica delle query poco performanti delle quali possiamo eventualmente parlare, credo probabilmente otterrai maggior beneficio in altri forum deputati alle ottimizzazioni applicative lato client, sempre che tali ottimizzazioni siano possibili, oltre a ridurre ovviamente il numero di righe restituite.. :)

    saluti


    http://www.asql.biz - DbaMgr2k - DbaMgr and further SQL Tools http://www.hotelsole.com/ - http://www.hotelsolericcione.de
    mercoledì 20 ottobre 2010 21:23
    Moderatore