Tænker du på noget, når du opretter en ny database? Jeg gætter på, at de fleste af jer ville sige nej, da vi alle bruger standardparametre, selvom de langt fra er optimale. Der er dog en masse diskindstillinger, og de er virkelig med til at øge systemets pålidelighed og ydeevne.
Vi vil ikke tale om vigtigheden af NTFS-filsystemet for datapålidelighed, selvom dette filsystem tillader MS SQL Server at bruge disken på den mest effektive måde.
Hvis du mangler ressourcer, og noget begynder at fungere langsomt, er det første, du tænker på, at opgradere. Men opgradering er ikke påkrævet i alle tilfælde. Du kan slippe afsted med tuning, selvom det ikke skal gøres, når serveren begynder at køre langsomt, men på design- og installationsstadiet.
Optimering er en kompleks proces og er ofte relateret ikke kun til et bestemt program (i vores tilfælde til en bestemt database), men også til OS og hardware. Selvom vi mest vil tale om databaser, kan vi ikke ignorere de ydre ting.
Dataarkitektur
SQL Server gemmer, læser og skriver data i blokke på 8 KB hver. Disse blokke kaldes sider. En database kan gemme 128 sider pr. megabyte (1 megabyte eller 1048576 bytes divideret med 8 kilobyte eller 8192 bytes). Alle sider er gemt i et omfang. Et omfang er de sidste 8 sekventielle sider eller 64 KB. Således gemmer 1 megabyte 16 omfang.
Sider og omfang er grundlaget for den fysiske SQL Server-databasestruktur. MS SQL Server bruger forskellige sidetyper, nogle af dem sporer tildelt plads, nogle indeholder brugerdata og indekser. Sider, der sporer den tildelte plads, indeholder de tæt komprimerede data. Det giver MS SQL Server mulighed for effektivt at gemme dem i hukommelsen for nem læsning.
SQL Server bruger to slags omfang:
- Omfang, der gemmer sider fra to til mange objekter, kaldes blandet omfang. Hvert bord begynder som et blandet omfang. Du bruger primært blandet omfang til de sider, der gemmer plads og indeholder små genstande.
- Udvider, der har alle 8 sider allokeret til ét objekt, kaldes ensartede omfang. De bruges, når en tabel eller et indeks kræver mere end 64 KB.
Det første omfang for hver fil er ensartet og indeholder sider af filoverskriften, de næste omfang indeholder 3 tildelte sider hver. Serveren tildeler disse blandede omfang, når du opretter en grundlæggende datafil og bruger disse sider til sine interne opgaver. Filhovedsiden indeholder filattributter, såsom navnet på databasen, der er gemt i filen, filgruppe, minimumsstørrelse, stigningsstørrelse. Dette er den første side i hver fil (side 0).
Forespørgselsudførelsesplan i SQL Query Analyzer
Side ledig plads (PFS ) på en tildelt side, der indeholder information om ledig plads i filen. Disse oplysninger er gemt på side 1. Hver sådan side kan strække sig til 8000 sammenhængende sider, hvilket er cirka 64 Mb data.
Transaktionsloggen samler alle oplysninger om de ændringer, der finder sted på serveren, for at gendanne en database på tidspunktet for systemfejl og for at sikre dataintegritet.
Bemærk, at alle tal er multipla af 8 eller 16. Dette skyldes, at harddiskcontrolleren lettere læser data af denne størrelse. Dataene læses fra disken efter sider, dvs. med 8 kilobyte, hvilket er en ganske optimal værdi.
Sidebeskyttelse
Fra MS SQL Server 2005 har databaseserveren en ny mulighed – datakontrol på sideniveau. Hvis AGE_VERIFY_CHECKSUM parameter er aktiveret (den er aktiveret som standard), vil serveren kontrollere kontrolsummerne for sider. Hvis vi ser i manualen for denne parameter, vil vi se, at kontrolsummen tillader sporing af input/output fejl, som OS ikke er i stand til at spore. Hvilken slags fejl er det? Det ser ud til, at de er de interne problemer på databaseserveren.
Dataintegritetstjekket går aldrig galt, så det er bedre at aktivere det. Til dette skal vi udføre følgende kommando:
ALTER DATABASE имя базы SET PAGE_VERIFY
Hvis der er en fejl på siden, vil serveren give os besked om det. Men hvordan kan vi rette det hurtigt? Der er mulighed for at gendanne data på sideniveau for dette.
Grafisk udførelsesplan
Filvækst
Når vi opretter en database, bliver vi bedt om at vælge den oprindelige størrelse og stigningsmetoden. Når vi mangler den aktuelle plads, udvider serveren den i overensstemmelse med den forudindstillede stigningsmetode.
Der er tre inkrementmetoder for filer:
- Vækst i megabyte.
- Vækst i procent.
- Manuel vækst.
De første to metoder udføres automatisk, men de anbefales kun til testdatabaser, da en administrator ikke har kontrol over filstørrelsen.
Hvis en fil øges med en vis mængde megabyte, kan dataindsættelseshastigheden på et tidspunkt stige, og filvæksten kan blive for hyppig, og det er ekstra omkostninger. Filvækst i procent er også urentabel. Det anbefales at bruge en filvækst på 10 %, og det er OK for små og mellemstore databaser. Men når den når 1000 gigabyte, vil den kræve 100 gigabyte ved hver vækst. Det vil føre til meningsløst spild af diskplads.
Kontroller altid ændringer i størrelsen af filer og transaktionslogfiler. Det giver dig mulighed for at bruge diskressourcerne på den mest effektive måde.
MS SQL Server-databaseegenskaber
Datakomprimering
Harddisk forbliver et fornuftigt sted på en computer. Processorernes ydeevne vokser voldsomt, mens harddiske ikke kan tilbyde noget nyt. For at gemme antallet af input/output-operationer og reducere de data, der er lagret på harddisken, kan du bruge diske med komprimering. Kun sådanne diske er gode til at gemme skrivebeskyttede filgrupper. Måske er det fordi komprimering er påkrævet til skrivninger, og det kræver ekstra processoromkostninger.
Datakomprimering og skrivebeskyttet tilstand er gode for arkivdataene. Regnskabsdata for de seneste år er for eksempel ikke nødvendige for at skrive og kan tage for meget plads. Ved at placere data på diskens arkivdel sparer du meget plads.
Diske for pålidelighed
Den følgende metode giver mulighed for at øge pålideligheden og ydeevnen på samme tid, og igen er den relateret til harddiske. Nå, der er det, mekanik er ikke kun den langsomste, men den mest upålidelige. Hvad angår pålidelighed, indsamlede jeg ikke statistikken, men både hjemme og på arbejdet beskæftiger jeg mig mest med harddiske.
Så for at øge ydeevnen og pålideligheden kan du blot bruge to eller flere harddiske i stedet for én. Det vil være endnu bedre, hvis de bliver forbundet til separate controllere. Du kan gemme databasen på én disk og transaktionslogfiler på en anden. Hvis der er en tredje disk, kan den gemme systemet.
Lagring af data og en log på separate diske giver dig mulighed for i høj grad at øge pålideligheden. Antag, at du har alt på én disk, og det går ned. Hvad skal man gøre? Du kan nå en virksomhed, der vil forsøge at inddrive alt eller forsøge at gøre det samme på egen hånd, men chancen for genopretning er langt fra 100%. Desuden kan det tage lang tid at vende tilbage til serveren. Hurtig gendannelse kan kun udføres til tidspunktet for den sidste sikkerhedskopi. Resten er tvivlsomt.
Og antag nu, at du har data og en transaktionslog på forskellige diske. Hvis disken med loggen slukker, vil data stadig være der. Det eneste er, at du ikke kan tilføje nye data, men hvis du opretter en ny log, kan du fortsætte med at arbejde.
Hvis disken med data går af, kan vi stadig reservere transaktionsloggen for at forhindre det mindste tab af data. Derefter gendanner vi dataene fra den komplette sikkerhedskopi (det skal altid gøres på forhånd, en god administrator gør dette mindst en gang om dagen) og tilføjer ændringer fra sikkerhedskopien af loggen.
Diske til ydeevne
Hvis data og en log er placeret på separate diske, betyder det ikke kun sikkerhed, men også vækst i ydeevnen. Sagen er, at databaseserveren samtidigt kan skrive data ind i log- og datafilen.
Vi kan gå videre og allokere én harddisk til transaktionsloggen og flere harddiske til data. Serveren arbejder oftere med data, derfor kræver den flere storages, som du kan arbejde med på samme tid. Og hvis disse lager er forbundet med forskellige controllere, er det samtidige arbejde garanteret.
Den hurtigste og mest pålidelige variant er at bruge RAID . Dog ikke hver RAID er pålidelig og hurtig på samme tid. For filgrupperne anbefales det at vælge RAID10 , da den indeholder velafbalancerede funktioner, men afhængigt af databasedataene kan du vælge en anden variant.
Du kan bruge en software- eller hardwareløsning som RAID . En softwareløsning er billigere, men den kræver ekstra ressourcer af CPU. Og en processor har ikke ekstra ressourcer. Derfor er det bedre at bruge hardwareløsninger, hvor en dedikeret chip er ansvarlig for RAID .
Indekser
Alle ved, at indekser er med til at øge datasøgningshastigheden. De fleste af os forstår, at indekser negativt påvirker dataindsættelse og opdatering, så jo flere indekser du har, jo sværere er det for serveren at vedligeholde dem. Så er det ikke mange, der engang mener, at indekser kræver vedligeholdelse. Databasesider, der indeholder indeksdata, kan flyde over og til sidst blive ubalancerede.
Ja, vi kan ignorere forskellige parametre og blot genskabe indekser en gang om måneden, hvilket svarer til vedligeholdelse. SQL Server indeholder to parametre, der forhindrer indekser i at forælde inden for en halv time efter deres oprettelse:FILLFACTOR og PAD_INDEX .
Du kan bruge FILLFACTOR-indstillingen til at optimere ydeevnen af indsættelses- og opdateringsoperationer, der indeholder et klynget eller ikke-klynget indeks. Indeksdata kan gemmes på mange datasider. Som jeg nævnte ovenfor, består hver side af 8 KB. Når en indeksside er fuld, opretter serveren en ny side og deler siden for dataindsættelsen i to.
Serveren kræver tid til sideopdeling og oprettelse af en ny side. For at optimere sideinddelingen skal du bruge FILLFACTOR mulighed for at bestemme procentdelen af ledig plads på alle blade af indekssiden. Jo større diskplads siderne på bladniveau har, desto sjældnere skal du opdele indekssider. Da vil indekstræet være for stort, og dets omgåelse vil tage ekstra tid.
PAD_INDEX indstillingen angiver udfyldningsprocenten for de ikke-bladede sider. Du kan bruge PAD_INDEX kun når FILLFACTOR indstilling er angivet, da den procentvise værdi af PAD_INDEX afhænger af den procentdel, der er angivet i FILLFACTOR .
Statistik
Statistikker gør det muligt for serveren at træffe den rigtige beslutning mellem indeksbrug og fuld tabelscanning. Antag, at du har en liste over ansatte i en støbeributik. En sådan liste vil blive lavet over cirka 90 % af mændene.
Antag nu, at vi skal finde alle kvinderne. Da der ikke er mange af dem, vil den mest effektive mulighed være at bruge indekset. Men hvis vi skal finde alle mændene, bremses indekseffektiviteten. Antallet af valgte poster er for stort, og omgåelse af indekstræet for hver af dem vil være en overhead. Det er meget nemmere at scanne hele tabellen – udførelsen vil være meget hurtigere, da serveren skal læse alle blade på lavt niveau af indekset én gang uden behov for flere læsninger af alle niveauer.
SQL Server indsamler statistik ved at læse alle feltværdier eller med en skabelon til oprettelse af den ensartet fordelte og sorterede værdiliste. SQL Server registrerer dynamisk procentdelen af rækker, der skal testes på basis af antallet af rækker i tabellen. Når der indsamles statistik, vil forespørgselsoptimeringsværktøjet udføre enten en fuld scanning eller rækkeskabeloner.
For at få statistik til at fungere, skal den oprettes. I tilfælde af massiv dataopdatering kan statistikken indeholde forkerte data, og serveren vil tage en forkert beslutning. Men alt kan rettes – du skal overvåge statistikken. For mere detaljeret information henvises til bøgerne om Transact-SQL eller MS SQL Server.
Oversigt
Standardindstillingerne tillader ikke at bruge alt potentialet i hardware og arbejde med alle de forskellige servere. Ansvaret for indstillingerne påhviler administratorer. At Microsoft-produkterne har simple installationsprogrammer, grafiske administrationsværktøjer og mulighed for at arbejde offline betyder ikke, at dette er en optimal variant.
Vi betragter ikke sådanne databasejusteringsmuligheder som hardwareacceleration. Hvis alle indstillingsmuligheder er opbrugt, er det bedre at tænke på opgraderingen, da hardwareacceleration påvirker systemets pålidelighed negativt.
Det vigtigste er, at enhver databaseserveroptimering eller enhver opgradering ikke hjælper, hvis forespørgsler ikke er optimeret.