Krav, begränsningar och rekommendationer för databasspegling

gäller för:SQL Server

Det här avsnittet beskriver förutsättningarna och rekommendationerna för att konfigurera databasspegling. En introduktion till databasspegling finns i Database Mirroring (SQL Server).

Stöd för databasspegling

En lista över funktioner som stöds av versionerna av SQL Server i Windows finns i:

• Utgåvor och funktioner som stöds i förhandsversionen av SQL Server 2025
• Utgåvor och funktioner som stöds i SQL Server 2022
• Utgåvor och funktioner som stöds i SQL Server 2019
• Utgåvor och funktioner som stöds i SQL Server 2017
• Utgåvor och funktioner som stöds i SQL Server 2016

Observera att databasspegling fungerar med alla databaskompatibilitetsnivåer som stöds. Information om vilka kompatibilitetsnivåer som stöds finns i ALTER DATABASE Compatibility Level (Transact-SQL).

Förutsättningar

• För att en speglingssession ska kunna upprättas måste partnerna och vittnet, om några, köras på samma version av SQL Server.

• De två partnerna, som är huvudservern och speglingsservern, måste köra samma version av SQL Server. Vittnet, om sådant finns, kan köras på valfri utgåva av SQL Server som stöder databasspegling.

  Anmärkning

  Du kan uppgradera serverinstanser som är partner i en speglingssession till en nyare version av SQL Server. Mer information finns i Uppgradera speglade instanser.

• Databasen måste använda den fullständiga återställningsmodellen. De enkla och massloggade återställningsmodellerna stöder inte databasspegling. Därför loggas bulkoperationer alltid helt för en speglad databas. Information om återställningsmodeller finns i Recovery Models (SQL Server).

• Kontrollera att speglingsservern har tillräckligt med diskutrymme för speglingsdatabasen.

  Anmärkning

  Information om hur du använder databasspegling i en replikerad databas finns i Databasspegling och replikering (SQL Server).

• När du skapar speglingsdatabasen på speglingsservern kontrollerar du att du återställer säkerhetskopian av huvuddatabasen och anger samma databasnamn MED NORECOVERY. Dessutom måste alla loggsäkerhetskopior som skapades efter den säkerhetskopieringen också tillämpas igen med NORECOVERY.

  Viktigt!

  Om databasspegling har stoppats måste eventuella efterföljande loggsäkerhetskopior som görs på huvuddatabasen tillämpas på speglingsdatabasen innan du kan starta om den.

Begränsningar

• Endast användardatabaser kan speglas. Du kan inte spegla huvuddatabaserna, msdb-, tempdb- eller modelldatabaserna .

• Det går inte att byta namn på en speglad databas under en databasspeglingssession.

• Databasspegling stöder inte FILESTREAM. Det går inte att skapa en FILESTREAM-filgrupp på huvudservern. Databasspegling kan inte konfigureras för en databas som innehåller FILESTREAM-filgrupper.

• Databasspegling stöds inte med antingen transaktioner mellan databaser eller distribuerade transaktioner. För mer information, se Transaktioner mellan databaser och distribuerade transaktioner för Always On-tillgänglighetsgrupper och databasspegling (SQL Server).

Rekommendationer för att konfigurera partnerservrar

• Partnerna bör använda jämförbara system som kan hantera identiska arbetsbelastningar.

  Anmärkning

  Om du planerar att använda högsäkerhetsläge med automatisk redundansväxling bör den normala belastningen på varje redundanspartner vara mindre än 50 procent av processorn. Om din arbetsbelastning överbelastar processorn kanske en redundanspartner inte kan pinga de andra serverinstanserna i speglingssessionen. Detta orsakar en onödig redundansväxling. Om du inte kan hålla cpu-användningen under 50 procent rekommenderar vi att du använder antingen högsäkerhetsläge utan automatisk redundans eller högprestandaläge.

• Om möjligt bör sökvägen (inklusive enhetsbeteckningen) för speglingsdatabasen vara densamma som sökvägen för huvuddatabasen. Du måste inkludera alternativet FLYTTA i RESTORE-instruktionen om fillayouterna måste skilja sig åt. Om huvuddatabasen till exempel finns på enheten "F:" men speglingssystemet saknar en F:-enhet.

  Viktigt!

  Om du flyttar databasfilerna när du skapar speglingsdatabasen kanske du inte kan lägga till filer i databasen senare utan att speglingen pausas.

• Alla serverinstanser i en speglingssession bör använda samma huvudkodsida och sortering. Skillnader kan orsaka problem under speglingskonfigurationen.

• Valfritt: uppskatta tiden för att vid behov gå över till en annan databas för att säkerställa att systemkonfigurationen ger den prestanda du behöver. Mer information finns i Beräkna avbrott i tjänsten under rollväxling (databasspegling).

• För bästa prestanda använder du ett dedikerat nätverkskort (nätverksgränssnittskort) för spegling.

• Vi gör inga rekommendationer om huruvida ett wan-nätverk (wide-area network) är tillräckligt tillförlitligt för databasspegling i högsäkerhetsläge. Om du bestämmer dig för att använda högsäkerhetsläge via ett WAN bör du vara försiktig med hur du lägger till ett vittne i sessionen, eftersom oönskade automatiska redundansväxlingar kan inträffa. Mer information finns i Rekommendationer för att distribuera databasspegling senare i det här avsnittet.

Rekommendationer för implementering av databasspegling

Optimala prestanda för databasspegling erhålls med hjälp av asynkron åtgärd. En speglingssession som använder synkron åtgärd kan få långsammare prestanda när dess arbetsbelastning genererar stora mängder transaktionsloggdata.

I testmiljöer är det lämpligt att utforska alla driftlägen för att utvärdera hur databasspegling fungerar. Innan du distribuerar spegling till en produktionsmiljö måste du dock se till att du förstår hur nätverket fungerar i verkligheten.

Högsäkerhetsläge med automatisk redundans är utformat för ett högtjänstnätverk som antingen har en dedikerad anslutning eller en ganska enkel nätverkskonfiguration som minimerar källorna till eventuella nätverksfel. En sådan högkvalitativ nätverksmiljö är nödvändig för högsäkerhetsläge med automatisk redundans och rekommenderas för alla databasspeglingssessioner. Högprestandaläge och högsäkerhetsläge utan automatisk redundans påverkas dock mycket mindre av nätverkets tillförlitlighet.

Därför rekommenderar vi att du följer följande distributionsriktlinjer för produktionsmiljöer:

1. Börja köra i asynkront läge med höga prestanda. Det här läget är minst känsligt för nätverksmiljön och ger den bästa konfigurationen för att utforska hur spegling fungerar. Vi rekommenderar att du kör systemet asynkront tills du är säker på att bandbredden stöder spegling och att du har utvecklat en förståelse för speglingskonfiguration och prestanda för asynkront läge i din miljö. För mer information, se Driftlägen för databasspegling.

   Viktigt!

   Under testningen rekommenderar vi att du övervakar dina sessioner för nätverksfel som gör att databasspegling misslyckas. Mer information om potentiella felkällor finns i Möjliga fel under databasspegling. Information om hur du övervakar databasspegling finns i Övervaka databasspegling (SQL Server).

2. När du är säker på att asynkron åtgärd uppfyller affärsbehoven kanske du vill prova synkron åtgärd för att förbättra dataskyddet. När du testar hur synkron spegling fungerar i din miljö rekommenderar vi att du först testar högsäkerhetsläget utan automatisk redundans. Det primära syftet med den här testningen är att se hur synkron åtgärd påverkar databasens prestanda. För mer information, se Driftlägen för databasspegling.

3. Vänta med att aktivera automatisk redundans tills du är säker på att högsäkerhetsläget utan automatisk redundans uppfyller företagets behov och att nätverksfel inte orsakar fel. För mer information, se Rollväxling under en databasspeglingssession (SQL Server).

Se även

Att konfigurera Databasspegling (SQL Server)
Transportsäkerhet för databasspegling och Always On-tillgänglighetsgrupper (SQL Server)
Databasspegling (SQL Server)
Felsök konfigurationen för databasspegling (SQL Server)