Möjliga fel vid databasspegling

Gäller för:SQL Server

Fysiska problem, operativsystem eller SQL Server kan orsaka ett fel i en databasspeglingssession. Databasspegling kontrollerar inte regelbundet de komponenter som Sqlservr.exe förlitar sig på för att kontrollera om de fungerar korrekt eller har misslyckats. Men för vissa typer av fel rapporterar den berörda komponenten ett fel för att Sqlservr.exe. Ett fel som rapporteras av en annan komponent kallas för ett hårt fel. Om du vill identifiera andra fel som annars skulle gå obemärkt förbi implementerar databasspegling sin egen timeout-mekanism. När en tidsgräns för spegling inträffar förutsätter databasspegling att ett fel har inträffat och deklarerar ett mjukt fel. Vissa fel som inträffar på SQL Server instansnivå leder dock inte till att speglingen överskrider tidsgränsen och kan gå oupptäckt.

Hastigheten för felidentifiering och därmed reaktionstiden för speglingssessionen till ett fel beror på om felet är hårt eller mjukt. Vissa hårda fel, till exempel nätverksfel, rapporteras omedelbart. I vissa fall kan dock komponentspecifika tidsgränser fördröja rapporteringen av vissa hårda fel. För mjuka fel avgör längden på tidsgränsen för spegling hastigheten för felidentifiering. Som standard är den här perioden 10 sekunder. Det här är det lägsta rekommenderade värdet.

Fel på grund av hårda fel

Möjliga orsaker till svåra fel är (men är inte begränsade till) följande villkor:

• En trasig anslutning eller kabel

• Ett felaktigt nätverkskort

• En routerändring

• Ändringar i brandväggen

• Omkonfiguration av slutpunkt

• Förlust av den enhet där transaktionsloggen finns

• Operativsystem- eller processfel

När loggenheten på huvuddatabasen till exempel inte svarar och misslyckas informerar operativsystemet Sqlservr.exe att ett allvarligt fel har uppstått.

Vissa komponenter, till exempel nätverkskomponenter och vissa I/O-undersystem, har sina egna tidsgränser för att fastställa fel. Sådana timeouter är oberoende av databasspegling, som inte har någon kunskap om dem och är helt omedvetna om deras beteende. I dessa fall ökar tidsgränsen tiden mellan ett fel och när databasspegling tar emot det resulterande svåra felet.

Om du vill hjälpa dig att tolka de feltillstånd som inträffar i nätverket kan du fråga nätverksteknikern vilka felmeddelanden som skickas till en port när följande händelser inträffar på en TCP-anslutning:

• DNS fungerar inte.

• Kablarna är urkopplade.

• Microsoft Windows har en brandvägg som blockerar en specifik port.

• Programmet som övervakar en port misslyckas.

• En Windows-baserad server har bytt namn.

• En Windows-baserad server startas om.

Fel på grund av mjuka fel

Villkor som kan orsaka speglingstimeouter omfattar (men är inte begränsade till) följande:

• Nätverksfel, till exempel tidsgränser för TCP-länkar, borttagna eller skadade paket eller paket som är i felaktig ordning.

• Ett operativsystem, en server eller en databas som inte svarar.

• Tidsgränsen för en Windows-server har överskridits.

• Otillräckliga databehandlingsresurser, till exempel överbelastning av processorer eller diskar, att transaktionsloggen fylls eller att systemet får slut på minne eller trådar. I dessa fall måste du öka tidsgränsen, minska arbetsbelastningen eller ändra maskinvaran för att hantera arbetsbelastningen.

Mekanismen för spegling Time-Out

Eftersom mjuka fel inte kan identifieras direkt av en serverinstans kan ett mjukt fel potentiellt leda till att en serverinstans väntar på obestämd tid. För att förhindra detta implementerar databasspegling sin egen timeout-mekanism, baserat på varje serverinstans i en speglingssession som skickar ut en ping på varje öppen anslutning med ett fast intervall.

För att en anslutning ska vara öppen måste en serverinstans få en ping på anslutningen under den definierade tidsgränsen, plus den tid som krävs för att skicka ytterligare en ping. Att ta emot en ping under tidsgränsen anger att anslutningen fortfarande är öppen och att serverinstanserna kommunicerar över den. När en serverinstans tar emot en ping återställs tidsgränsräknaren för anslutningen.

Om ingen ping tas emot på en anslutning under tidsgränsen anser en serverinstans att anslutningen har överskriden tidsgräns. Serverinstansen stänger tidsgränsanslutningen och hanterar timeout-händelsen enligt sessionens tillstånd och driftsläge.

Även om den andra servern faktiskt fortsätter korrekt anses en timeout vara ett fel. Om tidsgränsvärdet för en session är för kort för den regelbundna svarstiden hos någon av partnerna kan falska fel inträffa. Ett falskt fel inträffar när en serverinstans kontaktar en annan vars svarstid är så långsam att pingen inte tas emot innan tidsgränsen går ut.

I sessioner med hög prestanda är tidsgränsen alltid 10 sekunder. Detta räcker vanligtvis för att undvika falska fel. I högsäkerhetslägesessioner är standardtidsgränsen 10 sekunder, men du kan ändra varaktigheten. För att undvika falska fel rekommenderar vi att tidsgränsen för spegling alltid är 10 sekunder eller mer.

Ändra timeout-värdet (endast högsäkerhetsläge)

• Använd timeout-heltalssatsen><<ALTER DATABASE för databasen>SET PARTNER.

Så här visar du det aktuella timeout-värdet

• Fråga mirroring_connection_timeout i sys.database_mirroring.

Svara på ett fel

Oavsett typ av fel svarar en serverinstans som identifierar ett fel på lämpligt sätt baserat på instansens roll, sessionens driftsläge och tillståndet för alla andra anslutningar i sessionen. Information om vad som händer vid förlust av en partner finns i Driftlägen för databasspegling.

Se även

Beräkna avbrott i tjänsten under rollväxling (databasspegling)
Driftlägen för databasspegling
Övergång av roller under en databasspeglingssession (SQL Server)
Databasåterspegling (SQL Server)