Drift av SQL Server-system

Korrekt konfiguration av IO delsystem är avgörande för optimal prestanda och drift av SQL Server-system. Nedan finns några av de vanligaste bästa praxis att SQL Server.

 Förstå IO egenskaper SQL Server och de särskilda krav IO / egenskaper för din applikation.

För att vara framgångsrik i att designa och distribuera förvaring för din SQL Server-program måste du ha en förståelse för ditt program IO egenskaper och en grundläggande förståelse för SQL Server IO mönster. Performance Monitor är den bästa platsen att fånga denna information för ett befintligt program. Några av de frågor du bör ställa dig här är:

Vad är läs vs skriva kvoten av applikation?

Vilka är de typiska IO priser (IO per sekund, MB / s och storlek informationskravens)? Övervaka perfmon räknare:

* Average läsa bytes / sek, i genomsnitt skriver bytes / sek

** Läs/sec, skriver / sek

*** Disk läsa bytes / sek, disk skriva bytes / sek

**** Average disk sec / läs, genomsnittlig disk sek / skriva

***** Average Disk Queue Length

Hur mycket IO är sekventiell i naturen, och hur mycket IO är slumpmässigt i naturen? Är detta främst en OLTP program eller en Relational Data Warehouse applikation ?

För att förstå kärnan egenskaper SQL Server IO, se till SQL Server 2005 I / O-Basics.

Fler och snabbare spindlar är bättre för prestanda

Kontrollera att du har tillräckligt många spindlar för att stödja din IO krav med en acceptabel latency.

Använd filgrupper för administration krav som t.ex. backup / restore, partiell databas tillgänglighet mm

Använd datafiler till “stripe” i databasen över din specifika IO-konfiguration (fysiska diskar, LUN, etc.).

 Försök att inte “över” optimera utformningen av lagring, enklare konstruktioner i allmänhet leder till bra prestanda och större flexibilitet.

Om du inte förstår ansökan mycket väl undvika att försöka över optimera IO genom att selektivt att placera objekt på olika spindlar.

Se till att fundera över den tillväxtstrategi up front. När din data storlek växer, hur kommer du hantera tillväxt av datafiler / LUN / RAID grupper? Det är mycket bättre att designa för detta up front än att omfördela datafiler och LUN (er) senare i en produktion distribution.

Validera konfigurationer före installationen

Har grundläggande genom strömning provning av IO delsystemet innan driftsättning SQL Server. Se till att dessa prov har möjlighet att uppnå dina IO krav med en acceptabel latency. SQLIO är ett sådant verktyg som kan användas för detta. Ett dokument ingår i verktyget med grunderna för testning en IO delsystemet. Ladda SQLIO Disk Subsystem Benchmark Tool.

Förstå att det i syfte att köra SQLIO test inte är att simulera SQL Server exakta IO egenskaper utan snarare för att testa maximal genomströmning kan uppnås genom IO delsystem gemensam SQL Server IO typer.

IOMETER kan användas som ett alternativ till SQLIO.

* Placera alltid loggfiler på 1 0 RAID (eller RAID 1) diskar. Detta ger:

** bättre skydd mot hårdvarufel, och

*** bättre skrivprestanda.

Obs: I allmänhet RAID 1 0 ger bättre genomströmning för skriva-intensiva applikationer. De resultatbaserade som gjorts kommer att variera beroende på HW säljarens RAID implementationer. Vanligaste alternativet till RAID 1 0 är RAID 5. Generellt, RAID 1 0 ger bättre skrivprestanda än någon annan RAID-nivå som kan ge skydd, inklusive RAID 5.

* Isolera logg från data på den fysiska disken nivå

När detta inte är möjligt (t.ex. konsoliderad SQL miljöer) anser I / O-egenskaper och gruppera liknande I / O-egenskaper (dvs. alla loggar) om gemensamma spindlar.

Kombinera heterogen arbetsbelastning (arbetsbelastning med mycket olika IO och egenskaper latens) kan ha negativa effekter på det totala resultatet (t.ex. placering Exchange och SQL på samma fysiska spindlar).

* Överväg konfiguration av tempdb databas

Se till att flytta tempdb till adekvat lagring och pre-storlek efter installationen av SQL Server.Prestanda kan gynnas om tempdb placeras på RAID 1 0 (beroende på tempdb användning).

För tempdb databas, skapa en datafil per CPU, vilket beskrivs i # 7 nedan.

Foder upp antalet datafiler med CPU’s har skalbarhet fördelar för tilldelning intensiva arbetsbelastningar.

Det rekommenderas att ha 0,25 till 1 datafiler (per filgrupp) för varje processor på den mottagande servern.

Detta gäller särskilt för tempdb där rekommendationen är 1 datafil per CPU.

Dual Core räknas som 2 processorer, logisk procs (hyperthreading) inte gör det.

Bortse inte från några av SQL Server grunderna

Datafiler bör vara av samma storlek – SQL Server använder en proportionell fylla algoritm som gynnar anslagen i filer med mer ledigt utrymme.

Pre-storlek data-och loggfiler.

Lita inte på autogrow stället hantera tillväxten av dessa filer manuellt. Du kan lämna autogrow PÅ av säkerhetsskäl, men du bör proaktivt hantera tillväxten av datafiler.

Khan – MS SQL DBA – MCTS

Sharing knowledge occurs when people are genuinely interested in helping one another develop new capacities for action; it is about creating learning processes.  www.addarr.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: