none
Audit log trimming status "Pausing" RRS feed

  • Question

  • Bonjour à tous,

    Nous travaillons sur un environnement Sharepoint 2010 Standard Edition, Un frontal et un serveur BDD.

    Depuis quelques temps je constate un probleme dont j'ai du mal à comprendre l'origine.

    Tout à commencé lorsque nous avons constaté que le serveur de BDD avait une consommation d'IO disk enormes (environ 6To par jour pour un portail, consulté principalement, par 300 utilisateurs). Bref le volume semblait totalement disproportionné par rapport à l'activitée.

    En regardant de plus prés, ce volume d'IO était de la lecture par le serveur SQL sur la base de contenu qui heberge notre collection de site. Aprés plusieurs heures de recherche j'ai constaté qu'un processus SQL restait dans un état "Suspend" pendant un temps étrangement long, ce processus éxécutait la commande sql "WSS_mabasedecontenu.dbo.proc_GetAuditEntries;1".

    En jetant un oeil sur les job en cours au niveau de la console d'administration de Sharepoint il y avait un job "Audit Log trimming" dans un état "Pausing" depuis pas mal de temps.

    Aprés avoir cherché d'autres pistes j'ai fini par killer le processus sql, et suite à ce kill le job et passé en état "running" et a bien repris son activité (génération de tableau excel à partir des logs). Et tout est redevenu normal au niveau des IO disk (le taux de lecture et repassé à quelques Mo/s).

    Je me suis dis que tout était réglé sauf que le lendemain matin, le taux d'IO en lecture était remonté à > 100Mo/s et le job de nouveau en status "Pausing", nouveau kill => ok.

    Je ne comprend pas pourquoi ce job se bloque dans ce status "Pausing" et pourquoi cet état semble provoquer une boucle quelque part.

    Comment résoudre ce problème ?

    D'avance merci pour votre aide.

    Olivier

    mardi 17 septembre 2013 07:15

Réponses

  • Bonjour Olivier,

    Belle bête ! :)

    Je te colle la partie "intéressante" de mon article cité plus haut :

    Résolution

    La résolution a été de lancer manuellement (et à x reprises) la commande stsadm, mais avec cette fois le paramètre "enddate"  fixé à une date beaucoup + éloignée de la date du jour, afin de purger graduellement.

    Exemple de commande :

    stsadm -o trimauditlog –enddate 20110808 –databasename MOSS_Content_Site1

    En gros, tu purges mais en fixant une date de fin.

    Je ne sais pas s'il y a plus simple, mais dans mon cas j'avais du passer par ce système.

    Détail de la commande : ici !

    • Marqué comme réponse Olivier_1968 jeudi 19 septembre 2013 15:08
    mercredi 18 septembre 2013 07:52
    Modérateur
  • Bonjour Benoit,

    Désolé pour ce retour tardif, mais grace à tes info j'ai pu regler mon probleme.

    Par contre la commande stsadm -o trimauditlog n'existe plus avec Sharepoint 2010 (du moins je n'ai pas trouvé), je donc utilisé la commande powershell suivante :

    $site=get-spsite -identity http://ma_collection_de_site

    $site.audit.DeleteEntries("09/20/13")  => date de purge.

    Et voila, j'ai suprimé 74 millions d'enregistrements dans ma table audit, forcément ça a pris quelques heures.

    Encore merci.

    Olivier

    • Marqué comme réponse Florin Ciuca lundi 30 septembre 2013 18:59
    jeudi 19 septembre 2013 15:20

Toutes les réponses

  • Bonjour,

    Cà me rappelle une douloureuse expérience avec les trims de logs (cf. cet article).

    Du coup ma question : combien de lignes d'audit à purger ?

    mardi 17 septembre 2013 09:51
    Modérateur
  • Bonjour Benoit et merci pour ta réponse.

    J'ai jeté un oeil dans ma base de contenu et si je ne me trompe pas la table AuditData contient :

    74 412 327 enregistrements !!!!  y a t-il un moyen de purger tout ça sans passer par le job de log trimming ? je n'ai pas vraiement besoin des ces informations d'audits qui avaient été positionnée par manque d'expérience sur l'environnement.

    D'avance merci

    Olivier

    mercredi 18 septembre 2013 06:49
  • Bonjour Olivier,

    Belle bête ! :)

    Je te colle la partie "intéressante" de mon article cité plus haut :

    Résolution

    La résolution a été de lancer manuellement (et à x reprises) la commande stsadm, mais avec cette fois le paramètre "enddate"  fixé à une date beaucoup + éloignée de la date du jour, afin de purger graduellement.

    Exemple de commande :

    stsadm -o trimauditlog –enddate 20110808 –databasename MOSS_Content_Site1

    En gros, tu purges mais en fixant une date de fin.

    Je ne sais pas s'il y a plus simple, mais dans mon cas j'avais du passer par ce système.

    Détail de la commande : ici !

    • Marqué comme réponse Olivier_1968 jeudi 19 septembre 2013 15:08
    mercredi 18 septembre 2013 07:52
    Modérateur
  • Bonjour Benoit,

    Désolé pour ce retour tardif, mais grace à tes info j'ai pu regler mon probleme.

    Par contre la commande stsadm -o trimauditlog n'existe plus avec Sharepoint 2010 (du moins je n'ai pas trouvé), je donc utilisé la commande powershell suivante :

    $site=get-spsite -identity http://ma_collection_de_site

    $site.audit.DeleteEntries("09/20/13")  => date de purge.

    Et voila, j'ai suprimé 74 millions d'enregistrements dans ma table audit, forcément ça a pris quelques heures.

    Encore merci.

    Olivier

    • Marqué comme réponse Florin Ciuca lundi 30 septembre 2013 18:59
    jeudi 19 septembre 2013 15:20