Il TEMPDB e la sua configurazione.. pronti per le Ferie?

Innanzitutto grazie per le tante visualizzazioni ricevute!


Anche perchè diciamocelo, siamo in un periodo, quello a ridosso delle ferie estive, che certo non invoglia letture profonde e complicate.
Già certo, proprio non mi immagino qualcuno a leggere questo mio articolo sotto l’ombrellone!
Cercherò quindi di essere chiaro, conciso ...insomma breve.

Nello scorso articolo ho cercato di spiegare perché il database TEMPDB di SQL SERVER è importante.
Oggi, per continuare questo discorso vorrei raccontarvi qualcosa su come configurarlo correttamente. 

 

Configurare il database TempDB correttamente

Premesso che è sempre preferibile farlo risiedere sul disco più veloce di cui si dispone iniziamo dicendo che per impostarlo occorre prima di tutto eseguire il SQL Server Management Studio (SMSS). 

Dopo aver trovato tra i database di sistema il nostro TEMPDB fare tasto destro e scegliere la voce proprietà:

 



Si apre una finestra che ci mostra i due file fisici di cui è composto il database TEMPDB:

 

Nelle versioni meno recenti di SQL Server vengono creati due file.
Un file dati ed un file di log.

Innanzitutto le dimensioni dei due file sono minime.
Quello che succede è che appena i dati superano questa dimensione il sistema operativo sarà costretto ad aumentarne la dimensione.
Se questa operazione di resizing è frequenza avremo un decadimento delle prestazioni.

Per questo motivo è consigliabile dimensionare correttamente nel momento dell'installazione la loro dimensione.
L'obiettivo finale è quello di dimensionare i files in modo tale questa operazione di aumento delle dimensioni non avvenga mai oppure avvenga raramente.

Altro aspetto.

I server al giorno d'oggi dispongono di un numero di processori elevato.
Se però il file dati del TEMPDB è uno solo sarà comunque uno solo dei processori ad occuparsi di scrivere in questo file.

Da questo nasce l'idea di creare un file dati del TEMPDB per processore oppure ogni 2 o 4 processori.
Nell'immagine sotto sono stati creati 4 file su un server dotato di 8 processori.


Importante aspetto è quello di dimensionare i files tutti della stessa dimensione e incremento della dimensione.
Solo solo in questo modo SQL Server scriverà dentro di essi in modo parallelo.

Si dice in gergo che SQL Server adotta una logica di "Round Robin" ma per oggi non andiamo troppo in dettaglio ....è pur sempre fine luglio!

Un ultimo ma importante consiglio: se non abbiamo nessun problema di performance non andiamo a modificare la configurazione.
Solo per abbiamo problemi di prestazioni e se vediamo che il collo di bottiglia è proprio il TEMPDB allora Si!

Come dite? Come fare per determinare se il problema delle nostre scarse performance dipende dal TEMPDB?
Bhe, questo sarà argomento di un prossimo articolo..

A presto!


Luca Biondi @ SQLServerPerformance blog!

 
 
 



 

Comments

Post a Comment

I Post più popolari

SQL Server, execution plan and the lazy spool (clearly explained)

Image
Hi Guys, Welcome back! In one of the last posts we talked about Table Spool . We had explained what Spool are for by telling the somewhat curious story of the halloween problem . Here we specifically talked about a type of spool called Eager Spool   You can look to the execution plan below where the eager Spool is used to avoid the halloween problem in classic query of the "salary increase".. i suggest Well, if the story of the eager spool intrigued you, today instead we will speak about another type of Spool, the Lazy Spool . The Lazy spool Let's take a small step back. So, what is a Spool operation?  As we have already understood a spool operation is simply a temporary storage of data . Data are read from a source table and stored inside a worktable in the Tempdb database . While an Eager Spool is used to prevent the Halloween problem, the Lazy Spool is instead used to store data that will later be needed again when running a query . So, when a Lazy spool is used?  ...
Read more

SQL Server, datetime vs. datetime2

Image
Hi guys, This time, in this post we will speak about datetime and datetime2 datatypes. We will talk about the pros and cons. We will talk about all the differences between the two types of data. Write me in the comments which type of data do you prefer between the two. Enjoy the reading!     Datetime Vs. Datetime2 First of all, it must be said that the datatype datetime is certainly the best known native format for storing a date in SQL Server. However, Microsoft has also been introducing a new type of data for many years now, also used to manage dates. It is in fact from SQL server 2008 that it is present in datetime2 data type. This "new" type of data was born primarily to have higher accuracy . Let's in fact talk about ... precision ! Datetime Certainly the datetime data type is not very precise and certainly there are many cases in which its precision is simply not sufficient. Let's see it with an example. Open the SQL Management studio (SSMS) and write the fo...
Read more

La clausola NOLOCK. Approfondiamo e facciamo chiarezza!

Image
Ehi ragazzi! La domanda è di quelle importanti! Siete pronti per scoprire tutto ma proprio tutto sulla clausola NOLOCK?   Se la riposta è si, allora seguitemi! Oggi ne spiegheremo il funzionamento in maniera approfondita. Faremo una introduzione al concetto di tipi di LOCK Ed infine vedremo come mai una SELECT ne può bloccare un'altra. Non vi nascondo che il motivo di questo articolo è fare chiarezza. Su questo argomento si sentono spesso affermazioni “curiose” ma tra le tante questa è la prima: “ uso la SELECT con l’opzione WITH(LOCK) così non blocco le altre tabelle ”.   Ma, è proprio vero quanto affermato? Beh oggi facciamo il punto!   Buona lettura!     La clausola NOLOCK Diciamo subito per iniziare che cos’è la NOLOCK. NOLOCK è il nome di una clausola che è possibile specificare all’interno di uno statement di tipo SELECT utilizzando la seguente sintassi: SELECT * FROM TABELLA WITH (NOLOCK) Si noti che non possiamo ...
Read more