Wat is Waarschuwing: Database <db-naam> is verdacht? Je hebt waarschijnlijk gezien een databases gemarkeerd als verdachte in SSM ‘ s en je weet niet wat het vertegenwoordigt. Lees hieronder artikel om meer informatie over dit te weten te komen!
Wat is Waarschuwing: database db-naam is verdacht?
soms kunnen we geconfronteerd worden met een situatie die kritiek is, omdat onze SQL Server database in verdachte modus gaat. Op dat moment kan de database niet meer worden gebruikt en kan er geen werk meer worden gedaan.
de belangrijkste reden waarom de database in verdachte modus gaat is omdat de primaire bestandsgroep beschadigd is en de database niet kan worden hersteld tijdens het opstarten van de SQL Server.
ook kan de database in de verdachte staat komen om meerdere andere redenen, waaronder:
- een systeemstoring die kan worden veroorzaakt door een onjuist afsluiten van de databaseserver
- een beschadigd logbestand of een beschadigd MDF-bestand
- indien er geen ruimte meer op de schijf is
- SQL Server kan geen roll forward-of rollback-operatie voltooien
- beperkingen in termen van ruimte voor FAT32-bestandssystemen en andere redenen
om de database te herstellen en te herstellen van deze toestand, moet u de volgende stappen te doen:
- We zullen beginnen met het wijzigen van de status van de database door het uitvoeren van de sp_resetstatus opgeslagen procedure
EXEC sp_resetstatus 'TestDB'
- Stel de database van “Nood” – modus
ALTER DATABASE TestDB SET voor NOODGEVALLEN;
- Check de database voor eventuele inconsistenties
DBCC checkdb('TestDB');
- In het geval er fouten optreden tijdens de DBCC fase zet de database onmiddellijk in SINGLE USER MODUS met behulp van de onderstaande query:
ALTER DATABASE TestDB SET SINGLE_USER MET ROLLBACK ONMIDDELLIJKE;
- Ook op dit punt, om veiligheidsredenen raden wij u aan een back-up maken van de database
- Nadat u klaar bent met het maken van een back-up van de database moet u doorgaan naar de volgende query uitvoeren. Maar vergeet niet dat tijdens het gebruik van de volgende query, met de repair_allow_data_loss parameter, u een eenrichtingsoperatie uitvoert die uw database zal repareren, maar alle acties die tijdens dit proces worden gemaakt, kunnen niet worden teruggedraaid. Er is geen oplossing om terug te keren naar een vorige staat van de database, dat is waarom we sterk aanbevelen dat u de back-up die we op het vorige punt voorgesteld
DBCC CheckDB ('TestDB', REPAIR_ALLOW_DATA_LOSS);
- de laatste query die u moet uitvoeren is om de database in te stellen in MULTI USER mode
ALTER DATABASE TestDB set MULTI_USER;
- de laatste stap is om uw database server te vernieuwen en te controleren of de verbinding met uw database werkt. Na dit punt moeten gebruikers de mogelijkheid hebben om verbinding te maken met de database. In het geval er sprake is van verlies van gegevens kunt u de database die u eerder back-up herstellen