I løbet af det seneste år har jeg præsenteret mange sessioner om Azure SQL Database samt skrevet adskillige artikler og blogs. Jeg bliver ofte spurgt, om databasevedligeholdelse stadig er en vigtig faktor, når du bruger Azure SQL Database. Ja – opgaver som indeksvedligeholdelse, statistikopdateringer og konsistenstjek er stadig vigtige, og det er op til DBA at planlægge disse opgaver. Forvirringen stammer fra, at Azure SQL Database er en platform som en tjeneste, og at Microsoft er ansvarlig for infrastrukturen samt håndtering af backups. Mens nogle aspekter af fysisk korruption kan tages i betragtning, er logisk korruption i databasen det ikke. Af den grund anbefaler jeg stadig, at klienter kører DBCC CHECKDB for at sikre, at de er fuldt beskyttet.
Problemet, der opstår med enhver ny DBA, der arbejder med Azure SQL Database, er, at der ikke er en indbygget SQL Server Agent, som vi er vant til med SQL Server Standard og Enterprise Editions.
For at planlægge vedligeholdelsesjob mod en Azure SQL-database har du en række muligheder:
- Sammenkædede servere
- Databasevedligeholdelsesplaner
- Powershell
- Azure Services
- Elastiske job
Følgende demoer antager, at du allerede har konfigureret login-konti, firewall-regler og andre sikkerhedsindstillinger til fjernadgang til dine Azure SQL-databaser.
Linkede servere
At oprette forbindelse til en Azure SQL-database ved hjælp af en linket server er en meget almindelig tilgang, da de fleste DBA'er allerede er bekendt med at oprette og administrere linkede servere. De to mest almindelige måder, hvorpå jeg har set klienter bruge forbundne servere, er med enten SQL Server Native Client eller Microsoft OLE DB Provider for ODBC Drivers som udbyder. Hvis du bruger den oprindelige klient, skal du angive servernavnet som datakilde; Men hvis du bruger ODBC-driveren, skal du hente forbindelsesstrengen og bruge den som udbyderstrengen. Begge disse værdier kan findes i Azure Portal til din database. Når du klikker på din database, vil du se servernavnet og en mulighed for at vise databaseforbindelsesstrengene. Dette servernavn, sqlperformance.database.windows.net er, hvad jeg ville bruge til SQL Server Native Client-datakilden.
Når du klikker på "Vis databaseforbindelsesstrenge", har du i øjeblikket muligheder for ADO.NET, JDBC, ODBC og PHP. For at se forbindelsesstrengen for ODBC skal du klikke på fanen ODBC.
Dernæst skal du oprette den sammenkædede server i SSMS. Under "Serverobjekter", højreklik på "Linked Servers", vælg "New Linked Server", og indtast de nødvendige oplysninger afhængigt af din datakildeudbyders valg.
Klik derefter på "Sikkerhed" og definer dine præferencer. Typisk ser jeg muligheden "Bliv lavet ved hjælp af denne sikkerhedskontekst" med et eksternt login og adgangskode.
Når du har defineret alt dette, skal du klikke på OK. Du kan nu højreklikke på din nye linkede server og teste forbindelsen.
Du kan nu referere til den linkede server for at kalde eventuelle lagrede procedurer, såsom Ola Hallengrens Index Optimize og DatabaseIntegrityCheck direkte mod Azure SQL Database i et SQL Agent-jobtrin.
Databasevedligeholdelsesplaner
Hvis du planlægger at bruge en databasevedligeholdelsesplan til din vedligeholdelse, er processen en smule lettere. For at komme i gang skal du blot oprette din vedligeholdelsesplan manuelt eller ved hjælp af guiden. Hvis du bruger guiden, kan du, når du har oprettet vedligeholdelsesplanen, redigere planen og derefter tilføje Azure-forbindelsen. Du ændrer derefter hver opgave for at bruge den nye forbindelse. Din forbindelsesskærm skulle ligne følgende:
Du kan nu planlægge dine databasevedligeholdelsesplaner til at køre under dit vedligeholdelsesvindue.
PowerShell
PowerShell er en fremragende mulighed for at arbejde med opgaver, der kan gentages, og det er ligetil at bruge PowerShell med Azure SQL Database. Du kan bruge Invoke-SqlCmd-funktionen til at forespørge eller udføre sætninger mod dine databaser.
En almindelig tilgang er at bruge et script, der ligner:
$params = @{
'Database' = 'YourDatabase'
'ServerInstance' = 'instance.database.windows.net'
'Username' = 'UserName'
'Password' = 'ComplexP@$$word'
'Query' = 'Your Query Here'
}
Invoke-Sqlcmd @params Til din forespørgsel kan du bruge Ola Hallengrens indeksoptimerings- og konsistenstjek eller ethvert tilpasset script, du har brugt. Du skal derefter planlægge dine PowerShell-scripts ved hjælp af den planlægning, du bruger til din organisation.
Azure Services
Azure Automation er indbygget i Azure-platformen, og for at komme i gang skal du oprette en automatiseringskonto. Du skal angive et navn til kontoen, vælge dit abonnement, din ressourcegruppe, din placering og afgøre, om du vil oprette en Azure Run As-konto.
Når du har oprettet din konto, kan du begynde at oprette runbooks. Du kan gøre næsten alt med runbooks. Der er adskillige eksisterende kørebøger, som du kan gennemse og ændre til dit eget brug, herunder klargøring, overvågning, livscyklusstyring og mere.
Du kan oprette runbooks offline eller ved hjælp af Azure Portal, og de er bygget ved hjælp af PowerShell. I dette eksempel vil vi genbruge koden fra PowerShell-demoen og også demonstrere, hvordan vi kan bruge den indbyggede Azure Service-planlægger til at køre vores eksisterende PowerShell-kode og ikke skal stole på en lokal planlægger, opgaveplanlægger eller Azure VM for at planlægge et job.
Start med at klikke på Runbooks
Klik derefter på "Tilføj en runbook"
Klik på "Opret en ny runbook"
Angiv et navn og runbook-type, jeg valgte PowerShell til min demo.
Du er så i en redigeringsskærm for din nye runbook. Her kan du konfigurere detaljerne og bygge din runbook. Til denne demo kører jeg bare et PowerShell-script for at kalde en lagret procedure mod en database. Når du har udarbejdet al din kode, kan du udgive og gemme din runbook.
Herfra kan du starte runbook og validere alt fungerer i overensstemmelse hermed, samt planlægge runbook til at køre på bestemte tidspunkter. Lad os gå gennem denne proces ved at klikke på "Schedule"
Vi bliver nødt til at klikke på "Link en tidsplan til din runbook", og da vi ikke har oprettet nogen tidsplaner før, bliver vi nødt til at definere en ny ved at klikke på "Opret en ny tidsplan".
Ligesom vi gør i SQL Server Agent, angiv et tidsplannavn, en beskrivelse, hvis du vil, hvornår du skal starte, og hvor ofte den skal køre. Jeg indstiller dette til at ske hver dag kl. 02.00.
Jeg har nu en udgivet runbook, der er planlagt til at køre hver nat kl. 02.00 for at udføre indeksvedligeholdelse på en af mine databaser.
Elastiske job
Elastic Jobs er stadig i preview i øjeblikket, så jeg vil ikke gå i detaljer på grund af den høje sandsynlighed for, at skærme og funktionalitet vil ændre sig.
Brug af elastiske job kræver, at du har defineret en elastisk databasepulje og tildeler mindst én database til puljen, som du skal køre job imod. Når du har oprettet den elastiske pulje og tilføjet en database, kan du derefter klikke på opret job.
Giv dit job et beskrivende navn og angiv brugernavnet og adgangskoden til at oprette forbindelse til databaserne med, samt det script, du gerne vil køre. Klik på Gem og du har nu et elastikjob.
Du kan derefter vælge at køre jobbet, se scriptet eller annullere jobbet, hvis det kører.
Selvom der er visse ting, du kan gøre gennem Azure Portal med de elastiske job, er de rigtige kraft- og konfigurationsmuligheder tilgængelige via PowerShell API. For at planlægge et job skal du bruge cmdlet'en New-AzureSQLJobSchedule. Flere detaljer om de ekstra funktioner og hvordan du planlægger job kan findes her:
- Opret og administrer SQL Database elastiske job ved hjælp af PowerShell
Generelt kan jeg godt lide den elastiske jobfunktion og håber, at når den bliver gjort alment tilgængelig, vil der blive indbygget mere funktionalitet i Azure Portal uden at skulle administrere den med PowerShell. Jeg kan godt lide, at du kan køre T-SQL direkte, uden at skulle køre det i PowerShell, og hvordan det kan køre mod alle databaser i puljen.
Oversigt
Når det kommer til Azure SQL-databaser, ja, du er stadig ansvarlig for en vis vedligeholdelse på dine databaser. Du har adskillige metoder til at planlægge job, og afhængigt af dit behov og størrelsen af dit miljø, giver visse muligheder bedre løsninger. Linkede servere og databasevedligeholdelsesplaner er hurtige og nemme metoder, hvis du har lokale eller Azure VM'er med SQL-server allerede konfigureret og en lille Azure-implementering. PowerShell er altid en god mulighed, du skal bare finde en løsning til at planlægge scripts til at køre. Azure automation er en meget robust løsning, der giver dig mulighed for at oprette runbooks for at opnå stort set alt og nemt planlægge runbooks og elastiske jobs er en anden fantastisk Azure-baseret løsning, hvis du har opgaver, som du skal køre mod en gruppe af databaser i en elastisk pulje.