For å aktivere Query Store på en database i SQL Server Management Studio (SSMS) eller via T-SQL, må parameteren Wait Statistics Capture Mode være satt til On. Query Store kan slås på ved hjelp av kommandoen ALTER DATABASE database_name SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE). I Azure SQL Database, enten det er enkeltinstanser eller elastiske puljer, er det ikke mulig å deaktivere Query Store. Forsøk på å sette den til OFF vil resultere i en feilmelding, og i SSMS vil innstillingen automatisk gå tilbake til Read write dersom man prøver å endre den til Read only eller None.

Det er flere viktige konfigurasjonsparametere for Query Store som kan justeres enten i SSMS via egenskapssiden til databasen eller gjennom T-SQL. Disse inkluderer blant annet maksimal lagringsstørrelse (MAX_STORAGE_SIZE_MB), som angir hvor mye plass Query Store kan bruke på databasen. Standardverdien er 1000 MB for SQL Server 2019 og nyere, men for eldre versjoner er det 100 MB. I Azure SQL Database varierer standardverdiene med tjenestenivå, fra 10 MB på Basic til over 10 000 MB i høyere nivåer. Når denne grensen nås, bytter Query Store til skrivebeskyttet modus, noe som gjør ytelsesanalyser utdatert.

En annen viktig parameter er Statistics Collection Interval (INTERVAL_LENGTH_MINUTES), som bestemmer tidsintervallet for aggregering av spørringsstatistikk. Standardverdien på 60 minutter kan justeres for å samle mer eller mindre detaljerte data. Stale Query Threshold (STALE_QUERY_THRESHOLD_DAYS) regulerer hvor lenge kjørselsstatistikker og inaktive spørringer blir beholdt, med standard 30 dager (7 dager for Azure Basic). Størrelsesbasert opprydding (SIZE_BASED_CLEANUP_MODE) kan settes til AUTO, slik at systemet automatisk fjerner eldste og minst kostbare spørringer når lagringsgrensen nærmer seg 90 %.

Capture Mode (QUERY_CAPTURE_MODE) styrer hvilke spørringer som lagres. AUTO er standard, og fanger opp spørringer basert på utførelsesfrekvens og ressursbruk. Ved NONE lagres ingen nye spørringer, men eksisterende data oppdateres fortsatt. Data Flush Interval (DATA_FLUSH_INTERVAL_SECONDS) bestemmer hvor ofte data fra minnet skrives til disk, med 15 minutter som standard.

Når Query Store er aktivert, kan administratorer overvåke databaseytelsen gjennom flere rapporter i SSMS. Disse inkluderer lister over spørringer som har fått redusert ytelse (Regressed Queries), oversikt over ressursforbruk som CPU, I/O og kjøretid (Overall Resource Consumption), og lister over spørringer med høyest ressursforbruk. Det er også mulig å se spørringer med påtvungne planvalg (Forced Plans) og spørringer med stor variasjon i ressursbruk (High Variation), noe som gir verdifull informasjon for å identifisere og løse ytelsesproblemer. Videre finnes en visning over spørringer som har forårsaket lengste ventetider (Query Wait Statistics) og mulighet for sanntidsovervåkning av utvalgte spørringer (Tracked Queries).

En annen kritisk del av databaseadministrasjonen er å identifisere og håndtere blokkeringer. Blokkering oppstår når en transaksjon prøver å få tilgang til data som er låst av en annen transaksjon. Låser kan gjelde rader, sider, tabeller eller hele databasen, og kan eskalere for å dekke større datasett. Disse låsene forhindrer andre transaksjoner i å få tilgang til ressursene før de frigjøres. Mens kortvarige blokkeringer ofte ikke gir problemer, kan langvarige blokkeringer oppstå ved langvarige transaksjoner eller dårlig utformede SQL-spørringer og databasedesign. SQL Servers Auto-commit-funksjon legger automatisk til transaksjonskommandoer før og etter hver spørring, noe som vanligvis bidrar til å holde transaksjoner korte, men kompleksitet i transaksjonene kan likevel føre til blokkeringsproblemer.

Det er vesentlig å forstå at Query Store ikke bare er et verktøy for å overvåke ytelse, men også en mekanisme for å holde oversikt over endringer i spørringsplaner og oppdagelse av regresjoner over tid. Å bruke Query Store aktivt gir mulighet til å analysere historisk data, sette tvingende planer og raskt identifisere problematiske spørringer eller ressursflaskehalser.

Viktige aspekter som leseren bør være oppmerksom på inkluderer betydningen av riktig konfigurasjon av lagringsgrense og oppryddingsmoduser for å unngå at Query Store blir en flaskehals i seg selv. Videre må man forstå hvordan ventestatistikk samles inn og tolkes for å gi meningsfulle innsikter i blokkeringer og ventetider. I tillegg er det nødvendig å følge med på hvordan endringer i spørringsplaner påvirker ytelsen over tid, og å bruke muligheten til å tvinge frem gode planer ved behov. Å balansere detaljnivået på innsamlede data med lagringskapasitet og ytelse krever nøye vurdering for å oppnå optimal drift.

Hvordan fungerer automatisk tuning og indekshåndtering i Azure SQL Database?

Automatisk tuning i Azure SQL Database bruker egne anbefalinger for å overvåke og justere indekser som kan påvirke ytelsen negativt. Når en indeks blir oppdaget å forårsake nedgang i ytelse, kan systemet automatisk slette denne indeksen. Skulle denne handlingen føre til ytterligere forverring, blir indeksen automatisk gjenopprettet. Standardinnstillingen for FORCE PLAN er aktivert i Azure og arves av SQL Database-serveren og dens databaser, mens CREATE INDEX og DROP INDEX som standard er deaktivert. Administratorer har mulighet til å justere disse innstillingene individuelt på både server- og databasenivå, og databaser kan enten arve innstillinger direkte fra Azure eller fra SQL Database-serveren.

Ved bruk av Query Store kan administratorer identifisere ressurskrevende spørringer og optimalisere dem. Det er ikke nødvendigvis de spørringene som kjører lengst som påvirker ytelsen mest, men ofte de som kjøres hyppigst. Selv små forbedringer i slike hyppig kjørte spørringer kan ha betydelig innvirkning på total ytelse. Effektivitet i spørringskonstruksjonen er sentralt; settbaserte operasjoner er som regel mer ressursvennlige enn radbaserte, spesielt når store datamengder er involvert. Manglende eller overflødige indekser er en hyppig kilde til dårlig ytelse. Uten nødvendige indekser må SQL-serveren lese flere sider, noe som øker belastningen på I/O- og lagringssystemene.

Azure SQL Database tilbyr dynamiske visninger (DMVs) som gir innsikt i indeksbruk og manglende indekser, blant annet sys.dm_db_missing_index_details, sys.dm_db_index_usage_stats, og sys.dm_db_index_operational_stats. Disse kan hjelpe administratorer å vurdere hvor det er nødvendig å legge til eller fjerne indekser. Oppretting av nye indekser krever også ressurser, både i form av lagringsplass og I/O, så det anbefales å teste virkningen av hver ny indeks grundig, gjerne i et ikke-produksjonsmiljø. Automatisk tuning kan settes opp slik at den kun gir anbefalinger uten å iverksette endringer automatisk, noe som gir administratorer tid til å evaluere konsekvensene.

Spørringshint er kraftige verktøy som kan styre hvordan SQL-serveren kjører en spørring ved å overstyre optimalisererens valg. Hints legges til som en OPTION-klausul i T-SQL, og kan blant annet begrense antall prosessorer, styre minnebruk, eller tvinge omkompilering av spørringsplaner. Dette kan være nyttig i spesifikke tilfeller, men bør håndteres med forsiktighet, siden det binder planen til spørringen og kan hindre optimalisering ved endringer i server- eller databaseforhold. Microsoft anbefaler derfor at bare erfarne administratorer og utviklere bruker hints.

Gjennomgang av spørringsplaner er et viktig steg for å forstå hvordan spørringer blir utført. Query Store lagrer historikk over kjørte spørringer og deres planer, og kan vise estimater, faktiske planer, og sanntidsstatistikk. Verktøy som SQL Server Management Studio (SSMS) og Azure Data Studio gir grafiske fremstillinger som hjelper til med å analysere og forstå planene i detalj. Administratorer kan på denne måten identifisere flaskehalser og mulige forbedringer i planleggingen av spørringer.

Det er essensielt å forstå at effektiv databaseoptimalisering krever balansering av flere hensyn: ytelse, ressursbruk og vedlikeholdskostnader. Automatisk tuning i Azure gir kraftige muligheter, men krever samtidig at administratorer forstår mekanismene bak indeksadministrasjon, spørringsoptimalisering og bruken av hints for å oppnå best mulig resultat.

Viktige tillegg å ha i bakhodet er at indekser ikke bare påvirker spørringshastighet, men også skriveoperasjoner, siden indekser må oppdateres ved endringer i data. Effektiv bruk av ressurser fordrer også en helhetlig vurdering av workload og bruksprofil. Samtidig kan kompleksiteten i spørringsplaner og optimalisering gjøre det nødvendig med grundig testing og overvåking over tid for å sikre at endringer gir varige fordeler og ikke utilsiktede konsekvenser.

Hvordan effektivisere og automatisere distribusjon av SQL-ressurser i Azure med ARM og Bicep?

Når man distribuerer ressurser i Azure ved hjelp av ARM-maler (Azure Resource Manager templates), håndteres avhengigheter automatisk uavhengig av rekkefølgen på kommandoene i malen. For eksempel, hvis en mal inneholder både et virtuelt nettverk og en virtuell maskin, vil ARM alltid distribuere nettverket først, fordi det forstår at den virtuelle maskinen er avhengig av nettverket. Dette skjer uten at brukeren eksplisitt må angi avhengigheten i malen.

Å lage en ARM-mal fra bunnen av er mulig, men det krever inngående kjennskap til JSON-syntaksen og strukturen ARM benytter. Prosessen kan være tidkrevende, særlig for komplekse distribusjoner. En langt mer effektiv metode er å bruke alternativet "Download a template for automation" på gjennomgangssiden under opprettelsen av for eksempel en SQL Server-installasjon. Azure genererer da en ferdigkonfigurert mal basert på innstillingene brukeren har angitt. Denne malen kan redigeres, lagres og brukes om igjen ved behov.

Eksisterende distribusjoner i Azure kan også eksporteres som ARM-maler, inkludert alle deres gjeldende innstillinger. Dette gjør det mulig å standardisere installasjoner og gjenbruke konfigurasjoner på tvers av miljøer. Ved lagring av slike maler kan man også tilføye versjonskontroll, noe som gjør ARM til en form for bibliotek over distribusjoner som enkelt kan reproduseres.

Azure tilbyr i tillegg såkalte template specs, en strukturert og delbar måte å lagre ARM-maler på innenfor en ressursgruppe. Template specs administreres med rollebasert tilgangskontroll (RBAC), og kan opprettes direkte i Azure-portalen eller gjennom kommandolinjeverktøy som az ts create i Azure CLI eller New-AzTemplateSpec i PowerShell. Dette gir en mer formell og sikker måte å håndtere distribusjonsmaler på, særlig i større organisasjoner.

Distribusjon av ARM-maler og template specs kan skje gjennom flere metoder: manuelt via portalen, gjennom skript i Azure CLI, PowerShell, eller via Azure Cloud Shell. CLI og PowerShell støtter også automatisert masseutrulling, og gir fleksibilitet til både deklarative og imperative installasjoner.

Det er viktig å merke seg at det tradisjonelle Azure Templates-verktøyet fases ut 31. mars 2025. Microsoft anbefaler overgang til template specs. Selv om dette ikke inngår eksplisitt i DP-300-eksamensmålene, bør kandidater være kjent med endringen.

For brukere som ønsker å jobbe direkte med malenes kode, kan ARM-malens JSON-syntaks være kompleks og krevende. Her kommer Bicep som et kraftig alternativ. Bicep tilbyr en enklere og mer lesbar syntaks enn JSON, og egner seg både for utviklere og systemadministratorer.

Et eksempel: mens ARM-malen krever dypt nøstede strukturer med omstendelig bruk av parenteser og tegnsetting, kan Bicep uttrykke det samme på en mer direkte og modulær måte. Bicep støtter gjenbrukbare moduler og automatisk avhengighetsdeteksjon, slik at man ikke eksplisitt trenger å beskrive ressursavhengigheter – Bicep forstår dem automatisk.

Når en Bicep-fil distribueres, konverteres den automatisk til ARM JSON-format i bakgrunnen, slik at den fortsatt er fullt kompatibel med Azure-plattformens underliggende mekanismer. Dette gir brukeren det beste fra begge verdener – forenklet utvikling med høy presisjon og kontroll.

Distribusjon kan også automatiseres gjennom CLI og PowerShell. Eksempelvis kan en ARM-mal distribueres med følgende kommando i Azure CLI:

sql
az deployment group create --resource-group MyResourceGroup --template-file sqltemplate.json

Eller i PowerShell:

pgsql
New-AzResourceGroupDeployment -Name SQLDeployment -ResourceGroupName MyResourceGroup -TemplateFile 'C:\Templates\sqltemplate.json'

I tillegg til å distribuere deklarative maler, kan både Azure CLI og PowerShell brukes til imperative skript, som definerer og utfører hvert trinn eksplisitt, inkludert riktig rekkefølge og parametere. Dette er spesielt nyttig for brukere som ønsker mer detaljert kontroll eller trenger å integrere installasjoner i større automatiserte prosesser.

For eksempel, opprettelse av en SQL Server via CLI kan gjøres slik:

css
az sql server create --name myserver --resource-group MyResourceGroup --location norwayeast --admin-user adminuser --admin-password MySecureP@ssw0rd

Mens Bicep og ARM tilbyr deklarativ kontroll, gir imperative skript i CLI og PowerShell mulighet for betinget logikk og mer dynamisk atferd.

Det er avgjørende å forstå skillet mellom deklarative og imperative tilnærminger i infrastrukturen. Deklarative maler beskriver ønsket tilstand – hva som skal eksistere – mens imperative skript beskriver hvordan man kommer dit, steg for steg. Begge metodene har sin plass i moderne DevOps-prosesser, og en effektiv infrastrukturarkitekt behersker begge.

Å strukturere og standardisere SQL-distribusjoner i Azure gjennom ARM, Bicep og template specs gir både skalerbarhet, kontroll og reproduserbarhet. Dette er grunnleggende for organisasjoner som ønsker robusthet og forutsigbarhet i sin skyarkitektur.

Hvordan fungerer Always On Availability Groups og failover-kluster i SQL Server?

Always On Availability Groups samler flere sett med databaser under en enkelt gruppe som fungerer som én enhet. Gruppen består av ett sett med primære databaser som kan lese og skrive, og opptil åtte sett med sekundære databaser som kan være enten skrivebare eller skrivebeskyttede. Hver av disse databasene hostes på en server som kalles en tilgjengelighetsreplica. En enkelt primær replica håndterer alle klientforbindelser, mens sekundære replicae fungerer som potensielle failover-mål dersom den primære feiler. Synkroniseringen mellom primær og sekundære replicae sikrer at data kontinuerlig oppdateres i de sekundære databasene, og gir dermed høy tilgjengelighet og beskyttelse mot datatap.

For å kunne bruke Always On Availability Groups, kreves et klynge-miljø, som for eksempel Windows Server Failover Cluster (WSFC) på Windows eller Pacemaker på Linux. Hver tilgjengelighetsreplica må kjøres på forskjellige noder innenfor denne klyngen. Administratorer må først legge til Failover Clustering-funksjonen på hver server som skal fungere som en replica, for deretter å validere konfigurasjonen og legge til SQL-serverne i klyngen via Failover Cluster Manager. Når klyngen er operativ, må Always On-funksjonaliteten aktiveres i SQL Server Configuration Manager for hver replica, og serverne må startes på nytt for at endringene skal tre i kraft.

Opprettelse av en Always On Availability Group gjøres gjennom SQL Server Management Studio (SSMS). Der velger man "Always On High Availability" i Object Explorer, og starter veiviseren for nye tilgjengelighetsgrupper. Veiviseren leder administratoren gjennom prosessen med å navngi gruppen, velge hvilke databaser som skal inkluderes, og koble til de sekundære replicae. Etter opprettelsen kan gruppen overvåkes og administreres via en dedikert dashboard i SSMS, som gir innsikt i status og konfigurasjon.

En annen viktig funksjon er failover-grupper, som særlig brukes i Azure SQL Database og Azure SQL Managed Instance for å administrere replikering av databaser mellom servere i ulike geografiske regioner. Failover-grupper muliggjør automatisk overføring av tjenester ved feil i primærregionen, og krever at både primær og sekundær server har samsvarende innloggingsdetaljer og brannmurinnstillinger. Brukeren kan velge hvilke databaser som skal være med i gruppen, og sette opp standby-replikaer som bare brukes til katastrofegjenoppretting.

I et Windows Server Failover Cluster spiller quorum en kritisk rolle for å forhindre det som kalles «split-brain»-situasjoner. Dette oppstår dersom klyngen deles opp på grunn av nettverksfeil, og to separate cluster-deler begynner å operere uavhengig av hverandre. Dette kan føre til at databasen får to uavhengige kopier med inkonsistente data. Quorum-systemet fungerer som en stemmeordning der hver node sender regelmessige stemmer, og clusteret forblir operativt så lenge flertallet av stemmene mottas. Dersom en node ikke mottar nok stemmer, fjerner den seg selv fra klyngen.

Ved partall av noder i klyngen kan det oppstå stemmelikhet, som i praksis stopper klyngen. For å unngå dette opprettes en tiebreaker, kalt en witness, som kan være en disk, en filandel eller en skylagringsplassering. Witnessen gir den ene siden av en potensiell splitt en ekstra stemme, slik at clusteret kan fortsette å fungere med én konsistent database.

Konfigurering av quorum i WSFC gjøres ved å justere witness-innstillinger gjennom verktøy som Windows Admin Center eller Failover Cluster Manager. Her kan man velge mellom ulike typer witness, som skybasert blob-lagring eller filandel på nettverket, avhengig av miljø og behov.

Når SQL Server kjører som en Failover Cluster Instance (FCI) i Azure Virtual Machines, kreves fortsatt Windows Server Failover Clustering. En FCI fremstår utad som én SQL Server-instans, men muliggjør failover mellom nodene i klyngen for å sikre høy tilgjengelighet. Denne løsningen kombinerer både clustering og Always On-funksjonalitet, noe som gir en robust infrastruktur for kritiske databaser.

Det er viktig å forstå at for å opprettholde integritet og tilgjengelighet i slike distribuerte systemer, må konfigurasjonen av både kluster, quorum og tilgjengelighetsgrupper være presis og godt testet. Feil i disse komponentene kan føre til tap av data, inkonsistens eller nedetid. Samtidig må sikkerhetstiltak som riktig autentisering, brannmurinnstillinger og nettverkskonfigurasjon være nøye ivaretatt for å unngå uautoriserte tilganger eller at systemene blir sårbare for angrep.

Hvordan AI og IoT Revolusjonerer Helsevesenet 4.0
Hvordan samarbeid mellom ulike påtalemyndigheter kan forme store økonomiske etterforskninger
Hvordan fungerer køer i Python, og hvorfor er effektivitet viktig?
Hvordan planlegge for livsstilsendringer og håndtere uforutsette utfordringer i prosjekter
Hvordan anbefalinger fungerer: Bayesianske metoder og beslutningstaking i detaljhandelen