Forklar installationsindstillinger
Azure SQL Database, en PaaS (Platform as a Service), tilbyder høj skalerbarhed og minimal vedligeholdelse, hvilket gør den til en fremragende løsning til specifikke arbejdsbelastninger. Den er velegnet til udvikling af nye programmer, hvilket giver udviklere stor fleksibilitet i opbygningen af nye tjenester og tilbyder detaljerede udrulningsmuligheder i stor skala. Denne løsning med lav vedligeholdelse er ideel til forskellige arbejdsbelastninger, der sikrer effektiv og effektiv programudvikling.
Om udrulningsmodeller
Når du udruller Azure SQL Database, er der to primære udrulningsmodeller: enkelt database og elastiske puljer. I den elastiske puljemodel deles ressourcer mellem flere databaser i den samme pulje, mens ressourcer administreres uafhængigt for hver database i den enkelte databasemodel.
På samme måde som med virtuelle maskiner kan SQL Database udrulles ved hjælp af forskellige metoder, herunder PowerShell, Azure CLI eller Azure Portal.
Enkelt database
Udrulningsmodellen for en enkelt database er den nemmeste måde at bruge Azure SQL Database på. I denne model kan du administrere hver database individuelt med hensyn til skalering og datastørrelse. Hver database har sine egne dedikerede ressourcer, selvom der er installeret flere databaser på den samme logiske server.
Du kan overvåge ressourceudnyttelsen for hver database via Azure Portal. Denne funktion giver dig mulighed for nemt at spore og vurdere ydeevnen af dine databaser.
Elastiske bassiner
Elastiske puljer giver dig mulighed for at allokere lager- og beregningsressourcer til en gruppe databaser, så administrationen forenkles sammenlignet med håndteringen af hver enkelt database individuelt. De er nemmere at skalere end enkeltdatabaser, da ændringer i den elastiske pulje automatisk justerer ressourcerne for alle inkluderede databaser.
Denne model er omkostningseffektiv for software som tjenesteprogrammer, da ressourcer deles mellem alle databaser. Du kan konfigurere ressourcer ved hjælp af enten den DTU-baserede eller vCore-baserede indkøbsmodel.
Det er vigtigt løbende at overvåge ressourcer for at identificere stigninger i ydeevnen, der kan påvirke andre databaser i gruppen. Hvis du jævnligt vender tilbage til din allokeringsstrategi, sikrer du tilstrækkelige ressourcer til alle databaser.
Elastiske puljer er ideelle til multitenantarkitekturer med lav gennemsnitlig udnyttelse, hvor hver lejer har sin egen databasekopi.
Om køb af modeller
Når du har valgt den relevante udrulningsmodel til din SQL Database, er det næste trin at vælge den indkøbsmodel, der passer bedst til din arbejdsbelastning og dine budgetkrav. Azure SQL Database tilbyder to indkøbsmodeller: vCore-modellen og den DTU-baserede model. Hver model har sine egne fordele, så det er afgørende at forstå, hvilken model der passer bedst til dine krav til arbejdsbelastninger og omkostningsovervejelser.
vCore-baseret
Dette er den anbefalede indkøbsmodel, hvor beregnings- og lagerressourcer afkobles. Det betyder, at du kan skalere lager- og beregningsressourcer uafhængigt af hinanden. Denne fleksibilitet sikrer, at du kan justere ressourcer i henhold til dine specifikke behov, uden at det påvirker andre komponenter.
I den vCore-baserede indkøbsmodel afhænger dine omkostninger af flere faktorer, herunder tjenesteniveauet, hardwarekonfiguration, antallet af vCores og mængden af hukommelse, reserveret databaselager og faktisk sikkerhedskopieringslager.
Bemærk
Du kan finde oplysninger om priser på siden med priser på Azure SQL Database.
Et tjenesteniveau er en foruddefineret konfiguration, der bestemmer ydeevnen, lagertypen, høj tilgængelighed, indstillinger for it-katastrofeberedskab og tilgængeligheden af visse funktioner i databasen.
VCore-indkøbsmodellen tilbyder tre indstillinger for tjenesteniveau:
| Tjenesteniveau | Kapacitet |
|---|---|
| Generelt formål | Dette serviceniveau er designet til mindre intensive handlinger og tilbyder en omkostningseffektiv balance mellem beregnings- og lagermuligheder. Den omfatter både klargjorte og serveruafhængige beregningsniveauer, hvilket giver fleksibilitet til at imødekomme forskellige arbejdsbelastningsbehov og samtidig optimere budgettet. |
| Forretningskritisk | Dette niveau er ideelt til programmer, der kræver lagring med lav ventetid og høj ydeevne. Den understøtter In-Memory OLTP og indeholder en indbygget skrivebeskyttet replika. Derudover giver den mere hukommelse pr. kerne og bruger lokalt SSD-lager, hvilket gør det ideelt til arbejdsbelastninger, der er følsomme for ydeevnen. |
| Hyperskalering | Dette niveau er skræddersyet til programmer med store databaser og høje krav til gennemløb. Hyperskalering introducerer avancerede vandrette skaleringsfunktioner, der gør det muligt at tilføje beregningsnoder, efterhånden som datastørrelsen øges. Den understøttes udelukkende på enkelte SQL-databaser og muliggør betydelig skalering af lager- og beregningsressourcer ud over grænserne for tjenesteniveauerne Generelt formål og Forretningskritisk. |
DTU-baseret
I DTU-modellen er der tre tjenesteniveauer: Basic, Standard og Premium. Beregnings- og lagerressourcer afhænger af DTU-niveauet og tilbyder en række ydeevnefunktioner med faste lagergrænser, opbevaring af sikkerhedskopier og omkostninger.
Hvis din database f.eks. når sin maksimale lagergrænse, skal du øge din DTU-kapacitet, selvom beregningsudnyttelsen er lav. Skaleringshandlinger på Azure SQL Database kan også medføre korte forbindelsesafbrydelser i slutningen af processen. Dette kan ske i to hovedscenarier:
- Starter en skaleringshandling, der kræver en intern failover.
- Tilføjelse eller fjernelse af databaser fra den elastiske gruppe.
Bemærk
Hvis du vil håndtere forbindelsesfejl, skal du implementere korrekt forsøgslogik i dit program.
Forståelsen af samspillet mellem udrulnings- og indkøbsmodeller er afgørende for at optimere ydeevnen og omkostningseffektiviteten. Ved omhyggeligt at vælge den rigtige kombination kan du sikre, at din Azure SQL Database-installation opfylder dit programs krav, samtidig med at du holder dig inden for budgettet.
Hvis du f.eks. vælger udrulningsmodellen for en enkelt database, foretrækker du måske vCore-indkøbsmodellen for dens fleksibilitet i forbindelse med skalering af beregnings- og lagerressourcer uafhængigt af hinanden. Hvis du derimod vælger den elastiske model til udrulning af puljer, kan den DTU-baserede indkøbsmodel være mere omkostningseffektiv, da den giver dig mulighed for at dele ressourcer mellem flere databaser i puljen.
Udfør sikkerhedskopiering og gendannelse
Azure leverer problemfri sikkerhedskopierings- og gendannelsesfunktioner til SQL Database. Her er nogle vigtige funktioner:
Fortløbende sikkerhedskopiering
Azure SQL Database sikrer regelmæssige sikkerhedskopieringer og kopierer dem løbende for at få adgang til geo-redundant lager med læseadgang (RA-GRS). Fuld sikkerhedskopiering finder sted ugentligt, differentiale sikkerhedskopieringer hver 12.-24. time, og sikkerhedskopiering af transaktionslogfiler hvert 5. til 10. minut.
Geo-Restore
Med geo-redundante sikkerhedskopier som standard kan du nemt gendanne databaser til forskellige områder, der er nyttige til mindre strenge scenarier for it-katastrofeberedskab. Sikkerhedskopilager faktureres separat, men oprettes uden ekstra omkostninger med den maksimale størrelse på det valgte dataniveau. Varigheden af geogendannelse afhænger af databasens størrelse, transaktionslogfiler og samtidige gendannelsesanmodninger.
Bemærk
Geogendannelse er tilgængelig, når egenskaben redundans for sikkerhedskopiering af lager er angivet til geo-redundant sikkerhedskopieringslager.
PITR (Point-in-Time Restore)
Giver dig mulighed for at konfigurere en bestemt opbevaringspolitik for hver database fra 1 til 35 dage (standard er syv dage). Du kan også gendanne databaser til et bestemt tidspunkt på den samme server ved hjælp af Azure Portal, PowerShell, CLI eller REST API.
Long-Term opbevaring (LTR)
Langsigtet opbevaring er nyttig i scenarier, der kræver, at du angiver opbevaringspolitikken ud over det, der tilbydes af Azure. Du kan angive en opbevaringspolitik for op til 10 år, og denne indstilling er deaktiveret som standard.
Du kan få flere oplysninger om automatiserede sikkerhedskopier under Automatiserede sikkerhedskopier – Azure SQL Database & Azure SQL Managed Instance.
Aktivér automatisk justering
Automatisk justering er en effektiv indbygget funktion, der anvender maskinel indlæring til at optimere din forespørgselsydeevne. Den identificerer automatisk justering af salgsmuligheder og implementerer dem for at forbedre databasens effektivitet.
Automatisk justering omfatter i øjeblikket følgende funktioner:
- Identificering af dyre forespørgsler
- Gennemtving den seneste plan for god udførelse
- Tilføjer indeks
- Fjerner indeks
Azure-tjenester bruger avancerede algoritmer til at bestemme de bedste indeks for dine forespørgselsmønstre. Disse indeks testes indledningsvist på en kopi af databasen, før de anvendes på det dynamiske miljø, så der sikres minimal afbrydelse.
Alle databaser arver deres konfiguration fra den overordnede server, og du kan nemt deaktivere denne funktion, hvis det er nødvendigt. Denne fleksibilitet gør det muligt for udviklere at bevare kontrollen, samtidig med at de drager fordel af automatiserede forbedringer af ydeevnen.
Brug elastisk forespørgsel
Elastisk forespørgsel giver dig mulighed for at køre T-SQL-forespørgsler på tværs af flere databaser i SQL Database. Denne funktion er nyttig til programmer, der bruger navne på tre og fire dele, som ikke kan ændres, og den forbedrer mobiliteten ved at lette migreringen.
Elastiske forespørgsler understøtter følgende partitioneringsscenarier:
| Tjenesteniveau | Kapacitet |
|---|---|
| Lodret partitionering | Kaldes også forespørgsler på tværs af databaser. Data partitioneres lodret på tværs af flere databaser med forskellige skemaer. Du kan f.eks. have én database til kundedata og en anden til betalingsoplysninger. Lodret partitionering giver dig mulighed for at køre forespørgsler på tværs af databaser mellem disse databaser. |
| Vandret partitionering | Også kendt som sharding. Data partitioneres vandret for at distribuere rækker på tværs af flere skalerede databaser, der alle deler det samme skema. Denne topologi understøtter både modeller med enkelt lejer og multitenant. |
Denne fleksibilitet gør elastiske forespørgsler til et effektivt værktøj til administration og forespørgsel af data på tværs af flere databaser.
Konfigurer elastiske job
Den elastiske jobfunktion fungerer som SQL Server Agent-erstatning for Azure SQL Database på samme måde som funktionen Til administration af flere servere i en lokal SQL Server-forekomst.
Med elastiske job kan du udføre T-SQL-kommandoer på tværs af forskellige målinstallationer, herunder SQL-databaser, fleksible SQL Database-puljer og SQL-databaser i skårne kort. Disse databaseressourcer kan strække sig over forskellige Azure-abonnementer og -områder. Den parallelle udførelsesfunktion er nyttig til automatisering af databasevedligeholdelsesopgaver, der sikrer effektivitet og ensartethed på tværs af dine udrulninger.
Flyt data ved hjælp af SQL Data Sync
SQL Data Sync muliggør trinvis synkronisering af data på tværs af flere databaser, uanset om de kører på SQL Database eller i det lokale miljø SQL Server. Denne funktion er nyttig til aflastning af intensive produktionsarbejdsbelastninger til en separat database til analyser eller ikke-planlagte handlinger.
Datasynkronisering fungerer på en hubtopologi, hvor én database i synkroniseringsgruppen er angivet som hubben. Synkroniseringsgruppen kan indeholde flere medlemsdatabaser, og synkroniseringen sker mellem hubben og individuelle medlemsdatabaser. Ændringer spores ved hjælp af udløsere til indsættelse, opdatering og sletning via en oversigtstabel, der er oprettet i brugerdatabasen.
Når du opretter en synkroniseringsgruppe, skal du angive en database til lagring af metadata for synkroniseringsgruppen. Denne metadatadatabase kan enten være ny eller eksisterende, så længe den er placeret i det samme område som din synkroniseringsgruppe.
Du kan få flere oplysninger om, hvordan du konfigurerer SQL Data Sync, i Selvstudium: Konfigurer SQL Data Sync mellem databaser i Azure SQL Database og SQL Server.