Hoe prestaties van SQL-databases effectief te monitoren en te verbeteren in Azure?

Het meten en verbeteren van de prestaties van SQL-databases is essentieel voor elke organisatie die met kritieke applicaties werkt. Met behulp van de tools die Azure biedt, kunnen beheerders prestatiemetingen verzamelen en deze gegevens gebruiken om knelpunten in de infrastructuur of in de SQL Server-processen te identificeren. Dit is een cruciaal onderdeel van databasebeheer, omdat het ervoor zorgt dat de database optimaal functioneert en de benodigde resources op de juiste manier benut worden.

Het vergelijken van de algemene VM-prestaties met die van de SQL Server-processen biedt waardevolle inzichten. Zo kan het bijvoorbeeld duidelijk worden hoeveel van de serverbronnen door SQL Server worden verbruikt, en of de server over voldoende middelen beschikt voor andere applicaties of services. Als de server over voldoende middelen beschikt, kan het verlagen van de service-laag helpen om kosten te besparen, terwijl een gebrek aan middelen juist vraagt om een upgrade naar een hogere service-laag.

De prestaties van SQL-databases kunnen verder geanalyseerd worden aan de hand van de wachttijden, oftewel 'wait statistics'. Deze statistieken geven aan hoe vaak SQL Server moet wachten op een noodzakelijke bron, zoals CPU-cycli, geheugen of opslag, voordat een taak kan worden uitgevoerd. Wachttijden kunnen de algehele prestaties aanzienlijk vertragen. Door de wachttijden te volgen en te interpreteren, kunnen beheerders knelpunten in de SQL-architectuur isoleren en gericht aanpakken. Bijvoorbeeld, als de wachttijden ontstaan door een CPU die regelmatig 100% bereikt, kan het verhogen van de CPU-capaciteit helpen de wachttijden te verminderen en de prestaties te verbeteren. Ditzelfde principe geldt voor geheugen- en opslagcapaciteit: door de database uit te breiden met extra middelen kunnen wachttijden geminimaliseerd worden.

Azure biedt verschillende tools die beheerders helpen bij het configureren, monitoren en beheren van de prestaties van SQL-databases. De 'Overview'-pagina van een Azure SQL Database geeft een helder overzicht van de opslag en belangrijke prestatie-indicatoren. De 'Metrics'-pagina biedt de mogelijkheid om gedetailleerde grafieken van prestatiestatistieken te configureren, terwijl de 'Alerts'-pagina beheerders in staat stelt waarschuwingsregels in te stellen die meldingen sturen wanneer prestatiemaatstaven bepaalde drempels overschrijden.

SQL Insights biedt een robuuste oplossing voor het monitoren van alle Azure SQL-producten, inclusief Azure SQL Database, Azure SQL Managed Instance en SQL Server op een Azure VM. Dit systeem vereist een aparte VM voor monitoring, waarop de Azure Monitoring-agent en de Workload Insights-extensie geïnstalleerd moeten zijn. De beheerder maakt vervolgens een monitoring-profiel aan en configureert welke prestatiestatistieken gemeten moeten worden, hoe vaak deze gegevens verzameld moeten worden en naar welke Log Analytics-werkruimte de gegevens verzonden moeten worden.

SQL Insights is echter vanaf 31 december 2024 niet meer beschikbaar via de Azure-portal. Microsoft adviseert om in plaats daarvan de Azure Marketplace-afbeelding te gebruiken om een monitoring-VM te implementeren, die zowel de Azure Monitor Agent als de noodzakelijke extensies bevat. Het gebruik van deze tools kan helpen om een gedetailleerd en continu overzicht te krijgen van de prestaties van de SQL-databases, en biedt de mogelijkheid om de database-infrastructuur proactief aan te passen voor verbeterde prestaties en efficiëntie.

Het begrijpen van prestatie-indicatoren en het effectief configureren van monitoringtools zijn cruciaal voor het beheer van SQL-databases. Beheerders moeten niet alleen de serverprestaties monitoren, maar ook specifiek letten op de manier waarop SQL Server gebruikmaakt van de beschikbare middelen. Hierdoor kunnen ze beter inschatten wanneer een upgrade nodig is of wanneer resources efficiënter kunnen worden benut. Monitoring is dus niet alleen een reactie op incidenten, maar een continue strategie voor het optimaliseren van de prestaties van SQL-databases in de cloudomgeving van Azure.

Hoe zorgt Azure voor hoog beschikbare en veerkrachtige SQL Server-omgevingen?

In aanvulling op de HA/DR-beschermingsmogelijkheden die standaard in SQL Server zijn ingebouwd, biedt Azure eigen mechanismen voor virtuele machines die zorgen voor HA/DR-bescherming, onafhankelijk van de software die op de virtuele machines (VM's) draait. Deze mechanismen bieden belangrijke voordelen die bedrijven helpen om zowel operationele continuïteit te waarborgen als de risico’s van dataverlies te minimaliseren.

Azure Availability Sets splitsen de Azure-datacenters op in fault domains en update domains. Het doel van fault domains is ervoor te zorgen dat VM's die tot dezelfde availability set behoren, nooit op dezelfde fysieke server draaien. Dit biedt een extra beschermingslaag tegen hardwarestoringen. Aan de andere kant zorgen update domains ervoor dat software-updates en onderhoudswerkzaamheden niet gelijktijdig op alle VM's binnen dezelfde availability set worden uitgevoerd. Deze anti-affiniteitsregels zorgen ervoor dat een storing of onderhoudsvertraging in een datacenter niet meerdere VM's van een abonnee tegelijkertijd beïnvloedt.

Availability Zones bieden op een vergelijkbare manier bescherming tegen uitval op datacenter-niveau. Azure-regio's bestaan doorgaans uit meerdere datacenters, die zijn verdeeld in zones 1 tot 3. Door VM's in verschillende zones te plaatsen, kunnen Azure-abonnees ervoor zorgen dat elke VM zich in een ander datacenter bevindt. Dit betekent dat, zelfs in het geval van een grootschalige ramp of een andere gebeurtenis die een volledig datacenter uitschakelt, de VM's die zich in de andere zones van die regio bevinden, niet worden beïnvloed. Ze blijven online doordat ze zich in andere datacenters bevinden.

Azure Site Recovery is een andere belangrijke functie die organisaties helpt bij disaster recovery. Hiermee kunnen beheerders een Azure-VM uit de ene regio repliceren naar een andere regio. Mocht een heel datacenter of een volledige regio uitvallen, dan blijft de VM toegankelijk vanuit een andere regio. Het is belangrijk om te begrijpen dat Azure Site Recovery alleen werkt op VM-niveau en geen inzicht heeft in de specifieke SQL Server-transacties of andere software die op de VM draait.

In een HA/DR-strategie mag de rol van back-up en herstel niet worden onderschat. Back-ups vormen een fundamenteel onderdeel van de gegevensbeveiliging en moeten als een niet-onderhandelbare vereiste worden beschouwd. Het gebruik van geschikte back-up- en herstelstrategieën is essentieel om dataverlies te voorkomen. Dit geldt zowel voor IaaS-omgevingen (waar SQL Server op virtuele machines draait) als voor PaaS-omgevingen zoals Azure SQL Database, die automatische back-ups uitvoeren. Voor een IaaS-platform kunnen beheerders back-upopties selecteren op drie niveaus: SQL Server-software, besturingssysteem van de VM en de Azure-omgeving zelf. Het gebruik van geautomatiseerde back-ups kan eenvoudig worden ingesteld via de Azure-portal, waar beheerders de opslaglocatie, het retentiebeleid en de back-upplanning kunnen configureren.

Voor PaaS-deployments van Azure SQL Database en Azure SQL Managed Instance voert Azure automatisch back-ups uit, inclusief wekelijkse volledige back-ups, twee keer per dag een differentiële back-up en een transactie-logback-up elke tien minuten. Deze back-ups worden opgeslagen in Azure Blob Storage, met geo-redundantie, zodat ze in een ander datacenter worden bewaard dan de SQL Server zelf. Dit biedt een extra laag bescherming tegen uitval van een datacenter.

Wanneer back-ups eenmaal zijn gemaakt, is het herstellen van gegevens een cruciaal proces. Beheerders kunnen SQL Server Management Studio (SSMS) gebruiken om een database van een eerder gemaakte back-up te herstellen. Hier kunnen ze de herstelpunten selecteren, de herstelopties configureren en zelfs kiezen voor een punt-in-de-tijd herstel. Dit biedt flexibiliteit, vooral als een specifieke transactie of dataset moet worden hersteld, zonder de gehele database terug te zetten.

Het herstellen van een database naar een specifiek moment kan ook handig zijn bij het herstellen van een database na een corrupte transactie of een andere gebeurtenis die dataverlies heeft veroorzaakt. Het herstelproces kan variëren afhankelijk van het gekozen herstelmodel, zoals de opties voor 'WITH RECOVERY', 'WITH NORECOVERY' of 'WITH STANDBY'. Dit biedt beheerders de mogelijkheid om een database volledig te herstellen of om aanvullende logback-ups toe te passen zonder het herstelproces te onderbreken.

Het is essentieel om te begrijpen dat back-ups en herstelprocedures niet alleen technische processen zijn, maar ook een bedrijfsstrategie die de beschikbaarheid van cruciale gegevens en de continuïteit van de bedrijfsvoering waarborgt. Back-ups moeten regelmatig getest worden om ervoor te zorgen dat ze effectief kunnen worden hersteld in geval van nood. Organisaties moeten ervoor zorgen dat hun medewerkers goed opgeleid zijn in het beheer van back-ups en herstel, evenals in het reageren op noodgevallen.