Dela via


Felsök AlwaysOn-tillgänglighetsdatabaser i tillståndet Återställning väntar eller Misstänkt i SQL Server

Den här artikeln beskriver felen och begränsningarna för en tillgänglighetsdatabas i Microsoft SQL Server som är i ett Recovery Pending eller-tillstånd Suspect och hur du återställer databasen till fullständig funktionalitet i en tillgänglighetsgrupp.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 2857849

Sammanfattning

Anta att en tillgänglighetsdatabas som definieras i en AlwaysOn-tillgänglighetsgrupp övergår till ett Recovery Pending eller Suspect tillstånd i SQL Server. Om detta inträffar på tillgänglighetsgruppens primära replik påverkas databastillgängligheten. I det här fallet kan du inte komma åt databasen via klientprogrammen. Dessutom kan du inte släppa eller ta bort databasen från tillgänglighetsgruppen.

Anta till exempel att SQL Server körs och att en tillgänglighetsdatabas är inställd på Recovery Pending tillståndet eller Suspect . När du kör frågor mot dynamiska hanteringsvyer (DMV:er) på den primära repliken med hjälp av följande SQL-skript, kan databasen rapporteras i ett NOT_HEALTHY och-tillstånd RECOVERY_PENDING eller i ett SUSPECT tillstånd enligt följande:

SELECT
    dc.database_name,
    d.synchronization_health_desc,
    d.synchronization_state_desc,
    d.database_state_desc
FROM
    sys.dm_hadr_database_replica_states d
    JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id
    AND d.is_local = 1
database_name          synchronization_health_desc     synchronization_state_desc   database_state_desc
-------------------- ------------------------------ ------------------------------ ---------------------
<DatabaseName>                         NOT_HEALTHY              NOT SYNCHRONIZING      RECOVERY_PENDING
(1 row(s) affected)

Skärmbild av körningsresultatet för skript för att kontrollera databasens hälsotillstånd och synkroniseringstillstånd.

Dessutom kan den här databasen rapporteras vara i tillståndet Inte synkronisering/Återställning väntar eller Misstänkt i SQL Server Management Studio.

Skärmbild av databasen som inte synkroniseras/återställning väntar på tillstånd.

När databasen definieras i en tillgänglighetsgrupp kan databasen inte tas bort eller återställas. Därför måste du vidta specifika åtgärder för att återställa databasen och returnera den till produktionsanvändning.

Mer information

I följande innehåll beskrivs fel och begränsningar för en tillgänglighetsdatabas som är i ett väntande återställningstillstånd i olika situationer.

  • Databasstatus förhindrar återställning av databas

    Du försöker köra följande SQL-skript för att återställa databasen som har parametern RECOVERY :

    RESTORE DATABASE <DatabaseName> WITH RECOVERY
    

    När du kör det här skriptet får du följande felmeddelande eftersom databasen har definierats i en tillgänglighetsgrupp:

    Msg 3104, nivå 16, delstat 1, rad 1
    RESTORE kan inte köras på databasen <DatabaseName> eftersom det är konfigurerat för databasspegling eller har anslutit till en tillgänglighetsgrupp. Om du tänker återställa databasen använder du ALTER DATABASE för att ta bort spegling eller för att ta bort databasen från dess tillgänglighetsgrupp.

    Msg 3013, nivå 16, delstat 1, rad 1
    RESTORE DATABASE avslutas onormalt.

  • Databasstatus förhindrar att databasen släpps

    Du försöker köra följande SQL-skript för att släppa databasen:

    DROP DATABASE <DatabaseName>
    

    När du kör det här skriptet får du följande felmeddelande eftersom databasen har definierats i en tillgänglighetsgrupp:

    Msg 3752, nivå 16, delstat 1, rad 1
    Databasen <DatabaseName> är för närvarande ansluten till en tillgänglighetsgrupp. Innan du kan ta bort databasen måste du ta bort den från tillgänglighetsgruppen.

  • Databasstatus förhindrar att databasen tas bort från tillgänglighetsgruppen

    Du försöker köra följande SQL-skript för att ta bort databasen från tillgänglighetsgruppen:

    ALTER DATABASE <DatabaseName> SET hadr OFF
    

    När du försöker köra det här skriptet får du följande felmeddelande eftersom tillgänglighetsdatabasen tillhör den primära repliken:

    Msg 35240, nivå 16, delstat 14, rad 1
    Database <DatabaseName> kan inte kopplas till eller kopplas från tillgänglighetsgruppen <AvailabilityGroupName>. Den här åtgärden stöds inte på den primära repliken av tillgänglighetsgruppen.

    På grund av det här felmeddelandet kan du bli tvungen att redundansväxla databasen. När databasen är redigerad finns repliken som äger den väntande återställningsdatabasen i den sekundära rollen. I det här fallet försöker du köra följande SQL-skript igen för att ta bort databasen från tillgänglighetsgruppen på den sekundära repliken:

    ALTER DATABASE <DatabaseName> SET hadr OFF
    

    Du kan dock fortfarande inte ta bort databasen från tillgänglighetsgruppen och du får följande felmeddelande eftersom databasen fortfarande är i tillståndet Återställning väntar:

    Msg 921, nivå 16, delstat 112, rad 1
    Database <DatabaseName> har inte återställts ännu. Vänta och försök igen.

Lösning när databasen är i den sekundära rollen

Lös problemet genom att vidta följande allmänna åtgärder:

  • Ta bort repliken som är värd för den skadade databasen från tillgänglighetsgruppen när databasen är i den sekundära rollen.
  • Lös eventuella problem som påverkar systemet och som kan ha bidragit till databasfelet.
  • Återställ repliken till tillgänglighetsgruppen.

Om du vill utföra dessa åtgärder ansluter du till den nya primära repliken och kör ALTER AVAILABILITY GROUP sedan SQL-skriptet för att ta bort repliken som är värd för den misslyckade tillgänglighetsdatabasen. Följ stegen nedan.

De här stegen förutsätter att den primära repliken först är värd för den skadade databasen. Därför måste en redundansväxling först ske för att överföra repliken som är värd för den skadade databasen till en sekundär roll.

  1. Anslut till servern som kör SQL Server och som är värd för den sekundära repliken.

  2. Kör följande SQL-skript:

    ALTER AVAILABILITY GROUP <AvailabilityGroupName> FAILOVER
    
  3. Kör följande SQL-skript för att ta bort repliken som är värd för den skadade databasen från tillgänglighetsgruppen:

    ALTER AVAILABILITY GROUP <AvailabilityGroupName> REMOVE REPLICA ON '<SQLServerNodeName>'
    
  4. Lös eventuella problem på servern som kör SQL Server och som kan bidra till databasfelet.

  5. Lägg till repliken i tillgänglighetsgruppen igen.

Lösning när den primära repliken är den enda repliken i tillgänglighetsgruppen

Om den primära repliken är värd för den skadade databasen och är den enda fungerande repliken i tillgänglighetsgruppen måste tillgänglighetsgruppen tas bort. När tillgänglighetsgruppen har tagits bort kan databasen återställas från en säkerhetskopia, eller så kan andra återställningsåtgärder användas för att återställa databaserna och återuppta produktionen.

Om du vill ta bort tillgänglighetsgruppen använder du följande SQL-skript:

DROP AVAILABILITY GROUP <AvailabilityGroupName>

Nu kan du försöka återställa den problematiska databasen. Eller så kan du återställa databasen från den senast kända säkerhetskopian.

Lösning när du släpper tillgänglighetsgruppen

När du släpper en tillgänglighetsgrupp tas lyssnarresursen också bort och programanslutningen till tillgänglighetsdatabaserna avbryts.

För att minimera programavbrott använder du någon av följande metoder för att upprätthålla programanslutningen via lyssnaren och släppa tillgänglighetsgruppen:

Metod 1: Associera lyssnaren med en ny tillgänglighetsgrupp (roll) i Klusterhanteraren för växling vid fel

Med den här metoden kan du underhålla lyssnaren när du släpper och återskapar tillgänglighetsgruppen.

  1. På den instans av SQL Server som den befintliga tillgänglighetsgruppens lyssnare dirigerar anslutningar till skapar du en ny, tom tillgänglighetsgrupp. För att förenkla den här processen använder du transact-SQL-kommandot för att skapa en tillgänglighetsgrupp som inte har någon sekundär replik eller databas:

    USE master
    GO
    CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
        ENDPOINT_URL = 'tcp://sqlnode1:5022',
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        FAILOVER_MODE = MANUAL
    )
    
  2. Starta Klusterhanteraren för växling vid fel och välj sedan Roller i den vänstra rutan. I fönstret som visar rollerna väljer du den ursprungliga tillgänglighetsgruppen.

  3. Högerklicka på resursen för tillgänglighetsgruppen i fönstret längst ned i mitten under fliken Resurser och välj sedan Egenskaper. Välj fliken Beroenden , ta bort beroendet till lyssnaren och välj sedan OK.

    Skärmbild av fliken Beroenden för tillgänglighetsgruppegenskaper.

  4. Under resurserna högerklickar du på lyssnaren, väljer Fler åtgärder och väljer sedan Tilldela till en annan roll.

  5. I dialogrutan Tilldela källa till roll väljer du den nya tillgänglighetsgruppen och väljer sedan OK.

    Skärmbild av dialogrutan Tilldela källa till roll med den nya tillgänglighetsgruppen tillagd.

  6. I fönstret Roller väljer du den nya tillgänglighetsgruppen. I fönstret längst ned i mitten, under fliken Resurser , bör du nu se den nya tillgänglighetsgruppen och lyssnarresursen. Högerklicka på den nya resursen för tillgänglighetsgruppen och välj sedan Egenskaper.

  7. Klicka på fliken Beroenden, välj lyssnarresursen i listrutan och välj sedan OK.

    Skärmbild av fliken Beroenden för nya tillgänglighetsgruppegenskaper.

  8. I SQL Server Management Studio använder du Object Explorer för att ansluta till instansen av SQL Server som är värd för den primära repliken av den nya tillgänglighetsgruppen. Välj Always On High Availability (Alltid på hög tillgänglighet), klicka på den nya tillgänglighetsgruppen och välj sedan Lyssnare för tillgänglighetsgrupp. Du borde hitta lyssnaren.

  9. Högerklicka på lyssnaren, välj Egenskaper, ange lämpligt portnummer för lyssnaren och välj sedan OK.

    Skärmbild av egenskaper för lyssnare för tillgänglighetsgrupper som visar konfigurationen av lyssnaren.

Detta säkerställer att program som använder lyssnaren fortfarande kan använda den för att ansluta till instansen av SQL Server som är värd för produktionsdatabaserna utan avbrott. Den ursprungliga tillgänglighetsgruppen kan nu tas bort helt och återskapas. Eller så kan databaser och repliker läggas till i den nya tillgänglighetsgruppen.

Om du återskapar den ursprungliga tillgänglighetsgruppen bör du omtilldela lyssnaren till tillgänglighetsgrupprollen, konfigurera beroendet mellan den nya tillgänglighetsgruppens resurs och lyssnaren och sedan tilldela om porten till lyssnaren. För att göra detta följer du stegen nedan:

  1. Starta Klusterhanteraren för växling vid fel och välj sedan Roller i den vänstra rutan. I fönstret som visar rollerna klickar du på den nya tillgänglighetsgrupp som är värd för lyssnaren.
  2. I det nedre mittenfönstret under fliken Resurser högerklickar du på lyssnaren, väljer Fler åtgärder och väljer sedan Tilldela till en annan roll. I dialogrutan väljer du den återskapade tillgänglighetsgruppen och väljer sedan OK.
  3. I fönstret Roller klickar du på den återskapade tillgänglighetsgruppen. I det nedre mittenfönstret, under fliken Resurser , bör du nu se den återskapade tillgänglighetsgruppen och lyssnarresursen. Högerklicka på resursen för den återskapade tillgänglighetsgruppen och välj sedan Egenskaper.
  4. Välj fliken Beroenden , välj lyssnarresursen i listrutan och välj sedan OK.
  5. I SQL Server Management Studio använder du Object Explorer för att ansluta till instansen av SQL Server som är värd för den primära repliken av den återskapade tillgänglighetsgruppen. Välj Always On High Availability (Alltid på hög tillgänglighet), klicka på den nya tillgänglighetsgruppen och välj sedan Lyssnare för tillgänglighetsgrupp. Du borde hitta lyssnaren.
  6. Högerklicka på lyssnaren, välj Egenskaper, ange lämpligt portnummer för lyssnaren och välj sedan OK.

Metod 2: Associera lyssnaren med en befintlig SQL Server-redundansklusterinstans (SQLFCI)

Om du är värd för din tillgänglighetsgrupp på en SQL Server-redundansklusterinstans (SQLFCI) kan du associera den lyssnarklustrade resursen med den SQLFCI-klustrade resursgruppen medan du släpper och sedan återskapar tillgänglighetsgruppen.

  1. Starta Klusterhanteraren för växling vid fel och välj sedan Roller i den vänstra rutan.

  2. I fönstret som visar rollerna väljer du den ursprungliga tillgänglighetsgruppen.

  3. Högerklicka på resursen för tillgänglighetsgruppen i det nedre mittenfönstret under fliken Resurser och välj sedan Egenskaper.

  4. Välj fliken Beroenden , ta bort beroendet till lyssnaren och välj sedan OK.

  5. I det nedre mittenfönstret under fliken Resurser högerklickar du på lyssnaren, väljer Fler åtgärder och väljer sedan Tilldela till en annan roll.

  6. I dialogrutan Tilldela resurs till roll klickar du på SQL Server FCI-instansen och väljer sedan OK.

    Skärmbild av dialogrutan Tilldela resurs till roll.

  7. I fönstret Roller väljer du gruppen SQLFCI. I det nedre mittenfönstret, under fliken Resurser , bör du nu se den nya lyssnarresursen.

Detta säkerställer att program som använder lyssnaren fortfarande kan använda den för att ansluta till instansen av SQL Server som är värd för produktionsdatabaserna utan avbrott. Den ursprungliga tillgänglighetsgruppen kan nu tas bort och återskapas. Eller så kan databaser och repliker läggas till i den nya tillgänglighetsgruppen.

När tillgänglighetsgruppen har skapats på nytt, omtilldela lyssnaren tillbaka till tillgänglighetsgruppens roll. Konfigurera sedan beroendet mellan den nya resursen för tillgänglighetsgruppen och lyssnaren och tilldela om porten till lyssnaren:

  1. Starta Klusterhanteraren för växling vid fel och välj sedan Roller i den vänstra rutan.
  2. I fönstret som visar rollerna klickar du på den ursprungliga SQLFCI-rollen.
  3. I det nedre mittenfönstret, under fliken Resurser , högerklickar du på lyssnaren, väljer Fler åtgärder och väljer sedan Tilldela till en annan roll.
  4. I dialogrutan klickar du på den återskapade tillgänglighetsgruppen och väljer sedan OK.
  5. I fönstret Roller väljer du den nya tillgänglighetsgruppen.
  6. Under fliken Resurser bör du se den nya tillgänglighetsgruppen och lyssnarresursen. Högerklicka på den nya resursen för tillgänglighetsgruppen och välj sedan Egenskaper.
  7. Välj fliken Beroenden , välj lyssnarresursen i listrutan och välj sedan OK.
  8. I SQL Server Management Studio använder du Object Explorer för att ansluta till instansen av SQL Server som är värd för den primära repliken av den nya tillgänglighetsgruppen.
  9. Välj Always On High Availability (Alltid på hög tillgänglighet), klicka på den nya tillgänglighetsgruppen och välj sedan Lyssnare för tillgänglighetsgrupp. Du borde hitta lyssnaren.
  10. Högerklicka på lyssnaren, välj Egenskaper, ange lämpligt portnummer för lyssnaren och välj sedan OK.

Metod 3: Släpp tillgänglighetsgruppen och återskapa sedan tillgänglighetsgruppen och lyssnaren med samma lyssnarnamn

Den här metoden resulterar i ett litet avbrott för program som för närvarande är anslutna eftersom tillgänglighetsgruppen och lyssnaren tas bort och sedan återskapas:

  1. Släpp tillgänglighetsgruppen.

    Kommentar

    Detta kommer också att släppa lyssnaren.

  2. Skapa omedelbart en ny, tom tillgänglighetsgrupp som innehåller lyssnardefinitionen på samma server som är värd för produktionsdatabaserna.

    Anta till exempel att din tillgänglighetsgruppslyssnare är aglisten. Följande Transact-SQL-instruktion skapar en tillgänglighetsgrupp utan primär eller sekundär databas, men den skapar också en lyssnare med namnet aglisten. Program kan använda den här lyssnaren för att ansluta.

    USE master
    GO
        CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
            ENDPOINT_URL = 'tcp://sqlnode1:5022',
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL
        ) LISTENER 'aglisten' (
            WITH IP ((N'11.0.0.25', N'255.0.0.0')),
            PORT = 1433
        )
    GO
    
  3. Återställ den skadade databasen. Lägg sedan till den och den sekundära repliken tillbaka till tillgänglighetsgruppen.