Warum EventCache -Tabellengröße riesig ist

sharepoint.stackexchange https://sharepoint.stackexchange.com/questions/828

  •  16-10-2019
  •  | 
  •  

Frage

Ich habe eine Moss Publishing -Website. Inhalt ist ziemlich klein. Ich habe festgestellt, dass die Größe der Inhaltsdatenbank jetzt 5 GB ohne wesentliche Änderungen inhaltlich ist. Mit einem Skript, um die Größen der Tabellen anzuzeigen, habe ich festgestellt, dass die Größe der EventCache -Tabelle allein über 3,5 GB beträgt. Warum ist das? Was ist der Grund dafür? Was tun Sie dagegen, um die Größe zu reduzieren?

War es hilfreich?

Lösung

Haben Sie die folgenden Dinge überprüft: 1. Haben Sie Ihre Inhalts -DB aus einer früheren Version (SPS 2003) migriert? - In diesem Fall könnte es manchmal sein, dass die Timerjobs die EventCache -Tabelle am Ablaufdatum nicht gut abschneidet und die Reihen älter als die definierte Anzahl von Tagen, die noch in der Tabelle verbleiben.

  1. In MOSS SP2 haben wir einige Teile festgelegt, was auch ein unerwartetes Wachstum von Datenbanken verursacht, sich jedoch nicht sicher ist, ob dies auch für die EventCache -Tabelle in Sicherheit gilt.

  2. In einem Fall, den ich hatte, hatte der kostenlose Diskspace auf SQL Server nicht genügend Platz, um die Erstellung der Temps -DB durchzuführen, die während des Fortschritts von EventCache TA -BLE -Zeilen erstellt wurde. Wir konnten in diesem Fall mit einem 75 -GB -DB herausfinden, bei dem EventCache Allone 8 GB genommen hat, dass wir Platz von etwa 260 GB für die Löschung der Tabelle hatten.

  3. Ein weiterer Hinweis kann auch hier finden: KB Artikel: 957691 - Build 12.0000.6331.5000) "unterstützte Methode zum Löschen der EventCache -Tabelle"

Hoffe das kann dir helfen,

Greets, Steve Chen, Support Engineer SharePoint EMEA GTSC

Andere Tipps

Ändern Sie, wie viele Tage Ihr Änderungsprotokoll beibehalten und feststellen, ob diese Tabelle kleiner wird.

Läuft Ihr Spimer -Dienst auch korrekt mit dem richtigen Domain -Konto?

Haben Sie viele Benutzer mit vielen Benachrichtigungen?

Ich hatte kürzlich das gleiche Problem aufgrund von Datenbankbeschäftigung. EntsprechendDiese Seite, Es gibt einen Timer -Job, der alle alten Veranstaltungen löschen sollte, und Sie sollten sicherstellen, dass dieser Timer -Job "Sofortiger Alarm" ausgeführt wird.

Sie können überprüfen, ob alte Ereignisse tatsächlich gelöscht werden, indem Sie diese SQL an Ihrer Datenbank ausführen:

select top 1000 from [dbo].EventCache order by id desc

Überprüfen Sie dann, ob es keine Veranstaltungen mit Daten über ein oder zwei Wochen gibt.

Wenn Sie solche Veranstaltungen haben, wählen Sie die größte ID aus der obigen Abfrage aus und rennen Sie dann (nehmen wir an, die ID betrug 8500):

delete from [dbo.EventCache] where id < 8500

In meinem Fall erhielt ich einen Fehler, der angab, dass die Datenbank beschädigt war (und dies war der Grund, warum ich so viele Zeilen in meiner Datenbank hatte).

Um die Beschädigung der SharePoint -Datenbank zu beheben, können Sie Folgendes ausführen (wichtig: Dies kann zu einem gewissen Datenverlust führen):

ALTER DATABASE WSS_CONTENT SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('WSS_CONTENT', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE WSS_CONTENT SET MULTI_USER

(Meine Inhaltsdatenbank wurde "WS_Content" genannt, Ihre kann unterschiedlich sein).

Führen Sie dann die obige "Select" -Anweisung aus, um sicherzustellen, dass nicht zu viele Zeilen vorhanden sind, und löschen Sie sie, wenn ja.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit sharepoint.stackexchange
scroll top