A very busy APM database can grow large very quickly. See https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=143000 on what to generally do
This Knowledge Document explains:
1) Why running sqltools did not reduce the DB size.
2) Make suggestions what to do to stabilize the environment for the next 6 months.
3) Explain how to monitor the team center sluggish/no data condition
Release : 10.7.0
Component : APM Agents
We notice that many times the database was undersized or not properly configured. It is very important that we we use ample amount of available resources like RAM for caching underlying data (1GB). One should do health check first to see if database is configured properly. Over a period of time the shared memory gets exhausted thus causing sluggishness and often visible in the investigator as DB Stalls. Queries taking longer durations. This also applies to shared buffers which specifies how much memory is dedicated to the database.
Secondly oversized tables.
These include mostly the AT tables. (AT_EVIDENCES, AT_STORIES) and app map tables such as appmap_vertices, appmap_
Configuring query log will record the lag.
Fetching full map:
Periodic requests for ATC live mode map fetching is of two types, partial and full. Full map is requested requested when the difference between the versions is too large. If there are many changes happening then the version will be always significantly different and therefore full map is always sent. Lengthening the update interval could lead to this problem. This problem is fixed in the later versions.