Dataintegritet i Azure SQL Database

gäller för:Azure SQL Database

Microsoft ansvarar för att hantera dataintegritet i Azure SQL Database. Även om traditionella tekniker finns för DBA:er för att övervaka dataintegritet och återhämta sig från databaskorruption i SQL Server, har Microsoft SQL-ingenjörsteam utvecklat nya tekniker som hanterar vissa typer av korruption automatiskt och utan dataförlust. Tjänsten använder dessa tekniker för att undvika dataförlust och driftstopp i de fall där det kan undvikas.

Den här artikeln beskriver några av dessa tekniker, hur de fungerar och hur de påverkar kunder som är oroliga för vilka steg de bör vidta för att skydda sin data i Azure SQL Database.

Hur Microsoft hanterar dataintegritet

Att skydda dataintegriteten i Azure SQL Database innebär en kombination av tekniker och utvecklande metoder:

  • Omfattande övervakning av varningar om dataintegritetsfel. SQL Database Engine sänder ut varningar för alla fel och ohanterade undantag som indikerar problem med dataintegriteten. Ingenjörsteamet hanterar och undersöker dessa larm.

  • Identifiering av utebliven skrivning i I/O-system Databasmotorn har ytterligare funktionalitet för att upptäcka den vanligaste orsaken till observerade fysiska korruptionsfel: I/O-systemets "förlorade skrivningar". Denna funktionalitet spårar sidskrivningar och deras tillhörande LSN (Log Sequence Numbers). En efterföljande läsning av en datasida från disk jämförs med sidans förväntade LSN. Om LSN:erna på disken inte överensstämmer med de förväntade är sidan inaktuell, vilket leder till en omedelbar varning till teknikteamet.

  • Automatisk sidreparation. Vissa servicenivåer tillhandahåller databaskopior för affärskontinuitetsändamål. Tjänsten använder sedan automatisk sidreparation, vilket liknar teknologin som används i tillgänglighetsgrupper. Om en replika inte kan läsa en sida på grund av ett dataintegritetsproblem, hämtar tjänsten en ny kopia av sidan från en annan replik och ersätter den oläsliga sidan utan dataförlust eller kundstopp.

  • Dataintegritet i vila och under överföring. Alla databaser i tjänsten är konfigurerade för att verifiera sidor genom att använda inställningen CHECKSUM , som beräknar kontrollsumman över hela sidan och lagrar den i sidhuvudet för verifiering under läsning. Transport Layer Security (TLS) används också för all kommunikation utöver de grundläggande transportkontrollsummorna som tillhandahålls av TCP/IP.

  • Säkerhetskopiera och återställ integritetskontroller. Azure SQL Database utför sidverifiering både under servicemanaged backups och under varje återställningsoperation. Eventuella problem som hittas leder till en omedelbar varning till ingenjörsteamet.

Hur Microsoft hanterar incidenter med dataintegritet

Microsoft behandlar incidenter med felaktiga resultat eller korruption med största allvar. Företaget erbjuder support dygnet runt från alla Azure-utvecklingsteam. När man hanterar integritetsincidenter är målet att minimera otillgänglighet och minska mängden dataförlust.

Problem med systemdataintegritet

Microsoft åtgärdar problem som inte påverkar kunddata eller databastillgänglighet utan att meddela kunderna. Exempel inkluderar problem som automatisk sidreparation kan åtgärda, eller korruption i intern databasmetadata eller telemetri som inte påverkar kunddata eller frågeresultat.

Problem med kunddataintegritet

När Microsoft upptäcker ett problem med felaktiga resultat eller kunddatakorruption vidtar Microsoft följande åtgärder:

  1. Gör sitt bästa försök att kontakta kunden så snart som möjligt efter bekräftad upptäckt, i enlighet med integritetslagar.
  2. Om kontakt etableras arbetar kunden direkt med kunden för att förklara omfattningen av korruptionen, redogöra för återställningsalternativ och låta kunden välja det alternativ som passar bäst för deras applikation och scenario.
  3. Där det är möjligt hjälper de kunden att förstå omfattningen av påverkan på deras applikation, till exempel att identifiera om datakorruption har fått applikationen att ändra annan data på ett oväntat sätt.

Microsoft åtgärdar datakorruption genom att använda olika metoder och steg som vidtas i samordning med kunderna. Den försöker inte reparera det som kan leda till dataförlust utan kundens godkännande. Kunder kan inte utföra DBCC CHECKDB reparationsalternativ i Azure SQL Database eftersom du inte kan placera en databas i SINGLE_USER läge. Microsoft SQL-teamet kan dock vidta reparationsåtgärder inklusive men inte begränsat till:

  • Återskapa indexet. Till exempel, bygg om ett icke-klustrat index där bastabellen inte också är korrupt.
  • Kör DBCC CHECKDB med REPAIR_REBUILD en plats där reparationen inte har någon risk för dataförlust.
  • Kör DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS där reparationer kan orsaka viss förlust av data.
  • I scenarier där DBCC CHECKDB inte kan användas för att reparera dataintegritetsproblemet kan ingenjörer använda återställning till en viss tidpunkt före den tidpunkt då dataintegritetsproblemet uppstod, följt av en manuell uppspelning av relevanta transaktioner från transaktionsloggen. Ett exempel på när denna teknik tillämpas är när transaktionsloggen är korrupt på ett sätt som förhindrar automatisk uppspelning av alla transaktioner utan att kunddata korrupteras.

Ingenjörsteamet genomför detaljerade efteranalyser av problem som leder till felaktiga resultat eller datakorruption. Teamet följer noggrant de tillhörande reparationsartiklar som skapats på grund av problemet. Dessa postmortem-analyser leder till många betydande förbättringar, inklusive funktionen "lost writes" som beskrevs tidigare.

Kundeninitierade integritetskontroller

Det Microsoft-hanterade dataintegritetsskyddet ger tidig upptäckt av nya dataintegritetsproblem och åtgärdar dem när det är möjligt. Kundinitierade integritetskontroller ger DBCC CHECKDB ett extra skyddslager eftersom DBCC CHECKDB det är en omfattande korruptionsdetekteringsmekanism för hela databasen. DBCC CHECKDBkompletterar de Microsoft-hanterade funktionerna för dataintegritetsskydd.

Denna bredd och djup av detektering kräver betydande tid och extra beräknings- och I/O-resurser under DBCC CHECKDB exekveringen. Som ett resultat kan det DBCC CHECKDB påverka din arbetsbelastning på grund av resurskonkurrens.

Utöver övervakningen och skyddet som tjänsten erbjuder kan du köra DBCC CHECKDB på en frekvens och tidpunkt efter eget val, vilket balanserar det extra dataintegritetsskyddet mot den ökade resursförbrukningen.

DBCC CHECKDBär inte tillgängligt i Azure SQL Database Hyperscale. Som ett alternativ, använd för individuella tabeller DBCC CHECKTABLE ('<TableName>') WITH TABLOCK i databasen.

Kundfeedback och utvecklande metoder

Azure SQL:s ingenjörsteam ser regelbundet över och förbättrar tjänstens förmåga att upptäcka problem med dataintegriteten. Även om dataintegritetsfel är sällsynta, om du stöter på ett fel innan du fått notis från Azure Support, lämna in ett supportärende.

Om du har feedback att dela angående Microsoft strategi för dataintegritet vill ingenjörsteamet gärna höra från dig. För att kontakta ingenjörsteamet med feedback eller kommentarer om detta ämne, se https://aka.ms/sqlfeedback. Din feedback hjälper Microsoft att förbättra befintliga och utveckla nya funktioner för skydd av dataintegritet.

Relaterat innehåll

  • Last updated on