Introduktion
Denne artikel er en kort gennemgang af den primære planlagte vedligeholdelse med en database over 24/7 informationssystemet, der ikke har nedetid, samt tilgange til deres eksekvering i MS SQL Server.
Eventuelle kommentarer og opdateringer til artiklen er meget værdsat.
Planlagt vedligeholdelse
Der er følgende planlagte vedligeholdelse, jeg vil gerne påpege:
- Planlagt sikkerhedskopiering med yderligere bekræftelse uden gendannelse
- Planlagt gendannelse af sikkerhedskopier for at bekræfte deres ydeevne
- Analyse af datalagringsenhed, der indeholder systemet og alle de nødvendige databaser
- Planlagt test af nødvendige tjenester
- Planlagt optimering af systemets ydeevne
- Planlagt vedligeholdelse af dataintegritet
- Planlagt vedligeholdelse af datavalidering
De første tre punkter er de vigtigste, da de giver en systemgendannelse efter forskellige fejl. Jeg vil dog anbefale, at du også udfører de mindst tre punkter, så brugerne kan arbejde med lethed (alle forespørgslerne skal derfor udføres hurtigt), og så data bør valideres i alle rapporteringssystemer.
For at automatisere planlagt vedligeholdelse er det muligt at arrangere dets dele i Agent eller Windows Scheduler.
Det sjette punkt er baseret på CHECKDB-kommandoen.
Det syvende punkt er implementeret mod det domæneområde, der bruges i informationssystemet.
Jeg vil tale i detaljer om de første fem punkter.
Planlagte sikkerhedskopier med yderligere bekræftelse uden gendannelse
Da der er mange artikler om dette emne, skal det bemærkes, at det er nødvendigt regelmæssigt at udføre denne planlagte vedligeholdelse på en backup-server i stedet for på hovedserveren. Denne backupserver skal indeholde opdaterede data (for eksempel den, der blev hentet med replikering). Derudover skal du sikkerhedskopiere alle systemdatabaser (undtagen tempdb) på hver forekomst af MS SQL Server.
Når sikkerhedskopieringen mislykkes, eller en sikkerhedskopieringsscanning identificerer et problem, er det nødvendigt at rapportere disse oplysninger til administratorer. Du kan f.eks. e-maile dem.
Det er vigtigt at fastlægge en strategi for backup, som vil besvare følgende spørgsmål:
- Hvor ofte og hvornår skal vi sikkerhedskopiere data (fuld, differential- og transaktionslog)?
- Hvor længe og hvornår skal vi slette sikkerhedskopier?
Planlagt gendannelse af sikkerhedskopier for at bekræfte deres ydeevne
Jeg anbefaler, at du udfører denne procedure på en backup-server med tredjepartsværktøjer eller GENDANNELSE kommando.
Når gendannelse af backup mislykkes, er det nødvendigt at rapportere disse oplysninger til administratorer. Du kan f.eks. e-maile dem.
Derudover er det nødvendigt at gendanne sikkerhedskopier af systemdatabaser. For at gøre dette skal du gendanne dem som en sædvanlig brugerdatabase med et navn, der adskiller sig fra navnene på systemdatabaser.
Analyse af datalagringsenheder, der indeholder system og alle de nødvendige databaser
Du skal analysere, hvor meget plads hver database tager, hvordan filstørrelser ændrer sig, og hvordan størrelser af ledig plads på hele lagerenheden ændrer sig. For eksempel kan du udføre denne opgave delvist med automatisk dataindsamling om databasefiler og logiske drev i operativsystemet i MS SQL Server.
Du kan gøre dette tjek hver dag og derefter sende resultater. Som sædvanlig kan du sende dem til en e-mail.
Det er også nødvendigt at overvåge systemdatabaser, så du sikrer dig, at alt fungerer korrekt.
Derudover er det vigtigt at teste lagerenheder for at kontrollere, om der er nogen afskrivninger eller dårlige sektorer.
Bemærk, at under testning skal en enhed være ude af drift, og alle data skal kopieres til en anden enhed, da test belaster enheden drastisk.
Denne opgave er strengt relateret til systemadministratorens opgaver, så vi holder den til side. For at tage den fulde kontrol over sagen skal du automatisere levering af e-mailrapporter.
Jeg vil anbefale at udføre denne test to gange om året.
Planlagt test af nødvendige tjenester
Servicenedetid er en dårlig praksis. Derfor vil en backup-server træde i aktion i tilfælde af fejl. Alligevel er det nødvendigt at tjekke logs fra tid til anden. Derudover kan du også tænke på en automatisk dataindsamling med yderligere besked til en administrator ved at sende en e-mail.
Det er nødvendigt at kontrollere opgaver for SQL Server Agent eller Windows Scheduler med en automatisk dataindsamling om udførte opgaver i MS SQL Server.
Planlagt optimering af systemets ydeevne
Det omfatter følgende aspekter:
- Automatisk indeksdefragmentering i MS SQL Server-databaser
- Automatisk dataindsamling om ændringer af databaseskemaer i MS SQL Server. Du kan gendanne en sikkerhedskopi og sammenligne ændringer, for eksempel ved hjælp af dbForge
- Automatisk oprydning af fastlåste processer i MS SQL Server
- Rydning af procedurecachen. Her skal du bestemme hvornår og hvad der skal ryddes op
- Implementering af en præstationsindikator
- Udvikling og ændring af klyngede indekser
Derudover anbefaler jeg, at du slår AUTO_CLOSE fra funktion.
Nogle gange, af forskellige årsager, paralleliserer en optimering en forespørgsel, hvilket ikke altid er optimalt.
Derfor er der nogle anbefalinger, du bør huske på:
- Hvis du får mange data, så lad være med parallelitet.
- Hvis du får nogle få data, så brug ikke parallelisme.
Der er to parametre i SQL Server-instansindstillingerne, der er ansvarlige for parallelisme:
- maksimal grad af parallelitet. For at deaktivere parallelitet skal du indstille "1" som en værdi, hvilket betyder, at kun én processor vil udføre en kode.
- omkostningstærskel for parallelitet. Det skal være indstillet som standard.
Der er to hovedkøer:
- en kø for CPU-tiden (QCPU-kø). Det finder sted, når en forespørgsel er blevet aktiveret og venter på, at en processor udfører den.
- en kø for ressourcer (QR-kø). Det finder sted, når en forespørgsel venter på, at ressourcerne bliver ubundet for at udføre processen.
Følgende formel beskriver forespørgselsudførelsen (T):
T=TP+TQR+TCPU+TQCPU, hvor:
- TP kompilerer tid til en plan
- TQR er køtid for ressourcer (QR-kø)
- TQCPU er køtid for ressourcer, der skal frigøres (QCPU-kø)
- TCPU er tid til at udføre en forespørgsel
I systemvisningen sys.dm_exec_query_stats:
- total_worket_time =TP+TCPU+TQCPU
- total_elapsed_time =TQR+TCPU
Indbyggede værktøjer tillader ikke præcis vurdering af forespørgselsudførelsestid.
I de fleste tilfælde total_elapsed_time giver dig den tid, der er tæt på forespørgselsudførelsestidspunktet.
Du kan bestemme forespørgselsudførelsestiden mere nøjagtigt ved at bruge sporing. Alternativt kan du logge forespørgslens start- og sluttidspunkt. Vær forsigtig med spor, da de belaster systemet betydeligt. Det er således bedre at udføre det på en backup-server og samle data fra hovedserveren. I dette tilfælde vil kun netværket blive indlæst.
Ved parallelisering allokerer SQL Server N processer til en forespørgsel (i udgaven Standart n<=4). Hver proces kræver CPU-tid til at udføre en forespørgsel (en proces skal ikke altid udføres på hver kerne).
Jo flere processer du har, jo flere chancer er der for, at nogle bliver erstattet af andre, hvilket fører til øget TQCPU.
Det kan tage meget længere tid at udføre en forespørgsel ved parallelisering i følgende tilfælde:
- Lavt diskundersystemgennemløb. I dette tilfælde tager forespørgselsdekomponering meget længere tid.
- Data kan være blokeret for processen.
- Der er intet indeks for prædikatet, hvilket fører til en tabelscanning.
Bemærkninger:
Du skal deaktivere parallelle forespørgsler på servere, hvor der ikke er behov for at udføre et stort udvalg (total_worket_time bør reduceres på grund af et muligt fald i TCPU og TQCPU). For at gøre dette skal du indstille den maksimale grad af parallelitet til '1', for at kun én processor kan fungere.
Desuden kan du bruge andre rammer til at bygge et system, der bestemmer databasers højhastighedsydelse. . Det er vigtigt at forstå, hvordan disse rammer fungerer, og hvordan man fortolker hentede tal.
Med hensyn til udvikling og modifikation af indekser, nemlig klyngede indekser, er hovedpointen at forstå, hvordan logikken i indekser er sat, og hvordan den fungerer.
Husk, at primære og klyngede nøgler ikke betyder det samme:
En primær nøgle er en kolonne eller et sæt kolonner, som gør en post unik i tabellen. For den primære nøgle kan du enten oprette et unikt klynget eller ikke-klynget indeks. Den primære nøgle bruges i andre tabeller som en fremmednøgle for at give dataintegritet.
Et klynget indeks er et B-træ eller dets modifikation. Bladene indeholder selve data, mens noderne indeholder indeksoplysninger. Derudover kan et klynget indeks også være ikke-unik. Alligevel anbefaler jeg, at den er unik.
Jeg vil gerne minde om, at et B-træ er en struktur, der gemmer data i den rækkefølge, der er filtreret af et klynget indeks. Det er derfor vigtigt at gruppere felter, der er valgt som et klynget indeks, i en faldende eller stigende rækkefølge. Til et klynget indeks kan du bruge kolonner med heltal (identitet) samt data og tid. Alligevel er kolonner som en unik identifikator ikke egnede, da sidstnævnte vil føre til regelmæssig omstrukturering af et B-træ, hvilket vil øge mængden af aflæsninger og registreringer på en lagerenhed, hvor databasen er placeret.
Derudover skal du sikre dig, at indekset bruges sammen med systemvisningen sys.dm_db_index_usage_stats.
P.S. Det er nødvendigt at kontrollere, om data er opdateret på en backup-server, samt kontrollere et system, som synkroniserer disse data (f.eks. replikationer).
Læs også:
Automatisering af indeksdefragmentering i MS SQL Server-databaser
Automatisk dataindsamling af databaseskemaændringer i MS SQL Server
Automatisk sletning af fastlåste processer i MS SQL Server
Fejlfinding af langvarige forespørgsler i MS SQL Server
Implementering af en præstationsindikator