:strip_icc():strip_exif()/u/23158/crop6639d39f6d4f1_cropped.jpg?f=community)
Ik zit met volgend probleem :
De AudEvent tabel in SharedServices1_DB van Sharepoint is om en bij de 150GB groot en bevat 1231273324 records.
Situering en historiek :
Een jaar geleden werd een sharepoint installatie in gebruik genomen, met een aantal BDC applicatie-definities die ook nog eens onmogelijk vaak werden geïndexeerd door Sharepoint Search voor de zoekmotor (ondertussen is deze indexing frequentie aangepast).
In deze applicatie-definities werd destijds jammer genoeg niet aangegeven dat er geen audit mag gebeuren, wat volgens volgende websites de oorzaak zou kunnen zijn van deze enorme aantal records :
http://social.technet.mic...64-473a-8dc5-3daf35d7a280
en
http://social.msdn.micros...b-4508-882e-466371c1a53c/
Ondertussen heb ik de xml-files manueel aangepast en de oude definities vervangen door hun nieuwe versie.
Nu blijf ik echter zitten met een tabel van 150GB groot, waar geen enkele nuttige informatie in terug te vinden valt.
Als ik nakijk of ik deze mag truncaten, dan kom ik ofwel uit bij volgende whitepaper :
http://technet.microsoft.com/en-us/library/cc262731.aspx (waarvan het .doc bestand niet valt te downloaden, misschien bij één van jullie wel, maar mij lukt het niet - ik weet dus niet of er iets nuttig in staat
)
ofwel op een hoop sites die het probleem beschrijven, met de leuke woorden : Microsoft raadt aan om nooit zomaar de log-tabellen te truncaten...
Ik heb reeds op een testmachine met een exacte kopie van de server (VM) een trunc gedaan van de tabel en dat lijkt op zich goed te lopen, maar véél live testen kan ik natuurlijk niet doen op zo'n testmachine.
Heeft iemand van jullie vroeger reeds een gelijkaardige situatie meegemaakt ?
Oja, de functie voor het cleanen van auditlogs in stsadmin werkt niet voor de audevent tabel...
De AudEvent tabel in SharedServices1_DB van Sharepoint is om en bij de 150GB groot en bevat 1231273324 records.
Situering en historiek :
Een jaar geleden werd een sharepoint installatie in gebruik genomen, met een aantal BDC applicatie-definities die ook nog eens onmogelijk vaak werden geïndexeerd door Sharepoint Search voor de zoekmotor (ondertussen is deze indexing frequentie aangepast).
In deze applicatie-definities werd destijds jammer genoeg niet aangegeven dat er geen audit mag gebeuren, wat volgens volgende websites de oorzaak zou kunnen zijn van deze enorme aantal records :
http://social.technet.mic...64-473a-8dc5-3daf35d7a280
en
http://social.msdn.micros...b-4508-882e-466371c1a53c/
Ondertussen heb ik de xml-files manueel aangepast en de oude definities vervangen door hun nieuwe versie.
Nu blijf ik echter zitten met een tabel van 150GB groot, waar geen enkele nuttige informatie in terug te vinden valt.
Als ik nakijk of ik deze mag truncaten, dan kom ik ofwel uit bij volgende whitepaper :
http://technet.microsoft.com/en-us/library/cc262731.aspx (waarvan het .doc bestand niet valt te downloaden, misschien bij één van jullie wel, maar mij lukt het niet - ik weet dus niet of er iets nuttig in staat
)ofwel op een hoop sites die het probleem beschrijven, met de leuke woorden : Microsoft raadt aan om nooit zomaar de log-tabellen te truncaten...
Ik heb reeds op een testmachine met een exacte kopie van de server (VM) een trunc gedaan van de tabel en dat lijkt op zich goed te lopen, maar véél live testen kan ik natuurlijk niet doen op zo'n testmachine.
Heeft iemand van jullie vroeger reeds een gelijkaardige situatie meegemaakt ?
Oja, de functie voor het cleanen van auditlogs in stsadmin werkt niet voor de audevent tabel...
"I think there is a world market for maybe five computers" - Thomas Watson, chairman of IBM, 1943