Lentezza in query (indici e statistiche)

martedì 16 aprile 2013 - 16.52

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags Windows Server 2003 | SQL Server 2008 R2

massimo1965 Profilo | Junior Member

134 messaggi | Data Invio: mar 16 apr 2013 - 16:52

Ciao a Tutti
ho verificato che con un sistem SQL 2008 r2 32 bit exp installato su un 2003 server devo necessariamente eseguire ogni giorno il comando
use MioDataBase
go
EXEC sp_updatestats @resample = 'resample'
GO
per evitare che in fase di selezione vi siano dei ritardi impressionanti da 20 sec. a 1 sec.

Quello che trovo strano è che devo eseguire questo comando anche un paio di volte nell'arco della giornata.

Qualche idea ?
Grazie
MV

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 17 apr 2013 - 11:35

>Ciao a Tutti
ciao

>Quello che trovo strano è che devo eseguire questo comando anche
>un paio di volte nell'arco della giornata.
beh dipende molto dal tipo di operazioni che fai ed, in generale, anche dal numero di righe che devi gestire.
Ma, prima di tutto, hai il flag auto update statistics a true?
Sei sicuro che le statistiche non siano aggiornate da molto (controllale per capire come sono automaticamente manutenute).
Usi stored procedures o comandi diretti?
Lo trovi nelle proprietà del database, sezione Options.

>Grazie
di nulla!

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

massimo1965 Profilo | Junior Member

134 messaggi | Data Invio: mer 17 apr 2013 - 18:53

>>Ciao a Tutti
>ciao
>
>>Quello che trovo strano è che devo eseguire questo comando anche
>>un paio di volte nell'arco della giornata.
>beh dipende molto dal tipo di operazioni che fai ed, in generale,
>anche dal numero di righe che devi gestire.
>Ma, prima di tutto, hai il flag auto update statistics a true?
>Sei sicuro che le statistiche non siano aggiornate da molto (controllale
>per capire come sono automaticamente manutenute).
>Usi stored procedures o comandi diretti?
>Lo trovi nelle proprietà del database, sezione Options.

Alessandro
diciamo che in tutto si svolge in 2/3 ore e da 4 posti di lavoro vengoni inserite mediante al giorni
1800/2000 registrazioni, tramite comandi diretti INSERT / UPDATE
Il rallentamento si registra dopo questo periodo di massivo inserimento
Nelle opzioni del database trovo
Aggiornamento automatico stat = true
Creazione automatica = true

le statistiche le aggiorno dopo il backup serale con il comando EXEC sp_updatestats @resample = 'resample'
ma dato che non uso indici e chiavi primario, queste statistiche servono o no ?
(scusa l'ignoranza)

>
>>Grazie
>di nulla!

>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/profiles/Alessandro.Alpi

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 24 apr 2013 - 01:13

>Alessandro
>diciamo che in tutto si svolge in 2/3 ore e da 4 posti di lavoro
>vengoni inserite mediante al giorni
>1800/2000 registrazioni, tramite comandi diretti INSERT / UPDATE
>Il rallentamento si registra dopo questo periodo di massivo inserimento
>Nelle opzioni del database trovo
>Aggiornamento automatico stat = true
>Creazione automatica = true
>le statistiche le aggiorno dopo il backup serale con il comando
>EXEC sp_updatestats @resample = 'resample'
>ma dato che non uso indici e chiavi primario, queste statistiche
>servono o no ?
le insert, se non hai alcun indice (tanto meno cluster), non ti daranno mai problemi.
Credo che i rallentamenti li hai sulle update, che all'inizio magari vanno forte (poche righe con statistiche aggiornate) ma poi, a mano a mano che le righe aumentano e che le statistiche non si aggiornano, peggiorano drasticamente.
La chiave primaria direi che va fatta nel tuo caso, perchè sono convinto che le updates possano sfruttarla (visto che immagino che le update vadano per una chiave tua, diciamo).
Le statistiche servono a sql per decidere quale piano di esecuzione fare per un particolare comando (che poi, quando sql riesce, viene messo in cache, per il riutilizzo eventuale).

Io ti consiglio di fare, almeno un cluster per ogni tabella interessata. Se vuoi anche PK ma quello non è necessario a meno che non sia un requisito di modello (una PK è un indice cluster le cui chiavi non accettano null). e l'indice cluster corrisponde alla chiave e anche, se possibile, alle where delle tue update, secondo me ci prederai tantissimo.. Ma mi servirebbe vedere un po' di tabelle ed un traffico di esempio.
Non riesci a darmi un database fake con un traffico che già ti dà un rallentamento?

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

massimo1965 Profilo | Junior Member

134 messaggi | Data Invio: mer 24 apr 2013 - 10:54

>>Alessandro
>>diciamo che in tutto si svolge in 2/3 ore e da 4 posti di lavoro
>>vengoni inserite mediante al giorni
>>1800/2000 registrazioni, tramite comandi diretti INSERT / UPDATE
>>Il rallentamento si registra dopo questo periodo di massivo inserimento
>>Nelle opzioni del database trovo
>>Aggiornamento automatico stat = true
>>Creazione automatica = true
>>le statistiche le aggiorno dopo il backup serale con il comando
>>EXEC sp_updatestats @resample = 'resample'
>>ma dato che non uso indici e chiavi primario, queste statistiche
>>servono o no ?
>le insert, se non hai alcun indice (tanto meno cluster), non
>ti daranno mai problemi.
>Credo che i rallentamenti li hai sulle update, che all'inizio
>magari vanno forte (poche righe con statistiche aggiornate) ma
>poi, a mano a mano che le righe aumentano e che le statistiche
>non si aggiornano, peggiorano drasticamente.
>La chiave primaria direi che va fatta nel tuo caso, perchè sono
>convinto che le updates possano sfruttarla (visto che immagino
>che le update vadano per una chiave tua, diciamo).

la chiave che uso è un identity che si incrementa autonomamente,
la imposto ugualmente come chiave primaria ?

>Le statistiche servono a sql per decidere quale piano di esecuzione
>fare per un particolare comando (che poi, quando sql riesce,
>viene messo in cache, per il riutilizzo eventuale).
>
>Io ti consiglio di fare, almeno un cluster per ogni tabella interessata.
un cluster ? ammazza quanto sono ignorante....mi documento su come farlo e che cosa è
e al limite disturbo ancora....

>Se vuoi anche PK ma quello non è necessario a meno che non sia
>un requisito di modello (una PK è un indice cluster le cui chiavi
>non accettano null). e l'indice cluster corrisponde alla chiave
>e anche, se possibile, alle where delle tue update, secondo me
>ci prederai tantissimo.. Ma mi servirebbe vedere un po' di tabelle
>ed un traffico di esempio.
>Non riesci a darmi un database fake con un traffico che già ti
>dà un rallentamento?

questo è un problema, perchè si lavora di notte al limite ti posso dare il risultato del comando
sp_updatestats

Grazie e Ciao
MV
>
>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/profiles/Alessandro.Alpi

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 24 apr 2013 - 11:20

>la chiave che uso è un identity che si incrementa autonomamente,
>la imposto ugualmente come chiave primaria ?
non è necessario, ma di certo è più corretta. SQL te la imposterà come clustered, ovvero ordinerà i dati in base a quel campo.

>un cluster ? ammazza quanto sono ignorante....mi documento su
>come farlo e che cosa è e al limite disturbo ancora....
semplicemente è l'ordinamento con cui la tabella viene salvata. Puoi ben capire che se poi cerchi per la chiave dell'indice, la ricerca, sfruttando l'ordinamento, ci metterà molto meno.

>questo è un problema, perchè si lavora di notte al limite ti
>posso dare il risultato del comando
no no, mi serve proprio un database con un flusso dati.. altrimenti proprio non so come aiutarti

di base, dovresti partire con questa idea:
- le insert non daranno problemi, essendo append e non avendo chissà che struttura da allineare
- le update accelerano se usi delle where, e se quelle where sono simili alle chiavi per cui hai disegnato un indice
- disegna l'indice adatto (o più d'uno)
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

massimo1965 Profilo | Junior Member

134 messaggi | Data Invio: gio 25 apr 2013 - 00:04

>>la chiave che uso è un identity che si incrementa autonomamente,
>>la imposto ugualmente come chiave primaria ?
>non è necessario, ma di certo è più corretta. SQL te la imposterà
>come clustered, ovvero ordinerà i dati in base a quel campo.
>
>>un cluster ? ammazza quanto sono ignorante....mi documento su
>>come farlo e che cosa è e al limite disturbo ancora....
>semplicemente è l'ordinamento con cui la tabella viene salvata.
>Puoi ben capire che se poi cerchi per la chiave dell'indice,
>la ricerca, sfruttando l'ordinamento, ci metterà molto meno.
>
>>questo è un problema, perchè si lavora di notte al limite ti
>>posso dare il risultato del comando
>no no, mi serve proprio un database con un flusso dati.. altrimenti
>proprio non so come aiutarti

vedo se riesco a schedulare un backup, prima che parta il riordino degli indici
e poi ci mettiamo d'accordo su come fartelo avere...

>
>di base, dovresti partire con questa idea:
>- le insert non daranno problemi, essendo append e non avendo
>chissà che struttura da allineare
>- le update accelerano se usi delle where, e se quelle where
>sono simili alle chiavi per cui hai disegnato un indice
>- disegna l'indice adatto (o più d'uno)
ok
provo a mettere la chiave primaria come suggerito e vedo un po' cosa mi dicono...

ti ringrazio
MV

>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/profiles/Alessandro.Alpi

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 25 apr 2013 - 02:15

>provo a mettere la chiave primaria come suggerito e vedo un po'
>cosa mi dicono...
non ti ho suggerito la chiave, ma un indice per velocizzare le update.. ma questo lo devi conoscere tu, almeno fino a che non mi passi qualche info aggiuntiva..
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

massimo1965 Profilo | Junior Member

134 messaggi | Data Invio: gio 6 giu 2013 - 11:11

Alessandro
scusa ma non riesco a "portare via" il database.
Ad ogni modo penso che il problema sia anche l'installazione sul W2003 a breve converto tutto su un W2008 64 bit con SQL Standard Ed. Nel caso ti aggiorno.....
Per adesso grazie.

Massimo

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !