Het afgelopen jaar heb ik veel sessies over Azure SQL Database gegeven en talloze artikelen en blogs geschreven. Ik krijg vaak de vraag of database-onderhoud nog steeds een belangrijke factor is bij het gebruik van Azure SQL Database. Ja, taken zoals indexonderhoud, updates van statistieken en consistentiecontrole zijn nog steeds belangrijk, en het is aan de DBA om deze taken te plannen. De verwarring komt voort uit het feit dat Azure SQL Database een Platform as a Service is en Microsoft verantwoordelijk is voor de infrastructuur en voor het afhandelen van de back-ups. Hoewel sommige aspecten van fysieke corruptie kunnen worden verklaard, is logische corruptie binnen de database dat niet. Om die reden raad ik klanten nog steeds aan om DBCC CHECKDB te gebruiken om ervoor te zorgen dat ze volledig worden beschermd.
Het probleem dat zich voordoet bij elke nieuwe DBA die met Azure SQL Database werkt, is dat er geen ingebouwde SQL Server Agent is zoals we gewend zijn met SQL Server Standard en Enterprise Editions.
Om onderhoudstaken voor een Azure SQL Database te plannen, hebt u een aantal opties:
- Gelinkte servers
- Onderhoudsplannen voor databases
- Powershell
- Azure-services
- Elastische banen
Bij de volgende demo's wordt ervan uitgegaan dat u al aanmeldingsaccounts, firewallregels en andere beveiligingsinstellingen hebt geconfigureerd om op afstand toegang te krijgen tot uw Azure SQL-databases.
Gelinkte servers
Verbinding maken met een Azure SQL Database met behulp van een gekoppelde server is een veelgebruikte benadering, aangezien de meeste DBA's al bekend zijn met het maken en beheren van gekoppelde servers. De twee meest voorkomende manieren waarop ik clients heb gezien die gekoppelde servers gebruiken, zijn met de SQL Server Native Client of Microsoft OLE DB Provider voor ODBC-stuurprogramma's als provider. Als u de native client gebruikt, moet u de servernaam opgeven als gegevensbron; als u echter het ODBC-stuurprogramma gebruikt, moet u de verbindingsreeks ophalen en die gebruiken als de providerreeks. Beide waarden zijn te vinden in de Azure Portal voor uw database. Zodra u op uw database klikt, ziet u de servernaam en een optie om de databaseverbindingsreeksen weer te geven. Deze servernaam, sqlperformance.database.windows.net, is wat ik zou gebruiken voor de SQL Server Native Client-gegevensbron.
Wanneer u op "Show database connection strings" klikt, heeft u momenteel opties voor ADO.NET, JDBC, ODBC en PHP. Om de verbindingsreeks voor ODBC te zien, klikt u op het tabblad ODBC.
Vervolgens moet u de gekoppelde server in SSMS maken. Klik onder "Serverobjecten" met de rechtermuisknop op "Gekoppelde servers", selecteer "Nieuwe gekoppelde server" en typ de vereiste informatie in, afhankelijk van de keuze van uw gegevensbronprovider.
Klik vervolgens op "Beveiliging" en definieer uw voorkeuren. Meestal zie ik de optie "Maak gebruik van deze beveiligingscontext" met een externe login en wachtwoord verstrekt.
Zodra u dit allemaal hebt gedefinieerd, klikt u op OK. U kunt nu met de rechtermuisknop op uw nieuwe gekoppelde server klikken en de verbinding testen.
U kunt nu verwijzen naar de gekoppelde server om opgeslagen procedures, zoals Index Optimize en DatabaseIntegrityCheck van Ola Hallengren, rechtstreeks aan te roepen met de Azure SQL Database in een SQL Agent-taakstap.
Database-onderhoudsplannen
Als u van plan bent een database-onderhoudsplan te gebruiken voor uw onderhoud, is het proces een beetje eenvoudiger. Om aan de slag te gaan, maakt u eenvoudig uw onderhoudsplan handmatig of met behulp van de wizard. Als u de wizard gebruikt, kunt u na het maken van het onderhoudsplan het plan bewerken en vervolgens de Azure-verbinding toevoegen. U wijzigt vervolgens elke taak om de nieuwe verbinding te gebruiken. Uw verbindingsscherm zou er als volgt uit moeten zien:
U kunt nu plannen dat uw database-onderhoudsplannen worden uitgevoerd tijdens uw onderhoudsperiode.
PowerShell
PowerShell is een uitstekende optie voor het werken met herhaalbare taken en het gebruik van PowerShell met Azure SQL Database is eenvoudig. U kunt de Invoke-SqlCmd-functie gebruiken om instructies voor uw databases op te vragen of uit te voeren.
Een gebruikelijke benadering is om een script te gebruiken dat lijkt op:
$params = @{
'Database' = 'YourDatabase'
'ServerInstance' = 'instance.database.windows.net'
'Username' = 'UserName'
'Password' = 'ComplexP@$$word'
'Query' = 'Your Query Here'
}
Invoke-Sqlcmd @params Voor uw zoekopdracht kunt u de indexoptimalisatie- en consistentiecontroles van Ola Hallengren gebruiken, of elk aangepast script dat u hebt gebruikt. U moet dan uw PowerShell-scripts plannen met de planner die u voor uw organisatie gebruikt.
Azure-services
Azure Automation is ingebouwd in het Azure-platform en om aan de slag te gaan, moet u een automatiseringsaccount maken. U moet een naam voor het account opgeven, uw abonnement, resourcegroep en locatie selecteren en bepalen of u een Azure Run As-account wilt maken.
Nadat u uw account heeft gemaakt, kunt u runbooks gaan maken. Je kunt bijna alles doen met de runbooks. Er zijn tal van bestaande runbooks die u kunt doorbladeren en wijzigen voor eigen gebruik, waaronder provisioning, monitoring, levenscyclusbeheer en meer.
U kunt de runbooks offline maken of de Azure Portal gebruiken, en ze zijn gebouwd met PowerShell. In dit voorbeeld zullen we de code uit de PowerShell-demo hergebruiken en ook laten zien hoe we de ingebouwde Azure Service-planner kunnen gebruiken om onze bestaande PowerShell-code uit te voeren en niet hoeven te vertrouwen op een on-premises planner, taakplanner of Azure VM om een taak te plannen.
Begin door op Runbooks te klikken
Klik vervolgens op "Een runbook toevoegen"
Klik op "Een nieuw runbook maken"
Geef een naam en runbook-type op, ik heb PowerShell geselecteerd voor mijn demo.
U bevindt zich dan in een bewerkingsscherm voor uw nieuwe runbook. Hier kunt u de details configureren en uw runbook bouwen. Voor deze demo voer ik gewoon een PowerShell-script uit om een opgeslagen procedure tegen een database aan te roepen. Zodra u al uw code heeft uitgewerkt, kunt u uw runbook publiceren en opslaan.
Vanaf hier kunt u het runbook starten en valideren dat alles dienovereenkomstig werkt, en kunt u ook plannen dat het runbook op specifieke tijden wordt uitgevoerd. Laten we dit proces doorlopen door op "Planning" te klikken
We moeten klikken op "Koppel een schema aan uw runbook" en aangezien we nog geen schema's hebben gemaakt, moeten we een nieuwe definiëren door op "Een nieuw schema maken" te klikken.
Net zoals we doen in SQL Server Agent, geeft u een schemanaam op, een beschrijving als u dat wilt, wanneer u moet beginnen en hoe vaak het moet worden uitgevoerd. Ik heb ingesteld dat deze elke dag om 2 uur 's nachts plaatsvindt.
Ik heb nu een gepubliceerd runbook, gepland om elke nacht om 2 uur 's nachts uit te voeren om indexonderhoud uit te voeren op een van mijn databases.
Elastische banen
Elastic Jobs is momenteel nog in preview, dus ik zal niet in detail treden vanwege de grote kans dat schermen en functionaliteit zullen veranderen.
Voor het gebruik van elastische taken moet u een elastische databasepool hebben gedefinieerd en ten minste één database aan de pool toewijzen om taken tegen uit te voeren. Nadat u de elastische pool hebt gemaakt en een database hebt toegevoegd, kunt u op taak maken klikken.
Geef uw taak een beschrijvende naam en geef de gebruikersnaam en het wachtwoord op om verbinding te maken met de databases, evenals het script dat u wilt uitvoeren. Klik op opslaan en je hebt nu een elastische baan.
U kunt er dan voor kiezen om de taak uit te voeren, het script te bekijken of de taak te annuleren als deze wordt uitgevoerd.
Hoewel er bepaalde dingen zijn die u via de Azure Portal kunt doen met de elastische taken, zijn de echte kracht en configuratie-opties beschikbaar via de PowerShell API. Als u een taak wilt plannen, moet u de cmdlet New-AzureSQLJobSchedule gebruiken. Meer details over de extra functies en het plannen van taken vindt u hier:
- Maak en beheer elastische SQL Database-taken met PowerShell
Over het algemeen vind ik de functie voor elastische taken leuk en ik hoop dat wanneer deze algemeen beschikbaar wordt gemaakt, er meer functionaliteit in de Azure Portal zal worden ingebouwd zonder deze met PowerShell te hoeven beheren. Ik vind het leuk dat je T-SQL rechtstreeks kunt uitvoeren, zonder dat je het binnen PowerShell hoeft uit te voeren en hoe het tegen alle databases in de pool kan worden uitgevoerd.
Samenvatting
Als het gaat om Azure SQL Databases, ja, je bent nog steeds verantwoordelijk voor bepaald onderhoud aan je databases. Je hebt talloze methoden om taken te plannen, en afhankelijk van je behoefte en de grootte van je omgeving, zijn bepaalde opties betere oplossingen. Gekoppelde servers en onderhoudsplannen voor databases zijn snelle en gemakkelijke methoden als u on-premises of Azure-VM's hebt met SQL-server al geconfigureerd en een kleine Azure-implementatie. PowerShell is altijd een goede optie, je hoeft alleen maar een oplossing te vinden voor het plannen van de uitvoering van de scripts. Azure-automatisering is een zeer robuuste oplossing waarmee u runbooks kunt maken om zo ongeveer alles te bereiken en eenvoudig de runbooks en elastische taken kunt plannen. Dit is een andere geweldige op Azure gebaseerde oplossing als u taken hebt die u moet uitvoeren op een groep databases in een elastische pool.