Gegevensintegriteit in Azure SQL Database

Van toepassing op:Azure SQL Database

Microsoft is verantwoordelijk voor het beheren van dataintegriteit in Azure SQL Database. Hoewel er traditionele technieken bestaan voor DBA's om dataintegriteit te monitoren en te herstellen van databasecorrupties in SQL Server, ontwikkelde het SQL-engineeringteam van Microsoft nieuwe technieken die sommige klassen corruptie automatisch en zonder dataverlies behandelen. De dienst gebruikt deze technieken om dataverlies en stilstand te voorkomen in gevallen waarin dat mogelijk is.

Dit artikel beschrijft enkele van deze technieken, hoe ze werken en hoe ze klanten beïnvloeden die zich zorgen maken over welke stappen ze moeten nemen om hun gegevens in Azure SQL Database te beschermen.

Hoe Microsoft data-integriteit beheert

Het beschermen van gegevensintegriteit in Azure SQL Database omvat een combinatie van technieken en zich ontwikkelende methoden:

  • Uitgebreide monitoring van foutmeldingen voor dataintegriteit. De SQL Database Engine geeft meldingen voor alle fouten en niet-behandelde uitzonderingen die wijzen op zorgen over dataintegriteit. Het engineeringteam behandelt en onderzoekt deze meldingen.

  • I/O-systeemdetectie van verloren schrijfacties. De database-engine heeft extra functionaliteit om de meest voorkomende oorzaak van waargenomen fysieke corruptieproblemen te detecteren: I/O-systeem' "verloren schrijfopdrachten". Deze functionaliteit volgt paginaschrijfopdrachten en hun bijbehorende LSN's (Log Sequence Numbers). Een latere lezing van een datapagina vanaf de schijf wordt vergeleken met het verwachte LSN van de pagina. Als er een afwijking is tussen de LSN’s op de schijf en wat er verwacht wordt, is de pagina verouderd, wat onmiddellijk leidt tot een waarschuwing aan het engineeringteam.

  • Automatische paginareparatie. Sommige servicelagen bieden databasereplica's voor business continuity doeleinden. De dienst maakt vervolgens gebruik van automatische paginareparatie, vergelijkbaar met de technologie die wordt gebruikt in beschikbaarheidsgroepen. In het geval dat een replica een pagina niet kan lezen vanwege een probleem met dataintegriteit, haalt de service een verse kopie van de pagina op van een andere replica, waarbij de onleesbare pagina wordt vervangen zonder dataverlies of klantdowntime.

  • Dataintegriteit in rust en tijdens transport. Alle databases in de dienst zijn geconfigureerd om pagina's te verifiëren door gebruik te maken van de CHECKSUM instelling, die de checksum over de hele pagina berekent en deze opslaat in de paginaheader voor verificatie tijdens het lezen. Transport Layer Security (TLS) wordt ook gebruikt voor alle communicatie, naast de basiscontroles op transportniveau die door TCP/IP worden geleverd.

  • Integriteitscontroles voor back-up en herstel. Azure SQL Database voert paginaverificatie uit tijdens service-managed back-ups en tijdens elke hersteloperatie. Eventuele gevonden problemen leiden tot een onmiddellijke waarschuwing voor het engineeringteam.

Hoe Microsoft omgaat met incidenten in gegevensintegriteit

Microsoft behandelt incidenten van verkeerde resultaten of corruptie met de grootste ernst. Het bedrijf biedt 24×7 ondersteuning van alle Azure engineeringteams. Bij het afhandelen van integriteitsincidenten zijn de doelen om onbeschikbaarheid te minimaliseren en het verlies van data te minimaliseren.

Problemen met systeemgegevensintegriteit

Microsoft corrigeert problemen die geen invloed hebben op klantgegevens of beschikbaarheid van databases zonder klanten hiervan op de hoogte te stellen. Voorbeelden zijn problemen die automatische paginareparatie kan oplossen, of corruptie in interne databasemetadata of telemetrie die geen invloed heeft op klantgegevens of queryresultaten.

Problemen met klantgegevensintegriteit

Wanneer Microsoft een probleem met verkeerde resultaten of klantgegevenscorruptie detecteert, onderneemt Microsoft de volgende acties:

  1. Doet zijn uiterste best om zo snel mogelijk na bevestigde detectie contact op te nemen met de klant, in overeenstemming met privacywetten.
  2. Als er contact wordt gelegd, werkt hij direct samen met de klant om de omvang van corruptie uit te leggen, herstelopties uiteen te zetten en de klant de optie te laten kiezen die het beste past bij hun toepassing en scenario.
  3. Waar mogelijk helpt het de klant bij het begrijpen van de omvang van de impact op hun applicatie, bijvoorbeeld door te identificeren of datacorruptie heeft veroorzaakt dat de applicatie andere data op een onverwachte manier heeft veranderd.

Microsoft herstelt datacorruptie door verschillende methoden en stappen te gebruiken die in samenwerking met klanten worden genomen. Het probeert geen reparatie die tot dataverlies kan leiden zonder goedkeuring van de klant. Klanten kunnen geen reparatieopties uitvoeren DBCC CHECKDB in Azure SQL Database omdat je een database niet in SINGLE_USER modus kunt plaatsen. Het Microsoft SQL-team kan echter reparatiestappen ondernemen, maar niet beperkt tot:

  • Bouw de index opnieuw op. Bouw bijvoorbeeld een niet-geclusterde index opnieuw op waarbij de basistabel niet ook corrupt is.
  • Voer DBCC CHECKDB uit met REPAIR_REBUILD wanneer er geen risico op gegevensverlies bestaat.
  • Voer DBCC CHECKDB uit met REPAIR_ALLOW_DATA_LOSS, waarbij reparaties enig gegevensverlies kunnen veroorzaken.
  • Voor scenario's waarin DBCC CHECKDB het dataintegriteitsprobleem niet kan worden opgelost, kunnen ingenieurs point-in-time herstel gebruiken tot het punt vóór het dataintegriteitsprobleem, gevolgd door een handmatige herhaling van relevante transacties uit het transactielogboek. Een voorbeeld waarbij deze techniek van toepassing is, is wanneer het transactielogboek zo beschadigd is dat automatische herhaling van alle transacties voorkomt, maar zonder klantgegevens te beschadigen.

Het engineeringteam voert gedetailleerde naonderzoek uit naar problemen die leiden tot verkeerde resultaten of datacorruptie. Het team volgt nauwlettend de bijbehorende reparatieonderdelen die door het probleem zijn gemaakt. Deze postmortems leiden tot veel belangrijke verbeteringen, waaronder de eerder beschreven "lost writes"-functionaliteit.

Door de klant geïnitieerde integriteitscontroles

De door Microsoft beheerde data-integriteitsbescherming biedt vroege detectie van nieuwe dataintegriteitsproblemen en herstelt deze waar mogelijk. Door de klant geïnitieerde integriteitscontroles met behulp van DBCC CHECKDB bieden een extra beveiligingslaag, omdat DBCC CHECKDB een uitgebreid mechanisme is voor het detecteren van corruptie in de volledige database. DBCC CHECKDBvult de door Microsoft beheerde functies voor gegevensintegriteit aan.

Deze breedte en diepte van detectie vereist aanzienlijke tijd en extra rekenkracht en I/O-middelen tijdens DBCC CHECKDB de uitvoering. Daardoor kan DBCC CHECKDB invloed hebben op uw workloads als gevolg van resourceconflicten.

Naast de monitoring en bescherming die de dienst biedt, kun je draaien DBCC CHECKDB op een frequentie en tijdstip naar keuze, waarbij je de extra dataintegriteitsbescherming afweegt tegen het extra resourceverbruik.

DBCC CHECKDBis niet beschikbaar in Azure SQL Database Hyperscale. Als alternatief kun je de DBCC CHECKTABLE ('<TableName>') WITH TABLOCK voor individuele tabellen in de database gebruiken.

Klantfeedback en evoluerende methodologieën

Het Azure SQL engineeringteam beoordeelt en verbetert regelmatig de mogelijkheden voor het detecteren van dataintegriteitsproblemen van de dienst. Hoewel fouten in gegevensintegriteit zeldzaam zijn, dien een supportcase in als je een fout tegenkomt voordat je een melding van Azure Support ontvangt.

Als je feedback hebt over de dataintegriteitsstrategie van Microsoft, hoort het engineeringteam graag van je. Om contact op te nemen met het engineeringteam voor feedback of opmerkingen over dit onderwerp, zie https://aka.ms/sqlfeedback. Uw feedback helpt Microsoft om bestaande mogelijkheden te verbeteren en nieuwe mogelijkheden voor gegevensintegriteit te ontwikkelen.

Verwante onderwerpen

  • Last updated on