Rather surprising DB2 growth
Back in April our DB2 database was around 5GB, and since then has risen to 22GB. In the past couple weeks (at least, I wasn't tracking this before) I've noticed the backup grow by 400MB to 2GB per day:
Jun 18: 16,085,422,080
Jun 19: 16,418,467,840
Jun 23: 18,590,351,360
Jun 25: 19,036,774,400
Jun 26: 20,443,361,280
Jun 27: 22,813,655,040
I don't really see how this kind of growth is possible given we're certainly not checking in 2.5GB of data, nor generating that through builds. Is there something we're doing wrong?
Along a similar track, I've been trying to get incremental backups to work to no avail. In fact, all of the above backups were issued with the "incremental delta" parameter (and the TRACKMOD option was enabled on the database).
Any thoughts along incremental backup?
Jun 18: 16,085,422,080
Jun 19: 16,418,467,840
Jun 23: 18,590,351,360
Jun 25: 19,036,774,400
Jun 26: 20,443,361,280
Jun 27: 22,813,655,040
I don't really see how this kind of growth is possible given we're certainly not checking in 2.5GB of data, nor generating that through builds. Is there something we're doing wrong?
Along a similar track, I've been trying to get incremental backups to work to no avail. In fact, all of the above backups were issued with the "incremental delta" parameter (and the TRACKMOD option was enabled on the database).
Any thoughts along incremental backup?
6 answers
Can you please the Metrics and the Metrics by Namespace reports to single out which part of the DB had grown up:
Here is the Metrics report for jazz.net:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.reports.viewQuery&queryUUID=_doiJkHREEdywet_K-pGQGw&name=Metrics
If you do not see the report for your server, you will need to deploy its template to your server.
Here is the Metrics report for jazz.net:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.reports.viewQuery&queryUUID=_doiJkHREEdywet_K-pGQGw&name=Metrics
If you do not see the report for your server, you will need to deploy its template to your server.
Thanks for your help, it turns out it is, in fact, the build. I hadn't considered that we're posting all artifacts and logs back into the database.
In our particular case we don't need to track all of this in the same database as our source code. Our primary backup concern isn't the history of builds, but due to the number of developers on staff and the frequency of builds we do need to keep the retained build count rather high.
Is there a way to separate the build storage from the rest? Or tell DB2 to ignore those tables?
In our particular case we don't need to track all of this in the same database as our source code. Our primary backup concern isn't the history of builds, but due to the number of developers on staff and the frequency of builds we do need to keep the retained build count rather high.
Is there a way to separate the build storage from the rest? Or tell DB2 to ignore those tables?
> Is there a way to separate the build storage from the rest? Or tell DB2 to
> ignore those tables?
This is a great question, we should have this documented more clearly somewhere else. First, build results can be deleted from the repository, so if you've found the database has swelled, you can delete builds to get back to a sane state.
Additionally, what we do internally is to store only a small amount of critical data in the actually repository (eg, compile results, junits, some debug files) and we keep all the actual build output (product files) on storage servers which run a simple web app that can serve up URLs. The build results simply refer to the files by URL and they can be accessed from the build result, but not store in the repository.
Hope this helps.
Jean-Michel
> ignore those tables?
This is a great question, we should have this documented more clearly somewhere else. First, build results can be deleted from the repository, so if you've found the database has swelled, you can delete builds to get back to a sane state.
Additionally, what we do internally is to store only a small amount of critical data in the actually repository (eg, compile results, junits, some debug files) and we keep all the actual build output (product files) on storage servers which run a simple web app that can serve up URLs. The build results simply refer to the files by URL and they can be accessed from the build result, but not store in the repository.
Hope this helps.
Jean-Michel
Fortunately we've now discovered the distinction between artifactFilePublisher and artifactLinkPublisher. The former does drop everything into the database, the latter does not.
Feature request: allow the artifactLinkPublisher to upload the file to a Jazz webserver-accessible location from which the files can be served.
Thanks for the help guys.
Feature request: allow the artifactLinkPublisher to upload the file to a Jazz webserver-accessible location from which the files can be served.
Thanks for the help guys.
Fortunately we've now discovered the distinction between artifactFilePublisher and artifactLinkPublisher. The former does drop everything into the database, the latter does not.
Feature request: allow the artifactLinkPublisher to upload the file to a Jazz webserver-accessible location from which the files can be served.
Thanks for the help guys.
Hi Sterling
Feel free to add this feature request here:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=jazz.viewPage&id=com.ibm.team.workitem
then you can track the discussion. If you post the work item number or web link in this forum, that would be useful too.
anthony