DP-300 är en certifiering för den Azure Database Administrator som ska hantera relationsdatabaser i Microsoft Azure, ikke kun besvara SQL-frågor. Ett vanligt misstag är att fokusera för snävt på index och traditionell databasserveradministration, eftersom examen prövar planering, säkerhet, övervakning, optimering och automatisering i Azure och Microsoft Azure.
DP-300: Administering Relational Databases on Microsoft Azure är kopplad till rollen Azure Database Administrator Associate. Den passar främst den som redan arbetar med SQL Server, Azure SQL Database, Azure SQL Managed Instance eller SQL Server på Azure Virtual Machines och vill visa att kunskaperna håller i molnbaserad drift. Den som är helt ny i Azure-data bör normalt börja med DP-900, medan DP-203 hör hemma hos data engineers som bygger datalager, pipelines och analyslösningar snarare än driftar relationsdatabaser.
Vad DP-300 mäter i praktiskt DBA-arbete
Microsoft Learn beskriver DP-300 som en examen för administration av relationsdatabaser på Microsoft Azure. I praktiken innebär det att kandidaten behöver förstå hela livscykeln för en dataplattform: välja rätt tjänst, konfigurera säker åtkomst, övervaka belastning, felsöka prestanda, automatisera återkommande arbete och planera för återställning vid avbrott.
De offentliga målen för examen omfattar bland annat att planera och implementera dataplattformsresurser, implementera en säker miljö, övervaka och optimera resurser och frågor, automatisera uppgifter, planera och implementera hög tillgänglighet och haveriberedskap samt administrera med T-SQL. Det är värt att läsa dessa mål som arbetsuppgifter snarare än som rubriker. En drifttekniker behöver till exempel kunna avgöra om en applikation ska ligga på Azure SQL Database, Managed Instance eller SQL Server på en virtuell dator innan säkerhet, övervakning och återställning ens går att utforma korrekt.
En vanlig miss är att studera varje domän isolerat. Produktvalet påverkar nästan allt: SQL Agent, CLR, linked servers, SSIS, cross-database-beteende, backupkontroll, nätverk, patchning och licensmodell ser olika ut beroende på plattform. Den som bara lär sig portalvyer riskerar därför att missa varför en viss arkitektur är rimlig, trots att den tekniska inställningen i sig verkar enkel.
Bygg en labbmiljö som liknar arbetet
En användbar DP-300-labb behöver inte vara stor, men den bör vara realistisk. Den bör innehålla en resursgrupp, en Azure SQL Database, gärna en liten Managed Instance om budgeten tillåter, en Log Analytics-arbetsyta, Azure Monitor-konfiguration, Microsoft Entra ID-autentisering, Key Vault för nyckel- och hemlighetshantering samt en plats där T-SQL-skript kan köras från en administrativ klient.
För att hålla kostnaden nere bör miljön byggas med minsta rimliga storlek, kort livslängd och tydliga städrutiner. Serverless för Azure SQL Database kan vara användbart i en träningsmiljö, men det måste förstås som ett kostnads- och belastningsval snarare än som en generell rekommendation. Hyperscale, zonredundans, geo-replikering och Managed Instance är viktiga att förstå, men de kan bli onödigt dyra om de lämnas igång utan syfte.
En enkel labbskiss kan beskrivas som tre delar. Klientdelen består av Azure Cloud Shell eller en administrativ arbetsstation med Azure CLI, Az PowerShell och SQL-verktyg. Datadelen består av Azure SQL Database och, vid behov, Managed Instance eller SQL Server på Azure VM för jämförelser. Observability-delen består av Azure Monitor, Log Analytics, diagnostikinställningar och Query Store, eftersom prestanda i Azure inte kan bedömas enbart från SQL Server Management Studio.
Kommandon och moduler ändras över tid. Ett säkert arbetssätt är att versionskontrollera sina labbskript, kontrollera aktuell Azure CLI-version med az version, kontrollera installerade Az PowerShell-moduler med Get-InstalledModule Az* och anteckna vilka tjänstinställningar som användes när labben kördes. Det gör felsökning enklare och minskar risken att blanda gamla kommandon med aktuella Azure-funktioner.
Följande exempel visar hur en kortlivad labbresursgrupp kan tas bort när övningen är klar. Använd det bara för resurser som är avsedda att raderas, inte för delade miljöer.
Exempel — städa bort en DP-300-labbmiljö
az group delete \
--name rg-dp300-lab-se \
--yes
Kommandot tar bort resursgruppen och resurserna i den. Lärpoängen är inte själva raderingen, utan vanan att isolera labbresurser så att experiment med databaser, nätverk och övervakning inte blir kvar och orsakar oväntade kostnader.
Välj rätt dataplattform innan detaljerna studeras
DP-300 blir lättare att förstå när tjänsterna jämförs utifrån driftansvar. Azure SQL Database passar ofta när applikationen kan använda en plattformsnära databastjänst med låg administrativ börda. Managed Instance passar när kompatibilitet med SQL Server-funktioner väger tungt, till exempel vid migreringar där instansnära funktioner behövs. SQL Server på Azure VM ger störst kontroll, men lämnar också mer ansvar för operativsystem, patchning, backupstrategi, säkerhetshärdning och hög tillgänglighet.
| Val |
När det ofta är rimligt |
DP-300-fråga att kunna besvara |
| Azure SQL Database |
Ny eller moderniserad applikation där plattformshanterad drift är viktig. |
Hur påverkar service tier, serverless, Query Store, säkerhet och återställning lösningen? |
| Azure SQL Managed Instance |
Migrering från SQL Server där instansfunktioner och hög kompatibilitet behövs. |
Vilka nätverks-, säkerhets- och funktionsskillnader finns jämfört med Azure SQL Database? |
| SQL Server på Azure VM |
Miljöer där full kontroll över SQL Server och operativsystem krävs. |
Vilket ansvar ligger kvar hos administratören för patchning, backup, HADR och säkerhet? |
Den här jämförelsen är mer än teori. Om en applikation kräver SQL Agent-jobb, linked servers eller specifika instansfunktioner kan ett val som verkar billigare eller enklare skapa driftproblem senare. Omvänt kan en virtuell dator vara onödigt tung om arbetslasten passar i Azure SQL Database och teamet vill minska mängden serverunderhåll.
Säkerhet måste övas i Azure, inte bara i SQL Server
Säkerhetsdelen i DP-300 missförstås ofta av kandidater som kommer från lokala SQL Server-miljöer. SQL-logins, brandväggsregler och behörigheter är fortfarande relevanta, men Azure-lösningar bygger i hög grad på Microsoft Entra ID, hanterade identiteter, privata slutpunkter, rollbaserad åtkomst, kryptering och i vissa fall kundhanterade nycklar.
Det praktiska målet är att kunna förklara vem eller vad som får ansluta, genom vilken nätverksväg, med vilken identitet och med vilka databasbehörigheter. I en produktionsnära miljö bör administratören också förstå skillnaden mellan åtkomst till Azure-resursen och åtkomst inne i databasen. En person kan ha rätt att se en SQL-serverresurs i Azure-portalen utan att automatiskt ha rätt att läsa tabeller.
Det här T-SQL-exemplet illustrerar principen med minst privilegium för en applikationsidentitet som redan finns i Microsoft Entra ID. Namnet måste motsvara en faktisk identitet i tenant-miljön.
Exempel — ge en hanterad identitet begränsad databasåtkomst
CREATE USER [mi-orders-api-prod] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [mi-orders-api-prod];
ALTER ROLE db_datawriter ADD MEMBER [mi-orders-api-prod];
Exemplet skapar en databasanvändare för en extern identitet och lägger den i roller som ger läs- och skrivåtkomst. I en verklig lösning bör behörigheterna granskas mot applikationens faktiska behov; administrativa roller bör inte användas som genväg i labben, eftersom det bygger fel muskelminne inför både examen och drift.
Övervakning och prestanda handlar om mer än index
Prestandadelen i DP-300 kräver fortfarande förståelse för index, exekveringsplaner, statistik och frågeskrivning. I Azure räcker det däremot inte att öppna en långsam fråga och justera ett index. Administratören måste även se hur resursmodell, service tier, vCore-val, lagring, väntetyper, Query Store, Azure Monitor och Log Analytics samverkar.
Det gör prestandaarbetet mer kostnadsmedvetet. En långsam applikation kan bero på en dålig fråga, men den kan också bero på fel tjänstenivå, för snäv beräkningskapacitet, kallstart i serverless, överdriven loggning eller ett HADR-val som ger annan skrivlatens än väntat. DP-300 testar därför inte bara om kandidaten kan optimera SQL, utan om kandidaten kan välja rätt åtgärd utan att höja kostnaden i onödan.
Följande Azure CLI-exempel visar hur diagnostikinställningar kan skickas till en Log Analytics-arbetsyta. Resurs-ID:n hämtas från den egna miljön innan kommandot körs.
Exempel — aktivera diagnostik för en Azure SQL Database
SQL_DATABASE_ID=$(az sql db show \
--resource-group rg-dp300-lab-se \
--server sql-dp300-lab-se \
--name sqldb-orders-lab \
--query id \
--output tsv)
WORKSPACE_ID=$(az monitor log-analytics workspace show \
--resource-group rg-dp300-lab-se \
--workspace-name log-dp300-lab-se \
--query id \
--output tsv)
az monitor diagnostic-settings create \
--name ds-sqldb-orders-lab \
--resource $SQL_DATABASE_ID \
--workspace $WORKSPACE_ID \
--logs '[{"category":"SQLInsights","enabled":true},{"category":"Errors","enabled":true},{"category":"QueryStoreRuntimeStatistics","enabled":true}]' \
--metrics '[{"category":"Basic","enabled":true}]'
Efteråt bör administratören verifiera att loggar faktiskt flödar till arbetsytan och att Query Store är aktiverat där det behövs. Lärpoängen är att prestandafelsökning i Azure börjar med observerbarhet; utan mätdata blir både indexförslag och kapacitetsändringar gissningar.
Automatisering och T-SQL bör tränas tillsammans
DP-300 kräver att kandidaten kan administrera med T-SQL, men rollen är inte begränsad till queryfönstret. I praktiken används T-SQL tillsammans med Azure CLI, PowerShell, Azure Automation, DevOps-pipelines och schemalagda driftjobb. Det viktiga är att förstå vilken uppgift som hör hemma i databasen och vilken som bör hanteras av plattformen.
En återkommande fallgrop är att försöka återskapa allt från en lokal SQL Server-instans i Azure utan att fråga om plattformen redan erbjuder en bättre mekanism. Backup, patchning, vissa former av skalning och övervakning är plattformsegenskaper i Azure SQL Database, medan SQL Server på Azure VM kräver mer egen hantering. Det påverkar både automatiseringsdesign och ansvarsmodell.
PowerShell lämpar sig väl för återkommande administrativa kontroller. Exemplet nedan läser upp grundläggande information om databaser på en Azure SQL-server utan att ändra miljön.
Exempel — inventera databaser med Az PowerShell
Get-AzSqlDatabase \
-ResourceGroupName "rg-dp300-lab-se" \
-ServerName "sql-dp300-lab-se" |
Select-Object DatabaseName, Edition, Status, CurrentServiceObjectiveName
Resultatet hjälper kandidaten att koppla samman portalens vyer med automatiserbar administration. Vid studier bör sådana kommandon följas av frågor som rör drift: vilka databaser är aktiva, vilka service objectives används, vilken kostnadsprofil antyder de och vilka ändringar kräver change management?
Hög tillgänglighet och återställning kräver tydliga antaganden
HADR-målen i DP-300 handlar om mer än att känna igen begrepp som backup, restore, failover group och geo-replikering. Kandidaten behöver kunna resonera om återställningsmål, regionala beroenden, testad failover, applikationsanslutningar och datakonsekvens. En plan som aldrig har testats är svår att lita på, även om den ser korrekt ut i Azure-portalen.
Det är också viktigt att skilja mellan hög tillgänglighet inom en tjänst och katastrofåterställning mellan regioner. Azure SQL Database har plattformsegenskaper som förenklar mycket av det traditionella DBA-arbetet, men designvalen är fortfarande administratörens ansvar. Managed Instance och SQL Server på Azure VM har andra möjligheter och begränsningar, särskilt när äldre applikationer eller instansberoenden påverkar lösningen.
Det här kommandot visar hur en återställningspunkt kan listas för en databas. Det skapar inga nya resurser och är därför lämpligt som en säker observationsövning.
Exempel — kontrollera återställningspunkter för Azure SQL Database
az sql db list-deleted \
--resource-group rg-dp300-lab-se \
--server sql-dp300-lab-se \
--output table
Kommandot används för att undersöka borttagna databaser som kan vara möjliga att återställa inom tjänstens återställningsramar. I studier bör det följas av dokumentationsläsning om backup, retention, geo-restore och failover groups, eftersom återställning alltid beror på vald tjänst och konfiguration.
En studieplan som speglar examensarbetet
En effektiv studieplan börjar med Microsoft Learns aktuella examenssida för DP-300 och listan över skills measured. Kandidaten bör därefter översätta varje mål till en labbuppgift: skapa resurser, låsa ned åtkomst, samla in mätdata, analysera en långsam fråga, automatisera en kontroll, konfigurera återställningsrelaterade inställningar och dokumentera valet mellan plattformar.
Studierna bör växla mellan dokumentation, labb och scenariobedömning. Efter varje labb bör kandidaten skriva ned vilken tjänst som användes, vilka antaganden som gjordes, vilken säkerhetsmodell som gällde, hur övervakningen verifierades och vad som skulle ändras i produktion. Den sortens anteckningar är ofta mer värdefulla än skärmbilder, eftersom de tränar de beslut som DP-300 vill mäta.
- Planera resurser genom att jämföra Azure SQL Database, Managed Instance och SQL Server på Azure VM för samma applikationskrav.
- Säkra miljön med Microsoft Entra ID, hanterade identiteter, privata anslutningsvägar och databasroller med minsta privilegium.
- Övervaka och optimera med Query Store, Azure Monitor, Log Analytics och kostnadsmedvetna kapacitetsval.
- Automatisera återkommande kontroller med T-SQL, Azure CLI eller PowerShell i stället för manuell portalklickning.
- Planera återställning genom att testa backup-, restore- och failover-scenarier med tydliga antaganden.
Det är också här utbildning kan vara relevant, särskilt för den som vill få struktur på labbar och scenarier utan att fastna i enbart dokumentationsläsning. En DP-300-inriktad kurs hos Readynez bör i så fall ses som ett stöd för praktisk färdighetsträning, inte som en ersättning för egen labbning och läsning av Microsofts aktuella examensmål.
Vanliga fallgropar inför DP-300
Den första fallgropen är att överföra lokala SQL Server-vanor direkt till Azure. Det märks särskilt i säkerhet, där kandidater ofta fokuserar på SQL-logins och brandväggar men ägnar för lite tid åt Microsoft Entra ID, hanterade identiteter, privata slutpunkter och relationen mellan Azure RBAC och databasbehörigheter.
Den andra fallgropen är att behandla prestanda som ett rent T-SQL-problem. Indexering och frågeoptimering är centrala färdigheter, men i Azure måste de kopplas till tjänstenivå, resursgränser, observerbarhet och kostnad. Att skala upp kan vara rätt åtgärd i vissa fall, men det är en svag standardlösning om ingen först har analyserat väntestatistik, Query Store-data och arbetslastmönster.
Den tredje fallgropen är att läsa om HADR utan att testa återställning. En kandidat bör kunna beskriva vad som händer med anslutningssträngar, identiteter, beroenden och dataförlustantaganden vid ett avbrott. Det är där skillnaden mellan att känna igen terminologi och att kunna administrera en miljö blir tydlig.
Från examensmål till tryggare Azure-drift
DP-300 är mest värdefull när förberedelserna följer samma logik som arbetet: välj plattform utifrån krav, säkra åtkomst med rätt identitetsmodell, samla in mätdata innan optimering, automatisera sådant som upprepas och testa återställning innan den behövs. Den som studerar på det sättet tränar både examensmålen och den praktiska förmågan att drifta relationsdatabaser i Azure.
Det mest praktiska nästa steget är att jämföra den egna erfarenheten med Microsoft Learns aktuella DP-300-mål och bygga en liten labb som täcker luckorna. Om en mer styrd väg behövs kan Readynez användas som utbildningsstöd, men resultatet avgörs av hur väl kandidaten kan omsätta målen i verkliga beslut, kommandon och felsökning.
