SQL Server Ytelsesmonitor: En komplett guide [2026]

SQL Server Ytelsesmonitor er prosessen med å spore, analysere og administrere ytelsen og tilstanden til SQL Server databaser. Det innebærer å samle inn og tolke data om ulike aspekter av databasesystemet ditt for å sikre optimal ytelse, forhindre problemer og opprettholde databasetilstanden.

Ytelsesovervåking omfatter sporing av utførelsestider for spørringer, ressursutnyttelse, indeksytelse, blokkering og vranglåser og databasevekstmønstre. Denne kontinuerlige overvåkingen hjelper administratorer med å identifisere potensielle problemer før de påvirker brukere eller forretningsdrift.

1.2 Viktige fordeler med ytelsesovervåking

Effektiv SQL Server Ytelsesmonitoren gir flere viktige fordeler:

Proaktiv problemdeteksjon: Identifiser og håndter potensielle problemer før de påvirker brukere eller forretningsdrift
Ytelsesoptimalisering: Identifiser flaskehalser og ineffektivitet for å forbedre den generelle databaseytelsen
Kapasitetsplanlegging: Prognostisere ressursbehov og planlegge fremtidig vekst basert på historiske data
Samsvar og sikkerhet: Sørg for at regelverket overholdes og at mistenkelig aktivitet oppdages

1.3 Vanlige ytelsesutfordringer

Uten skikkelig ytelsesovervåking av SQL-databasen står organisasjoner overfor flere risikoer:

Uventet nedetid som forstyrrer forretningsdriften
Dårlig applikasjonsytelse som påvirker brukeropplevelsen
Datatap eller korrupsjon
Ineffektiv ressursutnyttelse som fører til unødvendige kostnader
Frustrerte brukere og potensielt inntektstap

Ifølge en IDC-studie fra 2023 stammer 65 % av problemer med databaseytelse fra dårlig overvåking eller optimaliseringspraksis.

2. Forstå Windows Ytelsesmonitor (PerfMon)

2.1 Hva er Windows Ytelsesmåler?

Windows Performance Monitor (PerfMon) er et innebygd Windows-verktøy som overvåker systemressurser og programytelse. For eksempel SQL Server administratorer, PerfMon gir uvurderlig innsikt i både operativsystem og SQL Server målinger, noe som gjør det avgjørende for omfattende ytelsesanalyse.

PerfMon måler ytelsesstatistikk med jevne mellomrom og lagrer denne statistikken i filer for senere analyse. Databaseadministratorer kan velge tidsintervall, filformat og hvilken statistikk som skal overvåkes. Verktøyet er ikke SQL Server-spesifikk – systemadministratorer bruker den til å overvåke selve Windows, Exchange, filservere og alle applikasjoner som kan oppleve flaskehalser.

2.2 Starte Ytelsesmonitor

Du kan starte Ytelsesmonitoren på flere måter:

Klikk Start, Type perfmon I søkeboksen klikker du på «Ytelsesmonitor» i søkeresultatet:
Press Windows + R, Type perfmon, og trykk Enter
naviger til kontroll Panel -> System og sikkerhet -> Administrative verktøy -> Ytelsesmåler

3. Essential SQL Server Ytelsestellere

3.1 Minneytelsestellere

Minnetellere er kritiske for overvåking SQL Server ytelse, da de indikerer om databasen din har tilstrekkelige minneressurser.

Tilgjengelige MByte

Denne telleren viser mengden fysisk minne som er umiddelbart tilgjengelig for allokering. Den bør forbli noenlunde konstant og ideelt sett ikke falle under 4096 MB. Lave verdier kan indikere at SQL Servers maksimale minneinnstilling er stående på standard, eller ikke-SQL Server applikasjoner bruker opp minne.

Forventet levealder på side

Forventet sidelevetid måler hvor lenge (i sekunder) en side forblir i bufferbassenget uten å bli referert til. En normal verdi er 300 sekunder eller mer. Lavere verdier indikerer minnetrykk og overdreven bufferomsetning, noe som reduserer hurtigbufferens effektivitet.

Bufferbufferbuffertreffforhold

Denne telleren angir prosentandelen av dataforespørsler som blir besvart ved hjelp av SQL-bufferhurtigbufferen (minnet) i stedet for å lese fra disk. Den møter vanligvis eller overstiger 99 %. Lavere verdier antyder at SQL Server trenger mer minne eller varmes fortsatt opp etter en omstart.

Minnetilskudd venter

Dette viser antall prosesser som venter på minne innenfor SQL ServerUnder normale forhold skal denne verdien konsekvent være 0. Høyere verdier indikerer utilstrekkelig minneallokering til SQL Server.

Målserverminne vs. totalt serverminne

Målserverminne indikerer den ideelle mengden minne SQL Server ønsker å bruke. Totalt serverminne viser hva SQL Server bruker for øyeblikket. Forholdet mellom disse verdiene skal være omtrent 1. Vesentlige forskjeller kan indikere minnebelastning eller utilstrekkelig tilgjengelig minne.

3.2 Prosessorytelsestellere

CPU-tellere hjelper med å identifisere flaskehalser i prosessorer og forstå hvordan SQL Server bruker dataressurser.

% Prosessortid

Dette måler prosentandelen av forløpt tid prosessoren bruker på å kjøre ikke-inaktive tråder. På aktive servere kan verdiene øke til 100 %, men vedvarende bruk over 70–75 % indikerer vanligvis ytelsesproblemer for brukere. Manglende eller utilstrekkelige indekser forårsaker ofte høy CPU-bruk.

% Privilegert tid

Prosessortiden er delt inn i brukermodus og privilegert (kjerne) modus. All disktilgang og I/O skjer i kjernemodus. Hvis denne telleren overstiger 25 %, utfører systemet sannsynligvis for mye I/O. Normale verdier varierer mellom 5 % og 10 %.

Prosessorkølengde

Denne telleren viser tråder som venter på CPU-ressurser. Verdier som er konsekvent over 1 (unntatt under SQL Server sikkerhetskopieringskomprimering) indikerer CPU-trykk. Dette betyr ofte at andre programmer er installert på SQL Server maskin, noe som bryter med beste praksis.

Kontekstbrytere/sek

Dette måler hvor ofte prosessoren bytter mellom tråder. Overdreven kontekstbytte kan påvirke ytelsen og indikerer høy systembelastning.

3.3 Ytelsestellere for disk-I/O

Disktellere er viktige for SQL-ytelsesovervåking, ettersom disk-I/O ofte blir den primære flaskehalsen i databasesystemer.

% disktid

Dette registrerer prosentandelen av tiden disken var opptatt med lese-/skriveoperasjoner. Verdier som konsekvent er over 85 % indikerer en I/O-flaskehals. Siden disken er mye tregere enn minne, forbedres ytelsen ved å redusere denne målingen.

Gj.sn. disksek/lesing og gj.sn. disksek/skriving

Disse tellerne måler gjennomsnittlig tid (i sekunder) for lese- og skriveoperasjoner. Hvis gjennomsnittsverdiene overstiger 10–20 ms, bruker disken for lang tid på å behandle data. Transaksjonsloggstasjoner krever spesielt rask skriveytelse.

Lengde på diskkø

Dette viser utestående forespørsler om å lese/skrive til disk. Verdier som er konsekvent høyere enn 2 (eller 2 per disk for RAID-arrayer) indikerer at disken ikke kan holde tritt med I/O-forespørsler.

Diskbyte/sek

Dette overvåker hastigheten på dataoverføring til/fra disk. Hvis dette overstiger diskens nominelle kapasitet, begynner data å lagres igjen, noe som indikeres ved å øke diskkølengden.

Diskoverføringer/sek

Denne sporer antall lese-/skriveoperasjoner som er utført på disken. SQL Server Datatilgang er vanligvis tilfeldig, noe som er tregere på grunn av bevegelse av diskhodet. Sørg for at denne verdien holder seg under diskstasjonens maksimale klassifisering (vanligvis 100/sek for standarddisker).

3.4 SQL Server Spesifikke tellere

3.4.1 Bufferhåndteringstellere

Buffer Manager-tellermonitor SQL Servers minnebufferoperasjoner:

Sidelesninger/sek: Kumulativt antall lesninger av fysiske databasesider
Sideskrivinger/sek: Kumulativt antall fysiske databasesideskrivinger
Late skriver/sek: Antall buffere skrevet av lat skriver for å frigjøre minne
Sjekkpunktsider/sek: Sider som er tømt av kontrollpunkt eller andre operasjoner som krever at alle skitne sider tømmes

3.4.2 SQL-statistikktellere

Disse tellerne gir innsikt i SQL Server behandling av spørring:

Batchforespørsler/sek: Antall SQL-batchforespørsler mottatt av serveren. Dette fungerer som et referansepunkt for serveraktivitet
SQL-kompileringer/sek: Antall SQL-kompileringer. Bør være 10 % eller mindre av totale batchforespørsler/sek.
SQL-rekompileringer/sek: Antall SQL-rekompileringer. Bør også være 10 % eller mindre av totale batchforespørsler/sek.

3.4.3 Generelle statistikktellere

Brukertilkoblinger: Antall brukere koblet til systemet. Brukes som et referansepunkt for å spore tilkoblingsvekst over tid.
Prosesser blokkert: Gjeldende antall blokkerte prosesser. Ideelt sett bør det være 0

3.4.4 Minnehåndteringstellere

Minnestipend i påvente: Totalt antall prosesser som venter på minnetildeling i arbeidsområdet. Bør ideelt sett være 0.

4. Konfigurere ytelsesmåler for SQL Server(Windows Vista / Server 2008 og senere)

Først av alt må vi opprette en container for å administrere tellere enklere:

For Windows Vista/Server 2008 og senere versjoner kan du opprette datainnsamlersett i denne delen.
For Windows XP / Server 2003 og tidligere versjoner kan du opprette tellerlogger i neste avsnitt.

4.1 Hva er datainnsamlersett?

Data Collector Sets organiserer ytelsestellere, hendelsessporingsdata og systemkonfigurasjonsinformasjon i én enkelt innsamlingsenhet. De gir mer fleksibilitet enn enkle tellerlogger og muliggjør automatisert, planlagt datainnsamling for omfattende ytelsesovervåking av SQL-databaser.

4.2 Opprette et datainnsamlersett

Opprett et tilpasset datainnsamlersett for å overvåke SQL Server ytelsestellere:

Åpne ytelsesmåleren
Expand Datainnsamlersett
Høyreklikk Brukerdefinert
Velg Ny -> Datainnsamlersett
Skriv inn et beskrivende navn (f.eks. «SQL Server Ytelsesmålinger)
Velg Opprett manuelt (Avansert)
Klikk neste
Trykk her Opprett datalogger -> Ytelsesteller
Klikk neste
Klikk Legg til å velge tellere
Legg til ønsket SQL Server og systemtellere.
Sett Prøveintervall
- For rutinemessig overvåking, bruk 1 minutt (60 sekunder)
- For aktiv feilsøking, bruk 15–30 sekunder
- Unngå å kjøre høyfrekvente opptak over lang tid, da de kan påvirke ytelsen og generere for mye data.
Klikk neste
Velg hvor loggene skal lagres
Klikk Finish, vil et nytt datainnsamlersett bli opprettet.
Som standard vil det nye datainnsamlersettet IKKE startes automatisk. Du finner den i venstre panel, under Ytelse -> Datainnsamlersett -> Brukerdefinert -> Din datainnsamler, høyreklikk på den og velg Start

4.3 Nøkkeltellere som skal legges til

Minne -> Tilgjengelige MB
Fysisk disk -> Gj.sn. disk sek/lesing (alle forekomster unntatt _Totalt)
Fysisk disk -> Gj.sn. disksek/skriving (alle forekomster unntatt _Total)
Fysisk disk -> Disklesninger/sek (alle forekomster unntatt _Total)
Fysisk disk -> Diskskrivinger/sek (alle forekomster unntatt _Total)
Prosessor -> % prosessortid (alle forekomster unntatt _Total)
SQLServer: Generell statistikk -> Brukertilkoblinger
SQLServer: Minnebehandling -> Venter på minnetildelinger
SQLServer: SQL-statistikk -> Batchforespørsler/sek
SQLServer: SQL-statistikk -> SQL-kompileringer/sek
SQLServer: SQL-statistikk -> SQL-rekompileringer/sek
System -> Prosessorkølengde

4.4 Angi stoppbetingelser

Konfigurer stoppbetingelser for å forhindre ubegrenset datavekst:

Etter at du har opprettet datainnsamlersettet, høyreklikker du på det og velger Eiendommer
Klikk på Stopp tilstand tab
aktiver Total varighet
Sett varighet til 1 dag (24 timer)
Klikk OK å spare

Dette sikrer at loggen ikke blir for stor og starter automatisk på nytt hvis planlagt.

4.5 Planlegging av datainnsamling

Automatiser datainnsamling for å sikre jevnlig overvåking:

Høyreklikk på datainnsamlersettet ditt og velg Eiendommer
Klikk på Planlegg tab
Klikk Legg til å lage en ny timeplan
Konfigurer startdato og -klokkeslett
Angi gjentakelsesmønster (f.eks. daglig)
Klikk OK for å lagre timeplanen

For automatisk oppstart, konfigurer datainnsamlersettet til å starte når serveren starter opp ved å opprette en oppstartsutløser i Windows Oppgaveplanlegger.

5. Konfigurere ytelsesmåler for SQL Server(Windows XP / Server 2003 og tidligere)

For Windows XP/Server 2003 og tidligere versjoner kan du opprette tellerlogger, som lar deg velge et sett med ytelsestellere og logge dem til en fil med jevne mellomrom.

5.1 Opprette tellelogger

Følg disse trinnene for å opprette en ny tellerlogg:

Åpne ytelsesmåleren
Expand Ytelseslogger og varsler i venstre rute
Høyreklikk Tellerlogger
Velg Nye logginnstillinger
Gi loggen navnet på databaseserveren din (f.eks. «ProductionSQL01»).
Klikk OK for å starte konfigurasjonen

Ved å opprette separate tellerlogger for hver server kan du teste ytelsen på individuelle servere uten å samle inn data for alle serverne samtidig.

5.2 Legge til ytelsestellere

Etter at du har opprettet en tellerlogg, legger du til de spesifikke ytelsestellerne du vil overvåke:

Klikk på Legg til tellere knapp
Endre datamaskinnavnet slik at det peker til din SQL Server f.eks
Press Tab for å laste inn tilgjengelige ytelsesobjekter
Velg et ytelsesobjekt fra rullegardinmenyen (f.eks. Minne)
Velg spesifikke tellere fra listen
Velg forekomster hvis aktuelt (f.eks. individuelle prosessorer eller disker)
Klikk Legg til å inkludere telleren
Gjenta for alle ønskede tellere
Klikk Lukke når ferdig

5.3 Konfigurering av prøveintervaller

Samplingsintervallet bestemmer hvor ofte Ytelsesmonitor samler inn data. Konfigurer passende intervaller basert på dine overvåkingsbehov:

I tellerloggegenskapene finner du Eksempeldata hver
Angi intervallet (standard er 15 sekunder)
For baseline-overvåking, bruk intervaller på 1 minutt for daglig innsamling
For feilsøking, bruk intervaller på 15–30 sekunder for korte utbrudd
Klikk OK å søke

Husk at mindre intervaller genererer mer data, som kan være vanskeligere å gjengi og analysere. Større intervaller kan gå glipp av viktige topper. Balanser datagranulariteten med lagrings- og analysekrav.

5.4 Konfigurering av loggfiler

Riktig loggfilkonfigurasjon sikrer at data lagres effektivt og tilgjengelig:

Klikk på Loggfiler fanen i tellerloggegenskaper
Endre loggfiltypen til Tekstfil (kommadelt) for enkel Excel-import
Klikk Konfigurer
Angi filbanen til en dedikert plassering (f.eks. en delt PerformanceLogs-mappe)
Klikk OK å bekrefte

Bruk en nettverkstilgjengelig delt mappe for logglagring, slik at du kan få tilgang til filer eksternt og dele dem med andre brukere.

5.5 Opprette legitimasjon

Konfigurer riktig påloggingsinformasjon slik at Ytelsesmonitor kan få tilgang til eksternt SQL Server tilfeller:

I tellerloggegenskapene finner du Løp så
Skriv inn domenebrukernavnet ditt i formatet: DOMENE\brukernavn
Klikk Angi passord
Skriv inn og bekreft passordet ditt
Klikk OK å spare

Dette lar PerfMon-tjenesten samle inn statistikk ved hjelp av domenetillatelsene dine i stedet for sin egen påloggingsinformasjon.

6. Analysere ytelsesmålerdata

6.1 Vise loggfiler i Ytelsesmåler

Ytelsesmonitor kan vise historiske data fra lagrede loggfiler:

Åpne ytelsesmåleren
I venstre rute klikker du Overvåkingsverktøy -> Ytelsesmåler.
Høyreklikk hvor som helst i grafområdet
Velg Eiendommer
Klikk på Kilde tab
Velg Loggfiler radioknapp
Klikk Legg til
Naviger til loggfilen din (.blg eller .csv)
Velg filen og klikk Open
Bruke Tidsramme glidebryteren for å velge perioden du vil analysere
Klikk OK for å lukke Egenskaper-dialogboksen
Klikk på det grønne plussikonet for å legge til tellere fra loggfilen
Velg ønskede tellere som skal vises
Klikk OK

Grafen vil nå vise historiske data fra loggfilen. Bruk glidebryteren for tidsintervall i Egenskaper for å begrense bestemte tidsperioder for detaljert analyse.

6.2 Eksportere data til Excel

Excel tilbyr kraftige analysefunksjoner for ytelsestellerdata:

Åpne Ytelsesmonitor med loggfilen lastet inn
Høyreklikk hvor som helst i grafområdet
Velg Lagre data som
Velg en plassering for filen
Velg Tekstfil (kommadelt) (.csv) fra rullegardinmenyen
Klikk Spar
Åpne CSV-filen i Excel

Formater de eksporterte dataene for bedre analyse:

Slett den halvtomme rad 2 og fjern celle A1
Formater kolonne A som dato/klokkeslett
Formater numeriske kolonner med null desimaler og tusenskilletegn
Finn og erstatt servernavn i overskrifter (f.eks. erstatt «\\SERVERNAME» med blankt)
Rydd opp i objektnavn i overskrifter (f.eks. «Minne», «Fysisk disk», «Prosessor»)
Reduser skriftstørrelsen i overskriften til 8 punkter for bedre synlighet

6.3 Tolkning av tellerverdier

6.3.1 Analyse av minneteller

Når du analyserer minnetellere, se etter disse indikatorene:

Tilgjengelige MByte: Bør holde seg over 4096 MB konsekvent
Forventet levealder: Verdier over 300 sekunder indikerer sunt minne. Lavere verdier tyder på minnepress.
Bufferbufferbuffertreffforhold: Bør oppfylle eller overstige 99 %. Lavere verdier indikerer for mye disklesing.
Minnestipend i påvente: Skal alltid være 0. Enhver positiv verdi indikerer minnemangel

6.3.2 Analyse av CPU-teller

CPU-ytelsesindikatorer inkluderer:

% Prosessortid: Vedvarende bruk på over 75 % indikerer ytelsesproblemer. Topper til 100 % er normale, men bør ikke vedvare.
Prosessorkølengde: Verdier over 1 indikerer CPU-belastning. Sjekk Oppgavebehandling for å identifisere hvilke prosesser som bruker CPU
% Privilegert tid: Bør holde seg mellom 5–10 %. Verdier over 25 % tyder på overdreven I/O-operasjon.

6.3.3 Analyse av diskteller

Terskler for diskytelse:

Gjnsn. disksek/lesing og skriving: Bør holde seg under 10–20 ms. Høyere verdier indikerer trege diskundersystemer.
Lengde på diskkø: Verdier som er konsekvent over 2 (eller 2 per disk i RAID) indikerer I/O-flaskehalser
% disktid: Vedvarende verdier over 85 % indikerer diskmetning

6.4 Bruk av formler og statistikk

Legg til statistiske formler i Excel for rask analyse:

Sett inn 7 tomme rader øverst i regnearket ditt
Legg til etiketter i kolonne A: Gjennomsnitt, Median, Min, Maks, Std. avvik
I celle B2 skriver du inn: =GJENNOMSNITT(B9:B100) (juster B100 til den siste dataraden)
I celle B3 skriver du inn: =MEDIAN(B9:B100)
I celle B4 skriver du inn: =MIN(B9:B100)
I celle B5 skriver du inn: =MAX(B9:B100)
I celle B6 skriver du inn: =STDEV(B9:B100)
Kopier formler på tvers av alle tellerkolonner
Merk celle B9 og trykk Alt+W+F+Enter for å fryse ruter

Denne statistikken hjelper med å identifisere trender, avvikere og normale driftsområder for hver teller.

7. Verktøy for ytelsesanalyse for logger (PAL)

7.1 Introduksjon til PAL

Performance Analysis for Logs (PAL) er et gratisverktøy utviklet av Clint Huffman som analyserer Performance Monitor-logger og genererer HTML-rapporter med terskelanalyse. PAL sammenligner ytelsesdataene dine mot kjente terskler og gir detaljerte anbefalinger for SQL Server ytelsesoptimalisering.

Last ned PAL fra GitHub-depotet: https://github.com/clinthuffman/PAL

7.2 Oppsett av PAL

Installer PAL ved å følge disse trinnene:

Last ned PAL-oppsettfilen fra GitHub
Kjør installasjonsprogrammet
Klikk neste på velkomstskjermen
Se gjennom og godta installasjonsmappen
Klikk neste å fortsette
Klikk Install for å starte installasjonen
Vent til installasjonen er fullført
Klikk Finish

7.3 Behandling av loggfiler med PAL

Analyser Ytelsesmonitor-loggene dine ved hjelp av PAL:

Start PAL fra Start-menyen eller installasjonsmappen
Klikk på Tellerlogg tab
Klikk Søk for å velge .blg-filen din
Naviger til loggfilen for Ytelsesmonitoren din
Klikk Open
Klikk på Terskelfil tab
Velg en terskelfil fra rullegardinmenyen (f.eks. «SQL Server 2016” )
Klikk på spørsmål tab
Svar på spørsmål om systemkonfigurasjonen din
Spesifiser om din SQL Server er OLTP eller datalager
Angi totalt tilgjengelig RAM
Klikk på Utgangsalternativer tab
Velg en utdatamappe for HTML-rapporten
Trykk her HTML Utgående format
Klikk på Henrette tab
Se gjennom valgene dine
Trykk her Start utførelsen nå
Klikk Finish

7.4 Analysere PAL-rapporter

Etter at PAL har fullført analysen, genereres en HTML-rapport som inneholder:

Sammendrag av ytelsesproblemer
Detaljert telleranalyse med diagrammer
Terskelbrudd uthevet i farger
Spesifikke anbefalinger for hvert problem
Historiske trender og mønstre

Rapporten bruker fargekoding for å angi alvorlighetsgrad: rød for kritiske problemer, gul for advarsler og grønn for sunne målinger. Gjennomgå hver seksjon for å forstå ytelsesflaskehalser og følg PALs anbefalinger for optimalisering.

8. Alternativ SQL Server Overvåkingsverktøy

8.1 Innebygd SQL Server verktøy

8.1.1 SQL Server Aktivitetsmonitor

SQL Server Aktivitetsmonitor viser sanntidsinformasjon om SQL Server prosesser og ytelse:

Open SQL Server Management Studio (SSMS) og koble til serverforekomsten din
Høyreklikk på servernavnet i Object Explorer
Velg Aktivitetsmonitor

Aktivitetsmonitoren viser prosesser, ressursventetider, datafil-I/O og nylige dyre spørringer. Den gir rask innsikt i gjeldende databaseaktivitet, men lagrer ikke historiske data.

8.1.2 SQL Server Ytelse Dashboard

SQL Server Management Studio inkluderer innebygde ytelsesrapporter:

In SQL Server Management Studio (SSMS), høyreklikk på SQL Server forekomst i Object Explorer
Velg Rapporter -> Standardrapporter
Velg mellom tilgjengelige rapporter som Ytelse Dashboard

Ytelsesdashbordet gir visuell innsikt i SQL Server instansytelse, inkludert systemets CPU-utnyttelse, gjeldende ventende forespørsler og ytelsesmålinger. Få tilgang til den via Standardrapporter-menyen.

8.1.3 SQL Server Profiler

SQL Server Profiler fanger opp og analyserer SQL Server hendelser som utførelse av spørringer, transaksjonsoperasjoner og påloggingsaktiviteter.

Å starte SQL Server Profiler:

In SQL Server Management Studio, klikk verktøy -> SQL Server Profiler

Profiler skaper betydelig ytelsesbelastning, så bruk den med omhu og helst utenom rushtid. For de fleste scenarier gir utvidede hendelser bedre ytelse med mindre innvirkning.

8.1.4 Utvidede hendelser

Utvidede arrangementer er et lettvekts ytelsesovervåkingssystem innebygd i SQL ServerDen erstatter SQL Server Profiler med bedre ytelse og lavere overhead.

Viktige funksjoner inkluderer:

Finmasket overvåking av spesifikke hendelser
Minimal ytelsespåvirkning
Tilpassbare arrangementsøkter
Integrasjon med SSMS og andre verktøy
Støtte for kompleks filtrering og aggregering

Opprett utvidede hendelsesøkter via SSMS:

In Objekt Explorer, utvid serveren din og gå til Administrasjon -> Utvidede hendelser -> Økter
Høyreklikk på Økter Og velg Ny øktveiviser
Følg instruksjonene for å starte en ny økt.

8.1.5 Dynamiske administrasjonsvisninger (DMV-er)

DMV-er eksponerer detaljert informasjon om servertilstand for å overvåke helse, diagnostisere problemer og finjustere ytelse. Viktige DMV-er inkluderer:

sys.dm_exec_query_stats: Statistikk for spørringsytelse
sys.dm_os_wait_stats: Ventetyper som påvirker serverytelsen
sys.dm_os_performance_counters: SQL Server ytelsestellerdata
sys.dm_exec_requests: Utfører forespørsler nå
sys.dm_exec_sessions: Aktive brukerøkter

Spør disse visningene ved hjelp av T-SQL for å få tilgang til ytelsesdata og historiske målinger i sanntid.

Grunnleggende bruk

-- See all active connections
SELECT * FROM sys.dm_exec_connections;

-- View current sessions
SELECT * FROM sys.dm_exec_sessions;

-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

8.2 Tredjeparts overvåkingsløsninger

Redgate SQL Monitor

Redgate SQL Monitor spesialiserer seg på overvåking SQL Server og Azure SQL Database-miljøer. Den tilbyr overvåking av hele eiendommen, tilpassbare varsler og dashbord, detaljerte rapporteringsmuligheter og integrering med andre Redgate-verktøy.

Solarwinds SQL Server Overvåkningsverktøy

SolarWinds SQL Server Overvåkingsverktøy, også kjent som SQL Sentry, er utviklet for å diagnostisere, løse og forhindre alvorlige ytelsesproblemer med SQL Server.

IDERA sine SQL Server Ytelsesovervåkingsverktøy

IDERA SQL Diagnostic Manager er en kraftig SQL Server Ytelsesovervåkingsverktøy utviklet for å hjelpe med proaktiv ytelsesovervåking, diagnostikk og finjustering.

Application Managers SQL-overvåking

Applications Manager tilbyr en Microsoft SQL Server Overvåkingsverktøy som gir nyttige IT-løsninger. Den er designet for å overvåke ytelsen til SQL-databaser, samtidig som den identifiserer feil og løser problemer som kan føre til stans i en organisasjons drift.

8.3 Overvåkingsverktøy med åpen kildekode

DBA-dashbord

DBA Dash er et gratis, åpen kildekode-overvåkingsverktøy som gir innsikt i SQL Server helse, ytelse og aktivitet. Det er spesielt nyttig for små og mellomstore miljøer og inkluderer daglige DBA-sjekker, ytelsesovervåking og konfigurasjonssporing.

SQLWATCH

SQLWATCH tilbyr desentralisert, nesten sanntidsbasert SQL Server overvåking med 5-sekunders granularitet for å fange opp arbeidsmengdetopper. Den støtter Grafana for sanntidsdashboards og Power BI for dyptgående analyse. Verktøyet tilbyr omfattende konfigurasjonsalternativer, null vedlikeholdskrav og ubegrenset skalerbarhet.

Opserver

Opserver er utviklet av Stack Exchange og overvåker flere systemer, inkludert SQL Server, Redis og Elasticsearch. Den gir en oversikt over alle servere for CPU-, minne-, nettverks- og maskinvarestatistikk på tvers av infrastrukturen din.

sp_HvemErAktiv

sp_WhoIsActive er en omfattende lagret prosedyre for aktivitetsovervåking laget av Adam Machanic. Den fungerer med alle SQL Server versjoner fra 2005 til nåværende utgivelser og brukes mye av SQL Server DBA-er for aktivitetsovervåking i sanntid.

For å bruke sp_WhoIsActive, last det ned fra http://whoisactive.com/, installer det i databasen din og kjør:

EXEC sp_WhoIsActive

Prosedyren viser hvilke spørringer som utføres for øyeblikket, venteinformasjon, blokkeringsdetaljer og ressursforbruk.

9. Beste praksis for SQL Server Ytelsesmåler

9.1 Etablering av ytelsesgrunnlag

Ytelsesgrunnlinjer etablerer normale driftsparametere for din SQL Server miljø. Uten grunnlinjer kan du ikke avgjøre om nåværende målinger indikerer problemer eller representerer typisk atferd.

Lag grunnlinjer ved å:

Samle inn ytelsesdata under normal drift i minst én uke
Registrering av målinger i både rushtid og utenom rushtid
Dokumentere typiske verdier for nøkkeltellere
Registrering av sesongvariasjoner hvis aktuelt
Lagring av basisdata for sammenligning med fremtidige målinger

Oppdater grunnlinjer kvartalsvis eller etter betydelige endringer i infrastrukturen, applikasjonsoppdateringer eller databaseendringer.

9.2 Angi passende varslingsterskler

Konfigurer intelligente terskler for å motta meningsfulle varsler uten å overvelde deg selv med varsler:

Ventende minnetildelinger > 0 indikerer minnebelastning
Prosessorkølengde > 2 per kjerne tyder på CPU-flaskehals
Disksek/lesing eller skriving > 20 ms indikerer treg I/O
Blokkerte prosesser > 5 signaliserer konfliktproblemer
Forventet sidelevetid < 300 sekunder indikerer minnebelastning

Juster terskler basert på grunnlinjedataene dine og spesifikke arbeidsbelastningsegenskaper. Bruk adaptive terskler som tar hensyn til normale variasjoner i miljøet ditt.

9.3 Regelmessig datagjennomgang og -analyse

Planlegg regelmessige ytelsesvurderinger for å identifisere trender og nye problemer:

Daglig: Gjennomgå overordnede målinger og nylige varsler
Ukentlig: Gjennomfør grundig analyse av ytelsestrender
Månedlig: Generer omfattende rapporter og sammenlign med baselines
Kvartalsvis: Gjennomgå kapasitetsplanlegging og langsiktige trender

Dokumenter funn og spor ytelsesforbedringer over tid.

9.4 Balansering av overvåkingskostnader

Overvåking i seg selv bruker ressurser, så balanser datainnsamling med ytelsespåvirkning:

Bruk intervaller på 30–60 sekunder for kontinuerlig overvåking
Bruk kun 15 sekunders intervaller for aktiv feilsøking
Begrens datainnsamlerens varighet for å unngå overdreven datamengde
Lagre logger på separate stasjoner fra databasefiler
Arkiver gamle ytelsesdata for å opprettholde håndterbare filstørrelser

Ytelsesmonitor legger til minimalt med overhead når den er riktig konfigurert, vanligvis under 2 % av systemressursene.

9.5 Langsiktig datalagring

Ta vare på ytelsesdata for meningsfull trendanalyse og kapasitetsplanlegging:

Oppbevar minst 1–2 år med ytelsesdata
Arkiver data til separat lagring etter 3–6 måneder
Komprimer eldre loggfiler for å spare plass
Dokumenter eventuelle viktige hendelser eller endringer som påvirker ytelsen

Gitt den relativt lille størrelsen på ytelsestellerdata, er det ofte mulig og verdifullt å beholde dem på ubestemt tid for langsiktig analyse.

9.6 Integrering med DevOps-praksiser

Innlemme ytelsesovervåking av databaser i CI/CD-pipelines:

Inkluder ytelsesmålinger for databasen i validering av distribusjon
Automatiser ytelsestesting for nye utgivelser
Valider at kodeendringer ikke påvirker ytelsen negativt
Lag ytelsesstandarder for hver utgivelse
Integrer overvåkingsvarsler med hendelseshåndteringssystemer

10. Feilsøking av vanlige ytelsesproblemer

10.1 Identifisering av CPU-flaskehalser

CPU-flaskehalser manifesterer seg som langsomme responstider for spørringer og høy prosessorutnyttelse. Bruk disse trinnene for å diagnostisere CPU-problemer:

Sjekk telleren for prosessorkølengde. Verdier over 2 per kjerne indikerer CPU-belastning.
Se gjennom % prosessortid. Vedvarende verdier over 75 % tyder på CPU-flaskehals
Eksternt skrivebord til SQL Server
Åpne Oppgavebehandling (Ctrl+Shift+Esc)
Klikk på prosesser tab
Trykk her Vis prosesser fra alle brukere
Klikk på prosessor kolonneoverskrift for å sortere etter CPU-bruk
Identifiser hvilke prosesser som bruker CPU-ressurser

Hvis ikke-SQL Server applikasjoner bruker mye CPU, fjern dem fra databaseserveren. Hvis sqlservr.exe bruker mye CPU, undersøk det ved hjelp av disse metodene:

Sjekk SQL-kompilasjoner/sek og SQL-rekompilasjoner/sek. Verdier over 10 % av batchforespørsler/sek indikerer overdreven kompilering.
Spør sys.dm_exec_query_stats for å identifisere CPU-intensive spørringer
Gjennomgå utførelsesplaner for manglende indekser eller ineffektiv drift
Vurder å legge til indekser for å redusere antall tabellskanninger

10.2 Diagnostisering av hukommelsesproblemer

Hukommelsesproblemer påvirker betydelig SQL Server ytelse. Diagnostiser minneproblemer ved hjelp av disse indikatorene:

Tilgjengelige minnedråper

Hvis tilgjengelige MB synker under 100 MB konsekvent, står operativsystemet overfor minnemangel. Windows kan få utløp for siden. SQL Server minne til disk, noe som fører til redusert ytelse.

Lav forventet levetid for sider

En forventet levetid på under 300 sekunder indikerer høy bufferhurtigbufferomsetning. Dette tyder enten på utilstrekkelig minneallokering eller for høyt minnetrykk fra spørringer.

Lav treffforhold for buffercache

Buffer Cache Hit Ratio under 99 % betyr SQL Server leser ofte data fra disk i stedet for minne. Dette skjer når bufferbassenget er for lite eller SQL Server varmes fortsatt opp etter omstart.

Minnetilskudd venter

Enhver verdi over 0 for Venter på minnetildelinger indikerer at spørringer venter på minnetildelinger. Dette representerer en kritisk minnemangel som krever umiddelbar oppmerksomhet.

For å løse minneproblemer:

Konfigurer SQL Server maks minneinnstilling for å gi tilstrekkelig RAM til operativsystemet (vanligvis 4–8 GB avhengig av serverstørrelse)
Aktiver tillatelsen «Lås sider i minnet» for SQL Server tjenestekonto
Legg til mer fysisk RAM på serveren hvis minnebelastningen vedvarer
Identifiser og optimaliser minneintensive spørringer

10.3 Løse problemer med disk-I/O

Disk I/O blir ofte den primære ytelsesflaskehalsen i databasesystemer. Diagnostiser diskproblemer ved hjelp av disse metodene:

Høy diskkølengde

Hvis diskkølengden konsekvent er over 2 (eller 2 per disk for RAID), indikerer dette at diskundersystemet ikke kan holde tritt med I/O-forespørsler. Dette skaper en etterslep av ventende operasjoner.

Overdreven diskforsinkelse

Verdier for gjnsn. disksek./lese- og gjnsn. disksek./skrive over 10–20 ms indikerer treg diskrespons. Transaksjonsloggdisker krever spesielt rask ytelse, ideelt sett under 5 ms for skriving.

Høy % disktid

Vedvarende % disktid over 85 % indikerer diskmetning. Disken bruker mesteparten av tiden sin på å behandle I/O-forespørsler med lite ledig kapasitet igjen.

Før du tar tak i diskproblemer, må du bekrefte at de ikke er symptomer på minneproblemer. Utilstrekkelig minnekapasitet. SQL Server å lese mer data fra disken, og kunstig blåse opp diskmålinger.

Slik løser du ekte disk-I/O-problemer:

Oppgrader til raskere disker (SSD-er i stedet for HDD-er)
Implementer RAID-konfigurasjoner for bedre ytelse
Separate databasefiler, transaksjonslogger og tempdb på forskjellige fysiske stasjoner
Legg til mer minne for å redusere diskavlesninger
Optimaliser indekser for å redusere unødvendig I/O
Gjennomgå og optimaliser spørringer med dårlig ytelse

10.4 Håndtering av blokkering og fastlåste hendelser

Blokkering skjer når én økt har låser som hindrer andre økter i å fortsette. Overvåk disse tellerne for å identifisere blokkeringsproblemer:

Prosesser blokkert: Burde ideelt sett være 0
Lås ventetider/sek: Antall låseforespørsler som krever ventetid
Gjennomsnittlig ventetid: Gjennomsnittlig ventetid på låsing

For å undersøke blokkering:

Åpne Aktivitetsmonitor i SSMS
Utvid prosesser seksjon
Se etter prosesser med verdier som ikke er null Blokkert av verdier
Identifiser ID-en for blokkerende økt
Se gjennom søkene som forårsaker blokkering

Bruk sp_WhoIsActive for mer detaljert blokkeringsanalyse. For mange wait_info-oppføringer indikerer ofte tempdb-konflikt eller blokkeringsproblemer.

For å redusere blokkering:

Minimer transaksjonsvarigheten
Bruk passende isolasjonsnivåer
Legg til indekser for å redusere låsevarigheten
Vurder READ_COMMITTED_SNAPSHOT-isolering
Gjennomgå og optimaliser langvarige spørringer

10.5 Problemer med spørringsytelse

Det er viktig å identifisere dyre spørringer for SQL-ytelsesovervåking. Bruk disse metodene for å finne problematiske spørringer:

Bruke Aktivitetsmåler

Høyreklikk på servernavnet i SSMS
Velg Aktivitetsmonitor
Expand Nylige dyre søk
Gjennomgangsspørringer med høy CPU, varighet eller logiske lesninger

Bruk av DMV-er

Spør sys.dm_exec_query_stats for å identifisere ressurskrevende spørringer:

SELECT TOP 50
    total_worker_time/execution_count AS avg_cpu_time,
    total_logical_reads/execution_count AS avg_logical_reads,
    execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.text)
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2) + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY total_worker_time DESC

Analysere utførelsesplaner

Åpne et nytt spørrevindu i SSMS
Klikk Vis estimert utførelsesplan (Ctrl+L) eller Inkluder faktisk utførelsesplan (Ctrl+M)
Utfør spørringen din
Gjennomgå utførelsesplanen for kostbare operasjoner
Se etter tabellskanninger, indeksskanninger eller operasjoner med høy kostnad

Optimaliser søk etter:

Legge til passende indekser
Omskriving av spørringer for å unngå dyre operasjoner
Oppdatering av statistikk
Bruk av spesifikke kolonnenavn i stedet for SELECT *
Unngå unødvendige DISTINCT- eller ORDER BY-klausuler

10.6 Oppdag og reparer korrupt database

Databaseskade kan føre til redusert ytelse, datatap og systemfeil. Det er avgjørende å oppdage og håndtere skade raskt for å opprettholde databasetilstanden.

Indikatorer for databasekorrupsjon

Se etter disse tegnene på potensiell korrupsjon:

Feilmeldinger i SQL Server feillogg (feil 823, 824 eller 825)
Uventede programfeil ved tilgang til bestemte tabeller
Treg spørrytelse på tidligere raske spørringer
SQL Server krasj eller uventede omstarter
Mistenkelige sider vises i tabellen msdb.dbo.suspect_pages

Bruk av DBCC CHECKDB for deteksjon

DBCC CHECKDB er det primære verktøyet for å oppdage databasekorrupsjon. Kjør det regelmessig for å oppdage problemer tidlig.

Overvåking av mistenkelige sider

SQL Server registrerer automatisk mistenkelige sider i msdb-databasen:

SELECT 
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)

Alle returnerte rader indikerer korrupsjonsproblemer som krever umiddelbar oppmerksomhet.

Strategier for korrupsjonsforebygging

Aktiver sideverifisering med alternativet SJEKKSSUM
Oppretthold regelmessige sikkerhetskopier av databasen
Bruk pålitelig maskinvare med feilretting
Overvåk diskhelse ved hjelp av produsentverktøy
Planlegg regelmessige DBCC CHECKDB-kjøringer
Hold SQL Server oppdatert med de nyeste oppdateringene

Gjenopprettings- og reparasjonsalternativer

Hvis det oppdages feil, kan du prøve det innebygde verktøyet DBCC CHECKDB å fikse dem. Hvis det mislykkes, bruk tredjepartsverktøy som DataNumen SQL Recovery som kan håndtere alvorlig korrupsjon.

11. Avanserte overvåkingsteknikker

11.1 Overvåking av spørrelager

Query Store, introdusert i SQL Server 2016, registrerer automatisk ytelsesdata for spørringer. Den gir verdifull innsikt i spørreatferd, utførelsesplaner og ytelsestrender.

Aktivering av spørrelager

Høyreklikk på en database i SSMS Object Explorer
Velg Eiendommer
Klikk på QueryStore side
In Driftsmodus (forespurt), plukke ut Les Skriv
Konfigurer ytterligere innstillinger etter behov
Klikk OK

Overvåking av spørringsytelse

Få tilgang til Query Store-rapporter via Object Explorer:

Utvid databasen i Object Explorer
Expand QueryStore
Velg blant tilgjengelige rapporter:
- Regreserte spørringer
- Totalt ressursforbruk
- Mest ressurskrevende spørringer
- Spørsmål med tvungne planer
- Sporede spørringer

Planregresjonsdeteksjon

Query Store oppdager automatisk når spørreutførelsesplaner endres og ytelsen forringes. Se gjennom rapporten om regresjonerte spørringer for å identifisere spørringer som er påvirket av planendringer.

Tvungen planhåndtering

Når Query Store identifiserer en bedre utførelsesplan, tving SQL Server å bruke det:

Åpne spørringen i spørrelageret
Høyreklikk på ønsket plan
Velg Styrkeplan

Dette forbedrer ytelsen umiddelbart uten at det kreves kodeendringer.

11.2 Overvåking av indeksvedlikehold

Indeksfragmentering forringer spørringsytelsen over tid. Overvåk og vedlikehold indekser regelmessig for å sikre optimal ytelse.

Fragmenteringskontroll

Bruk denne spørringen for å sjekke indeksfragmentering:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
    AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC

Kjør denne spørringen utenom rushtid, da den kan være ressurskrevende.

Analyse av sidetetthet

Sidetetthet angir hvor fulle indekssidene er. Lav tetthet sløser med plass og reduserer ytelsen:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75

Omorganisering vs. gjenoppbyggingsbeslutninger

Velg indeksvedlikeholdsoperasjoner basert på fragmenteringsnivåer:

Fragmentering 10–30 %: Bruk ALTER INDEX REORGANIZE
Fragmentering > 30 %: Bruk ALTER INDEX REBUILD
Fragmentering < 10 %: Ingen handling nødvendig

Omorganisering av drift krever færre ressurser og kan kjøres på nett. Gjenoppbyggingsoperasjoner er mer grundige, men bruker betydelige ressurser.

11.3 Oppdateringer av databasestatistikk

Hjelp med databasestatistikk SQL Servers spørreoptimaliseringsverktøy lager effektive utførelsesplaner. Utdatert statistikk fører til dårlig spørreytelse.

Automatisk gjenoppbygging av statistikk

Aktiver automatiske statistikkoppdateringer:

ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON

Overvåking av statistikk Helse

Sjekk når statistikken sist ble oppdatert:

SELECT 
    OBJECT_NAME(s.object_id) AS TableName,
    s.name AS StatisticsName,
    STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
    sp.rows,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated

Oppdater statistikken manuelt ved behov:

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 Innsamling av tilpassede ytelsesdata

Lag tilpassede ytelsesovervåkingsløsninger ved å spørre sys.dm_os_performance_counters direkte og lagre resultater i tabeller.

Opprette tilpassede samlingsskript

Bygg en lagret prosedyre for å samle inn ytelsestellerdata:

CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
    INSERT INTO dbo.PerformanceHistory (
        SampleTime,
        CounterName,
        CounterValue
    )
    SELECT 
        GETDATE(),
        counter_name,
        cntr_value
    FROM sys.dm_os_performance_counters
    WHERE counter_name IN (
        'Page life expectancy',
        'Batch Requests/sec',
        'Buffer cache hit ratio'
    )
END

Bruk av sys.dm_os_performance_counters

Spør ytelsestellere direkte:

SELECT 
    object_name,
    counter_name,
    instance_name,
    cntr_value,
    cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name

Lagring av historiske data

Opprett en tabell for å lagre ytelsesmålinger over tid:

CREATE TABLE dbo.PerformanceHistory (
    ID INT IDENTITY PRIMARY KEY,
    SampleTime DATETIME2 NOT NULL,
    PageLifeExpectancy BIGINT,
    BatchRequestsPerSec DECIMAL(18,4),
    BufferCacheHitRatio DECIMAL(5,2)
)

CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory 
ON dbo.PerformanceHistory

Pivoterte datalagringsmetoder

Lagre data i pivotert format med én rad per samplingstid og én kolonne per teller. Dette reduserer lagringsplass og forbedrer spørringsytelsen sammenlignet med å lagre én rad per teller per sampling.

11.5 Overvåking av flere servere

For miljøer med flere SQL Server tilfeller, implementer sentralisert overvåking.

Sentralisert overvåkingstilnærming

Opprett en dedikert overvåkingsdatabase på en separat server
Samle inn data fra alle servere i det sentrale arkivet
Bruk SQL Server Agentjobber for å kjøre inkassoskript
Implementer nettverkstilgjengelig innsamling av ytelsestellere

Ekstern serverovervåking

Konfigurer Ytelsesmonitor til å samle inn data fra eksterne servere ved å angi servernavn når du legger til tellere. Sørg for at brannmurregler tillater Ytelsesmonitor-trafikk.

Rapportering på tvers av servere

Lag rapporter som sammenligner ytelse på tvers av flere servere for å identifisere avvik og kapasitetsubalanser.

12. Overvåkning SQL Server i skymiljøer

12.1 Azure SQL-databaseovervåking

Azure SQL Database tilbyr innebygde overvåkingsfunksjoner som er forskjellige fra lokale overvåkingsfunksjoner. SQL Server.

Azure Monitor-integrasjon

Azure Monitor samler automatisk inn målinger fra Azure SQL Database, inkludert:

DTU- eller vCore-utnyttelse
Lagringsforbruk
Tilkoblingsstatistikk
Vranglåser og timeouts

Få tilgang til disse målingene via Azure Portal eller Azure Monitor API.

Innebygde overvåkingsfunksjoner

Azure SQL-databasen inkluderer:

Anbefalinger for automatisk tuning
Innsikt i spørringsytelse
Intelligent innsikt for avviksdeteksjon
Innebygd varsling og diagnostikk

Innsikt i spørringsytelse

Denne funksjonen gir visualisering av de mest ressurskrevende spørringene, analyse av spørrevarighet og historiske ytelsestrender. Få tilgang til den via Azure Portal under SQL Database-ressursen din.

12.2 Skybaserte overvåkingsverktøy

Skyplattformer tilbyr innebygde overvåkingsløsninger som er optimalisert for sine miljøer:

Azure Monitor og applikasjonsinnsikt for Azure SQL-database
AWS CloudWatch for RDS SQL Server
Google Cloud-overvåking for skyen SQL Server

Disse verktøyene integreres sømløst med skyinfrastruktur og gir enhetlig overvåking på tvers av alle skyressurser.

Hybrid miljøovervåking

For hybriddistribusjoner som spenner over lokale systemer og skytjenester, bruk verktøy som støtter begge miljøene, som Redgate SQL Monitor, SolarWinds DPA eller tilpassede løsninger som bruker sentralisert datainnsamling.

12.3 Ytelsesforskjeller i skyen

Cloud SQL Server miljøer har unike egenskaper:

Ressursallokeringsmodeller

Skyleverandører bruker ulike ressursallokeringsmetoder (DTU-er, virtuelle kjerner, serverløs) som påvirker hvordan du tolker ytelsesmålinger. Forstå begrensningene og egenskapene til tjenestenivået ditt.

Skaleringshensyn

Skymiljøer tilbyr dynamiske skaleringsmuligheter. Overvåk ressursutnyttelsen for å bestemme når du skal skalere opp eller ned. Mange skyplattformer tilbyr automatisk skalering basert på ytelsesterskler.

13. Automatisering av ytelsesovervåking

13.1 SQL Server Agentjobber

Automatiser datainnsamling ved hjelp av SQL Server Agentjobber for konsekvent overvåking uten manuell inngripen.

Planlagt datainnsamling

I SSMS, utvid SQL Server Agent
Høyreklikk Jobb og velg Ny jobb
Gi jobben et navn (f.eks. «Samle inn ytelsesmålinger»)
Klikk Steps og legg til et nytt trinn
Sett Type til Transact-SQL-skript
Skriv inn datainnsamlingsskriptet ditt
Klikk Rutetider og legg til en tidsplan
Konfigurer frekvens (f.eks. hvert 5. minutt)
Klikk OK å skape jobben

Automatisert rapportering

Opprett jobber som genererer og sender inn resultatrapporter via e-post:

Opprett en lagret prosedyre som genererer rapporter
Bruk Database Mail til å sende rapporter via e-post
Planlegg jobben til å kjøre daglig eller ukentlig

13.2 PowerShell-automatisering

PowerShell tilbyr kraftige automatiseringsfunksjoner for SQL Server ytelsesmåler.

Skript for innsamling av ytelsestellere

$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)

$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append

WMI-spørringer

Bruk WMI til å samle inn ytelsesdata fra eksterne servere:

$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01'
$memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01'

Write-Host "CPU Usage: $($cpu.LoadPercentage)%"
Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"

Automatisert varsling

Opprett PowerShell-skript som sjekker målinger og sender varsler når terskler brytes:

$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

if ($cpu -gt $cpuThreshold) {
    Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
        -Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}

13.3 Opprette overvåkingsdashboards

Visualiser ytelsesdata med interaktive dashbord for bedre innsikt.

Power BI-integrasjon

Koble Power BI til ytelsesdatatabellene dine
Lag visualiseringer for viktige målinger
Legg til slicere for tidsperiode og servervalg
Publiser dashbord til Power BI-tjenesten
Konfigurer automatiske oppdateringsplaner

Oppretting av dashbord i sanntid

Bruk verktøy som Grafana eller tilpassede webapplikasjoner for å lage sanntidsdashboards som spør direkte etter DMV-er og ytelsestellere.

Visualisering av historisk trend

Lag linjediagrammer som viser trender over tid for:

CPU utnyttelse
Minnebruk
Disk I / O
Forespørselsytelse
Antall tilkoblinger

14. Kasusstudier og praktiske eksempler

14.1 Casestudie: Løse minnepress

Symptomidentifikasjon

En produksjon SQL Server opplevde trege svartider på spørringer i rushtiden. Brukere klaget over tidsavbrudd i applikasjoner og dårligere ytelse.

Motanalyse

Ytelsesmonitordata avslørt:

Forventet levetid for sidene ble redusert til 50 sekunder (normal: >300)
Buffer Cache Hit Ratio falt til 85 % (normal: >99 %)
Ventende minnetildelinger viste ofte verdier på 5–10
Antall lesninger/sek på fysisk disk økte betraktelig

Oppløsningstrinn

Krysset av SQL Server maks minneinnstilling – oppdaget at den var satt til standard (ubegrenset)
Gjennomgått totalt serverminne kontra målserverminne – viste betydelig gap
Konfigurerte maksimalt serverminne for å gi 8 GB til operativsystemet
Aktiverte tillatelsen «Lås sider i minnet» for SQL Server tjenestekonto
La til 32 GB ekstra RAM til serveren
Overvåket ytelse i én uke – Forventet levetid for siden stabiliserte seg over 500 sekunder

Resultat: Svartidene på forespørsler ble forbedret med 60 %, brukerklager opphørte, og applikasjonsytelsen gikk tilbake til normalen.

14.2 Casestudie: Optimalisering av CPU-ytelse

Symptomidentifikasjon

A SQL Server viste konsekvent CPU-utnyttelse over 90 % i løpet av arbeidstiden, noe som forårsaket treg applikasjonsytelse og frustrasjon hos brukerne.

Motanalyse

Ytelsesovervåking avslørt:

Prosessortid i gjennomsnitt 92 % med hyppige topper til 100 %
Prosessorkølengde konsekvent over 4 (serveren hadde 8 kjerner)
SQL-kompileringer/sek var 25 % av batchforespørsler/sek (bør være <10 %)
SQL-rekompileringer/sek var 15 % av batchforespørsler/sek

Oppløsningstrinn

Brukte DMV-er for å identifisere de mest CPU-krevende spørringene
Analyserte utførelsesplaner for identifiserte spørringer
Oppdaget flere tabellskanninger på store tabeller på grunn av manglende indekser
Opprettet passende indekser basert på anbefalinger fra utførelsesplaner
Identifiserte dynamisk SQL som forårsaker overdreven kompilering
Endret applikasjonskode for å bruke parameteriserte spørringer
Implementert planveiledning for problematiske lagrede prosedyrer
Oppdatert statistikk for mye brukte tabeller

Resultat: CPU-utnyttelsen falt til 45 % i gjennomsnitt i løpet av arbeidstiden. Utførelsestiden for spørringer ble forbedret med 70 %. Applikasjonsresponsen ble betydelig forbedret.

14.3 Casestudie: Oppløsning av flaskehalser ved disk-I/O

Symptomidentifikasjon

Brukere rapporterte ekstremt treg applikasjonsrespons under datalasting og batchbehandling på kveldstid.

Motanalyse

Ytelsesdata viste:

Gjnsn. disksek/skriving oversteg 45 ms på transaksjonsloggstasjonen
Diskkølengden var i gjennomsnitt 12 på datafilstasjonen
% disktid holdt seg over 95 % i flere timer under batchjobber
Sideskrivinger/sek var usedvanlig høyt

Oppløsningstrinn

Bekreftet at minneinnstillingene var riktige – fant ingen minneproblemer
Analyserte diskkonfigurasjon – oppdaget alle filer på samme spindelsett
Separerte transaksjonslogger til dedikerte raske SSD-disker
Flyttet tempdb til separate SSD-disker
Implementerte flere tempdb-datafiler (én per kjerne)
Oppgraderte datafilstasjoner til RAID 10 SSD-konfigurasjon
Optimaliserte batchjobber for å bruke mindre transaksjonsbatcher
La til indekser for å redusere unødvendige tabellskanninger under batchoperasjoner

Resultat: Gjnsn. disksek/skriving falt til 3 ms. Gjennomsnittlig diskkølengde var under 1. Fullføringstiden for batchjobber ble redusert med 75 %.

15. Fremtidige trender i SQL Server Overvåking

15.1 Integrasjon av kunstig intelligens og maskinlæring

Kunstig intelligens og maskinlæring er i endring SQL Server ytelsesmåler.

Prediktiv Analytics

Maskinlæringsmodeller forutsier fremtidige ressursbehov basert på historiske data. Disse systemene kan forutsi:

Når lagringskapasiteten vil være oppbrukt
Forventede CPU- og minnekrav i perioder med høy trafikk
Forringelse av spørringsytelse før det påvirker brukerne
Optimale tidspunkter for vedlikeholdsoperasjoner

Anomali Deteksjon

AI-drevne verktøy oppdager automatisk uvanlige mønstre i ytelsesmålinger. De identifiserer avvik som menneskelige administratorer kan overse og skiller mellom normale variasjoner og ekte problemer.

Automatisert utbedring

Selvreparerende systemer løser automatisk vanlige problemer når de oppdages:

Start på nytt tjenester som har stoppet
Omfordele ressurser under toppbelastning
Bruk hurtigreparasjoner for kjente problemer
Gjenoppbygg fragmenterte indekser automatisk

15.2 Utviklingen av skybasert overvåking

Skyovervåking fortsetter å utvikle seg med nye muligheter.

Enhetlige overvåkingsplattformer

Moderne plattformer gir sikt i ett enkelt glass på tvers av:

Lokalt SQL Server forekomster
Skybaserte databaser
Hybride miljøer
Applikasjonsytelse
Infrastrukturmålinger

Observerbarhetstrender

Skiftet fra overvåking til observerbarhet understreker:

Forstå systematferd fra utganger
Korrelering av målinger, logger og spor
Dyp innsikt i distribuerte systemer
Problemdiagnose i sanntid

15.3 Selvreparerende databasesystemer

Future SQL Server versjonene vil inkludere flere autonome funksjoner.

Automatisk optimalisering

Databaser vil kontinuerlig optimalisere seg selv ved å:

Automatisk oppretting og sletting av indekser basert på arbeidsmengde
Justere konfigurasjonsinnstillinger for optimal ytelse
Omskriving av ineffektive spørringer transparent
Dynamisk håndtering av ressursallokering

Intelligent tuning

Avanserte systemer vil lære av ytelsesmønstre og bruke anbefalinger for justering automatisk, noe som reduserer behovet for manuell DBA-inngripen.

16. Konklusjon og viktige ting

16.1 Sammendrag av viktige overvåkingspraksiser

Effektiv SQL Server Ytelsesmonitorer krever en omfattende tilnærming som kombinerer verktøy, teknikker og beste praksis.

Oppsummering av kritiske tellere

Fokuser overvåkingsarbeidet på disse viktige tellerne:

Minne: Forventet sidelevetid, treffforhold for bufferbuffer, ventende minnetildelinger
CPU: % prosessortid, prosessorkølengde
Disk: Gj.sn. disksek/lesing og skriving, diskkølengde
SQL ServerBatchforespørsler/sek, Kompileringer/sek, Brukertilkoblinger

Sammendrag av beste praksis

Etablere grunnlinjer under normal drift
Angi intelligente varslingsterskler basert på grunnlinjer
Gjennomgå ytelsesdata regelmessig
Overhead for balanseovervåking med datagranularitet
Behold langsiktige data for trendanalyse
Bruk passende verktøy for hvert overvåkingsscenario

16.2 Tilnærming til kontinuerlig forbedring

SQL Server Ytelsesmonitor er ikke en engangsaktivitet, men en pågående prosess som krever kontinuerlig forbedring.

Regelmessige gjennomgangssykluser

Daglig: Sjekk varsler og gjeldende ytelse
Ukentlig: Gjennomgå trender og identifisere nye problemer
Månedlig: Analyser langsiktige mønstre og kapasitetsbehov
Kvartalsvis: Oppdater grunnlinjer og gjennomgå effektiviteten av overvåkingen

Hold deg oppdatert med verktøy

Hold overvåkingsverktøy og -teknikker oppdatert:

Evaluer nye overvåkingsfunksjoner i SQL Server oppdateringer
Test nye tredjepartsverktøy
Delta på opplæring og konferanser
Delta i SQL Server samfunnsfora
Del kunnskap med teammedlemmer

16.3 Neste trinn

Implementere SQL Server ytelsesovervåking systematisk:

Veikart for implementering

Uke 1: Konfigurer ytelsesmåler med viktige tellere
Uke 2: Opprett datainnsamlingssett for automatisert innsamling
Uke 3: Etablere grunnlinjer under normal drift
Uke 4: Konfigurer varsler for kritiske terskler
Måned 2: Implementer ytterligere overvåkingsverktøy (DMV-er, utvidede hendelser)
Måned 3: Utvikle tilpassede dashbord og rapporter
Pågående: Forbedre overvåkingen basert på erfaring og endrede krav

Tilleggsressurser

Fortsett å lære om SQL Server Ytelsesmonitor gjennom Microsoft-dokumentasjon, fellesskapsblogger og praktisk praksis. Eksperimenter med forskjellige verktøy og teknikker for å finne ut hva som fungerer best for ditt miljø.

17. Ofte stilte spørsmål (FAQ)

17.1 Hva er de viktigste SQL Server ytelsestellere å overvåke?

Det mest kritiske SQL Server ytelsesmålere inkluderer:

Minne: Forventet sidelevetid (bør være >300 sekunder) og treffforhold for bufferbuffer (bør være >99 %)
CPU: % prosessortid (vedvarende verdier <75 %) og prosessorkølengde (bør være <2 per kjerne)
Disk: Gjnsn. disksek/lesing og skriving (bør være <10–20 ms) og diskkølengde (bør være <2 per disk)
SQL Server: Batchforespørsler/sek, SQL-kompileringer/sek og ventende minnetildelinger (bør være 0)

Disse tellerne gir omfattende innsikt i systemtilstanden og bidrar til å identifisere flaskehalser raskt.

17.2 Hvor ofte bør jeg samle inn ytelsesdata?

Innsamlingsfrekvensen avhenger av overvåkingsmålene dine:

Baseline-overvåking: Hvert minutt (60 sekunder)
Aktiv feilsøking: Hvert 15.–30. sekund i korte perioder
Langsiktig trend: Hvert 5. minutt

Unngå å kjøre høyfrekvent innsamling kontinuerlig, da det kan påvirke ytelsen og generere for mye data. Bruk lengre intervaller for rutinemessig overvåking og kortere intervaller kun når du undersøker spesifikke problemer.

17.3 Hva er forskjellen mellom Ytelsesmonitor og SQL Server Profiler?

Ytelsesmonitor og SQL Server Profiler tjener forskjellige formål:

Performance Monitor:

Overvåker systemet og SQL Server ytelsestellere
Sporer ressursbruk (CPU, minne, disk)
Lav overhead, egnet for kontinuerlig overvåking
Gir aggregerte målinger over tid

SQL Server Profiler:

Sporer individuelle SQL Server hendelser og spørringer
Registrerer detaljert informasjon om utførelse av spørringer
Høyere driftskostnader, ikke anbefalt for kontinuerlig bruk
Best for feilsøking av spesifikke spørreproblemer
Utfaset til fordel for utvidede arrangementer

Bruk Ytelsesmonitor for generell systemovervåking og utvidede hendelser (ikke Profiler) for detaljert analyse på spørrenivå.

17.4 Kan ytelsesmåler påvirke SQL Server opptreden?

Når den er riktig konfigurert, har Ytelsesmonitor minimal innvirkning på SQL Server ytelse, vanligvis mindre enn 2 % overhead. Imidlertid kan overdreven overvåking forårsake problemer:

For mange tellere øker driftskostnadene
Svært korte prøveintervaller (under 15 sekunder) belaster ressurser
Kontinuerlig høyfrekvent innsamling genererer store loggfiler

For å minimere påvirkningen:

Overvåk kun nødvendige tellere
Bruk passende prøveintervaller (60 sekunder for rutinemessig overvåking)
Lagre logger på disker separat fra databasefiler
Planlegg ressurskrevende overvåking utenom rushtiden

17.5 Hvor lenge bør jeg oppbevare data om ytelsesovervåking?

Oppbevaring avhenger av dine analysebehov og lagringskapasitet:

Minimum: 3 måneder for feilsøking av nylige problemer
Anbefalt: 1–2 år for kapasitetsplanlegging og trendanalyse
Beste: På ubestemt tid hvis lagring tillater det, ettersom historiske data blir mer verdifulle over tid

Ytelsestellerdata komprimeres godt og bruker relativt lite plass. Vurder å arkivere eldre data til separat lagring i stedet for å slette dem. Mange organisasjoner opplever at årevis med historiske data er uvurderlige for kapasitetsplanlegging og identifisering av langsiktige trender.

17.6 Hva er gode terskelverdier for nøkkeltellere?

Anbefalte terskelverdier for varsling:

Minnetildelinger venter: Varsel når > 0
Forventet levetid for siden: Varsel når < 300 sekunder
% Prosessortid: Varsel når > 80 % i 5 minutter
Prosessorkølengde: Varsel når > 2 per kjerne
Gj.sn. disksek./lesing eller skriving: Varsel når > 20 ms
Diskkølengde: Varsel når > 2 per disk
Blokkerte prosesser: Varsling når > 5

Juster disse tersklene basert på grunnlinjedataene dine og spesifikke arbeidsbelastningsegenskaper. Det som er normalt for ett miljø kan tyde på problemer i et annet.

17.7 Hvordan overvåker jeg SQL Server ytelse eksternt?

Fjernkontroll for skjerm SQL Server tilfeller ved bruk av disse metodene:

Performance Monitor: Angi navnet på den eksterne datamaskinen når du legger til tellere
Kraftskall: Bruk parameteren -ComputerName med Get-Counter
DMV-er: Koble til eksterne servere via SSMS og spør etter DMV-er
Tredjepartsverktøy: De fleste overvåkingsverktøy støtter ekstern serverovervåking

Sørg for at brannmurregler tillater trafikk fra Ytelsesmonitoren, og at du har nødvendige tillatelser på den eksterne serveren. For flere servere bør du vurdere å implementere sentralisert overvåking med en dedikert overvåkingsserver og database.

17.8 Hva er det beste gratisverktøyet for SQL Server ytelsesmåler?

Flere gode gratisverktøy er tilgjengelige for overvåking SQL Server opptreden:

Windows Ytelsesmåler: Innebygd, omfattende og pålitelig
SSMS Aktivitetsmåler: Sanntidsovervåking uten ekstra installasjon
Utvidede arrangementer: Lettvekts hendelsesovervåking innebygd i SQL Server
sp_HvemErAktiv: Populær gratis lagret prosedyre for detaljert aktivitetsovervåking
DBA-dashbord: Overvåkingsverktøy med åpen kildekode og omfattende funksjoner
SQLWATCH: Åpen kildekode med overvåkingsmuligheter i nær sanntid

For de fleste organisasjoner gir Performance Monitor kombinert med SSMS-verktøy og sp_WhoIsActive utmerkede overvåkingsmuligheter uten ekstra kostnad.

17.9 Hvordan eksporterer jeg PerfMon-data for analyse?

Eksporter Ytelsesmonitor-data ved hjelp av disse metodene:

Eksporter til CSV:

Åpne Ytelsesmonitor med loggfilen lastet inn
Høyreklikk på grafen og velg Lagre data som
Velg Tekstfil (kommadelt) (.csv)
Velg plassering og lagre
Åpne i Excel for analyse

Bruk Relog-kommandoen:

relog input.blg -f csv -o output.csv

Dette kommandolinjeverktøyet konverterer binære loggfiler (.blg) til CSV-format for enklere analyse i regnearkprogrammer.

17.10 Når bør jeg bruke tredjeparts overvåkingsverktøy i stedet for innebygde alternativer?

Vurder tredjepartsverktøy når:

Håndtering av et stort antall SQL Server forekomster (10+)
Krever sentralisert overvåking på tvers av flere datasentre
Trenger avanserte funksjoner som prediktiv analyse eller avviksdeteksjon
Ønsker integrert varsling med hendelseshåndteringssystemer
Krav om samsvarsrapportering og historisk analyse
Mangler DBA-ressurser til å bygge og vedlikeholde tilpassede løsninger
Overvåking av heterogene databasemiljøer (SQL Server, Oracle, MySQL, osv.)

Innebygde verktøy fungerer bra for mindre miljøer eller når du har dyktige databaseadministratorer som kan utvikle tilpassede overvåkingsløsninger. Tredjepartsverktøy gir verdi gjennom tidsbesparelser, avanserte funksjoner og profesjonell støtte.

18. Ytterligere ressurser

18.1 Offisiell dokumentasjon

Microsoft tilbyr omfattende dokumentasjon for SQL Server ytelsesmåler:

SQL Server Dokumentasjon for ytelsesmåler: https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
Dynamiske administrasjonsvisninger: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
Utvidede arrangementer: https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
Spørrelager: https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
Ytelsesjustering og overvåking: https://learn.microsoft.com/en-us/sql/relational-databases/performance/

18.2 Anbefalte verktøy og nedlastinger

Viktige verktøy for SQL Server ytelsesmåler:

PAL-verktøy: https://github.com/clinthuffman/PAL
sp_HvemErAktiv: http://whoisactive.com/
DBA-dashbord: https://dbadash.com/
SQLWATCH: https://github.com/marcingminski/sqlwatch
Førstehjelpssett (Brent Ozar): https://www.brentozar.com/first-aid/
SQL Server Management Studio: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 Fellesskapsressurser

Lær av SQL Server samfunnet:

SQL Server Sentral: https://www.sqlservercentral.com/
Brent Ozar-bloggen: https://www.brentozar.com/blog/
SQL Shack: https://www.sqlshack.com/
MSSQLTips: https://www.mssqltips.com/
Reddit r/SQLServer: https://www.reddit.com/r/SQLServer/
stack Overflow SQL Server stikkord: https://stackoverflow.com/questions/tagged/sql-server

Disse ressursene inneholder veiledninger, råd om feilsøking og beste praksis fra erfarne SQL Server fagfolk. Deltakelse i fellesskapsfora hjelper deg å lære av andres erfaringer og dele din egen kunnskap.

om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring innen SQL Server miljøer og administrasjon av bedriftsdatabaser. Han har løst hundrevis av databasegjenopprettingsscenarier på tvers av finansielle tjenester, helsevesen og produksjonsorganisasjoner.

Yuan spesialiserer seg på SQL Server gjenoppretting av database, løsninger med høy tilgjengelighetog ytelsesoptimalisering. Hans omfattende praktiske erfaring inkluderer administrasjon av databaser på flere terabyte, implementering av Alltid på tilgjengelighetsgrupper, og utvikling av automatiserte sikkerhetskopierings- og gjenopprettingsstrategier for forretningskritiske forretningssystemer.

Gjennom sin tekniske ekspertise og praktiske tilnærming fokuserer Yuan på å lage omfattende veiledninger som hjelper databaseadministratorer og IT-fagfolk med å løse komplekse SQL Server utfordringer effektivt. Han holder seg oppdatert på det siste SQL Server utgivelser og Microsofts utviklende databaseteknologier, og tester jevnlig gjenopprettingsscenarioer for å sikre at anbefalingene hans gjenspeiler beste praksis i den virkelige verden.

Har spørsmål vedr SQL Server gjenoppretting eller trenger du ytterligere veiledning for feilsøking av databaser? Yuan ønsker velkommen tilbakemeldinger og forslag for å forbedre disse tekniske ressursene.