[MOSS 2007] - Augmentation anormale des bases de contenus
3 réponses
Houdini
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center
- 2 WFE, 1 indexeur, 1 SQL 2005
J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis.
Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 ,
8000) ont été lancés pour tester les points limites entre autres. Cela a eu
pour effet de faire grossir anormalement la base de contenu 12 Go (en prod,
elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les
tables en cause ou les index ? Malgré des sauvegardes régulières (base +
logs) et plan de maintenance (dont reindex).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Houdini
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
Merci de votre aide. Cordialement, Houdini
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été
activées par défaut sur les collections de sites, les tests de charges
n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu
s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog.
Problème résolu. Je vais rajouter des stratégies pour contrôler et
positionner les audits.
Bonne journée à tout le monde.
==========================================
"Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center
- 2 WFE, 1 indexeur, 1 SQL 2005
J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis.
Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 ,
8000) ont été lancés pour tester les points limites entre autres. Cela a eu
pour effet de faire grossir anormalement la base de contenu 12 Go (en prod,
elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les
tables en cause ou les index ? Malgré des sauvegardes régulières (base +
logs) et plan de maintenance (dont reindex).
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
Merci de votre aide. Cordialement, Houdini
Lognoul Marc [MVP]
Bonjour,
Désolé pour le retard dans la réponse, ton post vient juste d'apparaitre.
A l'exception d'un véritable problème, il estxiste en effet 3 fonctionalités qui font croitre les CDB de manière aussi massive: Les audits, comme vous l'avez détéctez vous-même Les recycle bins Les statistiques d'utilisation Le versioning
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Houdini" wrote in message news:
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== > "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
Merci de votre aide. Cordialement, Houdini
Bonjour,
Désolé pour le retard dans la réponse, ton post vient juste d'apparaitre.
A l'exception d'un véritable problème, il estxiste en effet 3 fonctionalités
qui font croitre les CDB de manière aussi massive:
Les audits, comme vous l'avez détéctez vous-même
Les recycle bins
Les statistiques d'utilisation
Le versioning
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Houdini" <Houdini@discussions.microsoft.com> wrote in message
news:5979525A-B684-48DB-9C87-1C2DB142FFA8@microsoft.com...
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été
activées par défaut sur les collections de sites, les tests de charges
n'ayant pas amélioré les choses, la table "AuditData" de la base de
contenu
s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog.
Problème résolu. Je vais rajouter des stratégies pour contrôler et
positionner les audits.
Bonne journée à tout le monde.
========================================== >
"Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center
- 2 WFE, 1 indexeur, 1 SQL 2005
J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100
wikis.
Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 ,
8000) ont été lancés pour tester les points limites entre autres. Cela a
eu
pour effet de faire grossir anormalement la base de contenu 12 Go (en
prod,
elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont
les
tables en cause ou les index ? Malgré des sauvegardes régulières (base +
logs) et plan de maintenance (dont reindex).
Désolé pour le retard dans la réponse, ton post vient juste d'apparaitre.
A l'exception d'un véritable problème, il estxiste en effet 3 fonctionalités qui font croitre les CDB de manière aussi massive: Les audits, comme vous l'avez détéctez vous-même Les recycle bins Les statistiques d'utilisation Le versioning
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Houdini" wrote in message news:
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== > "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
Merci de votre aide. Cordialement, Houdini
Pierre Vivier-Merle \(MVP\)
j'allais le dire !!! bien joué :-)
Cordialement / Regards, Pierre
-------------------------------------------- Pierre Vivier-Merle MVP MOSS 2007 http://blogs.developpeur.org/pierre
"Houdini" a écrit dans le message de groupe de discussion :
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== > "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
Merci de votre aide. Cordialement, Houdini
j'allais le dire !!! bien joué :-)
Cordialement / Regards,
Pierre
--------------------------------------------
Pierre Vivier-Merle
MVP MOSS 2007
http://blogs.developpeur.org/pierre
"Houdini" <Houdini@discussions.microsoft.com> a écrit dans le message de
groupe de discussion : 5979525A-B684-48DB-9C87-1C2DB142FFA8@microsoft.com...
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été
activées par défaut sur les collections de sites, les tests de charges
n'ayant pas amélioré les choses, la table "AuditData" de la base de
contenu
s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog.
Problème résolu. Je vais rajouter des stratégies pour contrôler et
positionner les audits.
Bonne journée à tout le monde.
========================================== >
"Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center
- 2 WFE, 1 indexeur, 1 SQL 2005
J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100
wikis.
Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 ,
8000) ont été lancés pour tester les points limites entre autres. Cela a
eu
pour effet de faire grossir anormalement la base de contenu 12 Go (en
prod,
elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont
les
tables en cause ou les index ? Malgré des sauvegardes régulières (base +
logs) et plan de maintenance (dont reindex).
-------------------------------------------- Pierre Vivier-Merle MVP MOSS 2007 http://blogs.developpeur.org/pierre
"Houdini" a écrit dans le message de groupe de discussion :
Bonjour à toutes et à tous,
Je me réponds à moi-même: toutes les fonctionnalités d'audit ayant été activées par défaut sur les collections de sites, les tests de charges n'ayant pas amélioré les choses, la table "AuditData" de la base de contenu s'est enrichie de plusieurs millions de lignes.
Il existe une commande "stsadm" pour purger cette table: trimauditlog. Problème résolu. Je vais rajouter des stratégies pour contrôler et positionner les audits.
Bonne journée à tout le monde. ========================================== > "Houdini" a écrit :
Bonjour à toutes et à tous,
Dans un environnement de préproduction (x64 - US) HP Blade Center - 2 WFE, 1 indexeur, 1 SQL 2005 J'ai 2 portails (consultation), 12 sites (faible volumétrie) et 100 wikis. Un workflow viendra par la suite.
Différents tests de charges en consultation (quelques users, 100 ,900 , 8000) ont été lancés pour tester les points limites entre autres. Cela a eu pour effet de faire grossir anormalement la base de contenu 12 Go (en prod, elle fait 1,03 Go).
Qu'est-ce qui peut faire grossir démesuément cette base ? Quelles sont les tables en cause ou les index ? Malgré des sauvegardes régulières (base + logs) et plan de maintenance (dont reindex).
