Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL Server
Efter en automatisk failover eller en planerad manuell failover utan dataförlust på en tillgänglighetsgrupp kan du upptäcka att failovertiden överskrider ditt återställningstidsmål (RTO). Eller, när du uppskattar failover-tiden för en sekundär replika med synkron commit (som en automatisk failover-partner) med metoden i Monitor performance för Always On Availability Group, upptäcker du att den överstiger din RTO.
Om din automatiska failover fortfarande inte är klar, se Felsökning av automatiska failover-problem i SQL Server 2012 Always On-miljöer.
Följande avsnitt beskriver vanliga orsaker till en failover-tid som överstiger RTO.
Rapporteringsbelastning hindrar redo-tråden från att köras
Redo-tråden på den sekundära repliken blockeras från att göra ändringar i datadefinitionsspråket (DDL) av en långvarig skrivskyddad fråga.
Explanation
På den sekundära replikan tar de skrivskyddade frågorna schemastabilitetslås (Sch-S). Dessa Sch-S lås kan hindra redo-tråden från att ta schemamodifieringslås (Sch-M) för att göra DDL-ändringar. En blockerad redo-tråd kan inte bearbeta loggposter förrän den har avblockerats. När blockeringen har hävts kan den fortsätta att hinna ikapp till slutet av loggen så att den efterföljande återställnings- och failoverprocessen kan fortsätta.
Diagnos och lösning
När redo-tråden blockeras genereras en utökad händelse som anropas sqlserver.lock_redo_blocked . Dessutom kan du fråga DMV:s sys.dm_exec_request på den sekundära repliken för att ta reda på vilken session som blockerar REDO-tråden, och sedan kan du vidta korrigerande åtgärder. Följande fråga returnerar sessions-ID:t för den skrivskyddade fråga som blockerar redo-tråden.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Du kan låta rapporteringsarbetsbelastningen avslutas, varpå redo-tråden avblockeras, eller så kan du avblockera redo-tråden omedelbart genom att köra KILL (Transact-SQL) kommandot på blocksessionens ID.
Redo-tråden halkar efter på grund av konkurrens om resurser
En hög rapporteringsbelastning på sekundärkopian har försämrat prestandan för sekundärkopian, och redo-tråden har halkat efter.
Explanation
När loggposter appliceras på den sekundära repliken läser redo-tråden loggposterna från loggdisken, och för varje loggpost går den sedan åt datasidorna för att applicera loggposten. Sidåtkomsten kan vara I/O-begränsad (åtkomst till den fysiska disken) om sidan inte redan finns i buffertpoolen. Om det finns en rapporteringsarbetsbelastning som är I/O-bunden konkurrerar rapporteringsarbetsbelastningen om I/O-resurser med redo-tråden och kan fördröja redo-tråden.
Diagnos och lösning
Du kan använda följande DMV-fråga för att se hur långt redo-tråden har halkat efter, genom att mäta skillnaden i avståndet mellan last_redone_lsn och 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
Om redo-tråden verkligen halkar efter behöver du undersöka grundorsaken till prestandaförsämringen på sekundärkopian. Om det uppstår en I/O-konflikt med rapporteringsarbetsbelastningen kan du använda Resource Governor för att styra CPU-cykler som rapporteringsarbetsbelastningen använder för att indirekt styra de I/O-cykler som tas, till viss del. Till exempel, om din rapporteringsarbetsbelastning förbrukar 10 procent av CPU:n men arbetsbelastningen är I/O-bunden, kan du använda Resource Governor för att begränsa CPU-resursanvändningen till 5 procent för att strypa läsbelastningen, vilket minimerar påverkan på I/O.