dotNet Umbria [DNU]

Ciao a tutti,

qualcuno sa dirmi perchè il processo di SQL si comporta  in questo modo?
Vi spiego lo scenario:

Applicazione winForm C# 2005, e database SQL Express residente sulla stessa macchina.

In pratica ho un form con  due TabPage; nel secondo c'è un datagridView con bindingsource ad una tabella di un Dataset che fisicamente corrisponde ad una vista nel DB con diverse join per decodificare, alcuni campi.
Il DataGridView viene carico al momento del selected del tabpage attraverso un metodo generato nel Dataset dove ho aggiunto alla Fill  una Where
con un range di date,   Es. DataInserimento >= @dataDa && DataInserimento <= @dataA

Il risultato è in media di 800-900 righe su un totale di 35.000  dell'intera vista.

Ora, Alcune volte  l'applicazione si blocca, e tra i processi si vede questo  SQLServr.exe che occupa costantemente 50% per molto tempo; dopo di che  a volte torna il controllo al DatagridView altre va in crash  tutta l'applicazione.

Consigliatemi!!

Grazie.

Ciao Francesco,

Puoi provare a vedere l'execution Plan da "Sql Server Management Studio" e vedere come la query viene interpretata.

Se nell'execution plan trovi degli oggetti "Table Scan" significa che per alcuni tipi di campo in join o in where non vengono utilizzati indici e quindi l'esecuzione deve leggere tutti i valori per filtrare i dati.
Questo sicuramente degrada le performance e in questo caso ti consiglio di inserire un indice in corrispondenza del campo in where o in join.

Dovresti notare un miglioramento significativo.

Per maggiori dettagli dovresti inviarmi la struttura della tabella (indici compresi)
e un esempio di query.

Se vuoi puoi farlo anche in privato attraverso la mia mail .

Ciao e a presto.

Ciao Paolo,

ho eseguito l'execution PLan mi sembra che non ci siano  "Table Scan" ma solo "Clustered Index Scan"   o "Hash Match", frutto di tabelle in Left Outer Join,  di cui una a un cost: 24% le alte si aggirano tra 5% e 9%.

Secondo te, ammesso che la query non sia ottimizzata,  è possibile che vada in crash l'applicazione WinForm?  Questa vista è creata sul DB e poi la utilizzo con un dataset e tableAdapter classico di VS 2005.

Sulla Macchina dove va più spesso in crash per prova abbiamo ho aggiunto anche un banco di memeria portandola ad 1 Gb  ma il processo SQL si piazza sempre al 50% per molto tempo con lo stesso risultato.

Cercherò di ricontrollare un po' tutto il flusso.

Ciao e Grazie.

Ciao Francesco,

Sicuramente il come dice Paolo il  Plan è il modo migliore per capire cosa succede. Parli di Vista, ma dunque le JOIN sono coinvolgono sia tabelle Fisiche che Viste su  Tabelle, Tabelle? in questo caso verifica come viene creata la Vista, magari su dei campi non Indicizzati. Verifica anche da quanto tempo su quel DB non vengono Riorganizzati gli Indici, magari sono stati fatti molti Insert e Delete e dunque le Statistiche non vengono utilizzate al meglio.

Ciao

 due domande:

hai provato a profilare le query che vengono fatte, e a rieseguirle dal query analizer (o dal mgmnt studio)?

che vuol dire che l'applicazione crasha? che errore hai?

 Ciao Francesco, il crash dell'applicazione potrebbe anche essere causato da un problema di timeout.
Anche se la connessione non va in timeout, potrebbe andare in timeout il SqlCommand che se non erro di default è impostato a 30 secondi.

Potresti anche incorrere in un problema di DB corrotto e questo potrebbe spiegare il perchè il piano di esecuzione è buono e le performance pessime.
TI consiglio di eseguire DBCC CHECKDB per controllare il DB , DBCC DBREINDEX per ricostruire gli indici e di ricostruire le statistiche delle tabelle interessate dalla query con il comando UPDATE STATISTICS.

Se il problema persiste dovresti prendere in considerazione la possibilità che non sia un problema di dati ma un problema relativo alla struttura della query.
Se ci sono delle join ridondanti, la query potrebbe caricare una grande mole di dati, ricaricando gli stessi dati più volte. (una sorta di loop)

In questo caso la soluzione potrebbe essere quella di riscrivere la query , oppure dividere il processo in più passi utilizzando magari una stored.

A presto e buon lavoro.