Felsöka problem med SQL Server AlwaysOn

Den här artikeln hjälper dig att lösa det vanliga problemet med AlwaysOn-konfiguration på SQL Server.

Ursprunglig produktversion: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Ursprungligt KB-nummer: 10179

Viktiga meddelanden

• Microsoft CSS-data anger att en betydande andel av kundproblemen ofta tidigare åtgärdas i en frisläppt CU, men inte tillämpas proaktivt och rekommenderar därför pågående, proaktiv installation av CU:er när de blir tillgängliga. Mer information finns i Meddelande om uppdateringar av SQL Server Incremental Servicing Model (ISM).

  Information om hur du kontrollerar de senaste processorerna som kan vara tillgängliga för din version finns i Så här fastställer du version, utgåva och uppdateringsnivå för SQL Server och dess komponenter.

• Du kan se användbara verktyg för felsökning och övervakning av alwayson-tillgänglighetsgrupper i felsöknings- och övervakningsguiden för AlwaysOn-tillgänglighetsgrupper för att lära dig mer om de verktyg som du kan använda för att diagnostisera olika typer av problem och för övervakning av tillgänglighetsgrupper. Guiden innehåller också ytterligare scenarier som kanske inte beskrivs i den här guidade genomgången.

• Den överordnade noden för Dokumentation om AlwaysOn-tillgänglighetsgrupper och innehåller en referens för ett enda stopp för olika frågor, se AlwaysOn-tillgänglighetsgrupper (SQL Server).

Jag behöver tips om hur du konfigurerar AlwaysOn-tillgänglighetsgrupper

Om du letar efter dokumentation om hur du konfigurerar AlwaysOn-konfiguration kan du läsa följande dokument:

Komma igång med AlwaysOn-tillgänglighetsgrupper (SQL Server) – Dokumentet innehåller svar på många frågor som du kan ha om tillgänglighetsgrupper och konfiguration. Genom att följa alla steg i den här artikeln och granska krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper (SQL Server) kan du förhindra många problem som du kan stöta på när du konfigurerar och underhåller tillgänglighetsgrupper i din miljö.

Ytterligare resurser

• Steg för steg: Skapa en SQL Server 2012 AlwaysOn-tillgänglighetsgrupp
• AlwaysOn-arkitekturguider
• Extern länk: SQL Server AlwaysOn-tillgänglighetsgrupper

Om den här informationen inte är användbar kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Jag har problem med att konfigurera AlwaysOn-tillgänglighetsgrupper

Vanliga konfigurationsproblem är att AlwaysOn-tillgänglighetsgrupper är inaktiverade, konton är felaktigt konfigurerade, databasspeglingsslutpunkten inte finns, slutpunkten är otillgänglig (SQL Server-fel 1418), nätverksåtkomsten finns inte och ett kopplingsdatabaskommando misslyckas (SQL Server-fel 35250). Läs följande dokument om du vill ha hjälp med att felsöka dessa problem:

Felsöka konfiguration av AlwaysOn-tillgänglighetsgrupper (SQL Server)

Ytterligare länk: Åtgärda: Fel 41009 när du försöker skapa flera tillgänglighetsgrupper

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Jag har problem med lyssnarkonfiguration (19471, 19476 och andra fel)

Ett av de vanligaste konfigurationsproblemen som kunder stöter på är skapande av tillgänglighetsgrupplyssnare. Felen liknar följande:

• Msg 19471, Level 16, State 0, Line 2The WSFC cluster could not bring the Network Name resource with DNS name '' online. DNS-namnet kan ha tagits eller har en konflikt med befintliga namntjänster, eller så kanske WSFC-klustertjänsten inte körs eller så kan det vara otillgängligt. Använd ett annat DNS-namn för att lösa namnkonflikter eller kontrollera WSFC-klusterloggen för mer information.

• Msg 19476, Level 16, State 4, Line 2Försöket att skapa nätverksnamnet och IP-adressen för lyssnaren misslyckades. WSFC-tjänsten kanske inte körs eller kan vara otillgänglig i sitt aktuella tillstånd, eller så kan värdena för nätverksnamnet och IP-adressen vara felaktiga. Kontrollera tillståndet för WSFC-klustret och verifiera nätverksnamnet och IP-adressen med nätverksadministratören.

Merparten av tiden beror skapandefelet på lyssnaren som resulterade i tidigare meddelanden på grund av bristande behörigheter för klusternamnsobjektet (CNO) i Active Directory för att skapa och läsa lyssnardatorobjektet. Om du vill felsöka det här problemet kan du läsa följande artiklar:

• Det går inte att skapa lyssnaren med meddelandet "Det gick inte att koppla nätverksnamnresursen till WSFC-klustret"

• Felsöka skapande av AlwaysOn-tillgänglighetsgruppslyssnare i SQL Server 2012

• Konfigurera en lyssnare för en AlwaysOn-tillgänglighetsgrupp

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Automatisk redundans fungerar inte som förväntat

Om du märker att den automatiska redundansväxlingen inte fungerar som förväntat under testning eller i produktion kan du läsa: Felsöka automatiska redundansproblem i SQL Server 2012 AlwaysOn-miljöer.

Felaktig konfiguration av Maximalt antal fel under den angivna perioden är en av de främsta orsakerna till att primärt inte automatiskt redväxlar över till den sekundära. Standardvärdet för den här inställningen är N-1, där N är antalet repliker. Mer information finns i Gränsen för maximala fel i redundanskluster (grupp).

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Jag har problem med att ansluta till AlwaysOn-tillgänglighetsgrupper

När du har konfigurerat tillgänglighetsgruppens lyssnare för en AlwaysOn-tillgänglighetsgrupp i SQL Server 2012 kanske du inte kan pinga lyssnaren eller ansluta till den från ett program. Du kan få ett fel som liknar följande:

Sqlcmd: Fel: Microsoft SQL Native Client : Tidsgränsen för inloggning har upphört att gälla.

Om du vill felsöka detta och liknande fel läser du följande:

• Timeout-fel och du kan inte ansluta till en SQL Server 2012 AlwaysOn-tillgänglighetsgrupplyssnare i en miljö med flera undernät
• Tidsgränser för anslutning i en tillgänglighetsgrupp med flera undernät

Mer informationslänkar:

• En uppdatering introducerar stöd för AlwaysOn-funktionerna i SQL Server 2012 eller en senare version till the.NET Framework 3.5 SP1
• SQL Server Multi-Subnet Clustering (SQL Server)

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Jag har problem med att konfigurera AlwaysOn-tillgänglighetsgrupper i min virtuella Azure-dator (IaaS)

1. Många problem som rör Always On uppstår på grund av felaktig konfiguration av lyssnaren. Om du har anslutningsproblem med lyssnaren

   1. Se till att du läser alla begränsningar för ILB-lyssnaren och följer alla steg som beskrivs i följande artikel med särskild uppmärksamhet på beroendekonfiguration, IP-adress och olika andra parametrar i PowerShell-skriptet.

   2. Om du är osäker kanske du vill ta bort och återskapa lyssnaren enligt ovanstående dokument.

2. Om du nyligen har flyttat den virtuella datorn till en annan tjänst eller om IP-adresserna har ändrats måste du uppdatera värdet för IP-adressresursen för att återspegla den nya adressen och du måste återskapa den lastbalanserade slutpunkten för tillgänglighetsgruppen. Du kan uppdatera IP-adressen med hjälp av Get kommandona eller Set enligt följande:

   Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
   

Rekommenderade dokument:

• Konfigurera en lastbalanserare för en SQL Server AlwaysOn-tillgänglighetsgrupp i Azure Virtual Machines

• Rekommendationer och metodtips vid distribution av SQL Server AlwaysOn-tillgänglighetsgrupper i Microsoft Azure (IaaS)

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Det tar lång tid att redundansväxlar från primär till sekundär eller vice versa

Efter en automatisk redundansväxling eller en planerad manuell redundansväxling utan dataförlust i en tillgänglighetsgrupp kan det hända att redundanstiden överskrider ditt mål för återställningstid (RTO). Information om hur du felsöker orsaker och potentiella lösningar finns i Felsöka: Tillgänglighetsgruppen har överskridit RTO.

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Ändringar på den primära repliken återspeglas antingen inte i eller är långsamma att replikera till den sekundära repliken

Du kanske märker att ändringar på den primära repliken inte sprids till sekundärt i tid. Prova följande för att felsöka och lösa dessa problem:

• Information om SQL Server 2012- och SQL Server 2014-miljöer finns i ÅTGÄRDA: Långsam synkronisering när diskar har olika sektorstorlekar för primära och sekundära replikloggfiler i SQL Server AG- och Logshipping-miljöer.

• Kontrollera om de sekundära noderna är i pausat tillstånd i klusteradministratören.

• Se Felsök: Ändringar på den primära repliken återspeglas inte på den sekundära repliken.

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Så här hanterar du storleken på transaktionsloggen för mina tillgänglighetsgruppsdatabaser

Du kan minska storleken på transaktionsloggen genom att konfigurera regelbundna säkerhetskopior på antingen primära eller sekundära servrar.

Mer information finns i följande avsnitt:

• Avlasta säkerhetskopieringar som stöds till sekundära repliker i en tillgänglighetsgrupp
• Utföra säkerhetskopieringar av transaktionsloggar med skrivskyddade sekundära repliker i AlwaysOn-tillgänglighetsgruppen – del 1

Om den här informationen inte är användbar kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Primära eller sekundära servrar slås i matchningstillstånd eller så uppstår oväntade redundansväxlingar

• Kontrollera system- och programhändelseloggarna för maskinvaruproblem och andra fel och kontakta leverantören för att åtgärda dem.

• Om du använder virtuella datorer kontrollerar du deras kunskapsbas för att se om det finns några nyligen rapporterade problem som kan bidra till problemet. Stora paketförluster på gästoperativsystemnivå på VMXNET3 vNIC i ESXi (2039495) har till exempel orsakat problem med tillgänglighetsgruppens konfiguration i vissa fall.

• Mer information:

  • Diagnostisera oväntad redundans eller tillgänglighetsgrupp i matchningstillstånd
  • Extern länk: SQL SERVER – Always On-tillgänglighetsgruppen har fastnat i matchningstillståndet under lång tid

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Det går inte att ansluta resurser

Kontrollera om det tar lång tid att återställa databaserna genom att granska meddelandena i SQL ErrorLog.

Om problemet kvarstår kan du läsa Mer information om AlwaysOn-tillgänglighetsgrupper.

Vanliga frågor och svar

1. Går det att ha två lyssnare för en tillgänglighetsgrupp?

   Ja, du kan konfigurera flera lyssnare för samma tillgänglighetsgrupp. Se Skapa flera lyssnare för samma tillgänglighetsgrupp (Goden Yao).

2. Är det möjligt att ha ett separat NIC-kort för alltid vid trafik och klientanslutning?

   Ja, du kan ha ett dedikerat nätverkskort för AlwaysOn-trafik. Se Konfigurera tillgänglighetsgrupp för att kommunicera i ett dedikerat nätverk.

3. Vilka utgåvor stöder AlwaysOn-redundansklusterinstanser?

   Det här avsnittet i SQL Server Books Online innehåller mer information: Utgåvor och funktioner som stöds för SQL Server 2016.

4. Hur återställs du om det uppstår ett fel på alla noder i klustret?

   Se WSFC-haveriberedskap via forcerat kvorum (SQL Server).

5. Var hittar jag information om stöd för distribuerade transaktioner i tillgänglighetsgruppens konfigurationer?

   Se Transaktioner – tillgänglighetsgrupper och databasspegling.

6. Hur uppdaterar jag AlwaysOn-konfigurationer?

   Se Uppgradera AlwaysOn-tillgänglighetsgruppreplikinstanser.

7. Hur lägger du till en TDE-aktiverad databas (transparent datakryptering) i tillgänglighetsgruppens konfiguration?

   Information om hur du lägger till TDE-aktiverad databas i tillgänglighetsgruppen finns i Konfigurera AlwaysOn för en TDE-databas.

8. Hur konfigurerar du aviseringar för att kontrollera om den sekundära släpar efter den primära?

   Du kan använda följande skript:

   SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
   dr_state.database_id AS database_id,
   is_ag_replica_local = CASE
       WHEN ar_state.is_local = 1 THEN N'LOCAL'
       ELSE 'REMOTE'
       END,
   ag_replica_role = CASE
       WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
       ELSE ar_state.role_desc
       END,
   dr_state.last_hardened_lsn, dr_state.last_hardened_time,
   datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
   FROM (( sys.availability_groups AS ag
   JOIN sys.availability_replicas AS ar
       ON ag.group_id = ar.group_id)
   JOIN sys.dm_hadr_availability_replica_states AS ar_state
       ON ar.replica_id = ar_state.replica_id)
   JOIN sys.dm_hadr_database_replica_states dr_state
       ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
   

9. Hur aviseras du om databasens tillstånd är annat än synkroniserat?

   Du kan använda följande skript:

   SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
   dr_state.database_id AS database_id,
   is_ag_replica_local = CASE
       WHEN ar_state.is_local = 1 THEN N'LOCAL'
       ELSE 'REMOTE'
       END,
   ag_replica_role = CASE
       WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
       ELSE ar_state.role_desc
       END,
   ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
   FROM (( sys.availability_groups AS ag
   JOIN sys.availability_replicas AS ar
       ON ag.group_id = ar.group_id )
   JOIN sys.dm_hadr_availability_replica_states AS ar_state
       ON ar.replica_id = ar_state.replica_id)
   JOIN sys.dm_hadr_database_replica_states dr_state
       ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
   

   Du kan också granska följande länkar för ytterligare metoder för att övervaka AlwaysOn-grupper:

   • Principbaserad hantering för driftsproblem med AlwaysOn-tillgänglighetsgrupper

   • Extern länk: Använda principbaserad hantering för SQL Server-tillgänglighetsgrupper Dataförlustaviseringar

   • Beteende för dynamiskt vittne på Windows Server 2012 R2-redundanskluster

Mer information om AlwaysOn-tillgänglighetsgrupper

• Felsöknings- och övervakningsguide för AlwaysOn-tillgänglighetsgrupper
• AlwaysOn-tillgänglighetsgrupper: en lösning med hög tillgänglighet och haveriberedskap