Under det senaste året har jag presenterat många sessioner om Azure SQL Database samt skrivit många artiklar och bloggar. Jag får ofta frågan om databasunderhåll fortfarande är en viktig faktor när jag använder Azure SQL Database. Ja – uppgifter som indexunderhåll, statistikuppdateringar och konsistenskontroll är fortfarande viktiga, och det är upp till DBA att schemalägga dessa uppgifter. Förvirringen beror på att Azure SQL Database är en plattform som en tjänst och att Microsoft ansvarar för infrastrukturen samt hanterar säkerhetskopieringarna. Även om vissa aspekter av fysisk korruption kan förklaras, är logisk korruption i databasen inte det. Av den anledningen rekommenderar jag fortfarande att klienter kör DBCC CHECKDB för att säkerställa att de är helt skyddade.
Problemet som uppstår när en ny DBA arbetar med Azure SQL Database är att det inte finns en inbyggd SQL Server Agent som vi är vana vid med SQL Server Standard och Enterprise Editions.
För att schemalägga underhållsjobb mot en Azure SQL-databas har du ett antal alternativ:
- Länkade servrar
- Databasunderhållsplaner
- Powershell
- Azure Services
- Elastiska jobb
Följande demos förutsätter att du redan har konfigurerat inloggningskonton, brandväggsregler och andra säkerhetsinställningar för att fjärråtkomst till dina Azure SQL-databaser.
Länkade servrar
Att ansluta till en Azure SQL-databas med en länkad server är ett mycket vanligt tillvägagångssätt eftersom de flesta DBA:er redan är bekanta med att skapa och hantera länkade servrar. De två vanligaste sätten som jag har sett klienter använda länkade servrar är med antingen SQL Server Native Client eller Microsoft OLE DB Provider för ODBC-drivrutiner som leverantör. Om du använder den inbyggda klienten måste du ange servernamnet som datakälla; men om du använder ODBC-drivrutinen måste du hämta anslutningssträngen och använda den som leverantörssträng. Båda dessa värden finns i Azure Portal för din databas. När du klickar på din databas kommer du att se servernamnet och ett alternativ för att visa databasanslutningssträngarna. Detta servernamn, sqlperformance.database.windows.net är vad jag skulle använda för SQL Server Native Client-datakällan.
När du klickar på "Visa databasanslutningssträngar" har du för närvarande alternativ för ADO.NET, JDBC, ODBC och PHP. För att se anslutningssträngen för ODBC, klicka på fliken ODBC.
Därefter måste du skapa den länkade servern i SSMS. Under "Serverobjekt", högerklicka på "Länkade servrar", välj "Ny länkad server" och skriv in nödvändig information beroende på valet av din datakälla.
Klicka sedan på "Säkerhet" och definiera dina inställningar. Vanligtvis ser jag alternativet "Gjorda med detta säkerhetssammanhang" med en fjärrinloggning och ett lösenord som tillhandahålls.
När du har definierat allt detta klickar du på OK. Du kan nu högerklicka på din nya länkade server och testa anslutningen.
Du kan nu referera till den länkade servern för att anropa alla lagrade procedurer, såsom Ola Hallengrens Index Optimize och DatabaseIntegrityCheck direkt mot Azure SQL Database i ett SQL Agent-jobbsteg.
Databasunderhållsplaner
Om du planerar att använda en databasunderhållsplan för ditt underhåll är processen lite enklare. För att komma igång, skapa helt enkelt din underhållsplan manuellt eller med hjälp av guiden. Om du använder guiden kan du när du har skapat underhållsplanen redigera planen och sedan lägga till Azure-anslutningen. Du ändrar sedan varje uppgift för att använda den nya anslutningen. Din anslutningsskärm bör se ut som följande:
Du kan nu schemalägga dina databasunderhållsplaner så att de körs under ditt underhållsfönster.
PowerShell
PowerShell är ett utmärkt alternativ för att arbeta med repeterbara uppgifter och att använda PowerShell med Azure SQL Database är enkelt. Du kan använda funktionen Invoke-SqlCmd för att fråga eller köra satser mot dina databaser.
Ett vanligt tillvägagångssätt är att använda ett skript som liknar:
$params = @{
'Database' = 'YourDatabase'
'ServerInstance' = 'instance.database.windows.net'
'Username' = 'UserName'
'Password' = 'ComplexP@$$word'
'Query' = 'Your Query Here'
}
Invoke-Sqlcmd @params För din fråga kan du använda Ola Hallengrens indexoptimerings- och konsistenskontroller, eller något anpassat skript som du har använt. Du måste sedan schemalägga dina PowerShell-skript med vilken schemaläggare du än använder för din organisation.
Azure Services
Azure Automation är inbyggt i Azure-plattformen och för att komma igång måste du skapa ett automationskonto. Du måste ange ett namn för kontot, välja din prenumeration, resursgrupp, plats och bestämma om du vill skapa ett Azure Run As-konto.
När du har skapat ditt konto kan du börja skapa runbooks. Du kan göra nästan vad som helst med runbooks. Det finns många befintliga körböcker som du kan bläddra igenom och ändra för eget bruk, inklusive provisionering, övervakning, livscykelhantering och mer.
Du kan skapa runbooks offline eller använda Azure Portal, och de är byggda med PowerShell. I det här exemplet kommer vi att återanvända koden från PowerShell-demon och även visa hur vi kan använda den inbyggda Azure Service-schemaläggaren för att köra vår befintliga PowerShell-kod och inte behöva förlita oss på en lokal schemaläggare, uppgiftsschemaläggare eller Azure VM för att schemalägga ett jobb.
Börja med att klicka på Runbooks
Klicka sedan på "Lägg till en runbook"
Klicka på "Skapa en ny runbook"
Ange ett namn och typ av runbook, jag valde PowerShell för min demo.
Du är då i en redigeringsskärm för din nya runbook. Här kan du konfigurera detaljerna och bygga din runbook. För denna demo kör jag bara ett PowerShell-skript för att anropa en lagrad procedur mot en databas. När du har utarbetat all din kod kan du publicera och spara din runbook.
Härifrån kan du starta runbooken och validera att allt fungerar därefter, samt schemalägga runbooken så att den körs vid specifika tidpunkter. Låt oss gå igenom denna process genom att klicka på "Schemalägg"
Vi måste klicka på "Länka ett schema till din runbook" och eftersom vi inte har skapat några scheman tidigare måste vi definiera ett nytt genom att klicka på "Skapa ett nytt schema".
Ungefär som vi gör i SQL Server Agent, ange ett schemanamn, en beskrivning om du vill, när du ska starta och hur ofta den ska köras. Jag ställer in att den här ska ske varje dag kl. 02.00.
Jag har nu en publicerad runbook, planerad att köras varje natt kl. 02.00 för att utföra indexunderhåll på en av mina databaser.
Elastiska jobb
Elastic Jobs är fortfarande i förhandsvisning, så jag kommer inte att gå in i detalj på grund av den höga sannolikheten att skärmar och funktionalitet kommer att förändras.
Att använda Elastic Jobs kräver att du har definierat en elastisk databaspool och tilldelar minst en databas till poolen att köra jobb mot. När du har skapat den elastiska poolen och lagt till en databas kan du klicka på skapa jobb.
Ge ditt jobb ett beskrivande namn och ange användarnamn och lösenord för att ansluta till databaserna med, samt skriptet du vill köra. Klicka på spara och du har nu ett elastiskt jobb.
Du kan sedan välja att köra jobbet, visa skriptet eller avbryta jobbet om det körs.
Även om det finns vissa saker du kan göra via Azure Portal med de elastiska jobben, är de verkliga kraft- och konfigurationsalternativen tillgängliga via PowerShell API. För att schemalägga ett jobb måste du använda cmdleten New-AzureSQLJobSchedule. Mer information om de extra funktionerna och hur du schemalägger jobb finns här:
- Skapa och hantera elastiska SQL Database-jobb med PowerShell
Sammantaget gillar jag funktionen för elastiska jobb och hoppas att när den görs allmänt tillgänglig kommer mer funktionalitet att byggas in i Azure Portal utan att behöva hantera den med PowerShell. Jag gillar att du kan köra T-SQL direkt, utan att behöva köra det inom PowerShell och hur det kan köras mot alla databaser i poolen.
Sammanfattning
När det gäller Azure SQL-databaser, ja, du är fortfarande ansvarig för visst underhåll på dina databaser. Du har många metoder för att schemalägga jobb, och beroende på ditt behov och storleken på din miljö ger vissa alternativ bättre lösningar. Länkade servrar och databasunderhållsplaner är snabba och enkla metoder om du har lokala eller virtuella Azure-datorer med redan konfigurerad SQL-server och en liten Azure-distribution. PowerShell är alltid ett bra alternativ, du behöver bara hitta en lösning för att schemalägga skripten att köras. Azure automation är en mycket robust lösning som låter dig skapa runbooks för att åstadkomma nästan vad som helst och enkelt schemalägga runbooks och elastiska jobb är en annan bra Azure-baserad lösning om du har uppgifter som du behöver köra mot en grupp av databaser i en elastisk pool.