Utbildning
Frågekörningen tar längre tid på SQL Server AlwaysOn-sekundära repliker
Den här artikeln hjälper dig att lösa problemet där du får problem med frågeprestanda på skrivskyddade sekundära repliker.
Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 4040549
Anta att du har en medlemsdatabas för Microsoft SQL Server AlwaysOn-tillgänglighetsgruppen som innehåller en eller flera stora tabeller som har ett clustered row-store
index. En fråga för en eller flera av de stora tabellerna slutförs snabbare på den primära repliken än på en sekundär replik.
Anteckningar
- Frågan orsakar en klustrad indexgenomsökning av en stor del av tabellen.
- Frågan använder NOLOCK-tipset.
- Körningsplanens operatorer och operatorordning är identiska för både snabba och långsamma körningar.
- Att fråga sys.dm_db_index_physical_stats visar betydande fragmentering av det klustrade indexet.
- Om du avsluter databasen från AlwaysOn-tillgänglighetsgruppen förbättras prestandan för samma (tidigare) sekundära replikinstans, så att den liknar prestanda på den primära repliken.
När ögonblicksbildisolering tillämpas ignoreras NOLOCK-tips . Skillnaden i körningsvaraktighet mellan de primära och sekundära replikerna beror på att NOLOCK-tipset ignoreras på den skrivskyddade sekundära repliken där ögonblicksbildisolering tillämpas men inte på den primära repliken där ögonblicksbildisolering inte tillämpas som standard. Detta gör att genomsökningen av det klustrade indexet får nyckelordningen framtvingad på den sekundära repliken. På den primära repliken har NOLOCK-tipset företräde och påverkar beteendet. När det klustrade indexet är mycket fragmenterat leder tillämpningen av nyckelordningen för genomsökningen på den skrivskyddade sekundära repliken till att SQL Server utfärdar ensidesläsningar. Men på den primära repliken genomsöker SQL Server en allokeringsenhet för att läsa flera sidor per I/O-begäran.
Åtgärda problemet genom att återskapa indexet på den primära repliken. Den här åtgärden sprids sedan till sekundära repliker. Mer information finns i Rekommendationer för indexunderhåll med AlwaysOn-tillgänglighetsgrupper.
Den faktiska I/O-statistikinformationen SET STATISTICS IO
och -körningsplanen kanske inte hjälper vid diagnos när det här problemet uppstår. Dessa ger dig information om antalet sidor som läss men inte antalet I/O-åtgärder som ska läsa sidorna.
Leta först efter fragmentering av det klustrade indexet. Dessutom kan du samla in prestandaövervakarens I/O-läsåtgärder/s och I/O-läsbyte/sek processräknare två gånger en gång när du kör frågan med databasen i tillgänglighetsgruppen och igen från samma instans när databasen tas bort från tillgänglighetsgruppen och tas online. Om indexfragmentering orsakar läsningar på en sida på den sekundära repliken men inte på den primära repliken, kan du förvänta dig ett större antal läs-I/s och ett mindre antal lästa byte/s när databasen finns i tillgänglighetsgruppen jämfört med när den inte är det.
Dessutom kan det här beteendet inträffa men inte visas märkbart i alla miljöer. Till exempel kan ett I/O-undersystem som kan hantera den ökade nivån av I/s med minimal svarstid och liknande dataflöde göra det möjligt för det här problemet att gå obemärkt förbi.
Ytterligare resurser
Dokumentation
-
Felsöka återställningsköer i en AlwaysOn-tillgänglighetsgrupp - SQL Server
Den här artikeln hjälper dig att felsöka problem som rör återställningsköer i en AlwaysOn-tillgänglighetsgrupp.
-
Felsöka lång sändningskö i en AlwaysOn-tillgänglighetsgrupp - SQL Server
Den här artikeln felsöker problem som rör loggöverföringsköer i en AlwaysOn-tillgänglighetsgrupp.