Problemen met AlwaysOn beschikbaarheid van databases in een "nuttige toepassing in behandeling" of "verdachte" staat in SQL Server 2012

Samenvatting

Stel dat een database beschikbaar die is gedefinieerd in een groep AlwaysOn beschikbaarheid naar een "nuttige toepassing in behandeling" of "verdachte" staat in Microsoft SQL Server 2012 overgangen. Als dit op de primaire replica van de beschikbaarheidsgroep gebeurt, wordt de beschikbaarheid van de database beïnvloed. In deze situatie, u heeft geen toegang tot de database via de clienttoepassingen. Bovendien kan neerzetten of de database te verwijderen uit de beschikbaarheidsgroep.

Stel bijvoorbeeld dat Microsoft SQL Server wordt uitgevoerd en dat een database met beschikbaarheid wordt ingesteld op de status 'mogelijk beschadigd' of 'recovery in behandeling'. Wanneer u het beheer van dynamische weergaven (DMVs) op de primaire replica een query met behulp van de onderstaande SQL-script, kan de database worden gerapporteerd in een NOT_HEALTHY en RECOVERY_PENDING staat of in een VERDACHTE toestand als volgt:

select dc.database_name, d.synchronization_health_desc, d.synchronization_state_desc, d.database_state_descfrom sys.dm_hadr_database_replica_states d join sys.availability_databases_cluster dcon d.group_database_id=dc.group_database_id and d.is_local=1
database_name   synchronization_health_desc    synchronization_state_desc     database_state_desc-------------------- ------------------------------ ------------------------------ ---------------------
<
Database name> NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING(1 row(s) affected)



Deze database kan ook worden aangemerkt als de niet synchroniseren / herstel in behandeling of verdachte staat in Microsoft SQL Server Management Studio.



Wanneer de database is gedefinieerd in een groep van beschikbaarheid, kan de database worden verwijderd of hersteld. Daarom moet u bepaalde stappen terug aan het gebruik van de productie en de database herstellen. Dit artikel beschrijft de fouten en beperkingen van een database met beschikbaarheid in de 'recovery in behandeling' of 'verdacht' staat en het terugzetten van de database met volledige functionaliteit in een beschikbaarheidsgroep.

Meer informatie

De volgende inhoud worden de fouten en beperkingen van een database met beschikbaarheid met een status 'recovery in behandeling' in verschillende situaties.

U probeert uit te voeren de volgende SQL-script om de database met de parameter herstel herstellen:

restore database <Database name> with recovery

Als u dit script uitvoert, wordt het volgende foutbericht wordt weergegeven omdat de database is gedefinieerd in een beschikbaarheidsgroep:

Msg 3104, niveau-16 staat 1, regel 1
HERSTELLEN kan niet worden uitgevoerd op '< naam Database >' omdat het is geconfigureerd voor database-mirroring of is lid van een groep van beschikbaarheid. Als u de database opnieuw wilt, Gebruik ALTER DATABASE mirroring verwijderen of de database verwijderen uit de groep van de beschikbaarheid.

Msg 3013, niveau-16 staat 1, regel 1
RESTORE DATABASE wordt abnormaal beëindigd.



U probeert uit te voeren de volgende SQL-script om de database te verwijderen:

drop database <Database name>

Als u dit script uitvoert, wordt het volgende foutbericht wordt weergegeven omdat de database is gedefinieerd in een beschikbaarheidsgroep:

Msg-3752, niveau-16 staat 1, regel 1
'< Naam Database >' van de database is momenteel lid van een beschikbaarheidsgroep. Voordat u de database neerzetten kunt, moet u deze verwijderen uit de groep van de beschikbaarheid.



U probeert de database wilt verwijderen uit de beschikbaarheidsgroep van de volgende SQL-script uitvoeren:

alter database <Database name> set hadr off

Wanneer u dit script uitvoert, wordt het volgende foutbericht wordt weergegeven omdat de beschikbaarheid van database tot de primaire replica behoort:

Msg 35240, 16, 14, staat regel 1 niveau
' <Naam Database>' database niet kan worden toegevoegd aan of verwijderd uit de beschikbaarheidsgroep ' <groepsnaam beschikbaarheid>'. Deze bewerking wordt niet ondersteund op de primaire replica van de groep van de beschikbaarheid.


Vanwege dit foutbericht kan verplicht worden uitgevoerd op de database. Nadat de database is overgenomen, is de replica die eigenaar is van de database "recovery in behandeling" in de secundaire rol. U probeert het opnieuw uitvoeren van de volgende SQL-script om de database te verwijderen uit de beschikbaarheidsgroep op de secundaire replica in deze situatie:

alter database <Database name> set hadr off

Echter, u niet de database nog steeds verwijderen uit de beschikbaarheidsgroep en omdat de database nog steeds in een 'recovery in behandeling', wordt het volgende foutbericht weergegeven:

Msg 921, niveau 16 staat 112, regel 1
' <Naam Database>' database is nog niet is hersteld. Wacht even en probeer het opnieuw.


Oplossing

Gebruik de volgende methoden, afhankelijk van de situatie dit probleem op te lossen.


Dit probleem op te lossen neemt u de volgende algemene acties:

  • Verwijderen uit de beschikbaarheidsgroep van de replica met de beschadigde database als de database in de secundaire rol is.

  • De problemen oplossen die door het systeem van invloed zijn op en die mogelijk hebben bijgedragen aan het mislukken van de database.

  • De van beschikbaarheidsgroep herstellen de replica.

Verbinding maken met de nieuwe primaire replica om de volgende acties uitvoeren, en voer het script SQL 'Beschikbaarheid van groep wijzigen' als u wilt verwijderen van de replica die als host voor de database beschikbaar fungeert. Ga hiervoor als volgt te werk.

Opmerking  Deze stappen wordt ervan uitgegaan dat de primaire replica eerst fungeert als host voor de beschadigde database. Daarom moet eerst een failover plaatsvinden om een overgang van de replica die als host de beschadigde database in een ondergeschikte rol fungeert.

  1. Verbinding met de server waarop SQL Server wordt uitgevoerd en die fungeert als host voor de secundaire replica.

  2. De volgende SQL-script uitvoeren:

    alter availability group <Availability group name> failover
  3. Voer de volgende SQL-script om te verwijderen van de replica die als host voor de beschadigde database uit de beschikbaarheid fungeert:

    alter availability group <Availability group name> remove replica on '<SQL Server node name>'
  4. Los problemen op de server waarop SQL Server wordt uitgevoerd en die kan bijdragen tot het mislukken van de database.

  5. De replica toevoegen in de beschikbaarheidsgroep.


Als de primaire replica fungeert als host voor de beschadigde database en is de enige werkende replica in de groep van de beschikbaarheid, de van beschikbaarheidsgroep moet worden verwijderd. Nadat de beschikbaarheidsgroep wordt verbroken, kunt u de database herstellen vanaf een back-up of andere inspanningen met emergency recovery herstel de databases en hervatten van de productie kunnen worden toegepast.

De beschikbaarheidsgroep VN de volgende SQL-script verwijderen:

drop availability group <Availability group name>

Op dit punt kunt u proberen de beschadigde database herstellen. Of, of kunt u de database terugzetten vanaf de laatst bekende goede back-up.

Als u een beschikbaarheidsgroep neerzet, wordt de listener-resource ook worden neergezet en interrupts connectiviteit van toepassingen met de beschikbaarheid van databases.

Om de uitvaltijd van toepassing, gebruikt u een van de volgende methoden connectiviteit van toepassingen door middel van de listener handhaven en de van beschikbaarheidsgroep neerzetten:

Methode 1: De listener koppelen aan een nieuwe beschikbaarheidsgroep (rol) Failover Cluster ManagementMet deze methode kunt u de listener behouden neer te zetten en de van beschikbaarheidsgroep opnieuw te maken.

  1. Op het exemplaar van SQL Server waarop de bestaande groep listener voor beschikbaarheid van verbindingen is om een nieuwe, lege beschikbaarheidsgroep te maken. Gebruik de Transact-SQL-opdracht een beschikbaarheidsgroep geen secundaire replica of een database heeft maken voor het vereenvoudigen van dit proces:

    use mastergo
    create availability group ag for replica on 'sqlnode1' with
    (endpoint_url = 'tcp://sqlnode1:5022', availability_mode=asynchronous_commit, failover_mode=manual)
  2. Failover-clusterbeheer starten en klik vervolgens op functies in het linkerdeelvenster. Selecteer in het deelvenster met de rollen, de oorspronkelijke beschikbaarheidsgroep.

  3. Klik met de rechtermuisknop op de groep beschikbaarheid van resource in het deelvenster onder het midden onder het tabblad bronnen en klik vervolgens op Eigenschappen. Klik op het tabblad afhankelijkheden , de afhankelijkheid van de listener verwijderen en klik op OK.

  4. Onder de resources, klik met de rechtermuisknop de listener, klikt u op Meer actiesen klik op toewijzen aan een andere rol.

  5. De nieuwe beschikbaarheidsgroep selecteren in het dialoogvenster Bron toewijzen aan de rol en klik op OK.

  6. Selecteer de nieuwe beschikbaarheidsgroep in het venster rollen . In het deelvenster onder het midden onder het tabblad bronnen en ziet u nu de nieuwe groep voor de beschikbaarheid en de bron van de listener. Klik met de rechtermuisknop op de nieuwe beschikbaarheid groep resource en klik vervolgens op Eigenschappen.

  7. Klik op het tabblad afhankelijkheden , selecteer de listener resource in de vervolgkeuzelijst en klik op OK.

  8. Gebruik in Microsoft SQL Server Management Studio Object Explorer verbinding maken met het exemplaar van SQL Server die fungeert als host voor de primaire replica van de nieuwe groep van beschikbaarheid. Klik op Beschikbaarheid AlwaysOn, klikt u op de nieuwe groep van beschikbaarheid en klik op Beschikbaarheid groep luisteraars. U moet de listener.

  9. Klik met de rechtermuisknop op de listener en klik op Eigenschappen, het juiste poortnummer voor de listener.

Dit zorgt ervoor dat toepassingen die gebruikmaken van de listener nog steeds kunt verbinding maken met het exemplaar van SQL Server die als host voor de productiedatabases zonder onderbreking fungeert. De oorspronkelijke beschikbaarheidsgroep kan nu worden volledig verwijderd en opnieuw gemaakt. Of de databases en replica's kunnen worden toegevoegd aan de nieuwe beschikbaarheidsgroep.

Belangrijk Als u de oorspronkelijke beschikbaarheidsgroep opnieuw maakt, moet u de listener terug naar de groep beschikbaarheid rol toewijzen, de afhankelijkheid tussen de nieuwe groep resource voor beschikbaarheid en de listener instellen en vervolgens de listener-poort toewijzen. Ga hiervoor als volgt te werk:

  1. Failover-clusterbeheer starten en klik vervolgens op functies in het linkerdeelvenster. In het deelvenster worden de rollen vermeld, klikt u op de nieuwe groep van beschikbaarheid die fungeert als host voor de listener.

  2. In het onderste middelste deelvenster onder het tabblad bronnen , met de rechtermuisknop op de listener, klikt u op Meer actiesen klik op toewijzen aan een andere rol. Kies de beschikbaarheidsgroep opnieuw gemaakt in het dialoogvenster en klik op OK.

  3. Klik op de beschikbaarheidsgroep opnieuw gemaakt in het venster rollen . In het middelste deelvenster van onder het tabblad bronnen en ziet u nu de groep opnieuw gemaakt beschikbaarheid en de bron van de listener. Klik met de rechtermuisknop op de groep opnieuw gemaakt beschikbaarheid van resource en klik vervolgens op Eigenschappen.

  4. Klik op het tabblad afhankelijkheden , selecteer de listener resource in de vervolgkeuzelijst en klik op OK.

  5. Met Object Explorer verbinding maken met het exemplaar van SQL Server die fungeert als host voor de primaire replica van de groep opnieuw gemaakt beschikbaarheid in SQL Server Management Studio. Klik op Beschikbaarheid AlwaysOn, klikt u op de nieuwe groep van beschikbaarheid en klik op Beschikbaarheid groep luisteraars. U moet de listener.

  6. Klik met de rechtermuisknop op de listener, klikt u op Eigenschappen, typ het juiste poortnummer voor de listener en klik op OK.

Methode 2: De listener koppelen met een bestaande SQL Server Failover geclusterd exemplaar (SQLFCI)

Als u host uw beschikbaarheidsgroep op een SQL Server Failover geclusterd exemplaar (SQLFCI), kunt u de listener geclusterde bron koppelen aan de geclusterde bron SQLFCI groep tijdens het neerzetten en maakt de beschikbaarheidsgroep opnieuw.

  1. Failover-clusterbeheer starten en klik vervolgens op functies in het linkerdeelvenster.

  2. Selecteer in het deelvenster met de rollen, de oorspronkelijke beschikbaarheidsgroep.

  3. Met de rechtermuisknop op de groep beschikbaarheid van resource in het onderste middelste deelvenster onder het tabblad bronnen en klik vervolgens op Eigenschappen.

  4. Klik op het tabblad afhankelijkheden , de afhankelijkheid van de listener verwijderen en klik op OK.

  5. In het onderste middelste deelvenster onder het tabblad bronnen , klik met de rechtermuisknop de listener, klikt u op Meer acties en klik op toewijzen aan een andere rol.

  6. Klik op het exemplaar van SQL Server FCI in het dialoogvenster Resources toewijzen aan de rol en klik vervolgens op OK.

  7. Selecteer de SQL Server Failover geclusterd exemplaar (SQLFCI) in het venster rollen . In het middelste deelvenster van onder het tabblad bronnen en ziet u nu de nieuwe resource van listener.

Dit zorgt ervoor dat toepassingen die gebruikmaken van de listener kunnen nog steeds met het verbinding maken met het exemplaar van SQL Server die als host fungeert de productiedatabases zonder onderbreking. De oorspronkelijke beschikbaarheidsgroep kan nu worden volledig verwijderd en opnieuw gemaakt. OF de databases en replica's kunnen worden toegevoegd aan de nieuwe beschikbaarheidsgroep.

Belangrijk Nadat de beschikbaarheidsgroep opnieuw gemaakt is, wijzen de listener terug naar de rol van de groep beschikbaarheid. Stel de afhankelijkheid tussen de nieuwe beschikbaarheid groep resource de listener en de poort naar de listener re-ssign:

  1. Failover-clusterbeheer starten en klik vervolgens op functies in het linkerdeelvenster.

  2. In het deelvenster worden de rollen vermeld, klikt u op de oorspronkelijke rol van Failover geclusterde SQL-exemplaar.

  3. In het middelste deelvenster van onder het tabblad bronnen en met de rechtermuisknop op de listener, klikt u op Meer actiesen klik vervolgens op een andere rol toewijzen.

  4. Klik op de beschikbaarheidsgroep opnieuw gemaakt in het dialoogvenster en klik op OK.

  5. Selecteer de nieuwe beschikbaarheidsgroep in het venster rollen .

  6. Klik op het tabblad bronnen ziet u de nieuwe groep voor de beschikbaarheid en de bron van de listener. Klik met de rechtermuisknop op de nieuwe beschikbaarheid groep resource en klik vervolgens op Eigenschappen.

  7. Klik op het tabblad afhankelijkheden , selecteer de listener resource in de vervolgkeuzelijst en klik op OK.

  8. Gebruik Object Explorer verbinding maken met het exemplaar van SQL Server die fungeert als host voor de primaire replica van de nieuwe beschikbaarheidsgroep in SQL Server Management Studio.

  9. Klik op Beschikbaarheid AlwaysOn, klikt u op de nieuwe groep van beschikbaarheid en klik op Beschikbaarheid groep luisteraars. U moet de listener.

  10. Klik met de rechtermuisknop op de listener, klikt u op Eigenschappen, typ het juiste poortnummer voor de listener en klik op OK.

Methode 3: De beschikbaarheidsgroep weghalen en opnieuw maken de beschikbaarheid en de gelijknamige listener-listener

Deze methode heeft tot gevolg dat er een kleine stroomstoring voor toepassingen die momenteel zijn verbonden omdat de beschikbaarheid en listener verwijderd en opnieuw gemaakt:

  1. De van beschikbaarheidsgroep weghalen.

    Opmerking Dit wordt ook de listener neerzetten.

  2. Maak onmiddellijk een van nieuwe, lege beschikbaarheidsgroep met de definitie van de listener op dezelfde server die host is van de productiedatabases. Stel bijvoorbeeld dat uw beschikbaarheid groep wordt 'aglisten'. De volgende Transact-SQL-instructie maakt een beschikbaarheidsgroep met geen primaire of secundaire database, maar maakt ook een listener met de naam 'aglisten'. Toepassingen kunnen deze listener gebruiken om verbinding te maken.

    use mastergo
    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. De beschadigde database herstellen. Vervolgens en de secundaire replica opnieuw toevoegen aan de beschikbaarheidsgroep.


Meer hulp nodig?

Uw vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Microsoft insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagenten.

×