En hög diskkölängd betyder inte att du har en I/O-flaskhals om du har ett SAN eller NAS, du kanske vill titta på andra ytterligare räknare. Kolla in SQL Server Urban Legender diskuteras för mer information.
1:Följande operationer använder kraftigt tempdb
- Upprepade skapande och släpp av tillfälliga tabeller (lokala eller globala)
- Tabellvariabler som använder tempdb för lagringsändamål
- Arbetstabeller kopplade till CURSOR
- Arbetstabeller associerade med en ORDER BY-sats
- Arbetstabeller associerade med en GROUP BY-sats
- Arbetsfiler associerade med HASH PLANS
Dessa SQL Server 2005-funktioner använder också tempdb kraftigt:
- versionshantering på radnivå (snapshotisolation)
- ombyggnad av onlineindex
Som nämnts i andra SO-svar, läs denna artikel
om bästa praxis för att öka tempdb-prestanda.
2:Att titta på mängden ledigt RAM-minne på servern, dvs. titta på WMI-räknaren Minne->Available Mbytes hjälper inte eftersom SQL Server cachelagrar datasidor i RAM, så alla db-server som körs tillräckligt länge kommer att ha lite ledigt RAM.
Räknarna du bör titta på som är mer meningsfulla när det gäller att tala om för dig om att lägga till RAM till servern är:
SQL Server Instance:Buffer Manager->Sidlivslängd (i sekunder) Ett värde under 300-400 sekunder innebär att sidorna inte finns i minnet särskilt länge och att data kontinuerligt läses in från diskar. Servrar som har en låg förväntad sidlivslängd kommer att dra nytta av ytterligare RAM.
och
SQL Server Instance:Buffer Manager->Buffer Cache hit Ratio Detta talar om procentandelen av sidor som lästes från RAM som inte behövde läsas från disk, ett cache-träffförhållande lägre än 85 kommer att innebära att servern kommer att dra nytta av ytterligare RAM
3 :Ja, det kan inte gå fel här. Att ha tempdb på en separat uppsättning diskar rekommenderas. Titta på denna KB-artikel
under rubriken:Flytta tempdb-databasen om hur man gör detta.