Yes - additional information:
TechNote: http://www-01.ibm.com/support/docview.wss?rs=3488&uid=swg21390701

Jazz.net: http://jazz.net/wiki/bin/view/Main/DatabaseMaintenanceFAQ

Eric.

nedgar a crit :

Can you determine what is causing this growth? Try looking at the
Reports page in the web UI, and examine the Repository reports
'Metrics by Namespace' and 'Latest Metrics by Namespace'.

One common candidate is if large artifacts from builds are published
back to the main server. If this is the case, another option is to
publish links instead.

Change Events are primarity created to track the different events and for sending feeds to the user. For e.g. change events are created when you change a Work item, deliver a change set, change a process specification, create a dashboard, errors or warnings on the server etc.

Change events are automatically deleted after a certain period. The type of change event (change event category) is used to calculate the expiration time of a change event. The tech note http://www-01.ibm.com/support/docview.wss?rs=3488&uid=swg21390701 describes how to scrub the change events in the database.

You might want to run a SQL query to find out the count of different types of change events. This would give you an idea on the type of change events that are present in the database. On DB2, the following query returns the count of every change event category.

db2 "select substr(event_category, 1, 50), count(*) from repository.change_event group by event_category"

--- Balaji
Jazz Server Team

Can you determine what is causing this growth? Try looking at the Reports page in the web UI, and examine the Repository reports 'Metrics by Namespace' and 'Latest Metrics by Namespace'.

One common candidate is if large artifacts from builds are published back to the main server. If this is the case, another option is to publish links instead.

I run the report and find the following data:

Parameters
Namespace:*
(14 items selected)
ItemType:
(56 items selected)
Duration:
Last 3 Months

Footprint:
Attribute:800M-1200M
ChangeEvent:400M-800M

Uncompressed Footprint:
Attribute:800M-1800M
ChangeEvent:400M-800M

Item count:
ChangeEvent:150,000-350,000

State count:
ChangeEvent:150,000-350,000

Can you give me some suggestions to reduce the size of databases?

Can you determine what is causing this growth? Try looking at the Reports page in the web UI, and examine the Repository reports 'Metrics by Namespace' and 'Latest Metrics by Namespace'.

One common candidate is if large artifacts from builds are published back to the main server. If this is the case, another option is to publish links instead.