Schlagwort: corrupt

Kategorien
IT SharePoint

SharePoint: Degradierte Search-Index-Komponente korrigieren

SharePoint Search Service Administration

Es kann manchmal vorkommen, dass eine Index-Partition der SharePoint Search Service Application degradiert, sich also in einem nicht mehr funktionstüchtigen Zustand befindet. Versucht man auf einer SharePoint-Seite dann eine Suche zu starten, wird man von einer Fehlermeldung begrüsst.

Der Administrator sieht dann in der Search Service Administration in der Central Administration ungefähr folgendes Bild:

Degraded SharePoint Index ComponentDas Ausrufezeichen signalisiert direkt, dass etwas nicht in Ordnung ist.

Um das Problem zu lösen, kann es genügen, die Index Component neu zu erstellen. Falls es daran liegt, dass die Disk, auf welcher die Index-Partition liegt, vollgelaufen ist, kann man auch eine zusätzliche Index-Komponente für die Partition auf einer anderen Disk erstellen.

Um eine neue Komponente zu erstellen, muss man PowerShell verwenden. Wie bei allen Änderungen an der Search Topology ist das Vorgehen so, dass man zuerst sich die aktuelle Topologie holt, diese dann klont, am Klon Anpassungen vornimmt und dann den Klon zur aktiven Topologie erklärt. Es ist ausserdem nötig, dass für das Vorgehen eine Index-Partition ohne Fehler vorhanden ist, das heisst, wenn nur eine vorhanden ist und diese einen Fehler hat, müsste man zuerst einen Index Reset machen. Die bestehende Index Component kann nicht entfernt werden, wenn sie die Letzte ist – das heisst, dass man zuerst in einem Durchgang eine neue Index Component hinzufügen muss, dann die Änderungen aktivieren muss und erst in einem zweiten Durchgang kann dann die problematische Komponente entfernt werden.

Hier der PowerShell-Code dazu:

# ----- Teil 1, neue Index-Komponente hinzufügen

# Aktive Topologie holen
$ssa = Get-SPEnterpriseSearchServiceApplication
$active = Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa 

# Einen Klon der aktiven Topologie erstellen
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

# Search Service Instance des Servers "SERVER1" holen (Namen muss natürlich angepasst werden)
$hostServer1 = Get-SPEnterpriseSearchServiceInstance -Identity "SERVER1"

# Neue Index-Komponente erstellen und zum Klon hinzufügen, Ziel-Instanz auf den gewünschten Server konfigurieren
$newIndexComponent = New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostServer1 -IndexPartition 0

# Verzeichnis für Index (auf der vorhin mitgegebenen Instanz (SearchServiceInstance)) einrichten
$newIndexComponent.RootDirectory = "I:\Index"

# Überprüfung der Konfiguration der Komponenten im Klon (muss nun die neue Komponente und auch die alte anzeigen)
Get-SPEnterpriseSearchComponent -SearchTopology $clone

# Den Klon als neue, aktive Topologie aktivieren (Änderungen werden erst jetzt aktiv!)
Set-SPEnterpriseSearchTopology -Identity $clone

# Überprüfung der aktiven Topologie
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# ----- Teil 2, alte Index-Komponente entfernen

# Aktive Topologie neu holen
$active = Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# Einen Klon der aktiven Topologie erstellen
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

# Search Components für die Topologie anzeigen (Component ID der degradierten Komponente kopieren)
Get-SPEnterpriseSearchComponent -SearchTopology $clone

# Index-Komponente (ID hier ersetzen/eintragen) aus der Topologie (Klon) entfernen
Remove-SPEnterpriseSearchComponent -Identity <Component ID> -SearchTopology $clone

# Den Klon als neue, aktive Topologie aktivieren
Set-SPEnterpriseSearchTopology -Identity $clone

# Überprüfung der aktiven Topologie
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# ----- Teil 3, alte Topologie (da nun inaktiv) löschen (wird aktuell noch mit dem Namen '$active' referenziert)
Remove-SPEnterpriseSearchTopology -Identity $active<span style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" data-mce-type="bookmark" class="mce_SELRES_start"></span>

Nun sollte die Search Service Administration wieder eine saubere Topologie ohne Fehlermeldungen anzeigen.

Kategorien
IT SharePoint SQL

Eine „suspect“ Datenbank reparieren

Es ist mir schon passiert, dass ich auf einmal keine SharePoint-Webseite meiner Virtual Machine mehr öffnen konnte. Auch die Central Administration funktionierte nicht mehr. Als Fehlermeldung erschien:

„This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database. To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu…“

Ein Ausführen des SharePoint Products Configuration Wizards war nicht möglich, der Wizard brach nach einigen Schritten ab, mit der Begründung, dass nicht auf die Configuration-Datenbank zugegriffen werden konnte.

Ein Blick in das MSSQL Management Studio zeigte dann, dass die SharePoint-Config-Datenbank im Status suspect, also verdächtig war.

Zum Glück gibt es einen Weg, die Datenbank wieder in einen gesunden Zustand zu bringen, oder zumindest es zu versuchen. Achtung: je nach Schweregrad der zu Grunde liegenden Störung kann es sein, dass bei diesem Vorgang Daten verloren gehen, da hier eine Reparatur der Datenbank mit „REPAIR_ALLOW_DATA_LOSS“ durchgeführt wird.

Via MSSQL Management Studio auf den Datenbankserver verbinden und ein neues Query-Fenster öffnen, danach folgende Zeilen ausführen („DatabaseName“ durch den Namen der „suspect“ Datenbank ersetzen):

EXEC sp_resetstatus [DatabaseName];
ALTER DATABASE [DatabaseName] SET EMERGENCY
DBCC checkdb([DatabaseName])
ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [DatabaseName] SET MULTI_USER

Je nach Grösse der Datenbank, Server-Leistung und Fehler-Anzahl kann der Vorgang zwischen wenigen Sekunden bis hin zu Stunden dauern. Bei mir brauchte es für eine 1 GB grosse Datenbank zum Beispiel ca. eine Minute. Im Ausgabefenster ist ersichtlich, was für Reparaturen vorgenommen wurden und ob diese zu Datenverlust führten.

Nachdem die Operation beendet wurde, kann man versuchen wieder auf die Datenbank zuzugreifen. In meinem Fall konnte ich wieder auf die SharePoint-Central-Administration und die Web-Applications zugreifen.