La scelta dei dischi rigidi è fondamentale per ottenere buone prestazioni con SQL Server, tutte le versioni: 15000 rpm drive SAS ovviamente sovraperformare il SATA II 7200 rpm. Il primo offrirà un numero di input-output per tassi più elevati, secondo e quindi di più trasferimenti, che è estremamente importante per l'uso in un database del server in cui il fattore limitante è spesso la prestazione di RAID e non il processore.

Vi è una relativamente poco conosciuta per aumentare ulteriormente il numero di ingressi / output al secondo (IO / s) su Windows 2003 se si utilizza un allineamento delle partizioni RAID. Dal momento che la creazione di partizioni Windows 2008 gestisce automaticamente questa ottimizzazione su Windows 2003, ma deve essere fatto manualmente.

RAID 5

Continua a leggere "Allineamento delle partizioni per SQL Server"

Due guide alla migrazione in inglese a SQLServer 2005 e 2008 pubblicato da Microsoft. Sono estremamente completo (350 pagine e 490) e trattano argomenti che vanno dalla pianificazione della migrazione delle procedure da seguire in caso di migrazione di configurazioni ad elevata disponibilità tramite strumenti di gestione del cambiamento.

Spesso si legge che un indice ha un impatto negativo sulle prestazioni delle query in aggiornamento. Ho realizzato un micro-benchmark su una delle nostre tabelle interne per determinare l'impatto di un po 'più preciso.

La tabella è una tabella utilizzata per la produzione di linee 8.555.648, pesatura 550 MB e avente da 8 colonne. Una di queste colonne è un campo Email unico e un altro è la data di inserimento nel database in formato datetime.

L'applicazione che uso è:

  Aggiornamento R_Temp.dbo.Email
 Set Date_In = '04 / 09/2008 '
 Dove Email ('test@gmail.com')
 è nullo e Date_In 

Ecco il piano di esecuzione stimato sul tavolo senza un indice:

Poiché non vi è alcun indice, SQL Server deve eseguire una scansione di tabella, vale a dire pienamente la scansione della tabella per trovare righe che soddisfano la query. Qui ci sono i costi di questa scansione:

Stimato I / O Costo: 52,1454
CPU Costo stimato: 4,70565
Operatore Costo stimato: 56,8511
Costo stimato sottostruttura: 56,8511

Continua a leggere "Influenza del tipo di indice di un aggiornamento"

Per migliorare le prestazioni di SQL interroga il dato più frequentemente è quello di "creare un indice". Questo purtroppo non è così semplice, l'indice non ottimizzare determinati tipi di query, per non parlare che ci sono due tipi principali di indici compresi i vantaggi e gli svantaggi variano. Quindi, sempre una riflessione completa degli interessi dell'indice rispetto ai problemi che possono comportare, ma anche eseguire una serie di test per verificare che gli indici hanno davvero un effetto positivo sulle prestazioni di query utilizzato. Anche una semplice query Select non possono beneficiare di un indice.

Per illustrare questo ho fatto un micro-benchmark su SQLServer 2005 per confrontare le prestazioni di una tabella senza un indice (heap), un indice ordinato (cluster) e un indice non ordinata (cluster) sul seguente query :

  Selezionare count (*) dal Email R_Temp.dbo.EMAIL Dove piace ('% Fred') 

Il tavolo ha 8,555,648 righe, pesa 550 Mb ed è composto da otto colonne. Il campo Email è unico.

Ecco il piano di esecuzione stimato per questa query sul tavolo senza un indice:

SQLServer deve attraversare l'intera tabella qui (Table Scan) per trovare le righe che soddisfano la query e il costo è molto alto: viene eseguito in 2,5 secondi sul mio server.

Continua a leggere "Influenza del tipo di indici su una Select"

Per determinare quali utenti sono monopolizzando di SQL Server è sufficiente utilizzare la seguente query:

SELECT
TOP 20
SPID, Blocked,
convert(varchar(10),db_name(dbid)) as Base,
CPU,
datediff(second,login_time, getdate())/60 as Minutes,
convert(float, cpu / datediff(second,login_time, getdate())) as PScore,
convert(varchar(16), hostname) as Hôte,
convert(varchar(20), loginame) as Login,
convert(varchar(50), program_name) as Programme
FROM master..sysprocesses
WHERE datediff(second,login_time, getdate()) > 0 and SPID > 50
ORDER BY PScore desc

Plus le PScore est élevé plus l’utilisation de la base est intensive.

De la même manière on peut déterminer les programmes les plus gourmands en observant la colonne BFactor lors de l’exécution de la requête suivante :

SELECT
convert(varchar(50), program_name) as Programme,
count(*) as CliCount,
sum(cpu) as CPUSum,
sum(datediff(second, login_time, getdate())) as SecSum,
convert(float, sum(cpu)) / convert(float, sum(datediff(second, login_time, getdate()))) as Score,
convert(float, sum(cpu)) / convert(float, sum(datediff(second, login_time, getdate()))) / count(*) as BFactor
FROM master..sysprocesses
WHERE spid > 50
GROUP BY
convert(varchar(50), program_name)
ORDER BY score DESC