HELP!!! How to clean-up DB on MS SQL 2005 EXPRESS
Hello,
according to solving of http://jazz.net/forums/viewtopic.php?t=9631 (still unresolved :-( ) we tried to switch logging from WARN to DEBUG mode and probably it was reason why DB has started to grow and achieved limit size 4GB. We have found out that it was caused by two tables (in both more then 800.000 rows) REPOSITORY.CHANGE_EVENT REPOSITORY.ITEM_STATES So we have switched logging back to WARN mode and we have deleted all rows which had EVENT_CATEGORY equal to 'SystemLog' from first table and which had ITEM_TYPE_DBID equal to 28 from second one Could it affect somehow Jazz? Is DEBUG log mode the right reason of DB growing? Does there exist another option how to decrease DB size? Thank you in advance David Csikkel Consultant, Tieto |
5 answers
Hello, Hi David I am not sure if removing the entries is good/bad but change_events and item_states sound like things you should NOT be removing. Perhaps someone from the repository team can comment? RTC does a lot of compression internally - so lots of rows in not necessarily occupying a lot of space (I could be completely wrong about these specific entries in the db). Can you run a repository report (it should be one of the Reports in any of your projects) - this should tell you what is using up the space and what the compressed size is. Are you able to move to another database, or get a version of SQL, that does not have the 4GB limit? If you fix the problem today, I suspect you will run out of space at some point - and your problem might be more complicated (there is a lot of real data in the db rather than lots of error message regards anthony |
|
Sorry :-O I missed to note one important thing we reached these 4GB in the short period (2-3weeks) in not often used Jazz server (5 iterations+plans, ~250 work items) without any file in repository and any builds. It points to saving of logging information in DB (according to DEBUG mode and 'System log' value in REPOSITORY.CHANGE_EVENT).
T.Y.I.A David |
Sorry :-O I missed to note one important thing we reached these 4GB in the short period (2-3weeks) in not often used Jazz server (5 iterations+plans, ~250 work items) without any file in repository and any builds. It points to saving of logging information in DB (according to DEBUG mode and 'System log' value in REPOSITORY.CHANGE_EVENT). Wow - that is amazing how quickly it filled up! Let's see what the repo team says. To make sure of this - please raise a defect here on jazz.net. anthony |
Was a work item submitted about this issue? I have a customer encountering the same thing.
Thanks, Gary |
Was a work item submitted about this issue? I have a customer encountering the same thing. Not sure if a defect was raised - but since this thread started, I saw an instance where there were error events being generated - very quickly and for a long time. This caused the DB to fill up. Moving to 2.0.0.2 iFix3 seemed to have solved the problem (originally on 2.0.0.2 - no iFix) anthony |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.