Question

J'ai un site d'édition MOSS. Le contenu est assez faible. J'ai remarqué que la taille de la base de données de contenu est maintenant 5GB sans aucun contenu significatif modifications. L'utilisation d'un script pour afficher les tailles des tables, j'ai remarqué que la taille de la table EventCache seule plus de 3,5 Go. Pourquoi est-ce? Quelle est la raison pour ça? Que faire pour réduire la taille?

Était-ce utile?

La solution

avez-vous vérifié les choses suivantes: 1. Avez-vous migré votre contenu DB à partir d'une version précédente (SPS 2003)?    -. Dans ce cas, il peut être parfois les timerjobs pour effacer la table eventcache à sa date expirations ne fonctionne pas bien et les lignes de plus que le nombre défini de jours restant encore dans le tableau

  1. Dans MOSS Sp2 nous avons fixé certaines parties qui provoque également une croissance inattendue des bases de données, mais pas sûr que cela vaut aussi pour la table de eventcache dans certains.

  2. Dans un cas, j'avais, l'espace disque libre sur SQL Server n'a pas assez d'espace pour effectuer la création de la température DB qui est construit au cours de la procédure de eventcache ta ble pour supprimer des lignes expiré. On pourrait comprendre, dans ce cas avec un 75GB DB où eventcache allone Touque 8 Go que nous avions un espace libre d'au sujet 260GB pour effacer le tableau.

  3. Un autre indice peut trouver ici aussi: KB Article: 957691 - Construire 12.0000.6331.5000) "Méthode prise en charge pour effacer la table de EventCache"

Espérons que cela peut vous aider,

Salue, Steve Chen, Support Engineer SharePoint EMEA NMT

Autres conseils

Essayez de changer le nombre de jours pour garder votre journal des modifications et voir si cette table devient plus petit.

En outre, est votre service SPTimer fonctionne correctement avec le compte de domaine correct?

Avez-vous beaucoup d'utilisateurs avec beaucoup d'alertes configuration?

J'ai eu récemment le même problème en raison de la corruption de base de données. Selon ce site , il y a travail du minuteur qui devrait être de supprimer tous les anciens événements, et vous devez vous assurer que ce travail du minuteur « alerte immédiate » est en cours d'exécution.

Vous pouvez vérifier si les anciens événements sont effectivement supprimés en exécutant cette SQL sur votre base de données:

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

Ensuite, assurez-vous qu'il n'y a pas d'événement avec des dates sur une semaine ou deux.

Si vous avez de tels événements, choisir le plus grand ID de la requête ci-dessus, puis exécutez (supposons que l'ID était 8500):

delete from [dbo.EventCache] where id < 8500

Dans mon cas, je reçu une erreur indiquant que la base de données était corrompue (ce qui était la raison pour laquelle j'avais tant de lignes dans ma base de données).

Pour corriger la corruption de base de données SharePoint, vous pouvez exécuter les éléments suivants (Important: Cela peut causer une perte de données):

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

(Ma base de données de contenu a été appelé "WS_CONTENT", le vôtre peut être différent).

Ensuite, exécutez l'instruction « Select » ci-dessus pour vous assurer qu'il n'y a pas trop de lignes, et le cas échéant, de les supprimer.

Licencié sous: CC-BY-SA avec attribution
Non affilié à sharepoint.stackexchange
scroll top