Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
SQL Server
De clientapplicatie voltooit een update van de primaire replica succesvol, maar bij het opvragen van de secundaire replica blijkt dat de wijziging niet wordt weergegeven. In dit scenario wordt ervan uitgegaan dat uw beschikbaarheid een gezonde synchronisatiestatus heeft. In de meeste gevallen verdwijnt dit gedrag na een paar minuten.
Als wijzigingen na enkele minuten nog steeds niet op de secundaire replica worden weergegeven, kan er een bottleneck ontstaan in de synchronisatieworkflow. De locatie van de bottleneck hangt ervan af of de secundaire replica is ingesteld op synchrone doorvoer of asynchrone doorvoer.
synchrone doorvoer
Elke succesvolle update op de primaire replica is reeds gesynchroniseerd met de secundaire replica, of dat de logrecords reeds zijn weggeschreven voor duurzame opslag op de secundaire replica. Daarom zou de bottleneck moeten zitten in het redo-proces dat plaatsvindt nadat het logbestand is weggeschreven op de secundaire replica.
Zodra redo is bijgehaald, worden alle leesbewerkingen op de secundaire replica uitgevoerd met snapshot-isolatie:
Langlopende transacties op de primaire replica
Opnieuw uitvoeren op secundaire replica
Asynchrone doorvoering
Aangezien asynchrone commit een transactie bevestigt zodra deze naar de lokale schijf wordt gespoeld, kan de bottleneck overal na dat punt zijn:
Langlopende transacties op de primaire replica
Netwerklatentie of doorvoer
Logboek vastleggen op de secundaire replica
Opnieuw doen op de secundaire replica
De volgende secties beschrijven de veelvoorkomende oorzaken waarom wijzigingen op de primaire replica niet worden weergegeven op de secundaire replica voor alleen-lezen zoekopdrachten.
Langdurige actieve transacties
Een langlopende transactie op de primaire replica voorkomt dat de updates op de secundaire replica worden gelezen.
Explanation
Alle leeswerklasten op de secundaire replica zijn snapshot-isolatiequeries. Bij snapshot-isolatie zien clients met alleen-leestoegang de beschikbaarheidsdatabase op de secundaire replica vanaf het beginpunt van de oudste actieve transactie in het redo-logboek. Als een transactie al uren niet is vastgelegd, verhindert de openstaande transactie dat alle alleen-lezenquery's nieuwe updates kunnen zien.
Diagnose en oplossing
Gebruik op de primaire replica DBCC OPENTRAN (Transact-SQL) om de oudste actieve transacties te bekijken en te kijken of ze kunnen worden teruggedraaid. Zodra de oudste actieve transacties zijn teruggedraaid en gesynchroniseerd met de secundaire replica, kunnen leesbewerkingen op de secundaire replica updates in de beschikbaarheidsdatabase waarnemen tot aan het begin van de op dat moment oudste actieve transactie.
Hoge netwerklatentie of lage netwerkdoorvoer veroorzaakt logopbouw op de primaire replica
Hoge netwerklatentie of lage doorvoer kunnen voorkomen dat logs snel genoeg naar de secundaire replica worden gestuurd.
Explanation
De primaire replica activeert doorstroomregeling voor het verzenden van het transactielogboek wanneer het maximumaantal toegestane niet-bevestigde berichten dat naar de secundaire replica is verzonden, is overschreden. Totdat sommige van deze berichten zijn bevestigd, kunnen geen logblokken meer naar de secundaire replica worden gestuurd. Deze situatie kan een ernstiger effect hebben op mogelijk dataverlies en mogelijk je recovery point objective (RPO) in gevaar brengen.
Diagnose en oplossing
Een hoge DMV-waarde log_send_queue_size kan aangeven dat logs worden teruggehouden bij de primaire replica. Door deze waarde te delen door log_send_rate krijg je een ruwe schatting van hoe snel data op de secundaire replica kan worden ingehaald.
Ook is het nuttig om de twee prestatieobjecten te controleren: SQL Server:Availability Replica > Flow Control Time (ms/sec) en SQL Server:Availability Replica > Flow control/sec. Door deze twee waarden te vermenigvuldigen zie je op het laatste moment hoeveel tijd er is besteed aan het wachten tot flow control is gewist. Hoe langer de wachttijd voor de flowcontrole, hoe lager de zendsnelheid.
Hieronder volgt een lijst met nuttige meetmethoden voor het diagnosticeren van netwerklatentie en doorvoer. Je kunt andere Windows tools zoals ping.exe gebruiken om netwerkgebruik te evalueren.
DMV log_send_rate
Prestatieteller
SQL Server:Database > Log Bytes Flushed/secPrestatieteller
SQL Server:Database Mirroring > Send/Receive Ack TimePrestatieteller
SQL Server:Availability Replica > Bytes Sent to Replica/secPrestatieteller
SQL Server:Availability Replica > Bytes Sent to Transport/secPrestatieteller
SQL Server:Availability Replica > Flow Control Time (ms/sec)Prestatieteller
SQL Server:Availability Replica > Flow Control/secPrestatieteller
SQL Server:Availability Replica > Resent Messages/sec
Om dit probleem op te lossen, probeer je je netwerkbandbreedte te upgraden of onnodig netwerkverkeer te verwijderen of te verminderen.
Een andere rapportageworkload verhindert dat de redo-thread wordt uitgevoerd
De redo-thread op de secundaire replica kan door een langlopende alleen-lezenquery geen DDL-wijzigingen aanbrengen. De redo-thread moet worden gedeblokkeerd voordat verdere updates beschikbaar kunnen worden gesteld voor de leeswerklast.
Explanation
Op de secundaire replica krijgen de alleen-lezen queries schemastabiliteitsvergrendelingen (Sch-S) vergrendelingen. Deze Sch-S vergrendelingen kunnen voorkomen dat de redo-thread schemawijzigings- (Sch-M) vergrendelingen verkrijgt om DDL-wijzigingen door te voeren. Een geblokkeerde redo-thread kan geen logrecords toepassen totdat deze is ontblokt.
Diagnose en oplossing
Wanneer de redo-thread wordt geblokkeerd, wordt een uitgebreide gebeurtenis met de naam sqlserver.lock_redo_blocked gegenereerd. Daarnaast kun je de DMV-sys.dm_exec_request op de secundaire replica navragen om te achterhalen welke sessie de REDO-thread blokkeert, en dan kun je corrigerende maatregelen nemen. De volgende query geeft de sessie-ID terug van de rapportagewerklast die de redo-thread blokkeert.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Je kunt de rapportagewerklast laten afronden, waarna de redo-thread wordt ontblokkeerd, of je kunt de redo-thread direct deblokkeren door het KILL (Transact-SQL) commando uit te voeren op de blokkerende sessie-ID.
Redo-thread loopt achter door conflicten om systeembronnen
Een grote rapportagebelasting op de secundaire replica heeft de prestaties van de secundaire replica vertraagd, en de redo-thread is achtergelopen.
Explanation
Bij het toepassen van logrecords op de secundaire replica leest de redo-thread de logrecords van de logschijf, en voor elk logrecord opent hij de datapagina's om het logrecord toe te passen. De pagina-toegang kan I/O-gebonden zijn (toegang tot de fysieke schijf) als de pagina nog niet in de bufferpool zit. Als er een I/O-gebonden rapportagewerklast is, concurreert de rapportagewerklast om I/O-bronnen met de redo-thread en kan de redo-thread vertragen. Deze situatie zorgt er niet alleen voor dat andere rapportageworkloads geen bijgewerkte gegevens kunnen zien, maar heeft ook invloed op de RTO.
Diagnose en oplossing
Je kunt de volgende DMV-query gebruiken om te zien hoe ver de redo-thread achterloopt, door het verschil te meten tussen de kloof tussen last_redone_lsn en last_received_lsn.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
Als de redo-thread inderdaad achterloopt, moet je de oorzaak van de prestatiedegradatie op de secundaire replica onderzoeken. Als er een I/O-conflict is met de rapportagewerklast, kun je Resource Governor gebruiken om CPU-cycli te regelen die door de rapportagebelasting worden gebruikt om indirect de I/O-cycli te regelen, tot op zekere hoogte. Als je rapportageworkload bijvoorbeeld 10 procent van de CPU verbruikt, maar de workload I/O-gebonden is, kun je Resource Governor gebruiken om het CPU-gebruik te beperken tot 5 procent en zo de leesworkload af te remmen, waardoor de impact op I/O minimaal blijft.