Parere ad esperto su db sqlserver 2000

giovedì 10 settembre 2009 - 11.22

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

ReRosso Profilo | Junior Member

67 messaggi | Data Invio: gio 10 set 2009 - 11:22

Ciao ragazzi...

Volevo un parere tecnico sul volume dati di un db sql server 2000.

Ho una tabella che può accumulare nel corso di un anno di esercizio circa 500.000 record. I dati mantenuti in tabella dovrebbero rimanere memorizzati per circa 3 anni e poi potenzialmente eliminati.

Le query di aggiornamento previste coinvolgono al massimo un record alla volta. Le query di selezione recuperano al massimo 20-30 record alla volta.

L'applicazione che lancia le query è di tipo web e sfrutta la modalità connessa (quindi con un data-reader).

La domanda è: la mole di dati specificata può causare rallentamenti nell'esecuzione delle query e se si in maniera sensibile??? E' consigliabile creare nel db una tabella storico in cui a fine anno scaricare i dati della tabella di lavoro?

Vorrei evitare finezze inutili....

Grazie a tutti

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 10 set 2009 - 11:52

>Ciao ragazzi...
Ciao

>La domanda è: la mole di dati specificata può causare rallentamenti
>nell'esecuzione delle query e se si in maniera sensibile??? E'
>consigliabile creare nel db una tabella storico in cui a fine
>anno scaricare i dati della tabella di lavoro?
500000 non sono poi tanti, nemmeno dopo 3 anni, ma dipende anche dal server che hai.
Poi SQL Server 2000 non è proprio il top della gamma, quindi, intanto mi viene da consigliarti almeno 2005

.
A parte queste considerazioni, forse la cosa migliore è spostare ogni anno i record in una tabella a parte, non esistendo su 2000 il partizionamento..
Del resto, devi capire dove ti servono le prestazioni, se in lettura, penserei seriamente anche ad un set di indici ben mirati.

>Grazie a tutti
di nulla!

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

ReRosso Profilo | Junior Member

67 messaggi | Data Invio: gio 10 set 2009 - 14:30

bè e' confortante...

a questo punto però ho un altro quesito.

se prevedo un query di eliminazione che una volta l'anno faccia la delete dei record più vecchi di tre anni è secondo te una soluzione praticabile?
diciamo che la tabella rimarrebbe costantemente su un livello di circa 1.500.000 record.

Eventualmente come creo un set di indici?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 10 set 2009 - 14:50

>se prevedo un query di eliminazione che una volta l'anno faccia la delete dei record più vecchi di tre anni è secondo te una soluzione praticabile?
Se puoi permetterti di avere così tanti record sì. Ma fai attenzione che se la tabella è poco normalizzata e senza indici le interrogazioni ci metteranno tanto.

>Eventualmente come creo un set di indici?
Con quel numero di record diventano necessari. Devi studiare i tipi di richiesta che si vanno a fare sulle tabelle. Ed in base a quello, studiando i piani di esecuzione, scegli come fare gli indici.

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

ReRosso Profilo | Junior Member

67 messaggi | Data Invio: gio 10 set 2009 - 18:58

Scusa se mi ripeto Axl...

ma tradotto in parole povere....tutte le tabelle del db sono caratterizzate da un campo "ID" di tipo int, impostato come identità con incremento automatico di 1, chiave primaria e il flag "crea come clustered".

Tutte le query di selezione sono eseguite sui campi "ID"; è questo che intendi per indici????

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 10 set 2009 - 23:13

>ma tradotto in parole povere....tutte le tabelle del db sono
>caratterizzate da un campo "ID" di tipo int, impostato come identità
>con incremento automatico di 1, chiave primaria e il flag "crea
>come clustered".
>Tutte le query di selezione sono eseguite sui campi "ID"; è questo che intendi per indici????
Quando crei una tabella da designer ed inserisci un campo ID che flagghi come chiave primaria, Enterprise Manager si occupa in automatico (se non diversamente specificato) di farti non solo il vincolo di univocità e di PRIMARY KEY (quindi anche non NULLABLE), bensì anche un INDICE CLUSTERED di default. Gli indici possono essere di due tipi, CLUSTERED appunto e NONCLUSTERED. Del primo tipo su SQL Server (ma non su tutti gli RDBMS) ne può esistere SOLO UNO, e definisce l'ordinamento fisico della tabella in memoria. Dell'altro invece puoi farne quanti ne vuoi, anche se il numero deve essere dipendente dai tipi di interrogazioni che fai.
Di solito, puoi permetterti di lasciare il tuo "ID" come clustered. Sappi che la tabella è ORDINATA fisicamente secondo il valore di quel campo. Se è autoincrementante (identità) sei sicuro di inserire sempre in nuove locazioni dell'indice senza inserire "in mezzo" all'albero che crei per l'ordinamento.
In parole molto povere un indice è un albero che consente il reperimento più veloce delle informazioni. Quello clustered è quello che tiene ordinato la tabella fisicamente, gli altri sono i vari ordinamenti che vuoi dare ai campi che definisci per l'indice per raggiungere la tabella. Non è un discorso molto semplice, ma prendi l'elenco del telefono.. Se non sapessi che è tutto in ordine di CITTA', PAESE, COGNOME, dovresti scansionare tutto il libro. Quei tre valori di ordinamento sono un indice CLUSTERED poichè ordinano i dati sul libro. All'inizio poi, hai un indice che punta a tutti i PAESI, dicendoti di che provincia fanno parte. Quello può essere un NONCLUSTERED perchè facilita la consultazione, ti permette di arrivare al paese, ma poi devi usare l'ordinamento del libro (il CLUSTERED).

Ora, nel tuo caso, dovresti:
- prendere tutte le interrogazioni che vai a fare sul db, tipicamente le SELECT
- dare priorità alle WHERE e ai criteri di JOIN, per poi arrivare a quali campi metti nelle SELECT stesse. Mi raccomando, MAI usare SELECT *, perchè non faciliti la vita al Query Processor..
- Eseguire con Query Analyzer le query, una ad una includendo il piano di esecuzione
- Con il piano di esecuzione alla mano, capire dove evitare inutili SCAN, laddove puoi ottenere SEEK
- Usare SET STATISTICS TIME ON e SET STATISTICS IO ON per vedere le letture che le query fanno
- In base al modello, creare INDICI appositi, a questo punto, visto che il clustered lo hai già, nonclustered

Solo col modello alla mano e tentando di capire come ragiona il motore puoi ottimizzare e fare tuning delle query.
Spero di essere stato chiaro almeno un po'..

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

ReRosso Profilo | Junior Member

67 messaggi | Data Invio: ven 11 set 2009 - 12:30

Grazie per l'assistenza
ciao...

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 !