Hur man övervakar och optimerar prestanda i Azure SQL Database: Verktyg och tekniker

För att upprätthålla och förbättra prestandan hos en Azure SQL-databas är det avgörande att använda de rätta verktygen och teknikerna för övervakning och optimering. En sådan process innebär en grundlig förståelse för hur olika övervakningsverktyg fungerar och hur de kan implementeras för att säkerställa att SQL-databasen körs på optimal nivå.

Med avvecklingen av SQL Insights, rekommenderar Microsoft att Azure-prenumeranter använder ett verktyg som kallas "Database Watcher" som den primära lösningen för prestandaövervakning i molnet för Azure SQL Database och Azure SQL Managed Instance-installationer. Database Watcher samlar in övervakningsinformation från databaser, hanterade instanser och elastiska pooler som valts av administratören och lagrar dessa data i en central datalagerlösning som Azure Data Explorer. Administratören måste skapa en resurs, en så kallad watcher, och konfigurera den genom att välja SQL-mål att övervaka samt en datalagringslösning för de övervakningsdata som samlas in. När dessa data samlats in kan administratörer visa dem via Azure-dashboards.

När en session är konfigurerad, kan data lagras på två sätt: antingen i en ringbuffer för realtidsbevakning, vilket innebär att data inte sparas utöver den aktuella sessionen, eller så lagras data i Azure-bloblagring för långsiktig lagring och efterföljande analys. Genom att noggrant välja vilka data som ska samlas in kan administratörer både effektivisera lagringshanteringen och förenkla den efterföljande analysen.

När det gäller prestandaoptimering av frågor i Azure SQL erbjuder Microsoft flera verktyg för att identifiera och åtgärda ineffektiva frågor. En sådan metod är Query Store, som finns i varje SQL-databas och sparar information om de frågor som exekveras, de exekveringsplaner som övervägs och de prestandastatistik som genereras under körningen. Genom att analysera denna information kan administratörer finjustera frågor och felsöka prestanda. Query Store innehåller tre separata lagringsområden: exekveringsplaner, körstatistik och väntestatistik, som alla hjälper till att identifiera eventuella flaskhalsar eller problem i fråga-exekvering.

En annan metod som kan användas för att övervaka och optimera SQL-prestanda är att identifiera och implementera indexändringar för frågor. Index kan drastiskt förbättra frågeprestanda genom att minska den tid det tar att hämta data från stora tabeller. Det är också viktigt att förstå hur SQL-servern använder index, och ibland kan det vara fördelaktigt att skapa nya index eller ändra befintliga för att bättre matcha frågornas exekveringsmönster.

Att förstå användningen av fråge-hintar är också centralt för att optimera frågeprestanda. Fråge-hintar ger administratörer möjlighet att tvinga SQL-servern att följa specifika exekveringsplaner eller att använda vissa index, vilket kan vara särskilt användbart när det finns komplexa eller oförutsägbara prestandaproblem.

För att identifiera och lösa prestandafrågor i realtid kan administratörer använda dynamiska vyer för hantering (DMVs). Dessa vyer ger detaljerad information om serveraktivitet och kan hjälpa till att identifiera blockeringar eller andra problem som påverkar prestandan.

När alla dessa verktyg och tekniker används tillsammans, kan administratörer inte bara upprätthålla en god prestandanivå för SQL-databaser utan också proaktivt identifiera och åtgärda potentiella problem innan de påverkar användarna.

Hur hanterar man blockeringar och prestanda i SQL-databaser?

Ett exempel på detta är om man kör följande kommando för att uppdatera en adress i en försäljningsdatabas:

sql
Copy code
BEGIN TRANSACTION
UPDATE salesdb.address SET city = 'New York' WHERE city = 'NY'

För att identifiera och åtgärda blockeringar i Azure SQL Database används dynamiska hanteringsobjekt (DMO), som kan vara vyer eller funktioner. Genom att analysera dessa kan administratörer snabbt lokalisera vilka transaktioner som orsakar blockeringar och åtgärda dem. Ett exempel på ett skript som kan användas för att identifiera blockeringar genom DMVs är följande:

sql
Copy code
WITH cteBL (session_id, blocking_these) AS

(SELECT s.session_id, blocking_these = x.blocking_these
 FROM sys.dm_exec_sessions s
 CROSS APPLY 
 (SELECT ISNULL(CONVERT(VARCHAR(6), er.session_id), '') 
  FROM sys.dm_exec_requests AS er 
  WHERE er.blocking_session_id = ISNULL(s.session_id, 0)
  AND er.blocking_session_id <> 0 
  FOR XML PATH('')) AS x (blocking_these))
SELECT s.session_id, blocked_by = r.blocking_session_id, bl.blocking_text, 
       input_buffer = ib.event_info, *
FROM sys.dm_exec_sessions s

LEFT OUTER JOIN sys.dm_exec_requests r ON r.session_id = s.session_id

INNER JOIN cteBL AS bl ON s.session_id = bl.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE blocking_these IS NOT NULL OR r.blocking_session_id > 0

ORDER BY LEN(bl.blocking_these) DESC, r.blocking_session_id DESC;

Detta skript hjälper till att identifiera sessioner och transaktioner som blockerar andra processer och ger detaljerad information om orsakerna till blockeringen.

För att ytterligare förbättra prestanda och undvika blockeringar är det viktigt att regelbundet övervaka och analysera resursanvändning på databasservern. Detta görs effektivt med hjälp av DMVs, som innehåller statistik om serverns resursutnyttjande, inklusive CPU, minne och I/O. En särskilt användbar vy är sys.dm_db_resource_stats, som samlar in resursanvändning varje 15:e sekund och lagrar informationen i en timme. Genom att köra SELECT-frågor kan administratörer få information om resursbelastning vid specifika tidpunkter, vilket gör det möjligt att identifiera flaskhalsar och optimera servern.

För att analysera långsiktiga trender och identifiera potentiella prestandaproblem vid hög trafik kan administratörer använda längre tidsperioder med hjälp av sys.resource_stats-vyn, som samlar statistik om resursanvändning var femte minut och lagrar denna information i upp till 14 dagar. Denna funktion är avgörande för att kunna förstå och åtgärda prestandaproblem över tid, särskilt när det gäller elastiska databassystem och SQL Database-inställningar som använder elastiska pooler för lagring.

Förutom att hantera blockeringar och övervaka resursanvändning, är det också viktigt att regelbundet analysera och optimera index i databasen. Dåligt utformade index kan påverka prestanda negativt och orsaka fördröjningar i databashanteringen. Azure SQL Database erbjuder funktioner som automatisk justering av index, där systemet använder maskininlärning för att identifiera när nya index bör skapas eller gamla bör tas bort. Detta kan automatiseras via funktionen för automatiskt justering av plan, som utvärderar exekveringsplaner och ser till att databasen använder de mest effektiva indexen för varje fråga.

Vid användning av automatisk justering är det viktigt att förstå att Azure SQL Database är utformad för att ärva inställningar från sin överordnade server. Genom att aktivera alternativ som FORCE PLAN och CREATE INDEX kan databasen automatiskt optimera sina index för att förbättra prestanda och reducera query-exekveringstider.

Sammanfattningsvis är det av största vikt att hålla koll på och hantera både blockeringar och prestanda i en SQL-databas. Genom att utnyttja rätt verktyg och strategier för att analysera och optimera databasen kan administratörer minimera driftstopp och säkerställa att databasens resurser används effektivt. Regelbundna granskningar och optimeringar, tillsammans med användning av dynamiska hanteringsvyer, kan ge värdefulla insikter och hjälpa till att förhindra problem innan de blir kritiska.

Hur kan man övervaka och automatisera prestandan i SQL-databaser i Azure?

SQL Insights, som är ett fjärrövervakningsverktyg för alla Azure SQL-produkter, samlar in metrikinformation från alla SQL-resurser i ett Azure-abonnemang. Detta verktyg använder en separat virtuell maskin för att samla in nödvändiga data. Ett annat viktigt verktyg är Query Store, som lagrar information om de databassökningar som utförs, de sökplaner som beaktas av servern och de statistikuppgifter som genereras under exekveringen av dessa sökningar.

En annan central aspekt av prestandaövervakning är "blocking", vilket inträffar när en transaktion försöker komma åt data som redan är låst av en annan transaktion. Om låsen kvarstår för länge kan det skapa flaskhalsar som leder till prestandaproblem. Detta gör att det är viktigt att effektivt hantera databasens lås och försäkra sig om att transaktionerna inte blockerar varandra under längre perioder.

DBCC CHECKDB-kommandot i T-SQL är ett användbart verktyg för att upptäcka inkonsekvenser i databasen och kontrollera strukturell integritet för alla objekt. Vid behov kan det också åtgärda vissa problem som upptäcks under denna process.

När det gäller att automatisera uppgifter som till exempel säkerhetskopiering eller indexunderhåll, erbjuder Azure SQL Database och SQL Server på Azure Virtual Machines olika verktyg för att skapa och hantera jobb som kan köras vid bestämda tider. SQL Server Agent är en Windows-tjänst som gör det möjligt att automatisera dessa underhållsjobb. När SQL Server Agent har aktiverats kan administratörer skapa jobb för att schemalägga uppgifter som indexunderhåll, säkerhetskopiering och uppdateringar. Detta är särskilt användbart för att köra resursintensiva jobb under lågtrafikperioder för att inte påverka användarna negativt.

I Azure SQL Managed Instance är SQL Server Agent redan aktiverat och kan inte startas eller stoppas manuellt, medan det i andra SQL Server-installationer på virtuella maskiner måste konfigureras att starta automatiskt. För att skapa och hantera jobb i SQL Server Agent kan administratörer använda SQL Server Management Studio (SSMS), där de kan definiera scheman och skapa jobb för olika underhållsbehov.

För att skapa en stabil och prestandafokuserad miljö i Azure SQL Databases är det avgörande att övervaka väntetider, hantera lås och fragmentering samt automatisera underhållsåtgärder. Genom att förstå dessa processer och implementera relevanta verktyg och tekniker, kan man optimera både prestanda och driftssäkerhet i SQL-baserade applikationer.

Hur man använder ARM-mallar och Bicep för att automatisera SQL-installationer i Azure

ARM-mallar (Azure Resource Manager) är kraftfulla verktyg som gör det möjligt för användare att definiera, distribuera och hantera infrastruktur på Azure-plattformen. När en mall skapas för att distribuera både ett virtuellt nätverk och en virtuell maskin, kommer ARM att distribuera det virtuella nätverket först, oavsett i vilken ordning kommandona är definierade i mallen. Detta beror på att ARM känner till att den virtuella maskinen är beroende av nätverket, vilket garanterar att alla resurser som krävs för en specifik installation är korrekt prioriterade och distribuerade.

Användare kan skapa egna ARM-mallar från grunden och manuellt fylla i rätt syntax, men det är en process som kräver djupgående kunskaper om mallformatet och dess kommandostruktur. Ett mycket enklare sätt att skapa en ARM-mall är att använda funktionen "Download a template for automation" på sidan "Review + Create" vid installation av en SQL-databas. Detta öppnar en förkonfigurerad mall som innehåller alla inställningar som valts under installationsprocessen. Denna mall kan sedan modifieras efter behov och sparas för framtida användning.

Azure erbjuder även ett alternativ för att lagra och dela ARM-mallar genom så kallade "template specs". Template specs är delbara resurser som lagras i resursgrupper och kan hanteras genom rollbaserad åtkomstkontroll (RBAC). Användare kan skapa och dela template specs via Azure-portalen eller använda kommandon som az ts create i Azure CLI, eller New-AzTemplateSpec i PowerShell. Dessa template specs gör det möjligt att skapa och dela mallar på ett organiserat och säkert sätt.

Ett betydande problem för många användare som arbetar med ARM-mallar är den komplexa JSON-syntaxen som används i dessa mallar. För användare som vill arbeta mer effektivt med mallkoden, erbjuder Azure ett alternativ: Bicep. Bicep är ett förenklat språk för att skapa deklarativa maller för Azure, och det har flera fördelar framför den traditionella JSON-syntaxen.

En annan viktig funktion hos Bicep är dess förmåga att automatiskt upptäcka beroenden mellan resurser. Detta innebär att användare inte behöver dokumentera dessa beroenden manuellt, som de gör i JSON-mallar. Till exempel, om en Bicep-mall definierar installationen av en SQL-server och en databas, behöver användaren inte explicit ange att databasen är beroende av servern – Bicep kommer att hantera detta åt användaren.

Det är också viktigt att notera att Bicep är fullt kompatibelt med ARM-mallar. När en användare distribuerar en Bicep-fil kommer ARM-motorn att konvertera Bicep-koden till en ARM-mall med JSON-syntax i bakgrunden. Detta gör Bicep till ett kraftfullt alternativ för användare som vill dra nytta av de förenklade funktionerna utan att behöva ge upp någon av ARM-mallens funktionalitet.

Azure CLI och PowerShell erbjuder kraftfulla kommandon för att distribuera både ARM-mallar och Bicep-filer. Exempelvis kan ett kommando för att distribuera en ARM-mall via Azure CLI se ut som följer:

bash
Copy code
az deployment group create --resource-group ResourceGroup1 --name 'sqltemplate.json'

Om Azure CLI inte är tillgängligt kan användaren istället använda Azure Cloud Shell för att köra samma kommandon. Även om användning av PowerShell för SQL-distributioner inte är så vanlig, är det också möjligt att skapa och distribuera maller via PowerShell. Här är ett exempel på ett PowerShell-kommando för att distribuera en ARM-mall:

powershell
Copy code
New-AzResourceGroupDeployment -Name SQLDeployment -ResourceGroupName ResourceGroup1 -TemplateFile 'c:\MyTemplates\sqltemplate.json' -TemplateParameterFile 'storage.parameters.json'

Det är även möjligt att skapa skript som automatiskt installerar SQL-komponenter direkt via dessa kommandon. Det är dock viktigt att förstå att dessa skript är imperativa, vilket innebär att de innehåller specifika kommandon för att installera SQL-komponenter i rätt ordning. Medan detta ger flexibilitet, innebär det också att användaren måste vara medveten om exakt vilka kommandon som behövs för att säkerställa att installationen utförs på ett korrekt sätt.

Det finns också ett tips för de som förbereder sig för certifiering: Azure Templates-verktyget är planerat att tas bort den 31 mars 2025. Microsoft rekommenderar istället användning av template specs. Detta är en viktig förändring att ha i åtanke, även om template specs inte ingår i DP-300 certifieringens officiella mål.

Hur säkrar man hög tillgänglighet och katastrofåterställning i Azure för SQL Server?

Azure tillhandahåller flera mekanismer för hög tillgänglighet (HA) och katastrofåterställning (DR) som kompletterar de skyddsmekanismer som finns i SQL Server. Dessa mekanismer fungerar oberoende av den programvara som körs på virtuella maskiner (VM) och ger en extra nivå av skydd för att säkerställa att företagets data är skyddad mot både hårdvarufel och operativa problem.

En av de viktigaste funktionerna i Azure är användningen av tillgänglighetsset. Tillgänglighetsset delar upp Azure-datacenter i olika fel- och uppdateringsdomäner. Fel-domäner ser till att virtuella maskiner (VM) som tillhör samma tillgänglighetsset aldrig körs på samma fysiska server, vilket innebär att om en server skulle gå ner, påverkar det inte fler än en VM åt gången. Uppdateringsdomäner säkerställer att underhållsåtgärder, som mjukvaruuppdateringar, inte körs samtidigt på alla VM i ett tillgänglighetsset, vilket minskar risken för att hela enheten blir otillgänglig vid uppdatering.

För att skydda mot större katastrofer på datacenter-nivå har Azure tillgänglighetszoner. Dessa zoner erbjuder ett högre skydd för VMs genom att placera dem i olika datacenter inom en och samma region. Detta innebär att om ett datacenter i en viss zon skulle drabbas av en katastrof, förblir de virtuella maskinerna i de andra zonerna opåverkade. Denna metod säkerställer att dina tjänster förblir tillgängliga även vid allvarliga regionala störningar.

Azure Site Recovery erbjuder en ytterligare möjlighet för katastrofåterställning genom att replikerar virtuella maskiner från en region till en annan. Detta säkerställer att om en hel region skulle falla, kan VM:erna fortfarande nås från en annan region. Men det är viktigt att notera att Site Recovery endast fungerar på VM-nivå och inte har insyn i SQL Server-transaktioner eller någon annan applikationsspecifik programvara som kan vara installerad på en VM.

För att säkerställa att de HA/DR-lösningar som implementeras faktiskt fungerar, måste de testas noggrant. Oavsett om det är genom checklistor, bordssamtal, simuleringar eller fullständiga test med avbrott, är det avgörande att alla som är involverade i katastrofåterställningsprocessen är förberedda och vet exakt vad de ska göra vid en kris. Detta kan inkludera att använda realistiska testscenarier för att mäta systemets förmåga att återställa en databas eller tjänst på ett tillförlitligt sätt under en nödsituation.

När det gäller säkerhetskopiering och återställning av SQL-databaser är det viktigt att förstå att dessa lösningar inte bara handlar om att hantera den tekniska infrastrukturen, utan även om att ha rätt strategi för att minimera nedtid och dataförlust. Oavsett om det handlar om att säkerhetskopiera på plats eller i molnet, erbjuder Azure många alternativ för att säkerställa att dina databaser kan återställas vid behov.

För att säkerställa att en databas kan återställas på rätt sätt, bör administratorer välja en strategi för säkerhetskopiering som passar deras behov. För exempelvis IaaS (Infrastructure as a Service)-miljöer där SQL Server installeras på en virtuell maskin, kan säkerhetskopieringen ske på tre nivåer: SQL Server, operativsystemet på den virtuella maskinen och själva Azure-miljön. Azure ger också möjlighet att aktivera automatiska säkerhetskopior vid skapandet av en virtuell maskin, vilket gör det möjligt för administratörer att specificera en lagringsbehållare, konfigurera en säkerhetskopieringsplan och välja en behållningstid.

För PaaS-lösningar (Platform as a Service), som Azure SQL Database och Azure SQL Managed Instance, skapas säkerhetskopior automatiskt, inklusive fullständiga säkerhetskopior en gång per vecka, differenskopior två gånger om dagen, och transaktionsloggar var tionde minut. Dessa säkerhetskopior lagras i Azure Blob Storage med geografisk redundans, vilket innebär att de lagras i ett annat datacenter än SQL Servern, vilket säkerställer att de är skyddade även vid allvarliga fysiska katastrofer.

Det är avgörande att förstå skillnaden mellan de olika återställningsalternativen, särskilt när det gäller hur SQL Server hanterar transaktioner och återhämtningsprocessen. När en databas återställs, måste SQL Server också hantera alla transaktioner som inte var fullständiga vid tidpunkten för återställningen. Därför erbjuder SQL Server olika återställningslägen som gör det möjligt för administratörer att kontrollera när återställningen ska anses vara slutförd och om ytterligare säkerhetskopior ska tillämpas.

Att förstå dessa koncept och ha en robust plan för hög tillgänglighet och katastrofåterställning är inte bara en teknisk nödvändighet utan också en affärsstrategi. För att säkerställa kontinuerlig drift måste varje organisation ha effektiva och realistiska tester för katastrofåterställning, och en detaljerad säkerhetskopierings- och återställningsplan för sina databaser, så att data kan återställas snabbt och effektivt vid en eventuell katastrof.