Industrie und Dienstleistungen
Der ideale Digitalisierungspartner kennt sich nicht nur mit Theorie und Technik, sondern auch mit der Branche seines Kundens aus. In acht Fokusbranchen stellen wir Ihnen ausgewiesene Experten zur Seite, die mit den Prozessen, Prioritäten und Herausforderungen Ihres Fachbereichs vertraut sind.
Kontakt
Fertigungsunternehmen
Seit Langem konzentriert sich proMX darauf, Unternehmen der produzierenden Industrie bei der digitalen Transformation Dynamics 365 zu unterstützen.
Über uns
proMX ist Ihr Digitalisierungs-Partner. Wir helfen Ihnen, die Prozesse Ihres Unternehmens so zu transformieren, dass Sie agiler, effizienter und wettbewerbsfähiger arbeiten können. Als Microsoft-Partner haben wir jahrelange Erfahrung und herausragende Beziehungen.
Mehr über proMX
Unsere Mission
Wir helfen Firmen jeglicher Größe bei der Transformation zu digitalen Unternehmen.
Armin Odorfer
22 Nov 2016 | Aktualisiert am: 16 Dez 2022
Expertenbeiträge | 3 Min. Lesezeit

In einem Datenbanksystem ist es wichtig, dass stets genügend freier Speicher auf der Datenbankpartition vorhanden ist. Neben einem regelmäßigen Datenbank-Backup ist daher auch das Monitoring des freien Speicherplatzes anzuraten.

Läuft die Datenbankpartition voll, versetzt der Microsoft SQL-Server die Datenbank, die nicht mehr vergrößert werden kann, in den Status „Recovery Pending“. Dies bedeutet, dass SQL die Datenbank nicht öffnen und auch die Datenbank-Dateien nicht sperren kann. Der Zustand kann mit einer Datenbank im Offlinemodus verglichen werden.

5
Wenn eine Datenbankpartition voll ist, wird der Status auf „Recovery Pending” gesetzt.

Datenbankreparatur nach „Recovery-Pending”-Status in 9 Schritten

Mit den folgenden Schritten lässt sich eine Datenbank (in diesem Beispiel: MX_MSCRM) in vielen Fällen wieder reparieren:

  1. Vergrößern Sie den freien Speicherplatz.
  2. Legen Sie Backups der Datenbankdateien *.mdf (Primary Data File), *.ndf (Secondary Data Files, falls vorhanden) und *.ldf (Log Files) an.
  3. Versetzen Sie die Datenbank in den Modus „Online”:
    ALTER DATABASE MX_MSCRM SET ONLINE
  4. Lassen Sie CheckDB über die betroffene Datenbank laufen (nur Warnungen).
    DBCC CHECKDB(‚MX_MSCRM‘) WITH NO_INFOMSGS Läuft CheckDB ohne Warnung durch, muss die Datenbank nicht repariert werden. Führen Sie andernfalls Schritt 5 aus.
  5. Versetzen Sie die Datenbank vor der Reparatur in den Einzelbenutzermodus:
    ALTER DATABASE MX_MSCRM SET SINGLE_USER
  6. Anschließend gibt es verschiedene Reparaturmodi. Normalerweise beginnt man mit „REPAIR_REBUILD“:
    DBCC CHECKDB(‚MX_MSCRM‘,REPAIR_REBUILD) Wenn die Reparatur gelingt, kann die Datenbank wieder in den Mehrbenutzermodus versetzt werden (siehe Schritt 9).
  7. Andernfalls folgt der nächste Reparaturmodus „REPAIR_ALLOW_DATA_LOSS“ (bitte beachten Sie, dass hierbei (wie der Name schon sagt) Daten verloren gehen können):
    DBCC CHECKDB(‚MX_MSCRM‘,REPAIR_ALLOW_DATA_LOSS) War die Reparatur erfolgreich, kann die Datenbank in den Mehrbenutzermodus versetzt werden (siehe Punkt 9).
  8. Zuletzt kann man die Reparatur über den „EMERGENCY“-Modus versuchen:
    ALTER DATABASE MX_MSCRM SET EMERGENCY
    ALTER DATABASE MX_MSCRM SET SINGLE_USER
    DBCC CHECKDB (MX_MSCRM,REPAIR_ALLOW_DATA_LOSS) WITH
    NO_INFOMSGS,ALL_ERRORMSGS
  9. Versetzen Sie die Datenbank in den Status „Online“ und aktivieren Sie den Mehrbenutzermodus:
    ALTER DATABASE MX_MSCRM SET ONLINE
    ALTER DATABASE MX_MSCRM SET MULTI_USER Hat alles geklappt, ist nach einem Refresh des Datenbankbaums der Status „Recovery Pending” verschwunden.
6
Nach Durchführung der oben genannten Schritte verschwindet der Status „Recovery Pending“.
 

Erfahren Sie hier mehr zu den SQL-Datenbanken im Status „Recovery Pending“.

Answering